On 16/09/2010 15:50, André Warnier wrote:
[...]
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.
I missed that. My interpretation is still that 2109 defines the
behaviour of Set-Cookie and 2965 that of Set-Cookie2 and that the intent
was that Set-Cookie2 should obsolete Set-Cookie, i.e. 2109 still defines
the behaviour of Set-Cookie. However, I am inexperienced in these
matters and may reading that wrong. I presume the behaviour of
Set-Cookie2 is not backwards compatible with that of Set-Cookie and
hence the introduction of a new header.
[...]
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.
And 2109. I would guess the extra text was added to 2965 because such
violations occurred.
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.
Just so.
[...]
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 ?).
I'm not blaming httpunit yet. My client library will use URLConnection
straight. It's possible, but unlikely, that this behaviour is in the
underlying java.net code. I should find out later today.
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.
Yes.
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 ?
Yes and no. Some of my resources are sensitive and some are public, and
which is which can vary over time. I could still give access to public
data over https, but I was trying to avoid that:
1) I publish URLs and don't want them to be https URLs; if its a secured
resource I redirect to the https url.
2) I wanted to try to avoid the processing overhead of SSL for public
resources.
The system has the potential to get quite big, so I don't want to build
in unnecessary overheads. If we are successful, then public data will
be a large part of the traffic.
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,
I'm not. At present I don't need any session state for unsecured
access. If I end up needing such session state, I'll set up an
unsecured JSESSIONID cookie. I am not relying on the JSESSIONID being
secret. I am associating an authenticated data with an SSL session not
with the tomcat session. Only requests over an authenticated SSL
session are considered authenticated. This may not work - depends on
how long SSL sessions stay around. I think I'm OK, but I need to build
it to find out - unless someone who has already tried it tells me it
doesn't work.
I really appreciate your taking the time to share your thoughts and advice.
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
