Re: [Jetty-support] Re: HttpResponse cookie encoding

[Chris H. <ch...@ha...>]

Embedded comments...

Chris Haynes


"Tony Thompson" commented


> The cookie is being shared with an IBM WebSphere server which apparently
> doesn't like the %20.  I don't see a reason why it wouldn't handle %20
> like it does any other encoded character so, I agree on that part.  I
> just thought that if cookie values are supposed to follow URL encoding
> rules,

Where do you get that supposition from?

I've checked RFC2965 (on Cookies) and RFC 2616(HTTP 1.1), which RFC2965
references for the definitions of 'token' and 'token-string', which are the
alternate constructs for a Cookie 'value'.

'quoted-string' appears to me to permit literal space characters between the
quotes.

'token' permits a simple two-character \CHAR escape mechanism, but has no
reference at all to the use of %hh encoding, or to the use of '+' to represent
space, that I can find.

These two (%hh and '+' ) belong to URL encoding space, but that's nothing to do
with cookies.

I think you are in uncharted territory when you do cross-server cookies -
Cookies are specified on the assumption that the semantics of the value string
are private to the server which sets them and gets them back. I'm curious to
know in what sense WebSphere 'doesn't like the %20'.  Do you mean it takes
exception to the characters themselves, or just that it does not convert them
back into a space, as you would desire?

I don't believe that _any_ encoding scheme is specified _anywhere_ for cookie
values.  Greg made a design decision to use a %hh system which would be
transparant to an application, but this assumes the string is encoded / decoded
by Jetty.

WebSphere may not provide any encoding at all, or may use something completely
different.


> a space is supposed to be '+'.

Not  AFAIK in this context. And BTW, I don't the believe the '+' convention is
specified anywhere in the URL RFCs, or anywhere else under IETF control. It's
occurs only in the W3C HTML specification (where it does not, architecturally,
belong - but then that's the Internet for you!).

If you _need_ to get a space character (or anything else that is
non-alphnumeric) through the cookie system, is there a problem with using a
quoted string?  I don't know what generation of browsers started supporting
them.

If I were faced with this problem I think I would do the encoding / decoding
myself in the application, asking the cookie itself (and the server technology)
to handle only the most simple of characters (i.e. those that are permitted by
the earliest browsers).. That's the _only_ way I think you can guarantee to get
cross-server cookie operation.

>
> Tony
>
> >>> gr...@mo... 02/24/05 05:22PM >>>
> Tony Thompson wrote:
> > There may be an issue with cookie encoding in Jetty 4 (not sure if it
> is
> > fixed in Jetty 5).  When Jetty encodes a cookie value that is sent
> back
> > to the client, if that cookie value has spaces in it, Jetty is
> encoding
> > them as %20.  I think that should be encoded as a '+' instead of
> %20.
>
> Well this is not really well specified.  With any version of cookies
> that
> have a good spec, then the value can be quoted.   But in order to
> support
> older cookie versions, Jetty does an encoding for spaces as quotes are
> not supported.
>
> You can try setting the cookie version if you think your browser are
> not
> ancient.
>
> Note that the %20 should not be a problem, unless you are sharing
> cookies
> with another server.
>
> cheers
>