If you can’t handle gzip content, it is probably best to avoid using HTTP/2 unless you know the server follows h2-13 or later where mandatory GZIP compression support in clients was dropped from the spec.
Up until this point the draft HTTP/2 spec stated that clients MUST support GZIP content-encoding and that servers MAY send responses with GZIP encoding regardless of the value of the Accept-Encoding header.
api.twitter.com still supports SPDY/3.1, where clients MUST support GZIP.
Although api.twitter.com advertises h2 support, it looks like they are using a server (and/or a server configuration) that is ignorant of the fact section 9.3 was dropped from the HTTP/2 spec. It could also be SPDY support adds in the GZIP assumption and it might be difficult to remove that assumption from the server code without removing SPDY support.
From HTTPbis New York Interim Minutes, 5 June 2014:
roberto: we need a new error code or new http semantics to force downgrade to http/1.1
will keeps arguing about making sure we don’t resolve the issue too soon without having a reasonable option to preserve the performance improvement
end resolution was to remove implicit gzip and google folks are supposed to put up a proposal for coming up with a ratchet / hard fail solution to move first to lock in support for compression, so any intermediary that tries to break it afterward will cause a hard fail.
