moparisthebest/curl
1
0
Fork 0
mirror of https://github.com/moparisthebest/curl synced 2024-12-22 08:08:50 -05:00
Code Issues Releases Wiki Activity
b557182db1
curl/tests/data/test587

59 lines
963 B
Plaintext
Raw Normal View History

formdata: ack read callback abort When doing a multipart formpost with a read callback, and that callback returns CURL_READFUNC_ABORT, that return code must be properly propagated back and handled accordingly. Previously it would be handled as a zero byte read which would cause a hang! Added test case 587 to verify. It uses the lib554.c source code with a small ifdef. Reported by: Anton Bychkov Bug: http://curl.haxx.se/mail/lib-2011-10/0097.html
2011-10-15 19:07:29 -04:00
<testcase>
tests: add keywords for a couple of HTTP tests
2012-11-19 11:54:52 -05:00
<info>
<keywords>
HTTP
HTTP POST
tests: added flaky keyword to tests 587 and 644 These are around 5% flaky in my Linux x86 autobuilds.
2017-10-06 17:04:40 -04:00
flaky
tests: add keywords for a couple of HTTP tests
2012-11-19 11:54:52 -05:00
</keywords>
</info>
formdata: ack read callback abort When doing a multipart formpost with a read callback, and that callback returns CURL_READFUNC_ABORT, that return code must be properly propagated back and handled accordingly. Previously it would be handled as a zero byte read which would cause a hang! Added test case 587 to verify. It uses the lib554.c source code with a small ifdef. Reported by: Anton Bychkov Bug: http://curl.haxx.se/mail/lib-2011-10/0097.html
2011-10-15 19:07:29 -04:00
#
# Server-side
<reply>
<data>
</data>
</reply>
# Client-side
<client>
<server>
http
</server>
# tool is what to use instead of 'curl'
<tool>
lib587
</tool>
<name>
HTTP multi-part formpost with aborted read callback
</name>
<command>
http://%HOSTIP:%HTTPPORT/587
</command>
</client>
#
# Verify data after the test has been "shot"
<verify>
<strippart>
formpost: better random boundaries When doing multi-part formposts, libcurl used a pseudo-random value that was seeded with time(). This turns out to be bad for users who formpost data that is provided with users who then can guess how the boundary string will look like and then they can forge a different formpost part and trick the receiver. My advice to such implementors is (still even after this change) to not rely on the boundary strings being cryptographically strong. Fix your code and logic to not depend on them that much! I moved the Curl_rand() function into the sslgen.c source file now to be able to take advantage of the SSL library's random function if it provides one. If not, try to use the RANDOM_FILE for seeding and as a last resort keep the old logic, just modified to also add microseconds which makes it harder to properly guess the exact seed. The formboundary() function in formdata.c is now using 64 bit entropy for the boundary and therefore the string of dashes was reduced by 4 letters and there are 16 hex digits following it. The total length is thus still the same. Bug: http://curl.haxx.se/bug/view.cgi?id=1251 Reported-by: "Floris"
2013-06-24 16:24:35 -04:00
s/^--------------------------[a-z0-9]*/------------------------------/
s/boundary=------------------------[a-z0-9]*/boundary=----------------------------/
formdata: ack read callback abort When doing a multipart formpost with a read callback, and that callback returns CURL_READFUNC_ABORT, that return code must be properly propagated back and handled accordingly. Previously it would be handled as a zero byte read which would cause a hang! Added test case 587 to verify. It uses the lib554.c source code with a small ifdef. Reported by: Anton Bychkov Bug: http://curl.haxx.se/mail/lib-2011-10/0097.html
2011-10-15 19:07:29 -04:00
</strippart>
<protocol>
POST /587 HTTP/1.1
Host: %HOSTIP:%HTTPPORT
Accept: */*
formadd: wrong pointer for file name when CURLFORM_BUFFERPTR used The internal function that's used to detect known file extensions for the default Content-Type got the the wrong pointer passed in when CURLFORM_BUFFER + CURLFORM_BUFFERPTR were used. This had the effect that strlen() would be used which could lead to an out-of-bounds read (and thus segfault). In most cases it would only lead to it not finding or using the correct default content-type. It also showed that test 554 and test 587 were testing for the previous/wrong behavior and now they're updated as well. Bug: http://curl.haxx.se/bug/view.cgi?id=1262 Reported-by: Konstantin Isakov
2013-08-04 17:27:27 -04:00
Content-Length: 718
formdata: ack read callback abort When doing a multipart formpost with a read callback, and that callback returns CURL_READFUNC_ABORT, that return code must be properly propagated back and handled accordingly. Previously it would be handled as a zero byte read which would cause a hang! Added test case 587 to verify. It uses the lib554.c source code with a small ifdef. Reported by: Anton Bychkov Bug: http://curl.haxx.se/mail/lib-2011-10/0097.html
2011-10-15 19:07:29 -04:00
Content-Type: multipart/form-data; boundary=----------------------------
------------------------------
Content-Disposition: form-data; name="sendfile"; filename="postit2.c"
</protocol>
# CURLE_ABORTED_BY_CALLBACK (42)
<errorcode>
42
</errorcode>
</verify>
</testcase>
Reference in New Issue Copy Permalink