Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upx/net/http2: Transport should do transparent gzip like HTTP/1 #13298
Comments
This comment has been minimized.
This comment has been minimized.
|
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. |
bradfitz
changed the title
http2 client conn doesn't decode gziped response
x/net/http2: Transport should do transparent gzip like HTTP/1
Nov 18, 2015
bradfitz
self-assigned this
Nov 18, 2015
bradfitz
added this to the Go1.6 milestone
Nov 18, 2015
This comment has been minimized.
This comment has been minimized.
Yes, I looked the code you pointed before. And I wonder why HTTP/1 works fine but HTTP/2 not. |
This comment has been minimized.
This comment has been minimized.
|
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. |
This comment has been minimized.
This comment has been minimized.
http.DefaultTransport.(*http.Transport).DisableCompression = trueI put this on top of code but not. :( |
This comment has been minimized.
This comment has been minimized.
|
But not what? |
This comment has been minimized.
This comment has been minimized.
|
Response always compressed even though I set DisableCompression=true. |
This comment has been minimized.
This comment has been minimized.
|
Additional Information. req.Header.Add("Accept-Encoding", "identity")Twitter still reply gzip response. |
This comment has been minimized.
This comment has been minimized.
karaziox
commented
Nov 21, 2015
|
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. |
This comment has been minimized.
This comment has been minimized.
|
I (or somebody) will implement this before Go 1.6. |
This comment has been minimized.
This comment has been minimized.
gopherbot
commented
Nov 26, 2015
|
CL https://golang.org/cl/17241 mentions this issue. |
This comment has been minimized.
This comment has been minimized.
gopherbot
commented
Nov 26, 2015
|
CL https://golang.org/cl/17242 mentions this issue. |
mattn commentedNov 18, 2015
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