Mohun Biswas wrote:
> > POST /upload HTTP/1.1
> User-Agent: XYZ/0.5 (SunOS_sparc_5.9)
> Host: piglet:8080
> Pragma: no-cache
> Accept: */*
> Cookie: JSESSIONID=D67FD8924005AB5803034924242A62BE
> Content-Length: 689
> Content-Type: multipart/form-data;
> boundary=----------------------------089aa8c52de2
>
> and it ends with no "----------------------------089aa8c52de2--" line.
>
> So - is this a malformed part and thus a libcurl problem or is it
> normal/standard-conformant behavior and a problem with the FileUpload
> class?

I'm pretty sure this ia fine HTTP, but an invalid multipart/form-data
request body.

So there is a libcurl bug, but..

> When the file to be uploaded has zero length the FileUpload parser
> hangs on the server side.

... the FileUpload parser has a bug too. The length of the whole
request body is determined by Content-Length here, _not_ by the
multipart boundary. After that many octets are received at the
server, it should respond, in this case probably with an error saying
that it's an invalid multipart/form-data request body (although I
suppose some upload code might be lenient and accept it).

The FileUpload parser should _never_ try to read more (or less) octets
than the number given in Content-Length. If it is parsing the
multipart body to find the end of the request, then that is a bug in
the server and a potential security hole.

-- Jamie
Received on 2004-10-25