Improving the Twitter API support for HTTP/2



Today, the Twitter API compresses HTTP/2 responses in the same way it does for SPDY responses - specifically, by assuming remote peers can always accept GZIP and DEFLATE formats.

Although this behaviour is part of the SPDY specification, it is not part of the HTTP/2 specification. This behaviour often surprises clients that find that the Accept-Encoding HTTP header is sometimes ignored (which can be dependent on the API endpoint being called), and that they receive compressed data instead of plain text, for example.

From early January 2018*, the Twitter API will be changing to always respect the Accept-Encoding header for HTTP/2 requests, in order to comply with the specification.

Note that there is no planned change to the way in which the API will respond to HTTP/1.1 requests.

* The current plan is for this improved behaviour to be enabled in the first week of January, but this is subject to change

Twitter API doesn't look header Accept-Encoding: identity
closed #2


This change has now been implemented.