Content-Encoding not specified in response headers

[swimfergs]

Using xAuth (we are approved) to request an access token (https://api.twitter.com/oauth/access_token) as per the API instructions:

If I specify an “Accept-Encoding: deflate, gzip” header in the request (something that our http lib does automatically), I receive a response from Twitter that is definitely zipped, yet there is no Content-Encoding header in the response (see below). Our http lib looks for the encoding specification and acts accordingly. Is this lack of a Content-Encoding header a bug?

Thanks!

Date: Tue, 13 Mar 2012 18:44:15 GMT
Status: 200 OK
X-Frame-Options: SAMEORIGIN
Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0
X-MID: 9d68f9ba816cd125576c995bc1647051b699526b
Content-Type: text/html; charset=utf-8
X-Transaction: 36d56a3fd558837b
X-Runtime: 0.05034
ETag: "9b6ea92a482dcd6e729e2ad5c250126e"
Strict-Transport-Security: max-age=631138519
Pragma: no-cache
Expires: Tue, 31 Mar 1981 05:00:00 GMT
Last-Modified: Tue, 13 Mar 2012 18:44:15 GMT
Set-Cookie: k=10.34.250.117.1331664255324786; path=/; expires=Tue, 20-Mar-12 18:44:15 GMT; domain=.twitter.com
Set-Cookie: guest_id=xx; domain=.twitter.com; path=/; expires=Fri, 14-Mar-2014 06:44:15 GMT
Set-Cookie: auth_token=xx; domain=.twitter.com; path=/; HttpOnly
Set-Cookie: auth_token_session=true; domain=.twitter.com; path=/
Set-Cookie: auth_token=xx; domain=.twitter.com; path=/; secure;

[kurrik]

Are you positive that you don’t see it? I just tried a request via cURL and it was in the output:

[kurrik@ ~] 14$ curl --request 'POST' 'https://api.twitter.com/oauth/access_token' --data 'x_auth_mode=client_auth&x_auth_password=PASSWORD&x_auth_username=USERNAME' --header 'Accept-Encoding: deflate,gzip' --header 'Authorization: OAuth realm="", oauth_nonce="65168955", oauth_consumer_key="CONSUMERKEY", oauth_timestamp="1331675532", oauth_signature_method="HMAC-SHA1", oauth_version="1.0", oauth_signature="DupvCY6IXLgH1YK5KLyt6Bkm0as%3D"' --verbose * About to connect() to api.twitter.com port 443 (#0) * Trying 199.59.148.87... connected * Connected to api.twitter.com (199.59.148.87) port 443 (#0) * SSLv3, TLS handshake, Client hello (1): * SSLv3, TLS handshake, Server hello (2): * SSLv3, TLS handshake, CERT (11): * SSLv3, TLS handshake, Server finished (14): * SSLv3, TLS handshake, Client key exchange (16): * SSLv3, TLS change cipher, Client hello (1): * SSLv3, TLS handshake, Finished (20): * SSLv3, TLS change cipher, Client hello (1): * SSLv3, TLS handshake, Finished (20): * SSL connection using RC4-SHA * Server certificate: * subject: C=US; ST=California; L=San Francisco; O=Twitter, Inc.; OU=Twitter Platform; CN=api.twitter.com * start date: 2010-05-18 00:00:00 GMT * expire date: 2012-05-17 23:59:59 GMT * common name: api.twitter.com (matched) * issuer: C=US; O=VeriSign, Inc.; OU=VeriSign Trust Network; OU=Terms of use at https://www.verisign.com/rpa (c)09; CN=VeriSign Class 3 Secure Server CA - G2 * SSL certificate verify ok. > POST /oauth/access_token HTTP/1.1 > User-Agent: curl/7.21.4 (universal-apple-darwin11.0) libcurl/7.21.4 OpenSSL/0.9.8r zlib/1.2.5 > Host: api.twitter.com > Accept: */* > Accept-Encoding: deflate,gzip > Authorization: OAuth realm="", oauth_nonce="65168955", oauth_consumer_key="CONSUMERKEY", oauth_timestamp="1331675532", oauth_signature_method="HMAC-SHA1", oauth_version="1.0", oauth_signature="DupvCY6IXLgH1YK5KLyt6Bkm0as%3D" > Content-Length: 75 > Content-Type: application/x-www-form-urlencoded > < HTTP/1.1 200 OK < Date: Tue, 13 Mar 2012 21:52:25 GMT < Status: 200 OK < X-Runtime: 0.06989 < ETag: "fd9198ba494b69a8ec7aa8427ce7cd49" < Strict-Transport-Security: max-age=631138519 < X-Frame-Options: SAMEORIGIN < X-MID: d9669284f2b7097b8bb3760b064db0872429dfb3 < Content-Type: text/html; charset=utf-8 < X-Transaction: 64f10989ba3d749e < Pragma: no-cache < Last-Modified: Tue, 13 Mar 2012 21:52:25 GMT < Expires: Tue, 31 Mar 1981 05:00:00 GMT < Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0 < Set-Cookie: ... BUNCH OF COOKIES ... < Vary: Accept-Encoding < Content-Encoding: gzip < Content-Length: 176 < Server: tfe < * Connection #0 to host api.twitter.com left intact * Closing connection #0 * SSLv3, TLS alert, Client hello (1): ???? (GZIP DATA) ????

Note that it showed up below the Set-Cookie headers, in a section which appears to be cut off from your paste. I don’t see a Content-Length or Server header in your response which we would serve as well.

[swimfergs]

Thanks for the reply. I definitely have’t ruled out the possibility that the response I’m seeing vs. the response that is being delivered aren’t identical. Unfortunately I can only access the headers in the response via an api to the library we’re using, and so I can’t be sure I’m seeing all that was sent. The source code that I do have access to has a code path that looks for and handles Content-Encoding in the response. If you’re certain that Content-Encoding is always set in responses, then I’m satisfied with that and will find a work-around on my end.

Thanks again.

[kurrik]

Well I’m certain that I’ve seen the header returned. I’m not certain that it is always returned though. I would suggest testing using twurl or some other non-library way of issuing an OAuth-signed HTTP request from your server. If you do find a case where the response comes back without the header, I would consider that an error (and we’d be thankful if you would let us know!)