OAUTH seems to have broken?

paulousky · 2011-12-22T09:18:32.000Z

Asked Hammock devs
https://github.com/danielcrenna/hammock/issues/59

deepra_uk · 2011-12-22T10:09:19.000Z

Same issue here. Tried with my client, Seesmic, and it doesn’t work for either.
I am getting a bunch of garbage characters as the response. Hope a solution is found for this ASAP.

deepra_uk · 2011-12-22T10:23:44.000Z

It appears that the problem is limited…
When I try to connect using Hootsuite’s web application, the Oauth seems to work fine.

paulousky · 2011-12-22T12:00:27.000Z

probably, it does not use hammock. Seesmic does

marco · 2011-12-22T12:00:58.000Z

Hi,

we noticed that we get gzip encoded data from the servers, which apparently breaks Hammock, even if we pass in ‘Accept-Encoding: identity’ - the response has ‘Content-Encoding: gzip’ set. I would consider that a violation of the HTTP protocol, no?

We also don’t get this for all users - some actually are able to use our apps that use Hammock just fine, so this might be an issue only on some of the frontend API servers.

Thanks,
Marco

dotMorten · 2011-12-22T15:25:32.000Z

I extended hammock to support gzip and I still see the problem

aeayala · 2011-12-22T15:36:15.000Z

I also I have problems with the api, sometimes I have no answer and I can show messages but not others.

aMikey_ · 2011-12-22T15:36:41.000Z

I had a similar issue to this on a different endpoint, but found that the code that was calling twitter wasn’t taking into account varying content types - ie it was not expecting a gzipped response. This code was working up until a couple of days ago, so presumably something was changed with respect to responses on the twitter side.

After updating our code to check the response content type (which it should have done regardless, probably) it now works fine, though your mileage may vary.

-Mike

mrcfield · 2011-12-22T17:01:01.000Z

Is anyone from Twitter investigating this at all?

dotMorten · 2011-12-22T17:26:02.000Z

Actually I take my previous statement back. The particular OAuth process didn’t use gzip encoding. I added gzip support to this as well, and it just started working again. So basically all you have to do is gzip decode if the response header says its encoded with gzip.
I would agree with what someone else who pointed out that returning gzip when not requesting gzip is breaking with the HTML spec.
I can also confirm the findings that it’s not consistent when gzip is returned and when it isn’t.

cheekyTaurusWP · 2011-12-22T17:39:56.000Z

Same thing here. Getting back nothing but gibberish in my content callbacks.

episod · 2011-12-22T17:41:29.000Z

We’re looking into this.

cheekyTaurusWP · 2011-12-22T18:53:34.000Z

Hi there, any update on this?

rschu · 2011-12-22T21:27:56.000Z

Like Marco and Morten wrote, the response is sometimes GZip packed. Just check if the Content-Encoding header is “gzip” or the first two bytes of the response for the GZip magic number (0x1f8b). See http://tools.ietf.org/html/rfc1952#page-6

ravikammaje · 2011-12-22T21:08:29.000Z

@aMikey_ - Can you please let us know what needs to be changed for handling gzip?
Thanks

mrcfield · 2011-12-22T21:23:48.000Z

I’ve implemented the work around too now also

It certainly seems, from my testing anyway, that the first attempt fails, then (while the browser still has the cookie) retrying again works. I’ve had this confirmed by several of my users too.

cheekyTaurusWP · 2011-12-22T21:41:22.000Z

I would like an explanation from Twitter on this before I recode and submit an app update, only to have Twitter change it again and break it further.

mrcfield · 2011-12-22T21:43:50.000Z

From what I understand, @BrandonWatson is “reaching out internally on the twitter relationship”. So fingers crossed for some kind of news soon.

cheekyTaurusWP · 2011-12-22T21:51:19.000Z

That’s good news.

rschu · 2011-12-22T22:20:56.000Z

The workaround is pretty straight forward and it’s very very unlikely that this will affect your app in the future.
Just test if the header Content-Encoding == “gzip”, if so, wrap the returned response stream in a GZipInputStream.