On Thu, Jan 17, 2013 at 04:17:41PM +0100, Ulrich Doehner wrote:
> the curl executable stalls on trying to read form data from a directory instead
> of a file.
>
> How to reproduce:
>
> curl --insecure --form 'REQUEST=</etc' https://www.commerzbank.com/cgi-bin/
> example.pl
>
> Version:
>
> curl 7.17.0 (sparc-sun-solaris2.10) libcurl/7.17.0 OpenSSL/0.9.7d zlib/1.2.3
> Protocols: tftp ftp telnet dict ldap http file https ftps Features: IPv6
> Largefile NTLM SSL libz

Although this version is over 5 years old, a recent daily snapshot is still
acting oddly for me when I tested it:

== Info: About to connect() to localhost port 8000 (#0)
== Info: Trying 127.0.0.1...
== Info: connected
== Info: Connected to localhost (127.0.0.1) port 8000 (#0)
=> Send header, 197 bytes (0xc5)
0000: POST / HTTP/1.0
0011: User-Agent: curl/7.28.2-20121217
0033: Host: localhost:8000
0049: Accept: */*
0056: Content-Length: 12430
006d: Content-Type: multipart/form-data; boundary=--------------------
00ad: --------af7d60bea0e7
00c3:
=> Send data, 94 bytes (0x5e)
0000: ------------------------------af7d60bea0e7
002c: Content-Disposition: form-data; name="REQUEST"
005c:
=> Send data, 48 bytes (0x30)
0000:
0002: ------------------------------af7d60bea0e7--

It looks to me like it's able to stat() the size of the directory and
sends the header based on that, but since it's not a file, it can't read
the data to sends no data. Meanwhile, the server waits forever for the
full amount of data (12430 bytes in this case) which isn't ever going to come.

It looks to me like there are two problems here: curl shouldn't try to send
data from a directory "file" in the first place, and a more general
problem, if it can't read all the data it stat'ed at the start (either
too much or too little), it should abort the transaction and return an
error code.

>>> Dan
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-users
FAQ: http://curl.haxx.se/docs/faq.html
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-01-19