From ec1f42a154a90e407c10ec087bd64fd46159a9e9 Mon Sep 17 00:00:00 2001 From: Daniel Stenberg Date: Thu, 22 Mar 2001 20:02:52 +0000 Subject: Treat 302-redirects the same way we treat 303-redirects --- lib/transfer.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) (limited to 'lib') diff --git a/lib/transfer.c b/lib/transfer.c index ce4d5a678..13f292d13 100644 --- a/lib/transfer.c +++ b/lib/transfer.c @@ -874,7 +874,6 @@ CURLcode Curl_perform(CURL *curl) switch(data->progress.httpcode) { case 300: /* Multiple Choices */ case 301: /* Moved Permanently */ - case 302: /* Found */ case 306: /* Not used */ case 307: /* Temporary Redirect */ default: /* for all unknown ones */ @@ -882,6 +881,24 @@ CURLcode Curl_perform(CURL *curl) * seem to be OK to POST to. */ break; + case 302: /* Found */ + /* (From 10.3.3) + + 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. + + (From 10.3.4) + + 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. + */ case 303: /* See Other */ /* Disable both types of POSTs, since doing a second POST when * following isn't what anyone would want! */ -- cgit v1.2.3