Possible bug in 4.x HttpProcessor server port handling?

["Setera, Craig" <Cr...@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.

Is this truly a bug as we believe?  If so, can someone actually patch it
into CVS, as I don't have authority for such things.

Thanks,
Craig

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