Handle 100 Continue transparently about http HOT 5 CLOSED

Thanks for filing this ticket and sparking the discussion about our expect-continue feature (Expect: 100-continue) 👍

First things first, here's how this works in the first place:

• This feature is specified as part of HTTP/1.1: https://tools.ietf.org/html/rfc7231#section-5.1.1
• Clients MAY implement this feature but are not required to do so
• Severs MAY implement this feature but are not required to do so
• If the client includes a Expect: 100-continue header, the server MAY return an intermediary HTTP/1.1 100 Continue response after receiving the request headers, which causes the client to start transmitting the actual message body
• If the client includes a Expect: 100-continue header, the server MAY reject the request with any "normal" error response message, which means the client never has to transmit the message body at all
• Clients MUST support servers that do not implement this feature. This usually adds a few seconds of delay where the client waits for the intermediary HTTP/1.1 100 Continue response
• Many common clients actually implement this feature when sending large requests only (usually a few KiB or MiB)

from http.

That being said, let's look into how this handled in React:
React has had this feature for a long time already, but it's currently completely undocumented. I'm currently adding documentation for this as part of #107. This means it's very likely this is hardly used at all.

This combined means that it may look like React is "slow" when consumers do not explicitly handle these headers. Other than this added delay, it actually works perfectly fine. This delay can be avoided by explicitly supporting this feature like this:

$http->on('request', function ($request, $response) {
    if ($request->expectsContinue()) {
        $response->writeContinue().
    }
    $response->writeHead(200, array('Content-Type' => 'text/plain'));
    $response->end("Hello World!\n");
});

This is necessary because this if block code could implement some custom application logic to check the request headers and such and we can't really provide a "default implementation" here.

For example, you may want to reject the request if it uses the wrong Content-Type or its Content-Length exceeds a certain threshold. In this case, a client would detect this error before even trying to upload the message body (which could possibly be multiple GiB).

from http.

This is necessary because this if block code could implement some custom application logic to check the request headers and such and we can't really provide a "default implementation" here.

While it can be used to check certain things ahead of the request body being sent, it generally increases the complexity for request handling and doesn't offer real benefits. It's fine if the server code handles it and the user code relies on the TCP buffer for back-pressure. The client will slow down if the receive buffer is full, so only 128KB or so will be buffered or the request body.

from http.

Progress update: I've added the v0.7.0 milestone because we're going to look into applying PSR-7 interfaces (#28) and will thus very likely ditch custom methods such as expectsContinue() and writeContinue() altogether.

@kelunik While I agree your suggestion would likely work for the 90% use case, I'm currently undecided about how exactly this will be implemented. Stay tuned :-)

Also, in case anybody else has any use for this feature, input is very much welcome! 👍

from http.

Closed via #144

from http.