[Webkit-unassigned] [Bug 178257] Content-Type parameter value parsing: backslash

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Oct 24 12:53:26 PDT 2017


https://bugs.webkit.org/show_bug.cgi?id=178257

Keith Rollin <krollin at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |krollin at apple.com

--- Comment #9 from Keith Rollin <krollin at apple.com> ---
<rdar://34980046> ended back up with us. This seems appropriate, since WebKit is what parses the HTTP headers. As noted in the radar, the networking layer doesn't look at this.

Copying my radar comment here for visibility, since I don't think Anne sees those through bugs.apple.com.

----------

See also <https://bugs.webkit.org/show_bug.cgi?id=178257>. Alexey advised Anne to post to bugs.apple.com, which caused it to end up here.

Per that bug and the GitHub issue, it sounds like this overall concerns adherence to <https://encoding.spec.whatwg.org/#concept-encoding-get>. I think Anne saying that we don’t follow it correctly. On the other hand, from our source code (ParsedContentType.cpp, assuming that’s the right file), it looks like we follow <http://tools.ietf.org/html/rfc2045#section-5.1> closely.

rfc2045 lays out the rules for parsing Content-Type. But it refers to a “quoted string”, which is not defined, other than to mention that it begins and ends with quotes, which are not part of the final value. >From that, it looks like we don’t do anything to treat the contents specially other than to consider the two characters — \” — as part of the content rather than a delimiter. That is, any slash and the character following it are included in the final value.

However, <https://tools.ietf.org/html/rfc7230#section-3.2.6> does provide a definition of quoted string:

   “A string of text is parsed as a single value if it is quoted using
   double-quote marks.
   …
   “The backslash octet ("\") can be used as a single-octet quoting
   mechanism within quoted-string and comment constructs.  Recipients
   that process the value of a quoted-string MUST handle a quoted-pair
   as if it were replaced by the octet following the backslash.”

So perhaps we’re not following this part of the HTTP spec.

Note that ParsedContentType.cpp was checked-in in r86289 in 2011, and so is definitely a pre-existing condition. Lowering priority based on the age of this issue.

I’m not sure who should handle this. The code was checked in from someone on the Chromium team. Starting with Geoff’s group.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20171024/68b89254/attachment.html>


More information about the webkit-unassigned mailing list