tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Tomcat does not respect the HTTP RFCs !
Date Sun, 29 Nov 2009 19:00:55 GMT
Konstantin Kolinko wrote:
> 2009/11/29 Bill Barker <>:
>> "André Warnier" <> wrote in message
>>> 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 ?
>>>> "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 for other requirements on Host support in
>>> HTTP/1.1.)"
>>> which section 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:
For additional commands, e-mail:

View raw message