Remy Maucherat wrote:
Jeanfrancois Arcand wrote:
Remy Maucherat wrote:
Jeanfrancois Arcand wrote:
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
jfarcand 2003/12/01 12:44:14
Modified: http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: Use the socket info instead of hardcoded
value. HttpServletRequest.getLocalPort() is currently broken if the
port are not the default one.
This looks wrong. I am almost certain this was on purpose. These must return the default value for the protocol, not the values actually used by the socket.
Humm. Then maybe the way HttpServletRequest.getLocalPort() is implemented is wrong. Can socket.getLocalPort() returns something different that 80 if the connector supposed to listen on 80 (maybe I'm missing something from the jk side here....)
I don't remember. I think you should look into the version history. I will tomorrow.
It was added with version 1.23. Bill ? ;-)
I've just realized that the sslSupport variable is no longer needed (so my fix needs to be cleaned). BTW the test I'm doing is:
telnet localhost 8080 GET /tomcat-test/ServletTest HTTP/1.1 Host: localhost
In the servlet, I'm doing request.getLocalPort(), which always returns 80. But it works if I do
telnet localhost 8080 GET /tomcat-test/ServletTest HTTP/1.1 Host: localhost:8080
;-)
Thanks for the example, I now remember the reason for the code. So I'll have to veto your patch.
The rule for HTTP/1.1 is that:
- it should use whatever is specified in the host header
- it should return the protocol default otherwise, since this is the same as not specifying anything in the host header
This comes from vhosting. serverName and serverPort must contain teh vhosting information.
HTTP/1.0 doesn't have the host header, so the socket is used.
Now the big question is actually what the new getLocalPort call should return. If you need an extra localPort (and its friend getLocalName - did you notice the getLocalName() call was always returning whatever hostname was in the host header) field in the request because it doesn't correspond to vhosting (I consider it would be yet another major blunder of the Servlet spec, but what can I do ...), then so be it.
:-( OK I will revert the fix and see what I can do with the Servlet spec (and try to see if we can do something in another place that will not impact the current code).
-- Jeanfrancois
Rémy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
