New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expect: 100-continue #114

Merged
merged 3 commits into from Apr 6, 2015

Conversation

Projects
None yet
2 participants
@romanb
Contributor

romanb commented Apr 6, 2015

This PR proposes an implementation for the HTTP 1.1 Expect: 100-continue / 100 Continue interaction whereby the client only sends the request body once it has received the 100 Continue. The behaviour (including timeout behaviour) when Expect: 100-continue is not set should be identical to the way it is now. If the header is set, two timeouts apply, the first for waiting on the 100 Continue and the second for waiting on the final response.

Context / Motivation

For completeness, the specific situation where I ran into the need for this feature is a service that streams uploads from clients directly to S3. S3 closes idle connections quite aggressively after ~5 seconds. When these connections (in state CLOSE_WAIT) then end up being used for another upload before being closed by the Manager, part or all of the request body is pushed into the "dead" socket (buffer) and thus lost due to the source not being repeatable. That the connection is closed is usually not immediately discovered during sending, depending on how much data is being sent, but eventually fails quickly on receiving with NoResponseDataReceived. The subsequent retry on a new connection is then doomed to time out due to part of the data being gone already.
By expecting a 100 Continue, the closed connection is guaranteed to be detected before the body is being sent. In the context of S3 it is also a good mechanism to handle potential redirects without sending (parts of) the body twice. For these reasons, it seems to be a good idea to use Expect: 100-continue for streaming S3 uploads from non-repeatable sources.

@snoyberg

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg Apr 6, 2015

Owner

The motivation and implementation both look good. I'm just reviewing a little bit further. Thank you for the contribution!

Owner

snoyberg commented Apr 6, 2015

The motivation and implementation both look good. I'm just reviewing a little bit further. Thank you for the contribution!

@snoyberg

This comment has been minimized.

Show comment
Hide comment
@snoyberg

snoyberg Apr 6, 2015

Owner

I've reviewed and released this to Hackage as 0.4.10, thanks again!

Owner

snoyberg commented Apr 6, 2015

I've reviewed and released this to Hackage as 0.4.10, thanks again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment