proper handling of expect 100

[shribe]

1. 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.

2. 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.

[benoitc]

@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 :)

[shribe]

On Mar 2, 2016, at 1:49 PM, Benoit Chesneau notifications@github.com 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
scott_ribe@elevated-dev.com
http://www.elevated-dev.com/
https://www.linkedin.com/in/scottribe/
(303) 722-0567 voice

[benoitc]

@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.

[benoitc]

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?

[benoitc]

HTTP 1xx informational responses are now supported via the inform_fun option (PR #808).

Example usage:

InformFun = fun(Status, Reason, Headers) ->
    io:format("Received ~p ~s~n", [Status, Reason])
end,
hackney:request(Method, URL, Headers, Body, [{inform_fun, InformFun}]).

Regarding the second question: hackney does not automatically add the Expect: 100-continue header, so no option is needed to disable it.