--

Thanks, Chris. JServ is url-decoding the cookie values
in JServUtils line 172.  This, I think, is a bug since, as you say,
the Netscape cookie spec does not require that cookies be
url-encoded (it recommends only). A lot of other CGI apps and
other app servers do not encode the cookie values so servlets
break using JServ when they need to interoperate with
legacy apps.

It would be fine if it was only my own servlets that generated
the cookies, since I could URLEncode them before adding
them to the response. But I have to work with some legacy
apps that do not do this.

I guess I'll have to patch JServ...

Thanks,
- Claude

At 07:11 PM 7/11/99 -0700, you wrote:
>--
>
>Since no one has stepped forward on this --
>
>The current JServ implementation has got to be wrong, because of what
>you describe: it's easy to not get back what you write into a cookie.
>If it's not a bug, I'd like to see the explanation.
>
>How to fix it is not quite so clear.
>
>Neither the Cookie spec (RFC 2109) nor any of the Servlet specs say
>whether cookie names or values should be encoded in any way, whether
>URLEncoding or something else.
>
>This creates a bit of dilemma for the implementor. Not all characters
>can be part of a header, and cookie names and values appear in Cookie:
>headers. This seems to be true even if the browser accepts
>quoted-strings for the values.
>
>The argument in favor of encoding is that all names and values are legal
>that way, and you get back what you write into a cookie.
>
>The argument against encoding is that you might care what the browser
>actually sends the server. Cookies can apply to a whole server, even a
>whole domain, and you might want to interoperate with existing CGIs Perl
>server code, etc.. To interoperate, you pretty much have to not encode
>the values. In this case there's no guarantee that your cookies will be
>accepted or understood by the browser. From this point of view,
>URLEncoding seems rather heavy-handed even if it's documented behavior
>for servlets.  Browsers accept a superset of what RFC 2109 allows, for
>example "=" in cookie values from Yahoo.
>
>One might try to balance these approaches by URLEncoding all characters
>not legal in cookie names and values in RFC2109. This would always give
>you back what you write into a cookie, and would be relatively
>interoperable, and would give you a quiet warning if you look at an
>actual cookie value created from illegal characters.
>
>Comments?
>--
>Cris Perdue
>Impact Online, Inc.
>http://www.volunteermatch.org
>
>
>
>
>--
>--------------------------------------------------------------
>To subscribe:        [EMAIL PROTECTED]
>To unsubscribe:      [EMAIL PROTECTED]
>READ THE FAQ!!!!     <http://java.apache.org/faq/>
>Archives and Other:  <http://java.apache.org/main/mail.html/>
>Problems?:           [EMAIL PROTECTED]



--
--------------------------------------------------------------
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]
READ THE FAQ!!!!     <http://java.apache.org/faq/>
Archives and Other:  <http://java.apache.org/main/mail.html/>
Problems?:           [EMAIL PROTECTED]

Reply via email to