- From: Yves Lafon <ylafon@w3.org>
- Date: Fri, 24 Oct 2008 09:25:27 -0400 (EDT)
- To: Etan Wexler <ewexler@stickdog.com>
- cc: HTTP Working Group <ietf-http-wg@w3.org>
On Fri, 24 Oct 2008, Etan Wexler wrote: > > Yves Lafon (as Yves) wrote in > <http://www.w3.org/mid/alpine.OSX.1.00.0810210932350.34078@nenpuar.ybpny>: > >> When you know that /new.txt will generate new URIs, the correct method to >> trigger [it] is POST and clearly not PUT. >> What's wrong with [the following scenario?] >> POST /give_me_a_new_URI >> => 303 See Other >> Location: /new1.txt >> => PUT /new1.txt >> ... > > In HTTP, a response whose status code is 303 fails to direct the user agent > to issue a request whose method is PUT. RFC 2616 recommends that the user > agent issue a request whose method is GET and whose Request-URI is the URI > that appeared in the Location header field of the preceding response (see, > for example, <http://greenbytes.de/tech/webdav/rfc2616.html#status.303>). The > latest (as of 2008-10-24) working draft of a revision to that part of RFC > 2616 allows, but does not mandate, a request whose method is GET (see, for > example, > <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-04.html#status.303>). Well, sure, the goal is not to redirect PUT, but to create a resource form a "templating" one. In that case you can even get the result of the creation using a GET, then do a PUT there. > Specifications aside, user agents in the field will react to a status code of > 303 with a request whose method is GET. Many operators of origin servers rely > on such behavior, as do the people who direct their user agents to those > origin servers. Well I didn't say the opposite, the 303 was not to redirect the PUT, just part of an orchestration of calls. Cheers, -- Baroula que barouleras, au tiéu toujou t'entourneras. ~~Yves
Received on Friday, 24 October 2008 13:25:36 UTC