Support SendResponse::send_continue #601

rawler · 2022-02-04T13:42:21Z

Support for Expect: 100-continue is mandated as MUST by
https://datatracker.ietf.org/doc/html/rfc7231#section-5.1.1. Yet servers
built on h2 cannot currently support this requirement.

One example of such usage, is hyper #2743.

This approach adds a send_continue method to SendResponse that a server
application can use to implement support itself. This PR does not solve
the feature itself, it merely provides sufficient support for a server
application to implement the functionality as desired.

rawler · 2022-02-04T13:48:54Z

One possible alternate solution, could be to implement more of the functionality directly, by hooking up the first attempt to read the request-body, as a signal to send 100-continue, if the header was there on the Request. Ideally, that would be implemented in Request::into_body, or add the behavior to the first call of RecvStream::poll_data. However, it seemed more invasive than I'd like it to be, and I didn't manage to wire it up in an acceptable way anyways.

rawler · 2022-02-04T13:56:15Z

src/proto/streams/state.rs

@@ -111,7 +111,7 @@ impl State {
                    Open { local, remote }
                }
            }
-            HalfClosedRemote(AwaitingHeaders) | ReservedLocal => {
+            HalfClosedRemote(AwaitingHeaders | Streaming) | ReservedLocal => {


I spent some time thinking about this in particular. There is no documentation on the struct hinting at how to reason about the state, but if I understood it correctly HalfClosedRemote means that we've gotten an EOS from the remote side. HalfClosedRemote(AwaitingHeaders) this side currently haven't written headers yet (the enum-name Peer is a bit misleading here?). This used to encode the rule that headers should only be sent once. With 100-continue in the picture, however, that doesn't really hold true. The easiest way I could see to model this, is to simply relax this rule as proposed here. Perhaps another approach could be feasible? I.E. something not "Opening the send-half", but instead explicitly "finish sending headers"?

The code comments at the top of file include the flow chart from the spec, but the the spec includes more description of each possible state: https://httpwg.org/specs/rfc7540.html#StreamStates.

It looks like your understanding is correct. I've also found the usage of Peer in this crate to be the opposite of what I usually think, but it is consistently used in this file and elsewhere to mean "me" (I usually think of peer as the remote, but I didn't come up with those names 🤷).

However, I think we don't want to change the state here, since sending a HEADERS frame with a 1xx code shouldn't mean it is now waiting to send DATA frames. It still needs to send the "final" code in another HEADERS frame.

seanmonstar · 2022-02-05T00:12:36Z

src/proto/streams/state.rs

@@ -111,7 +111,7 @@ impl State {
                    Open { local, remote }
                }
            }
