curl/tests/data/test273, branch gemini-meta

http: always send Host: header as first header

2015-03-12T11:15:24+00:00

...after the method line:

 "Since the Host field-value is critical information for handling a
 request, a user agent SHOULD generate Host as the first header field
 following the request-line." / RFC 7230 section 5.4

Additionally, this will also make libcurl ignore multiple specified
custom Host: headers and only use the first one. Test 1121 has been
updated accordingly

Bug: http://curl.haxx.se/bug/view.cgi?id=1491
Reported-by: Rainer Canavan

tests: Don't run HTTP digest tests for SSPI based builds

2014-11-06T20:36:08+00:00

Added !SSPI to the features list of the HTTP digest tests, as SSPI
based builds now use the Windows SSPI messaging API rather than the
internal functions, and we can't control the random numbers that get
used as part of the digest.

Do not mix CRLF and LF header endings in a couple of HTTP tests

2012-11-19T09:58:02+00:00

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.

Replaced 127.0.0.1 with %HOSTIP where possible

2007-09-14T19:32:31+00:00

Updated the test harness to add a new "crypto" feature check and updated the

2007-03-09T23:39:42+00:00

appropriate test case to use it.  For now, this is treated the same as the
"SSL" feature because curl doesn't list it separately.

Convert (most of) the test data files into genuine XML. A handful still

2007-01-23T02:25:56+00:00

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.

Venkat Akella found out that libcurl did not like HTTP responses that simply

2006-11-25T13:32:04+00:00

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.

Dave Dribin made libcurl understand and handle cases when the server

2005-10-20T20:07:32+00:00

(wrongly) sends *two* WWW-Authenticate headers for Digest. While this should
never happen in a sane world, libcurl previously got into an infinite loop
when this occurred. Dave added test 273 to verify this.