Clojurians Log v2
aleph
Fast and furious standards-debating action! 😄 https://lists.w3.org/Archives/Public/ietf-http-wg/2023JulSep/0183.html I'm trialling h2spec to validate Aleph's H2 server behavior, and on one of h2spec's issues, I responded with a disagreement about an interpretation of https://www.rfc-editor.org/rfc/rfc9113.html. After a little back and forth, I asked one of the RFC authors for clarification, he put it to the HTTP working group, and...there doesn't seem to be agreement among the experts, unfortunately. Since Aleph's not wedded to an implementation yet, do users have a preference for HTTP errors? Specifically, if it's possible, would you prefer HTTP 4xx/5xx responses (when possible) or "reset stream"/"go away" errors? The HTTP 4xx/5xx responses have the advantage of being able to provide a specific error message in the body. The "reset stream"/"go away" frames are handled via exception mechanisms (since the client will probably never get an HTTP response after getting RST_STREAM/GOAWAY), so you will get instant feedback that something went wrong. Their disadvantage is the available https://www.rfc-editor.org/rfc/rfc9113.html#name-error-codes are pretty generic, more so than even HTTP status codes.
By no means an authority on the subject, but +1 for HTTP responses when possible.
Ho boy 🙈 Glad to see that even the Big Boys ™️ have these kinds of issues. Hits quite close to home with regards to similar issues we're debating on our custom protocol 😄 FWIW, I find https://lists.w3.org/Archives/Public/ietf-http-wg/2023JulSep/0188.html and https://lists.w3.org/Archives/Public/ietf-http-wg/2023JulSep/0197.html to be very reasonable interpretations
reading that paragraph i get the impression that you must give the reset stream/go away errors, but you may also send a http response. if so i'd do both where possible (the more info the better)
The more I think about it, the more I'm leaning towards both. Response, then RST_STREAM. This assumes that can be done safely, but for us, it originally arose in the context of missing pseudo-headers, where it should be fine.
Where it gets tricky is if a stream error arises after the user handler has been called, in which case, we can't send an HTTP response, because the user handler may have already started writing.
That's probably rare for simple request / response streams, but more likely for long-lived streams that are, errr, streaming.
Right, in the latter case, I think the only option is RST_STREAM
I agree: Where possible, do both
(which is also what the posts I linked to reason for)