[twitter-dev] Re: Twitter API and ETags - No 304s?
On Feb 22, 1:31 pm, Tim Haines tmhai...@gmail.com wrote: The Twitter API returns ETags, that seem to change when the content changes and otherwise not. It doesn't seem to return 304's when the same ETag is sent back to it though. Has anyone seen it send 304s? The API always seem to return no-cache and past expiry headers, it *does* send 304's when you pass the etag in a If-None-Match header: $ curl --head http://twitter.com/users/show.xml?screen_name=philoye HTTP/1.1 200 OK Date: Wed, 24 Feb 2010 01:13:10 GMT Server: hi X-RateLimit-Limit: 150 X-Transaction: 1266973990-97869-341 Status: 200 OK ETag: 3022db84cebe898b561a397c20063f5e Last-Modified: Wed, 24 Feb 2010 01:13:10 GMT X-RateLimit-Remaining: 136 X-Runtime: 0.02109 Content-Type: application/xml; charset=utf-8 Pragma: no-cache Content-Length: 2057 X-RateLimit-Class: api Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post- check=0 Expires: Tue, 31 Mar 1981 05:00:00 GMT X-Revision: DEV X-RateLimit-Reset: 1266976693 Set-Cookie: _twitter_sess=BAh7CDoRdHJhbnNfcHJvbXB0MDoHaWQiJTA0MWYzMTQyNGZjMjU5MTJlYWQz %250AOWU1MzhhMmYxZTkzIgpmbGFzaElDOidBY3Rpb25Db250cm9sbGVyOjpGbGFz %250AaDo6Rmxhc2hIYXNoewAGOgpAdXNlZHsA-- ba31f1ea9e0800e1b4c3d564484c8fdf6885183d; domain=.twitter.com; path=/ Vary: Accept-Encoding Connection: close $ curl --head --header 'If-None-Match: 3022db84cebe898b561a397c20063f5e' http://twitter.com/users/show.xml?screen_name=philoye HTTP/1.1 304 Not Modified Date: Wed, 24 Feb 2010 01:13:41 GMT Server: hi Connection: close ETag: 3022db84cebe898b561a397c20063f5e Expires: Tue, 31 Mar 1981 05:00:00 GMT Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post- check=0 Vary: Accept-Encoding Set-Cookie: _twitter_sess=BAh7CDoHaWQiJTRiYTlkN2RlODVhN2NlNmMzMWM3MWY4Y2FhNGUwZjc4Igpm %250AbGFzaElDOidBY3Rpb25Db250cm9sbGVyOjpGbGFzaDo6Rmxhc2hIYXNoewAG %250AOgpAdXNlZHsAOhF0cmFuc19wcm9tcHQw-- fce6e5410dc71d9720ac35c5470bc7220e8b4ceb; domain=.twitter.com; path=/ The key is to send the ETag in a If-None-Match header, not an ETag header. I still don't understand why the Cache-Control and Expires headers are set this way though. Cheers, p.
Re: [twitter-dev] Re: Twitter API and ETags - No 304s?
Hi Phil, Thanks for sending through the examples. I must have been setting the header incorrectly - missing the quotes or something. It does indeed work for favorites too, whether authenticated or not.. Tim. On Wed, Feb 24, 2010 at 2:15 PM, philoye phil...@gmail.com wrote: On Feb 22, 1:31 pm, Tim Haines tmhai...@gmail.com wrote: The Twitter API returns ETags, that seem to change when the content changes and otherwise not. It doesn't seem to return 304's when the same ETag is sent back to it though. Has anyone seen it send 304s? The API always seem to return no-cache and past expiry headers, it *does* send 304's when you pass the etag in a If-None-Match header: $ curl --head http://twitter.com/users/show.xml?screen_name=philoye HTTP/1.1 200 OK Date: Wed, 24 Feb 2010 01:13:10 GMT Server: hi X-RateLimit-Limit: 150 X-Transaction: 1266973990-97869-341 Status: 200 OK ETag: 3022db84cebe898b561a397c20063f5e Last-Modified: Wed, 24 Feb 2010 01:13:10 GMT X-RateLimit-Remaining: 136 X-Runtime: 0.02109 Content-Type: application/xml; charset=utf-8 Pragma: no-cache Content-Length: 2057 X-RateLimit-Class: api Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post- check=0 Expires: Tue, 31 Mar 1981 05:00:00 GMT X-Revision: DEV X-RateLimit-Reset: 1266976693 Set-Cookie: _twitter_sess=BAh7CDoRdHJhbnNfcHJvbXB0MDoHaWQiJTA0MWYzMTQyNGZjMjU5MTJlYWQz %250AOWU1MzhhMmYxZTkzIgpmbGFzaElDOidBY3Rpb25Db250cm9sbGVyOjpGbGFz %250AaDo6Rmxhc2hIYXNoewAGOgpAdXNlZHsA-- ba31f1ea9e0800e1b4c3d564484c8fdf6885183d; domain=.twitter.com; path=/ Vary: Accept-Encoding Connection: close $ curl --head --header 'If-None-Match: 3022db84cebe898b561a397c20063f5e' http://twitter.com/users/show.xml?screen_name=philoye HTTP/1.1 304 Not Modified Date: Wed, 24 Feb 2010 01:13:41 GMT Server: hi Connection: close ETag: 3022db84cebe898b561a397c20063f5e Expires: Tue, 31 Mar 1981 05:00:00 GMT Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post- check=0 Vary: Accept-Encoding Set-Cookie: _twitter_sess=BAh7CDoHaWQiJTRiYTlkN2RlODVhN2NlNmMzMWM3MWY4Y2FhNGUwZjc4Igpm %250AbGFzaElDOidBY3Rpb25Db250cm9sbGVyOjpGbGFzaDo6Rmxhc2hIYXNoewAG %250AOgpAdXNlZHsAOhF0cmFuc19wcm9tcHQw-- fce6e5410dc71d9720ac35c5470bc7220e8b4ceb; domain=.twitter.com; path=/ The key is to send the ETag in a If-None-Match header, not an ETag header. I still don't understand why the Cache-Control and Expires headers are set this way though. Cheers, p.
[twitter-dev] Re: Twitter API and ETags - No 304s?
On Feb 24, 1:20 pm, Tim Haines tmhai...@gmail.com wrote: Thanks for sending through the examples. I must have been setting the header incorrectly - missing the quotes or something. It does indeed work for favorites too, whether authenticated or not.. Good to hear... I was having the same problem. First I was stupidly sending the ETag header instead of If-None-Match, then I wrapped quotes incorrectly. For anyone else, via curl, you need to wrap the ETag in double quotes and the whole header in single quotes. Or at least I did on my box, like so (extra spaces added for clarity). --header ' If-None-Match: 3022db84cebe898b561a397c20063f5e '
[twitter-dev] Re: Twitter API and ETags - No 304s?
I noticed this too, also noticed that Twitter sends no-cache header and expiration far in the past, which is just another way to tell browser not to cache anything. You can find my recent post here under subject Why do you sent no- cache headers I don't know why they sending Etag then, looks like it's half- implemented, maybe they are still working on implementing the correct way to deal with conditional requests. Since they probably don't store static files, it requires some extra programming to parse the conditional requests and then decide if to return 304 Not modified or an actual 200 response. On Feb 21, 9:31 pm, Tim Haines tmhai...@gmail.com wrote: Hey guys, The Twitter API returns ETags, that seem to change when the content changes and otherwise not. It doesn't seem to return 304's when the same ETag is sent back to it though. Has anyone seen it send 304s? I'm making calls against the method to retrieve favorited tweets. Tim.
