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
request.getLocalPort()).
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.
[1] http://tomcat.apache.org/tomcat-7.0-doc/servletapi/
int getLocalPort()
Returns the Internet Protocol (IP) port number of the interface on which the request
was received.
---------------------
getServerPort
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.
----------------------
[2]
http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Standard_Implementation
(proxyPort/proxyName)
---------------------
[3] http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#Proxy%20Support
---------------------
[4]
http://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Access_Log_Valve/Attributes
See "pattern", and the "%p" pattern :
%p - Local port on which this request was received
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
