On Thu, 22 Mar 2001, Edin Kadribasic wrote:

> OK. Now I know what is happening. The page I'm trying to get is a form
> that uses post method to modify itself. If it detects POST it will
> redirect to itself with different GET parameters, and so on. cURL is
> posting even on redirect which makes this form think it has been
> submitted again, and it again issues a redirect, so we end up in a
> redirect loop.
>
> I thinks this behaviour of cURL should be changes since no browser that I
> know of will use POST to get page that it was redirected to. It should
> use GET instead (when following a redirect).

Curl's behavoir in this situation has changed a few times over the years.

It started out always re-sending the same request, I then moved to always
revert from POST => GET after a location: and then we came to the current
system where we're actually attempting to follow (the spirit of) RFC2616.

The spec is a bit vague on what to do. Allow me to quote and comment (section
10.3.3 on return code 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.

I agree that this isn't what we do. But there's no way we can get this
"confirmed by the user". At least not with the current interface. I've kind
of taken the instruction "follow locations" as a confirmation from the user.

      Note: RFC 1945 and RFC 2068 specify that the client is not allowed
      to change the method on the redirected request.

... which supports curl's actions.

      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.

... where 303 means use GET.

And to round up things in favour of your suggestion, there's this piece of
text from the 10.3.4 section on error code 303:

      Note: Many pre-HTTP/1.1 user agents do not understand the 303
      status. When interoperability with such clients is a concern, the
      302 status code may be used instead, since most user agents react
      to a 302 response as described here for 303.

... which indicates that curl should treat 302 and 303 identically.

Summary: I agree, when receiving 302, curl should make a GET after the POST!

-- 
  Daniel Stenberg -- curl project maintainer -- http://curl.haxx.se/
_______________________________________________
Curl-and-php mailing list
Curl-and-php_at_lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/curl-and-php