SiteStreams bad request


#1

Hi

All of a sudden today I’ve started getting bad request http 400 errors

Any ideas?


#2

We are seeing this as well - SiteStreams are closing the connection with a 404 error. We are connecting via SSL and using HTTP 1.1

We are seeing: HTTP Error: HTTP/1.1 404 Not Found


#3

To which methods are you seeing this problem arise? The site stream itself or control streams for site streams?


#4

This is on initial connect to the sitestream.

Slightly revamped log messages:
Connecting to ssl://199.16.156.49, port=443, connectTimeout=5
Connection established for 16788, about to read
HTTP Error: HTTP/1.1 404 Not Found
Connection: close
Date: Wed, 08 Jan 2014 20:14:07 GMT
Not Found


#5

Initial connection to sitestreams

GET /1.1/site.json?delimited=length&follow=xxxxxx HTTP/1.1
Host: sitestream.twitter.com:443

The oauth headers are correct as if I modify them to make them ‘wrong’ I get a 401 error instead.

If I add the correct headers I get HTTP ERROR 400: Bad Request (Bad Request)


#6

I can confirm these sudden issues. We can’t connect to sitestreams.

Error 401: Unauthorized, API message: Insufficient privileges

#7

Same here, no changes in our codebases, and, oddly enough, one of our backup server has not suffered this issue, only our main server :S


#8

It’s odd, we’re getting 404s…

I’m wondering if there was a significant code change that caught a couple of us. I just checked and we were actually using an old endpoint “/2b/site.json” which I updated to “/1.1/site.json”, but that didn’t help at all.


#9

I’m asking engineering to look into this; hopefully it’s a temporary error condition. Stay tuned.


#10

Yeah I’m wondering if there was a code deployment that is much stricter. Are you getting 404 on /1.1/site.json?

I’ve tried on two different servers, same issue.


#11

I can email you the full headers including oauth if it’s any help or needed


#12

Please do – including the screen name you’re using to connect. episod at twitter dot com – if I can’t help look into it, I’ll forward it to someone who can.


#13

When you’re getting a 404 – can you verify that all the users you’re specifying to connect with using the follow parameter are both existent users and users you have valid access tokens for?


#14

Yea, I had hoped that maybe our use of the old endpoint was the problem. But our switch to to “https://sitestream.twitter.com/1.1/site.json” still results in immediate disconnects with a 404 response.


#15

I’ll take a look - unless recently deleted, they are existent.

However, I don’t think the api provides a great way to let us know which users may have revoked their access. Unless I’m missing something.

We do remove them when we discover they are bad, but proactively searching them out is problematic. We can probably come up with a test script to weed out any bad tokens if that is now required.


#16

Though it might be unrelated, I really recommend having a regular process that goes through the access tokens you have and runs account/verify_credentials with them; it’s probably the best way to check in on current status of each of your tokens.


#17

Ok, that makes sense - thanks for the tip.


#18

When you connect to sitestream.twitter.com, are you also sending that as the host header?


#19

Can you please email me the full request and response (headers and body) that’s resulting in these 400s, please? My first name at twitter.com is my email address.

Something off a raw cURL would be best.


#20

Something else that might help us to uniquely identify your connection attempts in our systems is for you to use a unique User Agent (just make something up and let me know).