John Franks writes:
But I would like to see 416 returned if the request is either
syntactically incorrect or unsatisfiable. I agree with Dave that it
is strange to ignore a syntactically incorrect header. It is unlikely
to be helpful to the (buggy) client. Indeed, to the user it might
well look like the server is buggy. I much prefer for the server to
announce definitively, "Hey, your client screwed up!"
It might seem strange to ignore a syntactically incorrect header,
but there are plenty of other HTTP headers that could be sent with
incorrect syntax, and the HTTP/1.1 spec says nothing at all about
what to do. For example, what does the server return for
GET /home.html HTTP/1.1
Host: foo.com
If-Modified-Since: cheeseburger
or
GET /home.html HTTP/1.1
Host: foo.com
Accept-Encoding: Tue, 04 Nov 97 17:04:50 GMT
The specification for the 400 (Bad Request) status code says
10.4.1 400 Bad Request
The request could not be understood by the server due to
malformed syntax. The client SHOULD NOT repeat the request
without modifications.
but it's not clear if the examples above are "could not be understood"
by a server.
I tried sending "If-Modified-Since: cheeseburger" in an HTTP/1.0
request to www.apache.org; it ignored the malformed header, and
sent me a status-200 response.
So, based as before on the Robustness Principle, and especially given
the general lack of definitive statements about this kind of problem
in the HTTP/1.1 spec, that we're better off with servers ignoring
malformed non-mandatory headers, rather than sending status-400
responses.
And I certainly think it's a mistake to use the same response code
to mean both "your code is buggy" and "your code is fine, but your
cache is out of date". The latter implies that the client might
take some automated action to recover; the former implies that the
client should probably not try to do an automatic recovery.
-Jeff