404 (not due to unversioned path )

[qubeeydev]

I am getting a 404 on /1.1/favorites/create.json

To ensure that it wasn’t an auth problem reporting wrong, I purposefully changed the auth a hair… and sure enough I got the 401 as expected so it is definitely not an auth problem… expecially since I use the same class to connect to /1.1/statuses/home_timeline.json just fine and also user stream.

here is my request and Twitter’s response.

POST /1.1/favorites/create.json HTTP/1.1
Authorization: OAuth oauth_consumer_key="XXXXX", oauth_nonce="135216146497738", oauth_signature="XXXXX", oauth_signature_method="HMAC-SHA1", oauth_timestamp="1352161465", oauth_token="XXXXX", oauth_version="1.0"
Host: api.twitter.com
Connection: close

id=265599949067124736

Twitter’s Reswponse

HTTP/1.1 404 Not Found
Date: Tue, 06 Nov 2012 00:26:08 GMT
Status: 404 Not Found
Expires: Tue, 31 Mar 1981 05:00:00 GMT
Last-Modified: Tue, 06 Nov 2012 00:26:08 GMT
Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0
Pragma: no-cache
X-Transaction: 4d621189ed1dd9bb
X-MID: 36679a3d3b026918cb5161836385d108ff42b316
X-Runtime: 0.04022
X-Transaction-Mask: a6183ffa5f8ca943ff1b53b5644ef1146e7941bb
X-Frame-Options: SAMEORIGIN
X-Access-Level: read-write-directmessages
Set-Cookie: k=10.40.29.137.1352161568515923; path=/; expires=Tue, 13-Nov-12 00:26:08 GMT; domain=.twitter.com
Set-Cookie: guest_id=v1%3A135216156851940931; domain=.twitter.com; path=/; expires=Thu, 06-Nov-2014 12:26:08 GMT
Set-Cookie: dnt=; domain=.twitter.com; path=/; expires=Thu, 01-Jan-1970 00:00:00 GMT
Set-Cookie: lang=en; path=/
Set-Cookie: lang=en; path=/
Set-Cookie: lang=en; path=/
Set-Cookie: twid=u%3D360860038%7CtuZ1UBpowBZg6I93nCLtmxB6d3c%3D; domain=.twitter.com; path=/; secure
Set-Cookie: _twitter_sess=BAh7CToMY3NyZl9pZCIlYzI2YjUzODdiZjM2ZjgyYWFlNzg5YTRhOTJlZjhm%250AODI6D2NyZWF0ZWRfYXRsKwgWJxzTOgE6B2lkIiUzNWQ5Zjc3N2Y3ZmY5MmQ0%250AYjVlNzExMjUxOWFlYmRlNyIKZmxhc2hJQzonQWN0aW9uQ29udHJvbGxlcjo6%250ARmxhc2g6OkZsYXNoSGFzaHsABjoKQHVzZWR7AA%253D%253D--c1cd4e8f80dd56ae7ab0175013fb5d09fa812ee2; domain=.twitter.com; path=/; HttpOnly
Vary: Accept-Encoding
Content-Type: application/json; charset=utf-8
Content-Length: 68
Server: tfe

{"errors":[{"message":"Sorry, that page does not exist","code":34}]}

[episod]

I’m unable to reproduce. Was the status ID you passed in the POST body existent at the time of attempting this favorite? If so, how recent was it at that time?

Make sure that you’re passing a Content-Type and Content-Length with your POST request with a POST body. If you don’t tell us the disposition of your content, we may not be able to interpret it.

[qubeeydev]

Wow… so turns out it was an auth issue after all. Here is what I found out. Including this incase someone else has similar issues.

First I added the content type and length as you suggested. No love :(. So I figured this HAS to be an auth issue that Twitter isn’t responding properly to.

So I used the oauth tool for our app, copied the nonce and timestamp, pasted it in my code to compare base strings, and ran it… poof it worked! Huh? Turns out it was the nonce? I was generating the nonce by taking the current timestamp and adding a large random number to the end. This worked fine for GET requests but not POST? As soon as I replaced the nonce with a UUID style instead of unique numeric the POST requests began working properly.

This was EXTREMELY weird and HARD to debug. Twitter should be responding with 401 if the auth fails. Only about 20% of the time with auth problems did I get a 401. In this case it was ALWAYS 404 and the headers looked as though I auth’d fine. The first time I hit a block a few days ago, Twitter was ALWAYS responding 503 unavailable and that too what auth related.

I’m all good now. But please tell your team to fix the responses so future developers don’t go through what I just did. Auth problems should ALWAYS return a 401 per HTTP1.1 spec.

[episod]

Can you give more details on the exact nonces you were using that appeared to cause problems? In fact, anything more you can tell me about the requests will help identify and isolate a problem in this case.