MIME type parsing: backslash |
||||||||
Issue descriptionA document labeled as text/html;charset="\g\b\k" ends up with the "default" encoding, rather than GBK. This is wrong per HTTP and per the specification I'm working on that's a bit more tolerant than HTTP to accept cases such as text/html; More context: https://github.com/whatwg/mimesniff/issues/38.
,
Oct 17 2017
@ annevankesteren: Could you please let us know is there any consistent repro steps available to check this issue from Chrome-TE end? Is this issue specific to documentaion?
,
Oct 22 2017
What is Chrome-TE? I've a test for this as part of https://github.com/w3c/web-platform-tests/pull/7764 which should make it easy to reproduce.
,
Oct 22 2017
Thank you for providing more feedback. Adding requester "divya.padigela@techmahindra.com" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 1 2017
Unable to test this issue from TE-End, hence adding TE-NeedsTriageHelp label for further triage
,
Mar 21 2018
,
Apr 4 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/aada226a0736b5be07a9ae849effa4d48e394abe commit aada226a0736b5be07a9ae849effa4d48e394abe Author: Matt Menke <mmenke@chromium.org> Date: Wed Apr 04 08:40:38 2018 Rework Content-Type parsing code to more closely resemble spec. This aligns behavior more closely FireFox, though less closely with Edge and Safari. See RFC at https://mimesniff.spec.whatwg.org/ (This behavior is also more consistent with https://tools.ietf.org/html/rfc7231#section-3.1.1.1) In particular, no longer split the string around semi-colons first, but instead parse character-by-character (Which only really affects weird things like charset=";"), and use backslash as an escape character in quoted string values. This affects both charset and boundary parameters, so we should keep an eye out for bug reports about either of those breaking in corner cases. This also applies the quoted string parsing logic to Content-Type boundary parameters (It was just used for charsets before) - this is unlikely to break anything, since the one consumer of that field arbitrarily removes all leading/trailing spaces and quotes from boundary strings. Bug: 774429 Change-Id: I28c9c035e1c1c28e181bd0e8005266cfd63af7e9 Reviewed-on: https://chromium-review.googlesource.com/990995 Commit-Queue: Matt Menke <mmenke@chromium.org> Reviewed-by: Bence Béky <bnc@chromium.org> Cr-Commit-Position: refs/heads/master@{#548008} [modify] https://crrev.com/aada226a0736b5be07a9ae849effa4d48e394abe/net/http/http_util.cc [modify] https://crrev.com/aada226a0736b5be07a9ae849effa4d48e394abe/net/http/http_util.h [modify] https://crrev.com/aada226a0736b5be07a9ae849effa4d48e394abe/net/http/http_util_unittest.cc [modify] https://crrev.com/aada226a0736b5be07a9ae849effa4d48e394abe/third_party/WebKit/LayoutTests/external/wpt/mimesniff/mime-types/charset-parameter.window-expected.txt
,
Apr 4 2018
,
Jul 6
,
Jul 6
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by ajha@chromium.org
, Oct 17 2017