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

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.


Regards
Henrik