Re: Section 14.36 Range, and PUTs

In a previous episode...Larry Masinter said:
-> 
-> 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,

I disagree.. from http/1.1 ID 04 about 'PUT'

--
of the one residing on the origin server. If the Request-URI does not
point to an existing resource, and that URI is capable of being
defined as a new resource by the requesting user agent, the origin
server can create the resource with that URI. If a new resource is
created, the origin server MUST inform the user agent via the 201
(Created) response.  If an existing resource is modified, either the
200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate
successful completion of the request. If the resource could not be
created or modified with the Request-URI, an appropriate error
response SHOULD be given that reflects the nature of the problem.
--

PUT is pretty clearly designed to support updates as well as additions
to files. Providing a mechanism to alter, say, 1 record of a flat file
of fixed length records seems to make a lot of sense.. In addition to
the usual concerns about versions that the client has, the server is
going to have to add some locking mechanism here, but should certainly
be allowed to implement it if they want to..

-> 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?

I agree Range is meaningless wrt POST and DELETE.

-P

Received on Monday, 3 June 1996 06:05:59 UTC