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

How to force flushing from the wrapped handler? #87

Open
wmertens opened this issue Jul 24, 2019 · 4 comments · Fixed by klauspost/compress#386
Open

How to force flushing from the wrapped handler? #87

wmertens opened this issue Jul 24, 2019 · 4 comments · Fixed by klauspost/compress#386

Comments

@wmertens
Copy link

I would like to quickly flush from one of my handlers but the response is too small and it ignores the flush.

As a workaround, I set the minsize to 0. What can I do to force flushing?

@jprobinson
Copy link
Contributor

I'm not quite sure I follow the problem, sorry. Could you please provide more context as to what you're trying to do?

The MinSize value is set because gzip provides no benefit if the response is small enough. I don't believe it has anything to do with actually "flushing" the response in HTTP terms.

@wmertens
Copy link
Author

I'm running into

gziphandler/gzip.go

Lines 252 to 255 in dd04395

// Only flush once startGzip or startPlain has been called.
//
// Flush is thus a no-op until we're certain whether a plain
// or gzipped response will be served.
- it seems more logical to me to always flush when a flush is requested…

@jprobinson
Copy link
Contributor

If there's nothing to flush....what would we flush there? It gets back to the point that if a response is too small, there's no benefit to gzip it and if there's nothing yet written, there's nothing to flush?

It sounds like having no MinSize actually is what you want then?

@wmertens
Copy link
Author

Well, I would argue that when I call .Flush(), it shouldn't be ignored, and if not enough bytes came in to justify compression yet, it should either just turn off compression for this response, or turn it on to be on the safe side in case it will be a long-lived response, but not simply ignore the flush.

Minsize is a workaround, so now other responses that don't need flushing but are still small will still get the compression overhead.

It took me some digging to find why it wasn't flushing… At the very least it could be mentioned?

klauspost added a commit to klauspost/compress that referenced this issue Jun 3, 2021
klauspost added a commit to klauspost/compress that referenced this issue Jun 3, 2021
* gzhttp: Support Flush always

Fixes nytimes/gziphandler#87
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 a pull request may close this issue.

2 participants