tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <>
Subject Re: 8-bit text in cookie values
Date Thu, 26 Dec 2013 19:23:29 GMT
On Dec 26, 2013, at 2:47 AM, Mark Thomas <> wrote:

Focusing on the 8-bit issue address by the patch, leaving the other RFC6265 thread for broader
discussion ...

>> The change only allows these characters in values if version == 0
>> where Netscape’s rather than RFC2109’s syntax applies (per the
>> Servlet spec). The Netscape spec is vague in that it does not
>> define “OPAQUE_STRING" at all and defines “VALUE” as containing
>> equally undefined “characters” although historically[1] those have
>> been taken to be OCTETs as permitted by RFC2616’s “*TEXT” variant
>> of “field-content.” The change will continue to reject these
>> characters in names and in unquoted values when version != 0
>> (RFC2109’s “word" rule)
>> [1] based on comments by Fielding et al. on http-state and what
>> I’ve seen in the wild
> Can you provide references for [1]?

This is the mail in the run up to RFC6265 that triggered the discussion:

The relevant bit was:
> Changing the ABNF
> to include base64 does not do that -- it is just another
> fantasy production that differs from all prior specs of
> the cookie algorithm.  Changing it to
>  cookie-value      = %x21-2B / %x2D-3A / %x3C-7E / %x80-FF
> or just the minimum
>  cookie-value      = %x21-2B / %x2D-3A / %x3C-7E
> returns the definition to the original Netscape spec (at
> least in the first case), reflects how they are implemented
> on the Internet, and eliminates this artificial distinction
> between the server and user agent requirements.

with the observation that the rule including %x80-ff was the one matching the Netscape spec.
The RFC6265 editor actually chose the latter production which led to the following exchange
asserting that the support for 8-bit characters implied by *TEXT was implicit in the original
Netscape spec.

In this message:
Roy asserts that the
  cookie-value      = %x21-2B / %x2D-3A / %x3C-7E / %x80-FF
production would be needed to support cookies currently in the wild, including the issue with
the __utmz cookie that I’ve seen.

Further discussion resulted in the final production:
 cookie-value      = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
 cookie-octet      = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
                       ; US-ASCII characters excluding CTLs,
                       ; whitespace DQUOTE, comma, semicolon,
                       ; and backslash

on the basis that setting headers with the top bit set was deemed a bad idea by httpbis (I
don’t have a reference for that). It was noted though that conformance to this was qualified
by "Servers SHOULD NOT send Set-Cookie headers that fail to conform to the following grammar”
which discourages 8-bit values but still allows them to be sent and means that parsers receiving
a cookie value need to be prepared to handle them.

Given cookies with these values may be set by other servers in the domain and are sent by
user agents, failing hard as we do now prevents the application handling the request at all.
The patch tolerates those characters and lets them through to the application. I don’t know
of any security issue there given they are being decoded as ISO-8859-1 rather than UTF-8.
I believe it’s backwards compatible in that the consequence to the application is that it
will now see the request with a cookie that it either expects or that it would be ignoring
anyway (on the basis that the cookie would be present if it didn’t have an 8-bit character).

The patch does not change the generation behaviour so any attempt to set a V0 cookie value
containing one of these characters will still cause an IAE from HttpServletResponse#addCookie().


View raw message