You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Go's net/http/fs.go sets the Content-Range header based on offsets in the uncompressed files.
But the Content-Range header applies to entity-body (RFC 2616):
14.16 Content-Range
The Content-Range entity-header is sent with a partial entity-body to
specify where in the full entity-body the partial body should be
applied.
And entity-body is defined as the gzipped stream:
entity-body := Content-Encoding( Content-Type( data ) )
So I believe that if we try to apply gzip encoding transparently, partial responses will become garbled.
I haven't actually tested whether this is a problem, but since I just spent half an hour investigating the RFC, I figured I'd share this with you.
The text was updated successfully, but these errors were encountered:
Ah, good to know. I'm not terribly familiar with how partial responses work, will try to write some test cases up and see what happens. Or feel free to send a pull request :)
Another problem might be ETags btw - I believe they may need to be different for the compressed and uncompressed resource. (All of this is trouble because the protocol is kinda broken when it comes to compression.)
Go's net/http/fs.go sets the Content-Range header based on offsets in the uncompressed files.
But the Content-Range header applies to
entity-body
(RFC 2616):And
entity-body
is defined as the gzipped stream:So I believe that if we try to apply gzip encoding transparently, partial responses will become garbled.
I haven't actually tested whether this is a problem, but since I just spent half an hour investigating the RFC, I figured I'd share this with you.
The text was updated successfully, but these errors were encountered: