W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1997

Re: Question on byte ranges

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Tue, 04 Nov 97 18:41:14 PST
Message-Id: <9711050241.AA10280@acetes.pa.dec.com>
To: http working group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4631
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


	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

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.

Received on Tuesday, 4 November 1997 18:50:54 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:21 UTC