tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject 8-bit text in cookie values, was: svn commit: r1553187
Date Tue, 24 Dec 2013 18:06:21 GMT
On Dec 24, 2013, at 2:29 AM, Mark Thomas <markt@apache.org> wrote:

> On 23/12/2013 19:15, jboynes@apache.org wrote:
>> Author: jboynes
>> Date: Mon Dec 23 19:15:35 2013
>> New Revision: 1553187
>> 
>> URL: http://svn.apache.org/r1553187
>> Log:
>> fix #55917 by allowing 8-bit ISO-8859-1 characters in V0 cookie values
> 
> -1 (veto)
> 
> The Tomcat community has (to date) always taken the view that cookie
> headers should be restricted (as per RFC2616 section 4.2) to
> "combinations of token, separators, and quoted-string".
> 
> That does not permit 0x80 to 0xFF in tokens.

I thought the V2 patch had addressed your concern about limiting cookie names to tokens so
went ahead and applied it. 

RFC2616 4.2 defines “message-header” as
message-header = field-name ":" [ field-value ]
       field-name     = token
       field-value    = *( field-content | LWS )
       field-content  = <the OCTETs making up the field-value
                        and consisting of either *TEXT or combinations
                        of token, separators, and quoted-string>

where TEXT is defined in 2.2 as
       TEXT           = <any OCTET except CTLs,
                        but including LWS>

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)

I don’t want to proliferate them but would it help to add another system property gating
this behaviour? Perhaps with 3 values: “reject” (the default, causing an IAE as now),
“skip” (logged but not returned to the application), and “allow” (returned to the
application).

Thanks
Jeremy

[1] based on comments by Fielding et al. on http-state and what I’ve seen in the wild

Mime
View raw message