Open Bug 1330245 Opened 7 years ago Updated 2 years ago

application/x-www-form-urlencoded parser should not strip BOM

Categories

(Core :: DOM: Core & HTML, defect, P3)

defect

Tracking

()

People

(Reporter: annevk, Unassigned)

Details

See https://github.com/w3c/web-platform-tests/pull/4517 for tests. (The other problem seen in those tests is that we don't properly detect EOF, but I think that's a known issue with the encoding library.)
Henri, do you know where the code that handles this lives?
Flags: needinfo?(hsivonen)
(In reply to Andrew Overholt [:overholt] from comment #1)
> Henri, do you know where the code that handles this lives?

http://searchfox.org/mozilla-central/source/intl/uconv/nsUTF8ToUnicode.cpp#324

That is, uconv always removes the BOM when decoding UTF-8. (encoding_rs has entry points with all the BOM handling policies that the spec requires.)
Flags: needinfo?(hsivonen)
Given encoding_rs' "someday soon" landing in Gecko I'm tempted to wontfix this. Henri/Anne, WDYT?
Flags: needinfo?(hsivonen)
Flags: needinfo?(annevk)
Even if we landed that, presumably we'd still need to make it do the correct thing for application/x-www-form-urlencoded. That is, an initial landing of that code presumably wants to preserve the same behavior as much as possible. So I think we still want this bug for tracking purposes.
Flags: needinfo?(annevk)
OK, cool.
Priority: -- → P3
I agree with annevk. Let's leave this open as a reminder to make this work right once encoding_rs lands.
Flags: needinfo?(hsivonen)
Component: DOM → DOM: Core & HTML
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.