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

Ensure streaming ResponseWriters implement Flush #406

Merged
merged 3 commits into from
Nov 30, 2022
Merged

Conversation

akshayjshah
Copy link
Member

The http.Flusher interface isn't part of the http.ResponseWriter
interface, but it's implemented by the HTTP/1 and HTTP/2 writers
provided by the standard library. It's also critical to Connect:
streaming handlers must flush messages to ensure that the client
receives them. This PR adds a check for unflushable response writers;
when the response writer for a streaming procedure can't be flushed, we
now return an explicit error instead of hanging.

Fixes #393.

The `http.Flusher` interface isn't part of the `http.ResponseWriter`
interface, but it's implemented by the HTTP/1 and HTTP/2 writers
provided by the standard library. It's also critical to Connect:
streaming handlers must flush messages to ensure that the client
receives them. This PR adds a check for unflushable response writers;
when the response writer for a streaming procedure can't be flushed, we
now return an explicit error instead of hanging.

Fixes #393.
Copy link
Contributor

@jchadwick-buf jchadwick-buf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Thanks for the quick follow-up.

@joshcarp
Copy link
Contributor

joshcarp commented Nov 29, 2022

I don't quite understand why this needs to be checked within the handler itself; wouldn't it be safer if it failed at creation of the connect.NewServerStreamHandler or connect.NewBidiStreamHandler and fail at startup instead?

Edit: I guess that the http.ResponseWriter isn't determined in NewBidiStreamHandler so this wouldn't be possible 🙃

@joshcarp joshcarp closed this Nov 29, 2022
@joshcarp joshcarp reopened this Nov 29, 2022
@joshcarp
Copy link
Contributor

whoops, apologies

@akshayjshah
Copy link
Member Author

I'm not sure why the build is failing on Windows :/ I won't be able to dig into it until late tonight (at the earliest) - if anyone else has time and is interested, please take a look! (Just ping this thread so nobody else picks it up at the same time.)

@pkwarren
Copy link
Contributor

pkwarren commented Nov 30, 2022

I'm not sure why the build is failing on Windows :/ I won't be able to dig into it until late tonight (at the earliest) - if anyone else has time and is interested, please take a look! (Just ping this thread so nobody else picks it up at the same time.)

@akshayjshah - Pushed a fix which should resolve the test failure. The testTrailerWriter wasn't deleting trailers set with the Trailer header.

@akshayjshah akshayjshah merged commit 9a4d409 into main Nov 30, 2022
@akshayjshah akshayjshah deleted the ajs/flush branch November 30, 2022 04:13
akshayjshah added a commit that referenced this pull request Dec 2, 2022
In #406, I was too cavalier about `net/http.ResponseWriter`'s API to
send HTTP trailers. Because we're not calling `WriteHeader` before
between predeclaring our trailers and actually setting the trailer
values, we end up sending the same data as both HTTP headers and
trailers.
akshayjshah added a commit that referenced this pull request Dec 5, 2022
In #406, I was too cavalier about `net/http.ResponseWriter`'s API to
send HTTP trailers. Because we're not calling `WriteHeader` before
between predeclaring our trailers and actually setting the trailer
values, we end up sending the same data as both HTTP headers and
trailers.
akshayjshah added a commit that referenced this pull request Jul 26, 2023
In #406, I was too cavalier about `net/http.ResponseWriter`'s API to
send HTTP trailers. Because we're not calling `WriteHeader` before
between predeclaring our trailers and actually setting the trailer
values, we end up sending the same data as both HTTP headers and
trailers.
emcfarlane added a commit that referenced this pull request Feb 16, 2024
This PR bumps the go version to 1.22 and the min version to 1.20. This
was prompted by a CI failure which I believe is related to this issue:
golang/go#55846.

Also included is a removal of a workaround for go1.19 header handling
introduced here in #406.
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.

Feature: Return error if ResponseWriter does not implement Flush() for streaming RPCs.
4 participants