tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: HtttServletRequest.getSession()
Date Thu, 16 Sep 2010 14:50:54 GMT
Brian McBride wrote:
>  On 14/09/2010 23:17, André Warnier wrote:
> [...]
>> Personal interpretation : if the browser receives a cookie marked 
>> "secure", it should only send it back with requests happening over an 
>> HTTPS connection.
>> (No matter if it was received over HTTP or HTTPS).
> I'm using httpunit for testing.  I observe it receiving a new JSESSIONID 
> cookie over SSL and immediately sending it back over on open connection.

See generic comment at end.

> RFC 2965 does not say that it overrides the older RFC 2109. 

It does, at the end of the Abstract :

    This document reflects implementation experience with RFC 2109 and
    obsoletes it.

And, both RFCs are written by the same authors.

> interpretation is that a user agent can follow RFC 2109 for Set-Cookie 
> headers, and possibly should.  My Tomcat is sending Set-Cookie headers, 
> not Set-Cookie2 headers.
> The text in RFC 2109 for the secure attibute is different to that in RFC 
> 2965:

> Note that the text about not sending a cookie received over a channel
> back over a less secure one is omitted.

Considering that the authors seem to want to obsolete RFC 2109 with RFC 2965, I would thus

say that the previous omission in RFC 2109 has been corrected in RFC 2965, and not the 
other way around.

> So I guess, strictly speaking, no user agent sending secure cookies
>  over an insecure channel is actually in violation of the RFC :(
Strictly speaking, probably not.  But I would say that it violates the spirit of RFC 2965.

> Is there a way to persuade Tomcat to use Set-Cookie2 headers?

That last, I don't know (except from adding the header yourself of course).

Generically, RFCs are written by the people most competent in the domain they are talking

about, and reviewed by other competent people.  They tend to make sense.
That does not mean that there is not from time to time an omission or a contradiction.
But in any case, RFCs are the best we have in terms of "standards of interoperability" on

the Internet.
And a general - but often unwritten - principle is : be strict in what you emit, and 
tolerant in what you receive.

So my personal tendency, when I develop something Internet-wise, is to do it according to

the strictest (personal) interpretation of the latest version of an RFC.  In other words,

to follow the MUST's and SHOULD's. Then on a second pass, I would look at the MAY's, to 
make the code, possibly, tolerant of the other side's interpretation of the RFC.
And then I will test this in the real world, and try to find out all the kinks that happen

with various IE versions (always a good test of server code tolerance), and see if that 
can be compensated for in a way that makes sense.
Of course that never catches everything that users may and will throw at you, so it is a 
recursive process.
And, let's face it : since 95% of corporate users still use one or the other version of 
IE, as developers we have not much choice but to accept what it throws at us and code 
around it. (On the positive side, it is also a very convenient scapegoat when you make a 
booboo and have to explain it to a customer; nobody ever questions the existence of bugs 
in IE anymore).

About the behaviour you are seeing with httpunit, in view of the cumulative interpretation

of RFC 2109 and 2695, my view would be that this is sloppy behaviour of httpunit (but 
maybe that is the point, since it is a testing tool ?).
But then also, you did not say if the cookie sent over HTTPS was marked "secure" (inasmuch

as this attribute exists for a Set-Cookie header; I have not checked).
If it was, and httpunit sends it back over a non-secure connection, then I definitely 
think it's sloppy.  If it wasn't, then my reading is that the server should know that if 
it does not mark the cookie as "secure", a user agent is entitled to consider that the 
cookie contains no sensitive information, and to do with it what it wants.

Now one more thing :
"> I'm using httpunit for testing.  I observe it receiving a new JSESSIONID
 > cookie over SSL and immediately sending it back over on open connection.
Which means that you have a Tomcat-based application of which part happens under HTTPS, 
and part over normal HTTP.  I personally find this iffy.  If you are going through the 
burden of setting up HTTPS, then why not run the entire session under HTTPS ?
If your login data is sensitive, then surely it is because what you are going to exchange

as data afterward is sensitive also, no ?
And if you relying on the fact that a JSESSIONID cookie received by the browser under a 
HTTPS connection, will be resent by the browser on a non-HTTPS connection, then in my view

you are exposing yourself to some next browser version which will have a stricter 
interpretation of these RFCs, and not send it anymore.

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

View raw message