-            HalfClosedRemote(AwaitingHeaders) | ReservedLocal => {
+            HalfClosedRemote(AwaitingHeaders | Streaming) | ReservedLocal => {


The code comments at the top of file include the flow chart from the spec, but the the spec includes more description of each possible state: https://httpwg.org/specs/rfc7540.html#StreamStates.

It looks like your understanding is correct. I've also found the usage of Peer in this crate to be the opposite of what I usually think, but it is consistently used in this file and elsewhere to mean "me" (I usually think of peer as the remote, but I didn't come up with those names 🤷).

seanmonstar · 2022-02-05T00:14:49Z

src/server.rs

+    /// [`SendResponse`]: #
+    /// [`send_reset`]: #method.send_reset
+    /// [`send_response`]: #method.send_response
+    pub fn send_continue(&mut self) -> Result<(), crate::Error> {


It might be out-of-scope to suggest this, but should we perhaps consider a slightly broader method, that allows sending other informational responses, like 103 Early Hints or future codes? In that case, we'd want to be able to send headers too...

I thought about it when writing the PR, but avoided it since I'm not sure what it's signature should be. send_info(Response<()>) feels a bit too wide, given that practically only 1xx responses are allowed here. OTOH, send_response(Response<()>) is also wider than it technically supports. (Extensions are cleared, the body unused, and the only Version supported really, is HTTP2), so maybe such API is fine.

seanmonstar · 2022-02-05T00:17:39Z

src/proto/streams/state.rs

@@ -111,7 +111,7 @@ impl State {
                    Open { local, remote }
                }
            }
-            HalfClosedRemote(AwaitingHeaders) | ReservedLocal => {
+            HalfClosedRemote(AwaitingHeaders | Streaming) | ReservedLocal => {


However, I think we don't want to change the state here, since sending a HEADERS frame with a 1xx code shouldn't mean it is now waiting to send DATA frames. It still needs to send the "final" code in another HEADERS frame.

rawler · 2022-02-06T20:18:36Z

Thank you 🙏 for a good and clear review. I've changed the according to the feedback.

rawler · 2022-02-25T10:20:12Z

Ping

rawler · 2022-05-02T07:10:43Z

Ping

Support for `Expect: 100-continue` is mandated as MUST by https://datatracker.ietf.org/doc/html/rfc7231#section-5.1.1. Yet servers built on `h2` cannot currently support this requirement. One example of such usage, is [hyper #2743](hyperium/hyper#2743). This approach adds a `send_continue` method to `SendResponse` that a server application can use to implement support itself. This PR does _not_ solve the feature itself, it merely provides sufficient support for a server application to implement the functionality as desired.

… come

rawler · 2022-12-12T23:17:16Z

Ping @seanmonstar

rawler · 2022-12-13T08:15:08Z

Maybe @LucioFranco have some time for a review? 🙏

zh-jq · 2023-04-04T14:22:42Z

Any progress? It's an important feature

zh-jq-b · 2023-06-27T02:26:09Z

@seanmonstar This is ready for a new review, do you have anytime to do it?

rawler commented Feb 4, 2022

View reviewed changes

seanmonstar reviewed Feb 5, 2022

View reviewed changes

rawler requested a review from seanmonstar March 8, 2022 12:58

rawler added 3 commits May 2, 2022 10:45

State::send_open:Add final_response indicating if more headers will…

0001a0f

… come

Change send_continue() into send_info() as per feedback

e8cb240

rawler force-pushed the send-continue branch from bf7d5af to e8cb240 Compare May 2, 2022 08:45

zh-jq-b mentioned this pull request Apr 11, 2023

g3proxy: support 100-Continue in h2 interception bytedance/g3#6

Open

1 task

zh-jq-b mentioned this pull request Feb 18, 2024

Figure out what to do about informational status codes #167

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support SendResponse::send_continue #601

Support SendResponse::send_continue #601

rawler commented Feb 4, 2022

rawler commented Feb 4, 2022

rawler Feb 4, 2022

seanmonstar Feb 5, 2022

seanmonstar Feb 5, 2022

seanmonstar Feb 5, 2022

seanmonstar Feb 5, 2022

rawler Feb 6, 2022

seanmonstar Feb 5, 2022

rawler commented Feb 6, 2022

rawler commented Feb 25, 2022

rawler commented May 2, 2022

rawler commented Dec 12, 2022

rawler commented Dec 13, 2022

zh-jq commented Apr 4, 2023

zh-jq-b commented Jun 27, 2023

Support SendResponse::send_continue #601

Are you sure you want to change the base?

Support SendResponse::send_continue #601

Conversation

rawler commented Feb 4, 2022

rawler commented Feb 4, 2022

rawler Feb 4, 2022

Choose a reason for hiding this comment

seanmonstar Feb 5, 2022

Choose a reason for hiding this comment

seanmonstar Feb 5, 2022

Choose a reason for hiding this comment

seanmonstar Feb 5, 2022

Choose a reason for hiding this comment

seanmonstar Feb 5, 2022

Choose a reason for hiding this comment

rawler Feb 6, 2022

Choose a reason for hiding this comment

seanmonstar Feb 5, 2022

Choose a reason for hiding this comment

rawler commented Feb 6, 2022

rawler commented Feb 25, 2022

rawler commented May 2, 2022

rawler commented Dec 12, 2022

rawler commented Dec 13, 2022

zh-jq commented Apr 4, 2023

zh-jq-b commented Jun 27, 2023