Re: Tomcat does not respect the HTTP RFCs !
-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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat does not respect the HTTP RFCs !
-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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat does not respect the HTTP RFCs !
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
Re: Tomcat does not respect the HTTP RFCs !
André Warnier wrote: 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. 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat does not respect the HTTP RFCs !
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat does not respect the HTTP RFCs !
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat does not respect the HTTP RFCs !
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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat does not respect the HTTP RFCs !
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. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
