go.httpgzip icon indicating copy to clipboard operation
go.httpgzip copied to clipboard

Problem with partial responses (Content-Range)

Open joliss opened this issue 12 years ago • 3 comments

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.

joliss avatar Sep 29 '13 15:09 joliss

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 :)

daaku avatar Sep 30 '13 17:09 daaku

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.)

joliss avatar Oct 05 '13 14:10 joliss

Another problem might be ETags btw - I believe they may need to be different for the compressed and uncompressed resource.

One way to deal with that is to weaken the ETag.

gsauthof avatar May 12 '19 12:05 gsauthof