Konstantin Kolinko wrote:
2009/11/29 Bill Barker <billwbar...@verizon.net>:
"André Warnier" <a...@ice-sa.com> wrote in message
news:4b119016.2020...@ice-sa.com...
Pid wrote:
On 28/11/2009 12:56, André Warnier wrote:
;-)
I just wanted, once, to use a subject line with capitals and an
exclamation mark.
It seems however that in this particular case, neither Tomcat nor Apache
httpd follow the rules, when they default to the .. default virtual host
in the case where they cannot find a match between the Host: header and
one of their defined virtual hosts.
Doesn't the following say that they MUST return a 400 status ?
http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.2
"An origin server that does not allow resources to differ by the
requested host MAY ignore the Host header field value when determining
the resource identified by an HTTP/1.1 request"
?
You are quoting selectively. The same line continues with
"(But see section 19.6.1.1 for other requirements on Host support in
HTTP/1.1.)"
which section 19.6.1.1 is quite stern about the fact that HTTP 1.1 servers
MUST support the Host: header properly.
So I persist.
Well, for IP-based VHosts (common for httpd), Pid is correct since the
server uses the IP address that recieved the request to determine where it
goes.
For name-based VHosts (the default for Tomcat), both Tomcat and httpd are
still in the clear since every host is valid on the server (the ones not
explicitly configured match the default host).
<spec-quote spec="rfc2616" section="5.2">
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.
</spec-quote>
You can always configure your default host to respond with
response.sendError(400); for every request.
Same answer as the one I posted on the Apache forum :
My original post was more like a jest or a provocation, rather than a
real question.
But is is interesting to see how in the end, a document such as RFC2616
which is meant to "specify" a relatively strict set of rules, and of
which I am sure the phrasing is examined carefully and repeatedly (it
being after all a revision of an earlier document on the same topic),
still leaves areas open to interpretation, or downright inconsistent.
What is for example, in this case, a hostname which is /invalid/ on this
host ?
If the request reached this host, then it must be that for the DNS
system, the hostname resolved to one of this physical host's IP
addresses. In that sense, any HTTP request which reaches the host could
be deemed to address a valid hostname.
Yet the HTTP server listening on that host (and port), may be configured
to accept requests for several specific hostnames, but not the one
mentioned in the request. In that sense, Tomcat's defaulting to a
"default" host whose name does not match the request hostname would be
in contravention of the RFC. Yet by the same token, Tomcat's defaulting
to the default host and accepting the request, would seem to make the
request's hostname "valid", since the request is accepted.
So basically, the HTTP RFC obliges the server to send a 400 response for
an invalid host, but what is an invalid host is decided by the server.
Kind of circular as far as arguments go.
By the way, Konstantin's response above matches the one given by the
Apache httpd gurus : have the default host respond with 400.
That would match the RFC.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
