redirecting DELETE requests

[scruffy...@gmail.com]

is there a reason that http.Client doesn't follow redirects for DELETE requests?

the source code for Client.Do (http://golang.org/src/pkg/net/http/client.go#L127) shows that HEAD and GET requests follow one set of redirects, and POST and PUT follow another.  Everything else doesn't follow a redirect.  I would think, though, that DELETE requests should follow in line with POST and PUT, especially since, after a DELETE request, there generally isn't anything left at the requested resource

[Péter Szilágyi]

Hi,

  I'm not 100% sure, but as far as I know the reason is that you simply cannot redirect after a DELETE. Per the HTTP spec: "This class [300] of status code indicates that further action needs to be taken by the user agent in order to fulfill the request". But in the case of DELETE, if the request was already fulfilled, any further action is already higher logic and not HTTP level.

  But consider the above a pointer rather than a definitive answer :)

Cheers,

  Peter

On Wed, Jun 19, 2013 at 1:17 PM, <scruffy...@gmail.com> wrote:

is there a reason that http.Client doesn't follow redirects for DELETE requests?

the source code for Client.Do (http://golang.org/src/pkg/net/http/client.go#L127) shows that HEAD and GET requests follow one set of redirects, and POST and PUT follow another.  Everything else doesn't follow a redirect.  I would think, though, that DELETE requests should follow in line with POST and PUT, especially since, after a DELETE request, there generally isn't anything left at the requested resource

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[John Nagle]

On 6/19/2013 9:44 AM, P�ter Szil�gyi wrote:
> Hi,
>
> I'm not 100% sure, but as far as I know the reason is that you simply
> cannot redirect after a DELETE. Per the HTTP

> spec<http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html>: "This

> class [300] of status code indicates that further action needs to be taken
> by the user agent in order to fulfill the request". But in the case of
> DELETE, if the request was already fulfilled, any further action is already
> higher logic and not HTTP level.

See "http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html",
sections 9.6 (PUT) and 9.7 (DELETE). For PUT,

"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."

So there's a defined rule for PUT as to whether the
PUT applies to the URL submitted or some redirection thereof.
PUT doesn't redirect either; either it PUTs where you told it to,
or it tells the user agent to retry somewhere else.

For DELETE, there's quite different language:

"The DELETE method requests that the origin server delete the resource
identified by the Request-URI. This method MAY be overridden by human
intervention (or other means) on the origin server." There's no
mention of redirection. Probably because if redirection was
done as with GET, with default error pages, people would end up
deleting the error page (or at least trying to) for a "not
found" condition.

John Nagle

[George Shammas]

Not saying your wrong, but the spec also doesn't say anything about 301s or 302s in the GET, HEAD, and POST methods.

PUT seems to be a special case because you're never should mod_rewrite it to modify another resource and should just tell the client what that other resource is. I now know I have been guilty of violating this aspect of the spec, but I am not sure how valid it is once you get into dynamic content.

On Jun 19, 2013 4:36 PM, "John Nagle" <na...@animats.com> wrote: