W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2007

Re: Issue i17 (Revise description of the POST method)

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 04 Jun 2007 17:39:08 +0200
Message-ID: <4664321C.9020902@gmx.de>
To: Henrik Nordstrom <henrik@henriknordstrom.net>
CC: HTTP Working Group <ietf-http-wg@w3.org>

Henrik Nordstrom wrote:
> sön 2007-06-03 klockan 23:10 +0200 skrev Julian Reschke:
>> Hi,
>>
>> I just realized that by resolving issue i17 
>> (<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i17>) by 
>> relaxing the semantics of POST, we may have broken the definition of 
>> PUT, which says 
>> (http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/draft-lafon-rfc2616bis-02.html#rfc.section.9.6.p.3>):
>>
>> "The URI in a POST 
>> request identifies the resource that will handle the enclosed entity. 
>> That resource might be a data-accepting process, a gateway to some other 
>> protocol, or a separate entity that accepts annotations."
>>
>> Now that the spec basically specifies how POST is used in the wild, is 
>> the comparison with POST in the definition of PUT still correct?
> 
> Think so. Why? I don't see any conflict.
> 
> But also don't see much reason why PUT should talk about what POST does
> instead of just focusing on what PUT does..
> 
> Proposal: Delete the text in PUT which describes POST. It's redundant
> with the description of POST and the two is just next to each other
> adding very little value.
> 
> From:
> 
> The fundamental difference between the POST and PUT requests is
> reflected in the different meaning of the Request-URI. The URI in a POST
> request identifies the resource that will handle the enclosed entity.
> That resource might be a data-accepting process, a gateway to some other
> protocol, or a separate entity that accepts annotations. In contrast,
> the URI in a PUT request identifies the entity enclosed with the request
> -- the user agent knows what URI is intended and the server MUST NOT
> attempt to apply the request to some other resource. If the server
> desires that the request be applied to a different URI, it MUST send a
> 301 (Moved Permanently) response; the user agent MAY then make its own
> decision regarding whether or not to redirect the request.
> 
> To:
> 
> The fundamental difference between the POST and PUT requests is
> reflected in the different meaning of the Request-URI. The URI in a PUT
> request identifies the entity enclosed with the request -- the user
> agent knows what URI is intended and the server MUST NOT attempt to
> apply the request to some other resource. If the server desires that the
> request be applied to a different URI, it MUST send a 301 (Moved
> Permanently) response; the user agent MAY then make its own decision
> regarding whether or not to redirect the request.
> ...

Good catch. The description of PUT currently contains text that we 
previously removed from POST (so this is a good example why looking at 
errata in isolation may be problematic).

Getting back to my original point: with the resolution of Issue i17, we 
have relaxed the constraints of POST so that the definition actually 
matches reality. I don't think it was intended to change the definition 
of PUT, though.

Thus, we may want to change

	"The fundamental difference ..."

to something like

	"One difference...."

because now there are more fundamental differences than before, right?


Best regards, Julian
Received on Monday, 4 June 2007 15:39:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:10 GMT