DO NOT REPLY [Bug 10418] - logic whether URL needs to be encoded in HttpServletResponse.encodeURL() broken

[bu...@apache.org]

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

H.Zeller@acm.org 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 H.Zeller@acm.org  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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org