tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: redirect request from 8080 to port 80
Date Wed, 15 May 2013 21:56:50 GMT
Mark Thomas wrote:
> On 15/05/2013 17:15, André Warnier wrote:
>> Ognjen Blagojevic wrote:
>>> André,
>>> On 15.5.2013 15:38, André Warnier wrote:
>>>> As far as I understand here, we are not talking about a proxy situation,
>>>> we are talking about Iptables, which does not proxy, it just modifies
>>>> packets.
>>>> So the URL that Tomcat gets from the 1st request line does not contain a
>>>> hostname[:port}.
>>> According to RFC2616 (Section 5.1.2), client may send absolute URI or
>>> absolute path. Majority of clients will send absolute path when
>>> talking to the server.
>> Absolute *path*, yes. They MUST do that if they are talking to "this"
>> server.
>> But HTTP 1.1 clients will only send an absolute URI (including
>> hotsname[:port] when talking to a proxy.
>> In this case we are not in a proxy situation, so the request line will
>> not contain http://hotsname[:port].
> While RFC2616 requires that a proxy uses an absolute URL nothing
> prevents a standard client from using them if it wishes. Which is why I
> stated in my reply "Depending on the client behaviour..."

To be totally precise about it, here is what RFC 2616 actually says :

"To allow for transition to absoluteURIs in all requests in future versions of HTTP, all 
HTTP/1.1 servers MUST accept the absoluteURI form in requests, even though HTTP/1.1 
clients will only generate them in requests to proxies."

So one must accept it, but in terms of the current HTTP 1.1, it should never happen for 
non-proxy requests.

>> Yes, that it will be read seems normal.
>> But that it would be logged as the port on which the request was
>> received, seems a bit less intuitive.
>> But if that is what happens..
> Repeating myself again, what is logged in the access logs depends on the
> pattern the access log is configured with.
>> I find it less intuitive because of the Javadoc of
>> HttpServletRequest.getLocalPort :
>>  getLocalPort
>> int getLocalPort()
>>     Returns the Internet Protocol (IP) port number of the interface on
>> which the request was received.
>>     Returns:
>>         an integer specifying the port number
>>     Since:
>>         Servlet 2.4
>> So that is the interface (the Connector), not the port number mentioned
>> in the Host header.
> Yes, but with the caveat that proxyPort will change the result of that call.

Ok, but if I understand the documentation correctly, one specifies (literally) by this 
attribute, the port to be returned by request.getServerPort() (and presumably 

So the port value that might be contained in the Host header is not used in this case.
That seems to contradict what Ongjen was writing earlier.

And it leads to this contrived but interesting case :
Suppose one has one Tomcat, with the HTTP Connector configured to listen on port 8080.
And suppose that one has 2 proxies (with different names) each listening on port 80 and 
forwarding requests to that one Tomcat on port 8080.
There would then be no possibility to configure Tomcat so as to respond correctly to both

proxies, no ?
(While if it was using the content of the Host header, it could).

Anyway, to get back to the OP's original issue, and considering the documentation only, I

do understand a bit of confusion as to what is really being logged in the Access Log.


int getLocalPort()

     Returns the Internet Protocol (IP) port number of the interface on which the request

was received.



int getServerPort()

     Returns the port number to which the request was sent. It is the value of the part 
after ":" in the Host header value, if any, or the server port where the client connection

was accepted on.








See "pattern", and the "%p" pattern :

%p - Local port on which this request was received

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message