404 errors under SSL

richardhyland · 2013-02-07T19:31:12.000Z

I’m seeing some strange errors affecting a minor subset of my users.

If accessing requests under API 1.1 over SSL (such as statuses/home_timeline.json) they are getting 404 errors, although most users are experiencing no issues whatsoever.

If those affected users switch to not using SSL they request goes through fine.

Any ideas?

episod · 2013-02-07T19:34:36.000Z

Make sure you aren’t sending any cookies along with your request. There’s a known issue with some users who have the outdated “contributor” feature running into this problem, but only if you’re sending cookies.

Also, while it looks like it’s not being enforced right now – API v1.1 requires SSL. It’s not optional.

richardhyland · 2013-02-07T19:49:11.000Z

No it shouldn’t be sending any cookies at all. I enforce ssl as I’m aware that 1.1 requires it. I just have a legacy setting to turn it off which I’ll be removing.

It’s strange the exact duplicate request with just https instead of http causes a 404 but it only affects some users. Seems to be iOS related too as I’m not hearing of issues on Android. I’m sending some legacy parameters like include_entities. Would that affect it?

episod · 2013-02-07T20:09:55.000Z

Depending on your HTTP environment – you might be sending cookies and just not know it. The API will occasionally respond with cookies, and many HTTP libraries will happily throw those back after they’ve received them unless you explicitly configure it not too.

This is especially true of browser-based environments.

richardhyland · 2013-02-07T20:53:53.000Z

Hi Taylor

I’ve checked and it’s definitely not sending cookies

[request setCachePolicy:NSURLRequestReloadIgnoringLocalAndRemoteCacheData];
[request setHTTPShouldHandleCookies:NO];

No idea what it could be

richardhyland · 2013-02-13T20:24:00.000Z

Hi Taylor

Here’s the error I’m getting, could it be the now removed parameters such as include_rts=true causing problems?

http://twitpic.com/c3fq0u

It’s not throwing errors for most users, but is for some, but here’s the request a few mins before

http://twitpic.com/c3fqbj

Definitely no cookies involved. I’m reading the status id from id_str thats forming the basis of the since_id

Other things I’m thinking of, do you now under API 1.1 get a 404 if there are no new tweets since the since_id tweet parameter or maybe if the since_id has been deleted but still in a cached timeline?

I’ve tried testing those and not seen it personally though.

episod · 2013-02-13T20:28:56.000Z

Hi Richard,

Since we last talked about this we’ve narrowed down the issue further… it’s still a cookie issue, but not necessarily due to cookies you yourself are sending. We’re working to resolve this - it’ll kind of randomly effect some users and not others until we have it resolved. If you want to temporarily mitigate, continue using v1’s statuses/home_timeline method for just a little longer.

richardhyland · 2013-02-13T20:33:21.000Z

Wonderful, I’m not going mad! Thank you so much for finding the problem