Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Sender: Jeremy Boynes <jeremy@boynes.com>
From: Jeremy Boynes <jboynes@apache.org>
Content-Type: multipart/signed;
 boundary="Apple-Mail=_EFC6D234-2639-41B6-9366-FC84DAA90A89";
 protocol="application/pgp-signature"; micalg=pgp-sha512
Message-Id: <1D0E8E98-EDF2-4564-8E4F-BB2DD2143462@apache.org>
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
Subject: Re: 8-bit text in cookie values
Date: Wed, 1 Jan 2014 10:18:23 -0800
References: <20131223191536.2AD9E23888D7@eris.apache.org>
 <52B961ED.604@apache.org> <75C80731-666D-45CD-A4B8-935F32AA16B4@apache.org>
 <52BC0933.7060807@apache.org>
 <8E981F81-6988-446C-8725-B6272F110C49@apache.org>
 <52C4498B.1050207@apache.org>
To: Tomcat Developers List <dev@tomcat.apache.org>
In-Reply-To: <52C4498B.1050207@apache.org>

--Apple-Mail=_EFC6D234-2639-41B6-9366-FC84DAA90A89
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

On Jan 1, 2014, at 8:59 AM, Mark Thomas <markt@apache.org> wrote:

> Signed PGP part
> On 26/12/2013 19:23, Jeremy Boynes wrote:
> > On Dec 26, 2013, at 2:47 AM, Mark Thomas <markt@apache.org> 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 =3D=3D
> >>> 0 where Netscape=92s rather than RFC2109=92s syntax applies (per
> >>> the Servlet spec). The Netscape spec is vague in that it does
> >>> not define =93OPAQUE_STRING" at all and defines =93VALUE=94 as
> >>> containing equally undefined =93characters=94 although
> >>> historically[1] those have been taken to be OCTETs as permitted
> >>> by RFC2616=92s =93*TEXT=94 variant of =93field-content.=94 The =
change
> >>> will continue to reject these characters in names and in
> >>> unquoted values when version !=3D 0 (RFC2109=92s =93word" rule)
> >>>
> >>> [1] based on comments by Fielding et al. on http-state and
> >>> what I=92ve seen in the wild
> >>
> >> Can you provide references for [1]?
> >
> > This is the mail in the run up to RFC6265 that triggered the
> > discussion:
> > =
http://www.ietf.org/mail-archive/web/http-state/current/msg01232.html
>=20
> Thanks
> >
> for that reference. What a complete mess. RFC6265 really
> dropped the ball on this. The grammar for cookie-value is a disaster.
> So far the issues include:
> - no support for 0x80 to 0xFF
> - no support for \" sequences
> - no support for using whitespace, comma, semi-colon, backslash
>=20
> I was beginning to think that factoring out the cookie generation /
> parsing and then providing different implementations (one for Netscape
> + RFC2109 - roughly what we have now with a few fixes, one for RFC6265
> and maybe one very relaxed) would be the way to go. Having looked at
> the first issue that plan already looks like it needs a re-think.
>=20
> I'm still hoping that by documenting all the various issues in one
> place we will be able to come up with a solution that both addresses
> all the issues you have raised and is better than the handful of
> system properties we have currently.

I think they did a reasonable job given the mess cookies are in the wild =
today. They summarize this in the preamble:
> The recommendations for cookie generation provided in Section 4 =
represent a preferred subset of current server behavior, and even the =
more liberal cookie processing algorithm provided in Section 5 does not =
recommend all of the syntactic and semantic variations in use today.

Section 4 recommends guidelines for servers generating cookies. I =
interpret that as being =93if you follow these guidelines, you have a =
good chance of actually getting back the value you tried to set.=94 The =
rules above (no 8-bit, no escaping, no Netscape delimiters) reflect that =
principle. A server application can step outside those guidelines but =
"thar ther be dragons."

=97
Jeremy


--Apple-Mail=_EFC6D234-2639-41B6-9366-FC84DAA90A89
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJSxFvwAAoJEKVK0I6noCM8PWoIALmTjRhXCPMmuoT6VJbpRfn8
LAQAiidHscwnU26VQN3zhb3bqCARZ68tEGfcR1PQJnZISrkvPsou+Xuxn2kLnS6w
/oOtOl0Gig8mY6mc8yIWmJclt0hwGvJZzYOKq0S9Wv2o7C6h4A5ihnueKQZLNZuL
pL+CSdvKZXR2OCxHi0ZqPvuKHspsDbkh38hRlrlpfnB+IlKXPuYGPOOOEaWR5rYe
v5+10epzZpvkgktaqBuiX//w5FAzawTQ8/FIK+rCQx0680jw4SUvGs7HpBl2xFnq
xuPwquRD0ObW3NrdmfLlBYIcm1FKuJpZVpwIyE6HopSTS5h2Fkb9VZU6ut8QNew=
=2am/
-----END PGP SIGNATURE-----

--Apple-Mail=_EFC6D234-2639-41B6-9366-FC84DAA90A89--