Skip to content
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

Introduce explicit support for informational responses. #42

Merged
merged 4 commits into from
Sep 12, 2023

Conversation

ioquatix
Copy link
Member

@ioquatix ioquatix commented Sep 11, 2023

The first step to support handling informational responses correctly is to expose the abstract model.

I'm not convinced 101 Switching Protocols is a non-final response in practice. Because there is no subsequent "final response".

This would be used in Async::HTTP like so:

image

More discussion here: socketry/async-http#134

cc @zarqman wdyt?

Types of Changes

  • New feature.

Contribution

@ioquatix ioquatix force-pushed the informational-response branch from bcaae82 to 02db800 Compare September 11, 2023 08:08
@zarqman
Copy link
Contributor

zarqman commented Sep 11, 2023

From the perspective of async-http's request/response cycle, I agree that 101 is functionally a final response.

From the connection/stream perspective, the 101 is non-final since the connection/stream continues on, albeit on a different protocol. For example, with websockets, the websocket stream itself is the "final" part of the response.

FWIW, RFC9110 uses "final" to contrast between 1xx and everything else (and "interim" as its inverse). I don't know if it's important to you to match terminology between protocol-http and the RFC or not. I'm not particular either way, and you've clarified intent in a comment already anyway.

As for the usage example above, it would loop when !parts which is a change from present behavior. Otherwise, makes sense enough. 👍

@ioquatix
Copy link
Member Author

From the connection/stream perspective, the 101 is non-final since the connection/stream continues on, albeit on a different protocol. For example, with websockets, the websocket stream itself is the "final" part of the response.

Even for final status codes like 200, the connection/stream continues on with a body - there is no significant practical difference in the implementation between 101 and 200 in this case.

FWIW, RFC9110 uses "final" to contrast between 1xx and everything else (and "interim" as its inverse). I don't know if it's important to you to match terminology between protocol-http and the RFC or not. I'm not particular either way, and you've clarified intent in a comment already anyway.

Basically, I don't agree with the RFCs terminology. In particular, HTTP/2 WebSockets do use 200 OK which I think is strong evidence that the identical usage in HTTP/1 of 101 is expected to be final. Calling 101 "non-final" is very confusing as you said, in the expected usage, it's considered final, as there is no further response status code expected. This is completely different from 100 and 103 where we do expect a final status code to come.

@ioquatix
Copy link
Member Author

I discussed this in more detail here: httpwg/http-core#1108

@ioquatix ioquatix merged commit 6c533bf into main Sep 12, 2023
@ioquatix ioquatix deleted the informational-response branch September 12, 2023 06:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants