http_listener: Expect 100 Continue

[lbromo]

Hi,

It there a way to handle Expect 100-contine on the server side?

As I understand RFC 2616, section 8.2.3 , it could be implemented as something like this (using a http_listener):

http_listener listener(address)
listener->support(methods::PUT, [] (http_request request){
  auto headers = request.headers();
  if( headers.find("Expect") != headers.end() ){ // Assumes it is  Expect: 100-continue
    request.reply(status_codes::Continue).wait();
  }
  // do_stuff();
  request.reply(status_codes::OK).wait();
  std::cout << "yay" << std::endl; // Never reached
});

Testing something like the above with curl yields:

> PUT /test_url HTTP/1.1
> Host: localhost:8000
> User-Agent: curl/7.49.1
> Accept: */*
> Content-Type: binary/octet
> Content-Length: 41392
> Expect: 100-continue
> 
* Done waiting for 100-continue
* We are completely uploaded and fine
< HTTP/1.1 100 Continue
< Content-Length: 0

curl never receives the 200 OK header (verified in Wireshark that it doesn't get send), and It seems like the sever is hanging on request.reply(status_codes::OK).wait(); (yay is never printed).

[ras0219-msft]

I think that with our current APIs Expect 100-continue is impossible to handle correctly. Requests are only designed to be .reply()'ed to once. I suppose what would be needed here is a .reply_with_continue() function which would send the intermediary notification.

As a side note: in general it is a bad idea to call .get() or .wait() inside another task or callback; you should write the rest of the function as a continuation and return that instead.

Instead of

auto x = t.get();
return x + 1;

prefer to write

return t.then([](const auto& x)
{
  return x + 1;
});

This will release your current thread back to the threadpool to more efficiently process requests.