moparisthebest/curl
1
0
Fork 0
mirror of https://github.com/moparisthebest/curl synced 2024-12-23 08:38:49 -05:00
Code Issues Releases Wiki Activity
cc44fb1dc8
curl/tests/data/test257

116 lines
2.6 KiB
Plaintext
Raw Normal View History

Convert (most of) the test data files into genuine XML. A handful still are not, due mainly to the lack of support for XML character entities (e.g. & => & ). This will make it easier to validate test files using tools like xmllint, as well as edit and view them using XML tools.
2007-01-22 21:25:56 -05:00
<testcase>
Fred New reported a bug where we used Basic auth and user name and password in .netrc, and when following a Location: the subsequent requests didn't properly use the auth as found in the netrc file. Added test case 257 to verify my fix.
2005-04-25 17:39:48 -04:00
<info>
<keywords>
HTTP
HTTP GET
followlocation
netrc
</keywords>
</info>
# Server-side
<reply>
<data>
HTTP/1.1 301 This is a weirdo text message swsclose
Date: Thu, 09 Nov 2010 14:49:00 GMT
Server: test-server/fake
Location: http://anotherone.com/2570002
Connection: close
This server reply is for testing a simple Location: following
</data>
<data2>
HTTP/1.1 302 Followed here fine swsclose
Date: Thu, 09 Nov 2010 14:49:00 GMT
Server: test-server/fake
Location: http://athird.com/2570003
If this is received, the location following worked
</data2>
<data3>
HTTP/1.1 200 Followed here fine swsclose
Date: Thu, 09 Nov 2010 14:49:00 GMT
Server: test-server/fake
Venkat Akella found out that libcurl did not like HTTP responses that simply responded with a single status line and no headers nor body. Starting now, a HTTP response on a persistent connection (i.e not set to be closed after the response has been taken care of) must have Content-Length or chunked encoding set, or libcurl will simply assume that there is no body. To my horror I learned that we had no less than 57(!) test cases that did bad HTTP responses like this, and even the test http server (sws) responded badly when queried by the test system if it is the test system. So although the actual fix for the problem was tiny, going through all the newly failing test cases got really painful and boring.
2006-11-25 08:32:04 -05:00
Content-Length: 52
Fred New reported a bug where we used Basic auth and user name and password in .netrc, and when following a Location: the subsequent requests didn't properly use the auth as found in the netrc file. Added test case 257 to verify my fix.
2005-04-25 17:39:48 -04:00
If this is received, the location following worked
</data3>
<datacheck>
HTTP/1.1 301 This is a weirdo text message swsclose
Date: Thu, 09 Nov 2010 14:49:00 GMT
Server: test-server/fake
Location: http://anotherone.com/2570002
Connection: close
HTTP/1.1 302 Followed here fine swsclose
Date: Thu, 09 Nov 2010 14:49:00 GMT
Server: test-server/fake
Location: http://athird.com/2570003
HTTP/1.1 200 Followed here fine swsclose
Date: Thu, 09 Nov 2010 14:49:00 GMT
Server: test-server/fake
Venkat Akella found out that libcurl did not like HTTP responses that simply responded with a single status line and no headers nor body. Starting now, a HTTP response on a persistent connection (i.e not set to be closed after the response has been taken care of) must have Content-Length or chunked encoding set, or libcurl will simply assume that there is no body. To my horror I learned that we had no less than 57(!) test cases that did bad HTTP responses like this, and even the test http server (sws) responded badly when queried by the test system if it is the test system. So although the actual fix for the problem was tiny, going through all the newly failing test cases got really painful and boring.
2006-11-25 08:32:04 -05:00
Content-Length: 52
Fred New reported a bug where we used Basic auth and user name and password in .netrc, and when following a Location: the subsequent requests didn't properly use the auth as found in the netrc file. Added test case 257 to verify my fix.
2005-04-25 17:39:48 -04:00
If this is received, the location following worked
</datacheck>
</reply>
# Client-side
<client>
<features>
netrc_debug
</features>
<server>
http
</server>
<name>
HTTP Location: following with --netrc-optional
</name>
<command>
http://supersite.com/want/257 -L -x http://%HOSTIP:%HTTPPORT --netrc-optional
</command>
# netrc auth for two out of three sites:
<file name="log/netrc">
machine supersite.com login user1 password passwd1
machine anotherone.com login user2 password passwd2
</file>
</client>
# Verify data after the test has been "shot"
<verify>
<strip>
^User-Agent:.*
</strip>
<protocol>
GET http://supersite.com/want/257 HTTP/1.1
Authorization: Basic dXNlcjE6cGFzc3dkMQ==
User-Agent: curl/7.14.0-CVS (i686-pc-linux-gnu) libcurl/7.14.0-CVS OpenSSL/0.9.7e zlib/1.2.2 libidn/0.5.13
Host: supersite.com
Pragma: no-cache
Accept: */*
Modified the default HTTP headers used by libcurl: A) Normal non-proxy HTTP: - no more "Pragma: no-cache" (this only makes sense to proxies) B) Non-CONNECT HTTP request over proxy: - "Pragma: no-cache" is used (like before) - "Proxy-Connection: Keep-alive" (for older style 1.0-proxies) C) CONNECT HTTP request over proxy: - "Host: [name]:[port]" - "Proxy-Connection: Keep-alive"
2005-05-11 05:52:59 -04:00
Proxy-Connection: Keep-Alive
Fred New reported a bug where we used Basic auth and user name and password in .netrc, and when following a Location: the subsequent requests didn't properly use the auth as found in the netrc file. Added test case 257 to verify my fix.
2005-04-25 17:39:48 -04:00
GET http://anotherone.com/2570002 HTTP/1.1
Authorization: Basic dXNlcjI6cGFzc3dkMg==
User-Agent: curl/7.14.0-CVS (i686-pc-linux-gnu) libcurl/7.14.0-CVS OpenSSL/0.9.7e zlib/1.2.2 libidn/0.5.13
Host: anotherone.com
Pragma: no-cache
Accept: */*
Modified the default HTTP headers used by libcurl: A) Normal non-proxy HTTP: - no more "Pragma: no-cache" (this only makes sense to proxies) B) Non-CONNECT HTTP request over proxy: - "Pragma: no-cache" is used (like before) - "Proxy-Connection: Keep-alive" (for older style 1.0-proxies) C) CONNECT HTTP request over proxy: - "Host: [name]:[port]" - "Proxy-Connection: Keep-alive"
2005-05-11 05:52:59 -04:00
Proxy-Connection: Keep-Alive
Fred New reported a bug where we used Basic auth and user name and password in .netrc, and when following a Location: the subsequent requests didn't properly use the auth as found in the netrc file. Added test case 257 to verify my fix.
2005-04-25 17:39:48 -04:00
GET http://athird.com/2570003 HTTP/1.1
User-Agent: curl/7.14.0-CVS (i686-pc-linux-gnu) libcurl/7.14.0-CVS OpenSSL/0.9.7e zlib/1.2.2 libidn/0.5.13
Host: athird.com
Pragma: no-cache
Accept: */*
Modified the default HTTP headers used by libcurl: A) Normal non-proxy HTTP: - no more "Pragma: no-cache" (this only makes sense to proxies) B) Non-CONNECT HTTP request over proxy: - "Pragma: no-cache" is used (like before) - "Proxy-Connection: Keep-alive" (for older style 1.0-proxies) C) CONNECT HTTP request over proxy: - "Host: [name]:[port]" - "Proxy-Connection: Keep-alive"
2005-05-11 05:52:59 -04:00
Proxy-Connection: Keep-Alive
Fred New reported a bug where we used Basic auth and user name and password in .netrc, and when following a Location: the subsequent requests didn't properly use the auth as found in the netrc file. Added test case 257 to verify my fix.
2005-04-25 17:39:48 -04:00
</protocol>
</verify>
Convert (most of) the test data files into genuine XML. A handful still are not, due mainly to the lack of support for XML character entities (e.g. & => &amp; ). This will make it easier to validate test files using tools like xmllint, as well as edit and view them using XML tools.
2007-01-22 21:25:56 -05:00
</testcase>
Reference in New Issue Copy Permalink