Search code examples
scalahttpcurlplayframeworkhttp-status-code-100

curl, play & expect 100 continue header


consider a web service written in play, which excepts POST request (for uploads). now, when testing this with a medium size image (~75K) I've found out a strange behaviour. well, code speaks more clearly than long explanations, so:

$ curl -vX POST localhost:9000/path/to/upload/API -H "Content-Type: image/jpeg" -d @/path/to/mascot.jpg
* Hostname was NOT found in DNS cache
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 9000 (#0)
> POST /path/to/upload/API HTTP/1.1
> User-Agent: curl/7.35.0
> Host: localhost:9000
> Accept: */*
> Content-Type: image/jpeg
> Content-Length: 27442
> Expect: 100-continue
> 
< HTTP/1.1 100 Continue
< HTTP/1.1 200 OK
< Content-Type: application/json; charset=utf-8
< Content-Length: 16
< 
* Connection #0 to host localhost left intact
{"success":true}

as you can see, curl decides to add the header Content-Length: 27442, but it's not true, the real size is 75211, and in play, I indeed got a body in size only 27442. of coarse, this is not the intended behaviour. so I tried a different tool, instead of curl I used the POST tool from libwww-perl:

cat /path/to/mascot.jpg | POST -uUsSeE -c image/jpeg http://localhost:9000/path/to/upload/API
POST http://localhost:9000/path/to/upload/API
User-Agent: lwp-request/6.03 libwww-perl/6.05
Content-Length: 75211
Content-Type: image/jpeg

200 OK
Content-Length: 16
Content-Type: application/json; charset=utf-8
Client-Date: Mon, 16 Jun 2014 09:21:00 GMT
Client-Peer: 127.0.0.1:9000
Client-Response-Num: 1

{"success":true}

this request succeeded. so I started to pay more attention to the differences between the tools. for starter: the Content-Length header was correct, but also, the Expect header was missing from the second try. I want the request to succeed either way. so the full list of headers as seen in play (via request.headers) is:

for curl:

ArrayBuffer((Content-Length,ArrayBuffer(27442)), 
            (Accept,ArrayBuffer(*/*)),
            (Content-Type,ArrayBuffer(image/jpeg)), 
            (Expect,ArrayBuffer(100-continue)), 
            (User-Agent,ArrayBuffer(curl/7.35.0)), 
            (Host,ArrayBuffer(localhost:9000)))

for the libwww-perl POST:

ArrayBuffer((TE,ArrayBuffer(deflate,gzip;q=0.3)), 
            (Connection,ArrayBuffer(TE, close)), 
            (Content-Length,ArrayBuffer(75211)), 
            (Content-Type,ArrayBuffer(image/jpeg)), 
            (User-Agent,ArrayBuffer(lwp-request/6.03 libwww-perl/6.05)),
            (Host,ArrayBuffer(localhost:9000)))

So my current thoughts are: the simpler perl tool used a single request, which is bad practice. the better way would be to wait for a 100 continue confirmation (especially if you gonna' upload a several GB of data...). curl would continue to send data until it receives a 200 OK or some bad request error code. So why play sends the 200 OK response without waiting for the next chunk? is it because curl specifies the wrong Content-Length? if it's wrong at all... (perhaps this refers to the size of the current chunk?). so where's the problem lies? in curl or in the play webapp? and how do I fix it?


Solution

  • the problem was in my curl command. I used the -d argument, which is a short for --data or --data-ascii, when I should have used --data-binary argument.