mirror of https://github.com/moparisthebest/curl
fd4cf78f36
curl_easy_setopt() that alters how libcurl functions when following redirects. It makes libcurl obey the RFC2616 when a 301 response is received after a non-GET request is made. Default libcurl behaviour is to change method to GET in the subsequent request (like it does for response code 302 - because that's what many/most browsers do), but with this CURLOPT_POST301 option enabled it will do what the spec says and do the next request using the same method again. I.e keep POST after 301. The curl tool got this option as --post301 Test case 1011 and 1012 were added to verify. |
||
|---|---|---|
| .. | ||
| curl | ||
| .cvsignore | ||
| Makefile.am | ||
| README | ||
README
_ _ ____ _
___| | | | _ \| |
/ __| | | | |_) | |
| (__| |_| | _ <| |___
\___|\___/|_| \_\_____|
Include files for libcurl, external users.
They're all placed in the curl subdirectory here for better fit in any kind
of environment. You should include files from here using...
#include <curl/curl.h>
... style and point the compiler's include path to the directory holding the
curl subdirectory. It makes it more likely to survive future modifications.
NOTE FOR LIBCURL HACKERS
All the include files in this tree are written and intended to be installed on
a system that may serve multiple platforms and multiple applications, all
using libcurl (possibly even different libcurl installations using different
versions). Therefore, all header files in here must obey these rules:
* They cannot depend on or use configure-generated results from libcurl's or
curl's directories. Other applications may not run configure as (lib)curl
does, and using platform dependent info here may break other platforms.
* We cannot assume anything else but very basic compiler features being
present. While libcurl requires an ANSI C compiler to build, some of the
earlier ANSI compilers clearly can't deal with some preprocessor operators.
* Newlines must remain unix-style for older compilers' sake.
* Comments must be written in the old-style /* unnested C-fashion */
To figure out how to do good and portable checks for features, operating
systems or specific hardwarare, a very good resource is Bjorn Reese's
collection at http://predef.sf.net/