You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
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).
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.
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! 👍
Activity
clue commentedon Feb 10, 2017
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:
Expect: 100-continueheader, the server MAY return an intermediaryHTTP/1.1 100 Continueresponse after receiving the request headers, which causes the client to start transmitting the actual message bodyExpect: 100-continueheader, the server MAY reject the request with any "normal" error response message, which means the client never has to transmit the message body at allHTTP/1.1 100 Continueresponseclue commentedon Feb 10, 2017
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:
This is necessary because this
ifblock 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-Typeor itsContent-Lengthexceeds 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).kelunik commentedon Feb 10, 2017
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.
clue commentedon Mar 3, 2017
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()andwriteContinue()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! 👍
clue commentedon Mar 14, 2017
Closed via #144