Support SendResponse::send_continue #601
Conversation
|
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 |
src/server.rs
Outdated
| /// [`SendResponse`]: # | ||
| /// [`send_reset`]: #method.send_reset | ||
| /// [`send_response`]: #method.send_response | ||
| pub fn send_continue(&mut self) -> Result<(), crate::Error> { |
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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.
|
Thank you 🙏 for a good and clear review. I've changed the according to the feedback. |
|
Ping |
|
Ping |
|
Ping @seanmonstar |
|
Maybe @LucioFranco have some time for a review? 🙏 |
|
Any progress? It's an important feature |
|
@seanmonstar This is ready for a new review, do you have anytime to do it? |
|
Any update on this @seanmonstar @LucioFranco ? |
|
As discussed on discord, I'm willing to help out in any capacity that you can use me to get this PR shipped. Be it more code contribution, review, testing, docs, ... do let me know. |
| /// [`SendResponse`]: # | ||
| /// [`send_reset`]: #method.send_reset | ||
| /// [`send_response`]: #method.send_response | ||
| pub fn send_info(&mut self, response: Response<()>) -> Result<(), crate::Error> { |
There was a problem hiding this comment.
Perhaps this just needs to document with a # Panics section that passing a response with a non-1xx status code is a misuse of the method.
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_info` 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.
Support for
Expect: 100-continueis mandated as MUST byhttps://datatracker.ietf.org/doc/html/rfc7231#section-5.1.1. Yet servers
built on
h2cannot currently support this requirement.One example of such usage, is hyper #2743.
This approach adds a
send_continuemethod toSendResponsethat a serverapplication 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.