DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=38745>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38745 Summary: Incorrect use of "Host" header field in client may yield weird results. Product: Tomcat 5 Version: Unknown Platform: Other OS/Version: other Status: NEW Severity: minor Priority: P3 Component: Connector:Coyote AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Version: Tomcat 5.5 used in JBoss, CVSTag=JBoss_4_0_2 date=20050502 2023) Component: Coyote Platform: happened on win32, but probably applies to all platforms. JVM: JDK 1.5.0_06 Web Server: JBoss 4.0.2sp1 Hi all, I'm working on a solution that needs to make use of URL rewriting for session ID's. I'm using response.encodeURL(url) in order to do this. The server uses port 8080. When accessing the site through Firefox, all is fine. All my URL's get rewritten perfectly and there are no issues. I'm also using wfetch.exe and this always failed to rewrite on the same access URL and the same code, also on 8080. I inspected the conversation and noticed that the client application incorrectly uses the "Host" header. The spec clearly says that Host should always be included for HTTP/1.1 and that if port is not specified, 80 is assumed. The only difference was this "Host" header in this case, all the other headers, parameters, URI was the same. I've looked into the JVM using a debugger. When the clients access the system, there is a 'CoyoteRequest' object that has a further 'request' variable in it. The latter request variable contains an attribute called 'serverPort', which is used in the "isEncodeable" method of "CoyoteResponse". If the port that Tomcat thinks the request was initiated on is equal to the request on the URL, the rewriting is carried out. Otherwise it is not. Im not sure whether this may create some security issues later on. I would have expected the container to use the port setting inside the context when it comes to URL rewriting, since the container can determine this easily and does not have to depend on the Host header (as Tomcat seems to depend). Can anyone confirm this is happening as I stated and whether this behaviour is correct? Because as I have just shown, this may also cause other issues for other people somehow. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
