[Webkit-unassigned] [Bug 87351] [BlackBerry] Cookie and Location header should be converted to latin-1/utf-8 in the same place.

[bugzilla-daemon at webkit.org]

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


Joe Mason <jmason at rim.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[BlackBerry] We should do   |[BlackBerry] Cookie and
                   |the latin1/utf8 check for   |Location header should be
                   |all headers not cookies     |converted to latin-1/utf-8
                   |only.                       |in the same place.
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |




--- Comment #8 from Joe Mason <jmason at rim.com>  2012-05-25 07:35:51 PST ---
Disagree.  We already have a check that converts an entire Cookie header (but not Set-Cookie) to UTF-8 or Latin-1 depending on contents, in ResourceRequestBlackBerry, and a different check that does the same conversion for Location headers, in NetworkJob.  If we're going to keep the Cookie check, we should at least merge this code to do the checks in the same place using the same method.

Or if what Adam says is true, we need to fix the Cookie check to only work on part of the header at a time.  But I argue that it's not important:

(In reply to comment #6)
> http://tools.ietf.org/html/rfc6265 specifies how to process the Cookie and Set-Cookie headers.  It's not correct to decode the whole header value as UTF-8.  The correct way to process the header as ASCII and then to use UTF-8 to decode portions of the header.

ASCII is a subset of UTF-8, so I don't see the difference between processing it as ASCII and then using UTF-8 to decode bytes which are not valid ASCII, and just decoding as UTF-8.

All it says in RFC6265 is:

   NOTE: Despite its name, the cookie-string is actually a sequence of
   octets, not a sequence of characters.  To convert the cookie-string
   (or components thereof) into a sequence of characters (e.g., for
   presentation to the user), the user agent might wish to try using the
   UTF-8 character encoding [RFC3629] to decode the octet sequence.
   This decoding might fail, however, because not every sequence of
   octets is valid UTF-8.

Which implies that we can decode the whole header as UTF-8.  This contradicts the BNF, in fact, which defines cookie-octet to only allow ASCII, but some sites do send UTF-8 and others send Latin-1, so we have to deal.

It's possible that some of the components of a Set-Cookie header, like the domain, should cause the cookie to be rejected if they're not plain ASCII, but we're not doing this check for Set-Cookie (yet?)

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.