Hassan Schroeder wrote:
On Tue, May 17, 2011 at 3:35 PM, André Warnier <a...@ice-sa.com> wrote:
(RFC 2616 says that a port can be present in the Host: header; but it does
not mention what the server should do with it. And I can't think of what it
could do with it either, since by the time the server reads this header, the
connection is already established with the webserver anyway.)
While I haven't run across that port # in the Host header bit before,
it's possible that the initial server (localhost in the example above)
is a proxy server, yes?
In which case the request endpoint could be another (virtual) host,
on a different port.
Not that that's probably relevant in this case, but FWIW :-)
Well, see HTTP RFC 2616 for that, section 5.1.2 Request-URI.
It is a bit confusing, but as I understand it, it is in the first request line that one
should specify the absolute URI for the request. Like in the example given :
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
So, supposing that for the browser, the proxy server is servername.company.com:8888, and
that the browser really wants the resource at http://www.w3.org/pub/WWW/TheProject.html,
1) the browser would establish a connection to "servername.company.com:8888"
2) over that connection, it would send the request :
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
Host: servername.company.com:8888
(because the proxy server "servername.company.com:8888" may just be one of the virtual
hosts running on that machine).
But then, section 5.2 The Resource Identified by a Request, says :
An origin server that does differentiate resources based on the host requested
(sometimes referred to as virtual hosts or vanity host names) MUST use the following rules
for determining the requested resource on an HTTP/1.1 request:
1. If Request-URI is an absoluteURI, the host is part of the Request-URI. Any Host header
field value in the request MUST be ignored.
2. If the Request-URI is not an absoluteURI, and the request includes a Host header field,
the host is determined by the Host header field value.
3. If the host as determined by rule 1 or 2 is not a valid host on the server, the
response MUST be a 400 (Bad Request) error message.
(while not forgetting that contrarily to what I was thinking, according to Konstantin
Tomcat actually parses and uses the :port element provided in the Host: header, at least
apparently to pass it as information to the webapp.)
(But since Tomcat, as far as I know, cannot act as a proxy server, these subtle
distinctions may be moot anyway).
Pfff...
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
