You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by André Warnier <aw...@ice-sa.com> on 2009/11/28 13:56:04 UTC
Tomcat does not respect the HTTP RFCs !
;-)
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat does not respect the HTTP RFCs !
Posted by David Smith <dn...@cornell.edu>.
André Warnier wrote:
> Konstantin Kolinko wrote:
>> 2009/11/29 Bill Barker <bi...@verizon.net>:
>>> "André Warnier" <aw...@ice-sa.com> wrote in message
>>> news:4B119016.2020105@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.
>
>
I'm not sure it's a gray area ... it's just up to the admins if their
server will answer to anything or just specific hostnames. Most admins
I know welcome the traffic no matter what name gets clients there. The
RFC does describe what the proper response is if the server config deems
the requested hostname as invalid.
--David
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat does not respect the HTTP RFCs !
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
André,
On 11/29/2009 2:00 PM, Warnier wrote:
> 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.
Agreed. In certain circumstances, I believe Apache httpd to be
(somewhat?) non-spec-compliant. For instance, Apache httpd chokes on
URIs like:
http://host/path/to/resource;parameter=value
httpd believes that, contrary to the HTTP spec, the ";" is a part of the
resource and not a separator between the resource locator and a
parameter to that resource. This is the reason we have hacks like
mod_rewrite and mod_jk's JkStripSession setting to allow httpd to work
properly with URIs containing ";jsessionid=...".
The section of the spec in this case is "RFC 2396: Generic URI Syntax"
(http://www.ietf.org/rfc/rfc2396.txt), section 3.3:
"
The path may consist of a sequence of path segments separated by a
single slash "/" character. Within a path segment, the characters
"/", ";", "=", and "?" are reserved. Each path segment may include a
sequence of parameters, indicated by the semicolon ";" character.
The parameters are not significant to the parsing of relative
references.
"
Unfortunately, there is wiggle-room, here: what does a "path segment
parameter" mean? Apache httpd has chosen to interpret path segment
parameters as part of a resource's physical path on a filesystem:
https://issues.apache.org/bugzilla/show_bug.cgi?id=42860
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAksULAEACgkQ9CaO5/Lv0PDfwQCgnioa6Rc32LP90TIfQUPfz6ZR
dPcAniwmKBVu+irtyGk4aDQplj7/LuzX
=W2o5
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat does not respect the HTTP RFCs !
Posted by André Warnier <aw...@ice-sa.com>.
Konstantin Kolinko wrote:
> 2009/11/29 Bill Barker <bi...@verizon.net>:
>> "André Warnier" <aw...@ice-sa.com> wrote in message
>> news:4B119016.2020105@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat does not respect the HTTP RFCs !
Posted by Konstantin Kolinko <kn...@gmail.com>.
2009/11/29 Bill Barker <bi...@verizon.net>:
>
> "André Warnier" <aw...@ice-sa.com> wrote in message
> news:4B119016.2020105@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.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat does not respect the HTTP RFCs !
Posted by Bill Barker <bi...@verizon.net>.
"Andr� Warnier" <aw...@ice-sa.com> wrote in message
news:4B119016.2020105@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>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat does not respect the HTTP RFCs !
Posted by André Warnier <aw...@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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat does not respect the HTTP RFCs !
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pid,
On 11/28/2009 8:03 AM, 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"
My interpretation is in line with André's, here. The server in question
/does/ differentiate resources based upon the host, so:
"
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.
"
It's that last one that's the kicker: it basically precludes the use of
"default" hosts.
On the other hand, the use of a default seems completely reasonable. The
use of a default host simply implies that /all/ hosts are valid for the
server in question.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAksUKU8ACgkQ9CaO5/Lv0PA15gCgrE1v9+L0YweYzPeg4+JuQ3ln
IiUAoJq5fEvDUK83Id7pDEJZDXHPSuRT
=GOfT
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat does not respect the HTTP RFCs !
Posted by Pid <pi...@pidster.com>.
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"
?
p
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org