15. April 2002 00:58 wrote Dirk Manske:
> Hallo,
>
> being non RFC conform to be browser conform?
>
> While doing a login transaction with my libcurl application I noticed
> that libcurl does a post after getting a 301 from a previous post request.
>
> Looking into http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.2:
> | 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.
>
> Hmm, libcurl is right...but most browsers do a get after a 301 to follow.

Here comes a better patch, forget previously sent patch:

---------- snip
--- transfer.c.orig Thu Feb 28 16:13:35 2002
+++ transfer.c Mon Apr 15 15:03:57 2002
@@ -1254,13 +1254,26 @@
          */
         switch(data->info.httpcode) {
         case 300: /* Multiple Choices */
- case 301: /* Moved Permanently */
         case 306: /* Not used */
         case 307: /* Temporary Redirect */
         default: /* for all unknown ones */
           /* These are explicitly mention since I've checked RFC2616 and they
            * seem to be OK to POST to.
            */
+ break;
+ case 301: /* Moved Permanently */
+ /* (quote from RFC2616, section 10.3.2):
+
+ 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.
+ */
+ /* To be erroneous like most browsers: */
+ if((data->set.httpreq==HTTPREQ_POST || data->set.httpreq==HTTPREQ_POST_FORM)
+ && strchr(data->change.url,'?') ){
+ infof(data, "Violate RFC 2616/10.3.2 and switch from POST to GET\n");
+ data->set.httpreq=HTTPREQ_GET;
+ }
           break;
         case 302: /* Found */
           /* (From 10.3.3)
---------- snip

Ok, or worser than hell?

Dirk Manke
Received on 2002-04-15