Am Dienstag, 19. März 2013, 00:04:28 schrieb Daniel Stenberg:

> You say your libcurl-using app doesn't work properly when doing a PUT? Then
> write the app to only do PUT to a generic HTTP server somewhere and make
> that work first before you integrate into your other logic.
> ...
> Can you provide us with a full recipe we can use and see if we get the
> problem as well?

Dear Daniel,

thx for your reply. It's difficult to find a generic server anywhere which
does exactly provide the behaviour which my cgi-bin shows.
Here's a step-to-step tutorial to simulate the problem:

- save attachments to /tmp & cd /tmp

$ gcc -g -o /srv/http/cgi-bin/ret_400.cgi ret_400.c
(or output wherever your httpd's cgi-bin directory is)

$ gcc -g `pkg-config libcurl --cflags --libs` curlputtest.c -o curlputtest

$ ./curlputtest

- now you get a prompt where you have to enter an http get request.
if you enter the absolute path of an existing file, it will upload that, e.g.:

GET /tmp/curlputtest.c HTTP/1.0

- the second line is the upload-destination, so the path where on your
webserver the ret_400 cgi-bin resides, for example:

X-DESTINATION: http://localhost/cgi-bin/ret_400.cgi

- the testprog will then output a debug line with the aquired paths:

curl put mode on!! source path '/dream/devel/dnstreamproxy/curlputtest.c'
destination url 'http://localhost/cgi-bin/ret_400.cgi'

- after another newline, curl will try to connect to the given url and try to
upload the file which fails with error 400 because the cgi-bin expects a
parameter with a length of exactly 10 characters. this is expected!

- if you enter a X-DESTINATION url with a 10-digit parameter, it succeeds with
status code 201:

X-DESTINATION: http://localhost/cgi-bin/ret_400.cgi?1234567890

- now if instead of an accessible file, you put some bogus stuff after in the
get request, it'll generate dummy packets and simulate a continuous stream
without determined file size:

GET /thisisnotafilename HTTP/1.0

- as X-DESTINATION your specify the cgi-bins uri but with wrong parameter,
then the expected behaviour is that it should not even once call the READFUNC
and error out with the 404 status right away like it does with the determined
file size.
instead the READFUNC is called over and over again and the upload never ends
(even though the cgi-bin on the server has set the 404 status and terminated
already) i've wiresharked this and it shows, that the apache doesn't actually
send out the http error code, until the curlputtest is aborted. i'm guessing
that the testcase for some reason doesn't even give the webserver a chance to
send its answer in this upload mode without determined content-size.
when uploading an actual file, it does work just fine, so this is already kind
of a minimal example and can't really be more simplified i guess :(

cheers,
fraxinas

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-03-19