tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: Bug 4690: sessions not scoped according to spec section 7.3
Date Tue, 12 Oct 2004 06:05:47 GMT
Nick Lothian wrote:

>>It should be extremely obvious that your little scheme relies only on 
>>the fact that you will be able to set cookies from an 
>>included resource. 
>>This is something which is unlikely to happen, given that:
>>- data is quite likely to have already been sent back (the 
>>response is 
>>now committed)
>Okay. I can understand that argument.
>It seems to me, though, that the proposed patch handles this, and that by
>setting a sufficient buffer size the likelyhood of the response being
>committed can be reduced.
If you are basing your application on likelihood ... If you have three 
contexts involved and a large page (which has to happen somtimes, right 
?), then it will break.

The patch you're asking for is not that the included session should set 
a session cookie, but that an included page could set cookies. So remove 
the if (included) return; from the right method.

>I realize this isn't really a great solution because the behaviour silently
>change depending on if the response has been committed or not. However,
>there are plenty of other things in the servlet spec that behave in similar
>ways (HttpServletRespone.addHeader, etc).
And they all have:
    public void addHeader(String name, String value) {

        if (isCommitted())

        // Ignore any call from an included servlet
 >>>>        if (included)
 >>>>            return;

        coyoteResponse.addHeader(name, value);


An included servlet can do nothing which involves setting something in 
the response header.

>This change means there is a way to make sessions behave as would be
>expected when used from a cross context request dispatcher. Currently that
>is impossible, so wouldn't this be an improvement?
You cannot reliably expect it to work. It will use a large amount of 
memory, and is vulnerable to anyone calling flush, etc. What you'll get 
is something which would work most of the time if the application is 
well written.

>>- the container might not have access to the internal objects 
>>from the 
>>request dispatcher, or at least it is rather hackish to try 
>>to access them
>Could you expand on this some? What internal object would the container need
>to access?
Well, the normal request doesn't allow adding cookies when including. So 
the container has to unwrap and hope that the original request is there. 
The simplest way to allow this easily would be to remove the requirement 
that addCookie can't be invoked when including.

>>It might work fine for academic examples, but will likely fail in the 
>>real world. Overall, I have found the Portlet TCK to be full of 
>>asumptions on the Servlet API, even though these are on a very weak 
>>technical foundation. I have attempted to bring that up with 
>>the Portlet 
>>spec lead, with very little success.
>I'm sorry to hear that. 
>I suspect that the Portlet specification suffers somewhat from "First
>Version Syndrome" - there are a number of things that could be better
>specified, and there are required bits of functionality that are missing.
One of the other issue I've found is that it attempts to specify the 
lifecycle of the session from the included context (ie, what happens 
when you invalidate it, and then what happens when you call 
getSession(false) again after calling invalidate). There's another issue 
as well, but it's less tricky.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message