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/02/25 22:16:28 UTC

DO NOT REPLY [Bug 6668] New: - HttpProcessor takes incorrect defaults for proxy port according to HTTP/1.1 Spec

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

HttpProcessor takes incorrect defaults for proxy port according to HTTP/1.1 Spec

           Summary: HttpProcessor takes incorrect defaults for proxy port
                    according to HTTP/1.1 Spec
           Product: Tomcat 4
           Version: 4.0.2 Final
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Catalina
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: craig.setera@kingland.com


We've been debugging a problem in our application related to the port being 
sent during a redirect.  In our case, both the host and port requested will be 
mapped on the way into and out of our network.  We obviously need our redirects 
to be sent with the correct server and port set, but we were seeing only the 
host being sent back correctly in the redirect response.

After some time debugging, it seems that there is a bug in the parseHeaders() 
method of org.apache.catalina.connector.http.HttpProcessor.  In that method, 
the "host" HTTP header is processed to set the server name and port.  According 
to the HTTP 1.1 Spec (section 14.23) "A "host" without any trailing port 
information implies the default port for the service request (e.g., 80 for an 
HTTP URL)".  The parse headers code does not appear to set the server port if 
the ":" is not found in the header and therefore the port remains the original 
port specified on the connector.

It would seem that the current handling of the no-colon case should be changed 
to something like this:
               if (n < 0) {
                	if (connector.getScheme().equals("http")) {
                		request.setServerPort(80);
                	} else if (connector.getScheme().equals("https")) {
                		request.setServerPort(443);
                	}
                	
                    if (proxyName != null)
                        request.setServerName(proxyName);
                    else
                        request.setServerName(value);
                } else { ...

After patching the source locally, this solves our proxy redirection problems.  
It may be that bugzilla bug #5762 is related to this, although it is kind of 
hard to tell.

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