From: Chris H. <ch...@ha...> - 2005-02-27 06:28:14
|
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 > |