tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 38745] New: - Incorrect use of "Host" header field in client may yield weird results.
Date Wed, 22 Feb 2006 00:36:20 GMT
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: gwat@cesar.org.br


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


Mime
View raw message