Age | Commit message (Collapse) | Author |
|
prefixing a command with '*' means it is allowed to fail without
aborting the chain actions
|
|
591 -> FTP multi PORT and 425 on upload
592 -> FTP multi PORT and 421 on upload
593 -> FTP multi PORT upload, no data conn and no transient neg. reply
594 -> FTP multi PORT upload, no data conn and no positive prelim. reply
1206 -> FTP PORT and 425 on download
1207 -> FTP PORT and 421 on download
1208 -> FTP PORT download, no data conn and no transient negative reply
1209 -> FTP PORT download, no data conn and no positive preliminary reply
|
|
This test is created to verify Rene Bernhardt's patch which makes sure
libcurl properly _not_ deals with Negotiate if not asked to even if the
proxy says it can serve it.
|
|
|
|
I created test 587 in commit 840eff44f2b but forgot to add the file to
the tarball. Added now.
|
|
This is using the verbatim 525 test code but it disables EPRT in the
server and this should work just as well anyway.
|
|
As commit 5850cc4808ab clarifies, libcurl can deliver header lines that
are longer than CURL_MAX_WRITE_SIZE, only body data is limited to that
size. The curl tool has check (when built debug-enabled) that made the
wrong checks and this new test 1205 verifies that larger headers work.
|
|
The fix is pretty much the one Nick Zitzmann provided, just edited to do
the right indent levels and with test case 1204 added to verify the fix.
Bug: http://curl.haxx.se/mail/lib-2011-10/0190.html
Reported by: Nick Zitzmann
|
|
Verifies the fix from commit 322f3d5af7093
|
|
|
|
|
|
|
|
|
|
Content-disposition headers can provide file names with semicolons which
previously would be cut off at that point.
Added test case 1311 and 1312 to verify -J.
Bug: http://curl.haxx.se/bug/view.cgi?id=3375603
Reported by: Peter Hjalmarsson
|
|
The 20xx range is for multiple sequential tests.
|
|
When libcurl has said to the server that there's a POST or PUT coming
(with a content-length and all) it has to either deliver that amount of
data or it needs to close the connection before trying a second request.
Adds test case 1129, 1130 and 1131
The bug report is about when used with 100-continue, but the change is
more generic.
Bug: http://curl.haxx.se/mail/lib-2011-06/0191.html
Reported by: Steven Parkes
|
|
|
|
|
|
This is a few first rather basic tests of curl_formadd() and
curl_formget(). Should serve as building blocks to add more variations
to the test.
|
|
When a time condition isn't met, so that no body is delivered to the
application even though a 2xx response is being read from the server, we
must close the connection to avoid a re-use of the connection to be
completely tricked.
Added test 1128 to verify.
|
|
Test 585 and 586 were added. Using a modified lib500.c
|
|
Added test 1126 and 1127 to verify curl's behaviour when If-Modified-Since
is used and a 200 is returned.
The list of test cases in Makefile.am is now sorted numerically.
|
|
Inspired by a patch from OB.Conseil. Added test case 708 to verify.
|
|
When TE: is inserted in the request, we must add a "Connection: TE" as
well to be HTTP 1.1 compliant. If a custom Connection: header is passed
in, we must use that and only append TE to it. Test case 1125 verifies
TE: + custom Connection:.
|
|
|
|
Transfer-Encoding differs from Content-Encoding in a few subtle ways,
but primarily it concerns the transfer only and not the content so when
discovered to be compressed we know we have to uncompress it. There will
only arrive compressed transfers in a response after we have requested
them with the appropriate TE: header.
Test case 1122 and 1123 verify.
|
|
Also add test case 584 for the same
Bug: http://curl.haxx.se/bug/view.cgi?id=3214223
|
|
|
|
Added tests for a number of POP3 LIST operations, including one
that shows a curl problem when listing no messages, so is
disabled.
|
|
This test case is meant to verify that the logic in commit
60172a0446bbe3f8b actually works. This test failed for me before that
change and it works after it.
|
|
Add test 582 for uploading a file using sftp and the multi interface.
(Patch and test slightly tweaked by Daniel Stenberg)
Initially marked as disabled until it is fixed in the source.
|
|
|
|
|
|
Test 558 was just a subset of 559 which is something that can be
easily added later.
|
|
Moved some definitons into the header file so that we can reuse them.
|
|
|
|
|
|
|
|
I came up with 33 different ways to call it and verify that it returns the
correct return code.
|
|
|
|
|
|
This is the first approach at doing fairly clean and easy to write and
debug unit tests.
|
|
curl mustn't try to use the control connection after the 421 is received
|
|
|
|
The URL parser got a little stricter as it now considers a ? to be a
host name divider so that the slightly sloppier URLs work too. The
problem that made me do this change was the reported problem with an URL
like: www.example.com?email=name@example.com This form of URL is not
really a legal URL (due to the missing slash after the host name) but is
widely accepted by all major browsers and libcurl also already accepted
it, it was just the '@' letter that triggered the problem now.
The side-effect of this change is that now libcurl no longer accepts the
? letter as part of user-name or password when given in the URL, which
it used to accept (and is tested in test 191). That letter is however
mentioned in RFC3986 to be required to be percent encoded since it is
used as a divider.
Bug: http://curl.haxx.se/bug/view.cgi?id=3090268
|
|
|
|
This is an attempt to reproduce bug #3076808
|
|
|
|
HTTP allows that a server sends trailing headers after all the chunks
have been sent WITHOUT signalling their presence in the first response
headers. The "Trailer:" header is only a SHOULD there and as we need to
handle the situation even without that header I made libcurl ignore
Trailer: completely.
Test case 1116 was added to verify this and to make sure we handle more
than one trailer header properly.
Reported by: Patrick McManus
Bug: http://curl.haxx.se/bug/view.cgi?id=3052450
|
|
The 66 bytes checked are those 38 bytes with the chunked encoding
headers added: 8+8+10+35+5 = 66
The three-letter words become 8 bytes on the wire because they are sent
like: "3\r\none\r\n"
... and there's the trailing 5 bytes write after the four lines since
the final chunk is sent (which is "0\r\n\r\n").
|