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
