On Dec 24, 2013, at 2:29 AM, Mark Thomas <ma...@apache.org> wrote: > On 23/12/2013 19:15, jboy...@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
signature.asc
Description: Message signed with OpenPGP using GPGMail
