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. |
||
|---|---|---|
| .. | ||
| AIX | ||
| DOS | ||
| EPM | ||
| Linux | ||
| NetWare | ||
| OS400 | ||
| Solaris | ||
| Win32 | ||
| vms | ||
| .cvsignore | ||
| Makefile.am | ||
| README | ||
README
_ _ ____ _
___| | | | _ \| |
/ __| | | | |_) | |
| (__| |_| | _ <| |___
\___|\___/|_| \_\_____|
PACKAGES
This directory and all its subdirectories are for special package
information, template, scripts and docs. The files herein should be of use for
those of you who want to package curl in a binary or source format using one
of those custom formats.
The hierarchy for these directories is something like this:
packages/[OS]/[FORMAT]/
Currently, we have Win32 and Linux for [OS]. There might be different formats
for the same OS so for Linux we have RPM as format.
We might need to add some differentiation for CPU as well, as there is
Linux-RPMs for several CPUs. However, it might not be necessary since the
packaging should be pretty much the same no matter what CPU that is used.
For each unique OS-FORMAT pair, there's a directory to "fill"! I'd like to
see a single README with as much details as possible, and then I'd like some
template files for the package process.