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=10418>. 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=10418 logic whether URL needs to be encoded in HttpServletResponse.encodeURL() broken [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- URL|http://www.freiheit.com/user|http://vicdor.org/~hzeller/S |s/hzeller/SessionBugDemonstr|essionBugDemonstration.java |ation.java | Status|RESOLVED |REOPENED Resolution|WONTFIX | ------- Additional Comments From [EMAIL PROTECTED] 2004-02-07 21:27 ------- Since the original SessionBugDemonstration hasn't been reachable, I've moved it to http://vicdor.org/~hzeller/SessionBugDemonstration.java Please note, that this Bug is also related to #10419; problems with faulty clients like IE that may as well send invalid session IDs in cookies (see comments there) could be effectively thwarted if tomcat would choose to encode URLs in that case. I still think that the behaviour is faulty and it is still not fixed. The _requested_ session ID is an ID that comes from the client and might not necessarily be a valid ID (the browser continues to send cookies as long as it is not shutdown). So consider a web application that has a cookie that timed out. Later the user chooses to not accept any new cookies and enters the web application again. So this is not 'in the middle' of something that cookies are disabled (as Remy Maucherat states in comment at 2002-07-03 07:55) but between two usages of the same application. The web application creates a new session but gets a 'requested' session ID from the old cookie still lying around .. and chooses not to encode URLs based on that fact -- even though the session-ID it got has nothing to do with the session ID newly created. However, since the URLs are not encoded and the browser does not accept the new cookie, the application will simply not work because it will never see its newly creates session id again. As long as the application has not received the _first valid_ cookie from the browser it must encode its URLs. Every application should (conservativly) start encoding its URLs until it knows that it gets the session ID from the cookie; ITS session id, not SOME. Right now, tomcat optimistically assumes that if there is _some_ JSESSIONID-cookie then everything will go fine.. I had to do several workarounds in different applications already because of this (like http://cvs.sourceforge.net/viewcvs.py/j-wings/wings/src/org/wings/session/SessionServlet.java?annotate=1.25#385 ) As application developer you often stumble over this bug when you actually test your application if it works with cookies enabled and disabled -- you've to restart your browser everytime you invalidate a session ... Or if you don't restart your browser that often but use it for weeks (ok, this is probably unlikely on windows but on Un*x I do this all the time :-) Since there is no comment that explains that this is _not_ a bug and since this bug actually requires to do workarounds at the application level (see above), I'll reopen it again. If you think, the solution I provided is to expensive I'll dig through the sources again and find another one. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
