Re: Please look at me.I'm serious: POSSIBLE BUG?:: RE: Problem Se tting Cookies

[Ed Abrams <Ed...@trellix.com>]

Hello,

Here is a message that might not have made it to the list, with a very good
reply by Marius.  I'm eager to hear from Craig, because I think that the
FIXME message from CRM is from him!

Thanks, :)

Eddie
eda@trellix.com

-----Original Message-----
From: Marius Sorin Barduta [mailto:marius@necomm.ro]
Sent: Thursday, June 08, 2000 1:58 PM
To: Ed Abrams
Subject: Re: Re: Please look at me.I'm serious: POSSIBLE BUG?:: RE:
Problem Setting Cookies


Hello Ed,

>First off, let me say that I think that this feature *SHOULD*
> be allowed, as I can think of many situations in which it would be very
> useful to set state in a browser before having that browser relocated.
> Furthermore, I can see no possible security implications that are not
> already implied by cookies in general.

I agree with you. In fact we relied on this behaviour when using JServ just
to found it is broken when moved code to Tomcat.

>  Finally, if the specification says
> nothing, then I am absolutely inclined to think that this behavior should
be
> allowed in Tomcat code, because I have verified that all 4.0+ generation
> browsers in the mainstream (i.e., Netscape, IE and Opera) do in fact read
> and respond to headers sent in redirections.
>
> Article A seems to be completely neutral with respect to the topic of the
> reset of the response header under a redirection circumstance.
>
> Article B implies that the cookie header should be left in on a redirect:
> "Servers may return a Set-Cookie response header(sic: s) with any
response."
> If the server is allowed to do this, then Tomcat code should not prevent
it.

Well, to be precise we should recall what "may" means in RFCs. So, from RFC
2119 we find that:

<!--StartFragment-->

5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

<!-- EndFragment -->

So, "Servers may return a Set-Cookie response header with any response." is
interpreted like "It is optional for a server to return a Set-Cookie
response header etc etc".
So far, it seems to me that Tomcat does not broke any standard other than a
"de facto" one.

> Article C illustrates the real security issues with cookies, and as far as
I
> can tell, none of these are relevant to the cookie being in a redirect
> reponse header.

I agree again.

> Which brings me to Article D, the code with the cryptic but suggestive
> 'FIXME' line.  Clearly, the author thought something was broken here.  But
> what?  What did the author want this method to do?  Why are we going to
> reset *every* response but an *unauthorized* one?

I think that the session cookie (JSESSIONID) is treated differently because
reset() from HttpServletResponseFacade
is a wrapper for a Response.reset()
Below is the code for the ResponseImpl which, I think, is the implementation
for the Response interface:
As you can see, it seems that only the userCookies get wiped out.


 public void reset() throws IllegalStateException {
 // Force the PrintWriter to flush its data to the output
        // stream before resetting the output stream
        //
         userCookies.removeAllElements();  // keep system (session) cookies
         contentType = Constants.DEFAULT_CONTENT_TYPE;
        locale = new Locale(Constants.LOCALE_DEFAULT, "");
        characterEncoding = Constants.DEFAULT_CHAR_ENCODING;
         contentLength = -1;
         status = 200;

 if (usingWriter == true && writer != null)
     writer.flush();

 // Reset the stream
 out.reset();

        // Clear the cookies and such

        // Clear the headers
        if( notIncluded) headers.clear();
    }

> If we knew what the intended spec here was, we could FIXYOU. :)

Yeah :-)
BTW, why haven't you sent the message to the tomcat-user list (not only to
me)?


Keep in touch,
Marius

Re: Please look at me.I'm serious: POSSIBLE BUG?:: RE: Problem Setting Cookies

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Ed Abrams wrote:

> Hello,
>
> Here is a message that might not have made it to the list, with a very good
> reply by Marius.  I'm eager to hear from Craig, because I think that the
> FIXME message from CRM is from him!

Trying to catch up on > 1500 messages because of JavaOne :-(

The call to reset() was originally added, incorrectly, as a bug fix just before
Tomcat 3.1 final was released.  Among other things, it has the nasty side effect
of wiping out any headers and cookies you might have set prior to doing a
sendRedirect().

I am about to commit a patch that I thought I had done quite a while ago,
changing this to call response.resetBuffer() instead.  This is the correct
behavior -- only the data content buffered by the servlet should be erased, not
the headers.  It will show up in tonight's nightly build of Tomcat.

>
> Thanks, :)
>
> Eddie
> eda@trellix.com
>

Craig