Returning 400 in virtual host environments where host header does not match
Consider a web server that serves three virtual hosts:
- mysite.com
- myothersite.com
- imnotcreative.com
Now, suppose the server receives the following unhandled request message (code formatting removes trailing sequences \r\n
):
GET / HTTP/1.1
Host: nothostedhere.com
I don't see any guidance in RFC 2616 (maybe I missed this?) On how to respond to a request for a hostname that is not on the current server. For example, Apache simply uses the first virtual host specified in its configuration as the "primary host" and pretends that the client requested that host. Obviously this is more robust than returning a response 400 Bad Request
and ensures that the client always sees some kind of view.
So my question is ...
Can anyone explain the reasons for the robustness argument to dissuade me from responding with 400
(or some other error code) if the client is requesting a non-existent host when using the HTTP / 1.1 protocol?
Note that all HTTP / 1.1 requests MUST specify a header Host:
in accordance with RFC 2616. For HTTP / 1.0 requests, the only viable option is to execute the "primary" host result. This question specifically addresses HTTP / 1.1 protocol requests.
source to share
400 is not actually the semantically correct response code in this scenario.
The request could not be understood by the server due to incorrect syntax .
This is not what happened. The request is syntactically valid, and by the time the server reaches the routing phase (when you check the header value) it will have already been determined.
I would say the correct answer code here is 403:
The server understood the request, but refuses to fulfill it.
This describes what happened more accurately. The server refuses to fulfill the request because it is unable, and a more detailed error message can be provided in the message entity.
There is also an argument that a 404 will be acceptable / correct, as no suitable document can be found with which to satisfy the request, but personally I think this is the wrong option because the 404 states are:
The server did not find anything matching the request-URI
This explicitly mentions the Request-URI issue, and at this early stage in the routing phase, you are probably not interested in the URI, as you first need to pass the request to the host before it can determine if it has a suitable document to handle the URI path.
The HTTP / 1.1 headers are Host:
required. If a client claims to be using version 1.1 and does not provide a header Host:
, then 400 is definitely the correct response code. If the client claims to be using version 1.0, then there is no need to supply a host header and this should be handled gracefully - and this scenario has the same situation as an unrecognized domain.
Indeed, you have two options in this case: send a request to the default virtual host container or respond to an error. As stated above, if you are going to answer with an error, I believe the error should be 403.
source to share
I would say it depends a lot on the type (s) of clients you expect to use and the type of service you offer.
-
For a generic website:
It's safe enough to assume the requests are being launched from the user's browser, in which case I'll be more grateful if the header is missing or incorrectHost:
. I even went as far as to say that the way Apache handles the case (i.e. reverting to the first matching VHost) is fine. After all, you don't want to scare your customers. -
For the API / RPC service type:
This is a completely different case. You MUST expect everyone who consumes your service to adhere to your requirements. Thus, if it requires the consumer to pass a valid headerHost:
and the consumer doesn't, you should return with a reasonable answer (400 Bad Request
seems plausible to me).
source to share