benoitc
proper handling of expect 100
-
On a post, request returns status code 100 & headers, I see no indication in the docs as to the proper way to now send the body and wait for the response.
-
Is there an option to disable the adding of the "Expect: 100-continue" header? Consider an "intermediate" node in some micro-services setup, where it is proxying out a request that has been validated, sanitized, & normalized such that there is no chance of the request being rejected based on the headers, no need to incur the extra latency.
@shribe for now it is expected to send the body immediately and then automatically answering. Your usage makes perfect sense for me, I think we could add an option to not return it. Not sure about the wording yet though :)
On Mar 2, 2016, at 1:49 PM, Benoit Chesneau [email protected] wrote:
@shribe for now it is expected to send the body immediately and then automatically answering. Your usage makes perfect sense for me, I think we could add an option to not return it. Not sure about the wording yet though :)
The problem here is that although a careful reading of RFC2616 makes it clear that the client does not have to wait, there are servers which fall over if the body is sent immediately. Not to mention that there is absolutely no point in sending Expect: 100-continue and immediately sending the body. If it's not going to be used correctly, just strip it out (which is what I wound up doing).
Scott Ribe [email protected] http://www.elevated-dev.com/ https://www.linkedin.com/in/scottribe/ (303) 722-0567 voice
@shribe Patches are always welcomes.
Anyway the current implementation does the following: if an expect result is expected it will wait fro at most 1second from the server if a response come. If it timeout then it sends the body: https://github.com/benoitc/hackney/blob/master/src/hackney_response.erl#L59-L70
in other cases the response stop, you will receive the current response and can continue on it by sending a new request.
There is actually an issue with streamed body. Right now you will have to ask by yourself to get the expected response (using hackney_response:expected_response/1) and continue on it or not. The implementation should provides a better workflow to support the RFC 7331.
I am thinking to the following:
On data: return {expect_response, ExpectBody}. Then use the send body method to continue to send the body if needed. or close the connection.
Thoughts?