On sab, giu 07, 2014 at 03:17:17 +0200, Daniel Stenberg wrote: > Hey all, > > Finally, RFC 2616 is deprecated and HTTP 1.1 is now offically instead done > in the whole range of new RFCs in the subject. This revision work has taken > almost seven years to complete.
I'll bite then :) Attached is a more or less insignificant patch that updates the info messages when changing method on 301/302 (which is now allowed). There may be more similarly small changes to be done, but I have just skimmed through the various "Changes from RFC 2616" and haven't really checked how curl handles all of that. Also, should the docs/RESOURCES and the various references to RFC2616 be updated as well? Cheers
From fbd6b8221ea2dcec73daa16cae53e2bdb1856487 Mon Sep 17 00:00:00 2001 From: Alessandro Ghedini <[email protected]> Date: Sun, 8 Jun 2014 18:59:48 +0200 Subject: [PATCH] transfer: fix info messages when switching method on 301 and 302 The method change is forbidden by the obsolete RFC2616, but libcurl did it anyway for compatibility reasons. The new RFC7231 allows this behaviour so there's no need for the scary "Violate RFC 2616/10.3.x" notice. Also update the comments accordingly. --- lib/transfer.c | 58 +++++++++++++++++++++++++++------------------------------- 1 file changed, 27 insertions(+), 31 deletions(-) diff --git a/lib/transfer.c b/lib/transfer.c index e0f613b..dc817a6 100644 --- a/lib/transfer.c +++ b/lib/transfer.c @@ -1719,54 +1719,50 @@ CURLcode Curl_follow(struct SessionHandle *data, */ break; case 301: /* Moved Permanently */ - /* (quote from RFC2616, section 10.3.2): + /* (quote from RFC7231, section 6.4.2) * - * 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. + * Note: For historical reasons, a user agent MAY change the request + * method from POST to GET for the subsequent request. If this + * behavior is undesired, the 307 (Temporary Redirect) status code + * can be used instead. * * ---- * - * As most of the important user agents do this obvious RFC2616 violation, - * many webservers expect this. So these servers often answers to a POST - * request with an error page. To be sure that libcurl gets the page that + * Many webservers expect this, so these servers often answers to a POST + * request with an error page. To be sure that libcurl gets the page that * most user agents would get, libcurl has to force GET. * - * This behavior can be overridden with CURLOPT_POSTREDIR. + * This behaviour is forbidden by RFC1945 and the obsolete RFC2616, and + * can be overridden with CURLOPT_POSTREDIR. */ if((data->set.httpreq == HTTPREQ_POST || data->set.httpreq == HTTPREQ_POST_FORM) && !(data->set.keep_post & CURL_REDIR_POST_301)) { - infof(data, - "Violate RFC 2616/10.3.2 and switch from POST to GET\n"); + infof(data, "Switch from POST to GET\n"); data->set.httpreq = HTTPREQ_GET; } 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. - - This behavior can be overridden with CURLOPT_POSTREDIR - */ + /* (quote from RFC7231, section 6.4.3) + * + * Note: For historical reasons, a user agent MAY change the request + * method from POST to GET for the subsequent request. If this + * behavior is undesired, the 307 (Temporary Redirect) status code + * can be used instead. + * + * ---- + * + * Many webservers expect this, so these servers often answers to a POST + * request with an error page. To be sure that libcurl gets the page that + * most user agents would get, libcurl has to force GET. + * + * This behaviour is forbidden by RFC1945 and the obsolete RFC2616, and + * can be overridden with CURLOPT_POSTREDIR. + */ if((data->set.httpreq == HTTPREQ_POST || data->set.httpreq == HTTPREQ_POST_FORM) && !(data->set.keep_post & CURL_REDIR_POST_302)) { - infof(data, - "Violate RFC 2616/10.3.3 and switch from POST to GET\n"); + infof(data, "Switch from POST to GET\n"); data->set.httpreq = HTTPREQ_GET; } break; -- 2.0.0
signature.asc
Description: Digital signature
------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
