tags:

views:

128

answers:

2

Hello,

I'm writing a simplistic HTTP server that will accept PUT requests mostly from cURL as client and I'm having a bit of an issue with handling the "Expect: 100-continue" header.

As I understand it, the server is supposed to read the header, send back a "HTTP/1.1 100 Continue" response on the connection, read the stream up to the value on "Content-Length" and then send back the real response code (Usually "HTTP/1.1 200 OK" but any other valid HTTP answer should do).

Well, that's exactly what my server does. The problem is that, apparently, if I send a "100 Continue" answer, cURL fails to report any subsequent HTTP error code and assumes the upload was a success. For instance, if the upload is rejected due to the nature of the content (there is a basic data check happening), I want the calling client to detect the problem and act accordingly.

Am I missing something obvious ?

edit: here is a sample output from cURL with a secondary header containing an error:

> PUT /test1%2Epdf HTTP/1.1
> Authorization: Basic xxxx
> User-Agent: curl/7.20.0 (i386-pc-win32) libcurl/7.20.0 OpenSSL/0.9.8l zlib/1.2.3
> Host: localhost
> Accept: */*
> Content-Length: 24
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
< HTTP/1.1 415 Unsupported Media Type
< Connection: close
< Content-Type: text/xml
< Content-Length: 289
<

Thanks

+1  A: 

Actually there should be real header after 100 Continue header

So, I normally do like this on client side.

$contents=curl_exec($ch);

list( $header, $contents ) = explode( "\r\n\r\n", $contents , 2);
if(strpos($header," 100 Continue")!==false){
    list( $header, $contents) = explode( "\r\n\r\n", $contents , 2);
}
S.Mark
Well, I do send a real header after the code 100 answer. It seems that cURL doesn't care, though.
Stephane
+1  A: 

Try adding an empty line (CRLF) after the 100 Continue line (see RFC 2616, Section 6),

Julian Reschke
It seems the missing line is a bug. I've checked the code and there is an empty line after the "100 continue"
Stephane