W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

Re: Section 14.36 Range, and PUTs

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Fri, 31 May 96 16:47:02 MDT
Message-Id: <9605312347.AA26643@acetes.pa.dec.com>
To: Larry Masinter <masinter@parc.xerox.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/665
    Ohmygod, I don't think we've really ever contemplated how Range
    requests should work with PUT. Personally, I think it should be
    disallowed. Illegal. An error. MUST NOT send. ABEND, eh?, forbidden,
    protocol violation; horns should go off, alarms should ring, etc.
    Also with POST and DELETE. Otherwise, you might have people believing
    that DELETE with Range: 10-12 means delete just those bytes?

    Range is like "accept", it's a request-header that applies to the
    result, not the operation.

The spec, as currently written, does not discuss PUT+Range.  On
the other hand, I don't think it's entirely meaningless, and it
could be useful.  And I think it's a red herring to discuss
DELETE+Range; we don't have to think about the world's stupidest
programmer when writing a spec.  Let Dilbert handle that.

Perhaps it might be a good idea to wait until HTTP/1.x (x > 1)
to allow PUT+Range.  But Paul has pointed out a potential problem;
if any future version of an HTTP/1.x client could send it,
we should certainly require an HTTP/1.1 to reject it rather than
ignore the Range header.

I would say "HTTP/1.1 origin servers MUST respond to requests
containing Range headers, other than GET or HEAD requests, with a 501
(Not Implemented) response.  HTTP/1.1 proxies MUST forward such
requests to the origin server and MUST NOT cache a response to such a
request."  The second sentence allows us to introduce PUT+Range
in a future version without breaking the whole world.

Received on Friday, 31 May 1996 16:57:21 UTC

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