- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Fri, 31 May 96 16:47:02 MDT
- To: Larry Masinter <masinter@parc.xerox.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
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.
-Jeff
Received on Friday, 31 May 1996 16:57:21 UTC