-
Notifications
You must be signed in to change notification settings - Fork 18k
x/net/http2: Transport should do transparent gzip like HTTP/1 #13298
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
Comments
Twitter is replying with "Content-Encoding: gzip" even without "Accept-Encoding: gzip"? The http2 transport is not sending "Accept-Encoding: gzip". Thus, it's not the Go Transport's job to decompress it. The HTTP/1 Transport code only decompresses it when it asks for it itself, using the logic in // Ask for a compressed version if the caller didn't set their
// own value for Accept-Encoding. We only attempt to
// uncompress the gzip stream if we were the layer that
// requested it.
requestedGzip := false
if !pc.t.DisableCompression &&
req.Header.Get("Accept-Encoding") == "" &&
req.Header.Get("Range") == "" &&
req.Method != "HEAD" {
// Request gzip only, not deflate. Deflate is ambiguous and
// not as universally supported anyway.
// See: http://www.gzip.org/zlib/zlib_faq.html#faq38
//
// Note that we don't request this for HEAD requests,
// due to a bug in nginx:
// http://trac.nginx.org/nginx/ticket/358
// https://golang.org/issue/5522
//
// We don't request gzip if the request is for a range, since
// auto-decoding a portion of a gzipped document will just fail
// anyway. See https://golang.org/issue/8923
requestedGzip = true
req.extraHeaders().Set("Accept-Encoding", "gzip")
} So, yes, HTTP/2 should do the same. But it's a little weird that Twitter is replying like that too. |
Yes, I looked the code you pointed before. And I wonder why HTTP/1 works fine but HTTP/2 not. |
It works fine because HTTP/1 is decompressing it because it asked for it. HTTP/2 is not asking for it, so it should not have to decompress it. Twitter should not be sending uncompressed content without "Accept-Encoding: gzip" in the request. Try HTTP/1 with Transport.DisableCompression set to true. I bet it would also fail, if it's a Twitter problem. |
http.DefaultTransport.(*http.Transport).DisableCompression = true I put this on top of code but not. :( |
But not what? |
Response always compressed even though I set DisableCompression=true. |
Additional Information. req.Header.Add("Accept-Encoding", "identity") Twitter still reply gzip response. |
I just hit this problem when doing oauth2 authentication with facebook. It seems the facebook http2 implementation doesn't care for the Accept-Encoding header and sends gzip no matter what. Manually adding the Accept-Encoding: gzip to the request will correctly fix the problem. I suppose this is because a previous draft of the spec required the support for gzip, they removed that since. Seems more of a bug on Twitter/Facebook side than on go. I'll let you judge. |
I (or somebody) will implement this before Go 1.6. |
CL https://golang.org/cl/17241 mentions this issue. |
CL https://golang.org/cl/17242 mentions this issue. |
And updates h2_bundle.go with the fix from x/net/http2. Fixes #13298 Updates #6891 Change-Id: Ia25f22fa10e2a64b9d59211269882681aa18c101 Reviewed-on: https://go-review.googlesource.com/17241 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org>
Tests are in net/http (clientserver_test.go, TestH12_AutoGzip) from https://golang.org/cl/17241 Fixes golang/go#13298 Change-Id: I3f0b237ffdf6d547d57f29383e1a78c4f272fc44 Reviewed-on: https://go-review.googlesource.com/17242 Reviewed-by: Andrew Gerrand <adg@golang.org>
try with your consumer keys. twitter send http2 response in recently.
the response Body should be decoded because content-encoding is gzip. but not decoded Body.
/cc @bradfitz
The text was updated successfully, but these errors were encountered: