DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10419 Session-ID grabbing from Request accepts invalid session cookies in presense of valid URL sessions ------- Additional Comments From [EMAIL PROTECTED] 2002-07-03 17:40 ------- Here's an FYI regarding disambiguating session id cookies. Tomcat always sets the "path" attribute of the cookie to correspond to the context path of the web application for which that cookie applies. A client is supposed to send back cookies only when the request URI matches the path prefix. Thus, you will only get >1 session id cookie under the following circumstances: (1) You have context paths nested inside each other (app1 uses "/foo" and app2 uses "/foo/bar") (2) You have a broken client that doesn't respect the "path" attribute or the cookie value ordering rules (see below for more). Case (1) highlights another interesting issue -- the cookies that are included in the request don't have any identifiers with them, so it is not obvious how you are supposed to tell them apart. Fortunately, the specs define a rule to deal with this -- the client is supposed to send the cookie for the longest matching path first. Thus, in the overlapping case defined above, a request to "/foo/bar/baz" will include two values for the session id cookie -- first the one for the "/foo/bar" context and then the one for the "/foo" context. A request to "/foo/xyz" will only send the cookie for the "/foo" context. This is why Tomcat takes the first session id cookie in the list; a properly programmed client will ensure that this is the right one for the most deeply nested context path that matches the request URI. Tomcat cannot do anything to help you on case (2) however. :-) -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
