generic-library/curl
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
ba06278e97
curl/tests/data/test1012

80 lines
1.4 KiB
Plaintext
Raw Normal View History

Philip Langdale provided the new CURLOPT_POST301 option for 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.
2007-09-26 14:44:59 +02:00
<testcase>
<info>
<keywords>
HTTP
HTTP POST
followlocation
</keywords>
</info>
#
# Server-side
<reply>
<data>
HTTP/1.1 301 OK swsclose
Location: moo.html&testcase=/10120002
Date: Thu, 09 Nov 2010 14:49:00 GMT
Connection: close
</data>
<data2>
Do not mix CRLF and LF header endings in a couple of HTTP tests Consistently use CRLF instead. The mixed endings weren't documented so I assume they were unintentional. This change doesn't matter for curl itself but makes using the tests with a proxy between curl and the test server more convenient. Tests that consistently use no carriage returns were left unmodified as one can easily work around this.
2012-11-14 19:49:12 +01:00
HTTP/1.1 200 OK swsclose
Location: this should be ignored
Date: Thu, 09 Nov 2010 14:49:00 GMT
Connection: close
Philip Langdale provided the new CURLOPT_POST301 option for 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.
2007-09-26 14:44:59 +02:00
body
</data2>
<datacheck>
HTTP/1.1 301 OK swsclose
Location: moo.html&testcase=/10120002
Date: Thu, 09 Nov 2010 14:49:00 GMT
Connection: close
Do not mix CRLF and LF header endings in a couple of HTTP tests Consistently use CRLF instead. The mixed endings weren't documented so I assume they were unintentional. This change doesn't matter for curl itself but makes using the tests with a proxy between curl and the test server more convenient. Tests that consistently use no carriage returns were left unmodified as one can easily work around this.
2012-11-14 19:49:12 +01:00
HTTP/1.1 200 OK swsclose
Location: this should be ignored
Date: Thu, 09 Nov 2010 14:49:00 GMT
Connection: close
Philip Langdale provided the new CURLOPT_POST301 option for 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.
2007-09-26 14:44:59 +02:00
body
</datacheck>
</reply>
#
# Client-side
<client>
<server>
http
</server>
<name>
HTTP POST with 301 redirect and --post301
</name>
<command>
http://%HOSTIP:%HTTPPORT/blah/1012 -L -d "moo" --post301
</command>
</client>
#
# Verify data after the test has been "shot"
<verify>
<strip>
^User-Agent:.*
</strip>
<protocol nonewline="yes">
POST /blah/1012 HTTP/1.1
Host: %HOSTIP:%HTTPPORT
Accept: */*
Content-Length: 3
Content-Type: application/x-www-form-urlencoded
mooPOST /blah/moo.html&testcase=/10120002 HTTP/1.1
User-Agent: curl/7.10 (i686-pc-linux-gnu) libcurl/7.10 OpenSSL/0.9.6c ipv6 zlib/1.1.3
Host: %HOSTIP:%HTTPPORT
Accept: */*
Content-Length: 3
Content-Type: application/x-www-form-urlencoded
moo
</protocol>
</verify>
</testcase>
Reference in New Issue Copy Permalink