You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2002/11/20 18:05:03 UTC

DO NOT REPLY [Bug 14714] New: - Problem with encodeURL() and Refresh tags/header

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=14714>.
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=14714

Problem with encodeURL() and Refresh tags/header

           Summary: Problem with encodeURL() and Refresh tags/header
           Product: Tomcat 4
           Version: 4.1.12
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Connector:Coyote HTTP/1.1
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: ap@apeiron.de


The problem arises when you want to use a URL that has been encoded by
HttpServletResponse.encodeURL() with either a "Refresh" header or a "Refresh"
meta tag. Netscape/Mozilla seem to work, but IE 4.x, 5.x, 6.x looses the
session if cookies are turned off. To make an example:

I need to reload a certain page (or a different page) after some period 
of time. I use a meta-tag

<meta http-equiv="refresh" content="30;
URL=http://my.server.com/my/servlet;jsessionid=WHATEVER?id=1234">

The problem is the ";" in the URL. IE seems to stop parsing and does
not submit the session id. While I have seen that this is some kind of
general problem servlet containers have, the usual workaround, submitting
the session id as ordinary request parameter, does no longer work with
Tomcat. I think that it worked with previous versions. 

Even quoting the URL does not solve the problem. Other people may experience
similar problems if they want to use such an URL in JavaScript. No, 
encodeRedirectURL() does not work, either. 

PS: For me, the severity would be at least "major", I just didn't want to 
escalate the thing too much.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>