-
Notifications
You must be signed in to change notification settings - Fork 127
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
Range-Requests aren't properly handled #83
Comments
klauspost
added a commit
to klauspost/compress
that referenced
this issue
Jun 2, 2021
Fixes nytimes/gziphandler#83 Adds `KeepAcceptRanges()` if for whatever reason you would want to keep them.
klauspost
added a commit
to klauspost/compress
that referenced
this issue
Jun 2, 2021
Fork and clean up+extend the dead `nytimes/gziphandler` project. * Adds `http.Transport` wrapper. * Includes nytimes/gziphandler#106 as well as support for stateless encoding. * Implements a variant of nytimes/gziphandler#81 * Fixes nytimes/gziphandler#103 * Strip "Accept-Ranges" on compressed content. Fixes nytimes/gziphandler#83 * Removes testify from deps. * Constructors boiled down. * Defaults to this gzip package. * Allocations reduced. Default settings comparison: ``` λ benchcmp before.txt after.txt benchmark old ns/op new ns/op delta BenchmarkGzipHandler_S2k-32 51302 25554 -50.19% BenchmarkGzipHandler_S20k-32 301426 174900 -41.98% BenchmarkGzipHandler_S100k-32 1546203 912349 -40.99% BenchmarkGzipHandler_P2k-32 3973 2116 -46.74% BenchmarkGzipHandler_P20k-32 20319 12237 -39.78% BenchmarkGzipHandler_P100k-32 96079 57348 -40.31% benchmark old MB/s new MB/s speedup BenchmarkGzipHandler_S2k-32 39.92 80.14 2.01x BenchmarkGzipHandler_S20k-32 67.94 117.10 1.72x BenchmarkGzipHandler_S100k-32 66.23 112.24 1.69x BenchmarkGzipHandler_P2k-32 515.44 967.76 1.88x BenchmarkGzipHandler_P20k-32 1007.92 1673.55 1.66x BenchmarkGzipHandler_P100k-32 1065.79 1785.58 1.68x benchmark old allocs new allocs delta BenchmarkGzipHandler_S2k-32 22 19 -13.64% BenchmarkGzipHandler_S20k-32 25 22 -12.00% BenchmarkGzipHandler_S100k-32 28 25 -10.71% BenchmarkGzipHandler_P2k-32 22 19 -13.64% BenchmarkGzipHandler_P20k-32 25 22 -12.00% BenchmarkGzipHandler_P100k-32 27 24 -11.11% ``` Client Transport: Speed compared to standard library for an approximate 127KB payload: ``` BenchmarkTransport Single core: BenchmarkTransport/gzhttp-32 1995 609791 ns/op 214.14 MB/s 10129 B/op 73 allocs/op BenchmarkTransport/stdlib-32 1567 772161 ns/op 169.11 MB/s 53950 B/op 99 allocs/op Multi Core: BenchmarkTransport/gzhttp-par-32 29113 36802 ns/op 3548.27 MB/s 11061 B/op 73 allocs/op BenchmarkTransport/stdlib-par-32 16114 66442 ns/op 1965.38 MB/s 54971 B/op 99 allocs/op ``` This includes both serving the http request, parsing requests and decompressing.
CAFxX
added a commit
to CAFxX/httpcompression
that referenced
this issue
Jan 25, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When wrapping a handler that supports HTTP Range-Requests (e.g.
http.FileServer
), gziphandler relays them as-is, thus violating the HTTP standard and breaking clients.That means, currently, gziphandler compresses ranges returned by the wrapped handler instead of returning ranges of the compressed output (of the complete wrapped content).
The HTTP standard basically says that
Content-Length
is the size of theContent-Encoding
output and that range requests specify ranges into theContent-Encoding
encoded output, as well.Expected behavior: Either (a) gziphandler filters out the
Accept-Ranges: bytes
headers in wrapped handler responses (and anyRange:
headers in passed requests), or, (b) it handles Range-Requests on its own and doesn't pass them down to the wrapped handler.Note that implementing (b) would be kind of complicated, e.g. a range that is smaller than the configured minSize would have to trigger a compression up to the range end.
How to reproduce:
Create a handler like this:
Request a full compressed page:
Note how the Content-Length is the size of the compressed content, as expected.
Getting a range:
Note the following issues:
And the range isn't a prefix of the previous result:
Another range request:
Similar issues as before and the range isn't gzip-compressed.
The text was updated successfully, but these errors were encountered: