On Fri, 26 Jan 2001, Kevin P Roth wrote:

> Do you recall why the change was made at version 7.1? Is there something
> in the HTTP spec that would require this? Do you know what IE or Netscape
> does?

I made the change back then based on the number of people that reported
problems. Silly enough I didn't check what the HTTP spec says.

> Inquiring minds would love to know...

(RFC2626 page 61: http://curl.haxx.se/rfc/rfc2616.txt)

Now, let's see... If we do a POST and the server responds... (Summary below)

300 -
  We should probably POST again.

301 -
  "If the 301 status code is received in response to a request other
  than GET or HEAD, the user agent MUST NOT automatically redirect the
  request unless it can be confirmed by the user, since this might
  change the conditions under which the request was issued.

  Note: When automatically redirecting a POST request after
  receiving a 301 status code, some existing HTTP/1.0 user agents
  will erroneously change it into a GET request."

  ... sounds like we should POST again. Or not follow at all based on the
  first paragraph!

302 -
  "If the 302 status code is received in response to a request other
  than GET or HEAD, the user agent MUST NOT automatically redirect the
  request unless it can be confirmed by the user, since this might
  change the conditions under which the request was issued.

  Note: RFC 1945 and RFC 2068 specify that the client is not allowed
  to change the method on the redirected request. However, most
  existing user agent implementations treat 302 as if it were a 303
  response, performing a GET on the Location field-value regardless
  of the original request method. The status codes 303 and 307 have
  been added for servers that wish to make unambiguously clear which
  kind of reaction is expected of the client."

  ... sounds like a POST to me. If at all.

303 -
  "The response to the request can be found under a different URI and
  SHOULD be retrieved using a GET method on that resource."

  ... no doubts here. GET!

304 -
  This is only received if we request it conditionally and this means
  "Not modified". We shouldn't get any Location: header in this response.

305 -
  "The requested resource MUST be accessed through the proxy given by
  the Location field. The Location field gives the URI of the proxy.
  The recipient is expected to repeat this single request via the
  proxy. 305 responses MUST only be generated by origin servers."

  ... woa! We don't really support this one. At least don't follow it.

306 -
  Not used.

307 -
  "If the 307 status code is received in response to a request other
  than GET or HEAD, the user agent MUST NOT automatically redirect the
  request unless it can be confirmed by the user, since this might
  change the conditions under which the request was issued."

  Must not follow it... But I figure it would be POST if we did follow it.
  After all, the -L is what I would call "confirmed by the user".

Summary

 Curl's behaviour is correct for 303 and wrong in all other cases. 305 should
 set the proxy and redo the request, the rest should do a POST to the
 location it follows to.

More work.

-- 
  Daniel Stenberg -- curl project maintainer -- http://curl.haxx.se/