200 "errors"
Chris Babcock
[usak@cl-t090-563cl bin]$ time curl -Lsim 10 http://twitter.com/account/rate_limit_status.xml
HTTP/1.0 200 OK
Connection: Close
Pragma: no-cache
cache-control: no-cache
Refresh: 0.1
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/1999/REC-html401-19991224/strict.dtd">
<!-- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd"> -->
<HTML>
<HEAD>
<META HTTP-EQUIV="Refresh" CONTENT="0.1">
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
<META HTTP-EQUIV="Expires" CONTENT="-1">
<TITLE></TITLE>
</HEAD>
<BODY><P></BODY>
</HTML>
real 0m0.100s
user 0m0.002s
sys 0m0.004s
[usak@cl-t090-563cl bin]$ time curl -Lsim 10 http://twitter.com/account/rate_limit_status.xml
HTTP/1.1 200 OK
Date: Sun, 09 Aug 2009 07:17:05 GMT
Server: hi
Last-Modified: Sun, 09 Aug 2009 07:17:05 GMT
Status: 200 OK
ETag: "d3498c2414150299df3cc1f6bb73b92c"
Pragma: no-cache
Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0
Content-Type: application/xml; charset=utf-8
Content-Length: 302
Expires: Tue, 31 Mar 1981 05:00:00 GMT
X-Revision: 5a9a0d1ff0ba64c181510974278cfccc10e77d0b
X-Transaction: 1249802225-83448-6420
Set-Cookie: _twitter_sess=BAh7BzoHaWQiJWVkNjk5Njk2YWNhNjQ3ZjgyOGQzNzdjNTAzMTE3ZjBmIgpm%250AbGFzaElDOidBY3Rpb25Db250cm9sbGVyOjpGbGFzaDo6Rmxhc2hIYXNoewAG%250AOgpAdXNlZHsA--639086f2287f85ef9e07f98d16adcce416b79e8d; domain=.twitter.com; path=/
Vary: Accept-Encoding
Connection: close
<?xml version="1.0" encoding="UTF-8"?>
<hash>
<remaining-hits type="integer">150</remaining-hits>
<hourly-limit type="integer">150</hourly-limit>
<reset-time-in-seconds type="integer">1249805825</reset-time-in-seconds>
<reset-time type="datetime">2009-08-09T08:17:05+00:00</reset-time>
</hash>
real 0m0.184s
user 0m0.002s
sys 0m0.003s
In a browser that would be functionally the same as a 302, but I'm not
using a browser so the semantics are kind of important.
It *seems* to happen whenever I hit the API with a cold request. Pure
speculation. If I think of a way to test it, I will do so.
Chris Babcock
Rich
frustrating.
Basically I'm checking for status 200, then I'm checking for Content-
Type XML. However from time to time I'm getting non XML back from
this function.
On Aug 9, 8:27 am, Chris Babcock <cbabc...@asciiking.com> wrote:
> This is what the200response is looking like:
> Vary: Accept-Encoding
> Connection: close
>
> <?xmlversion="1.0" encoding="UTF-8"?>
Ryan Sarver
Seems like you aren't the only ones right now. I'm going to work with
Ops to see if we can figure out where it is coming from. Can you
provide us with a little more info so it will be easier to track this
down?
1. The IP of the machine making requests to the Twitter API. If you're
behind NAT, please be sure to send us your *external* IP.
2. The IP address of the machine you're contacting in the Twitter
cluster. You can find this on UNIX machines via the "host" or
"nslookup" commands, and on Windows machines via the "nslookup"
command.
3. The Twitter API URL (method) you're requesting and any other
details about the request (GET vs. POST, parameters, headers, etc.).
4. Your host operating system, browser (including version), relevant
cookies, and any other pertinent information about your environment.
5. What kind of network connection you have and from which provider,
and what kind of network connectivity devices you're using.
Thanks in advance, Ryan
Rich
On Aug 18, 4:21 pm, Ryan Sarver <rsar...@twitter.com> wrote:
> Chris, Rich,
>
> Seems like you aren't the only ones right now. I'm going to work with
> Ops to see if we can figure out where it is coming from. Can you
> provide us with a little more info so it will be easier to track this
> down?
>
> 1. The IP of the machine making requests to the Twitter API. If you're
> behind NAT, please be sure to send us your *external* IP.
> 2. The IP address of the machine you're contacting in the Twitter
> cluster. You can find this on UNIX machines via the "host" or
> "nslookup" commands, and on Windows machines via the "nslookup"
> command.
> 3. The Twitter API URL (method) you're requesting and any other
> details about the request (GET vs. POST, parameters, headers, etc.).
> 4. Your host operating system, browser (including version), relevant
> cookies, and any other pertinent information about your environment.
> 5. What kind of network connection you have and from which provider,
> and what kind of network connectivity devices you're using.
>
> Thanks in advance, Ryan
>
Rich
Ryan Sarver
Can you provide your source IP that you are seeing this issue from? We
can only dig into the logs if we know where your traffic is coming
from.
Thanks, Ryan
Rich
503's that everyone seems to be getting) I'll drop you an email again
if I see it again!
Many thanks
Richard
Jeffrey Greenberg
using since_id)
This is seriously messing things up!
@jeffGreenberg
@tweettronics
Details:
url: http://search.twitter.com/search.json?q=%23fail%20since%3A2009-08-19&rpp=100&since_id=3397530515
httpresponse = 200
returned text:
Larry Wright
do I send the details you are requesting?
On Aug 25, 7:18 pm, Jeffrey Greenberg <jeffreygreenb...@gmail.com>
wrote:
> using since_id)
> This is seriously messing things up!
> @jeffGreenberg
> @tweettronics
>
> Details:
>
Allan Zhang
is a little better, but it still slow compare to several days ago.
Thanks
Allan Zhang
Alex
any update on this issue ?
twittme_mobi
I am getting the same error - i can found it in the logs of my app
every day - at least 20 times.
1. The IP of the machine making requests to the Twitter API. If you're
behind NAT, please be sure to send us your *external* IP.
Name: twittme.mobi
Address: 67.222.129.154
2. The IP address of the machine you're contacting in the Twitter
cluster. You can find this on UNIX machines via the "host" or
"nslookup" commands, and on Windows machines via the "nslookup"
command.
Name: twitter.com
Address: 128.121.146.100
3. The Twitter API URL (method) you're requesting and any other
details about the request (GET vs. POST, parameters, headers, etc.).
'account/rate_limit_status.xml'
4. Your host operating system, browser (including version), relevant
cookies, and any other pertinent information about your environment.
Linux, mobile browser,firefox, no cookies used.
5. What kind of network connection you have and from which provider,
and what kind of network connectivity devices you're using.
devices are mostly mobile..probably using mobile connections or
wireless.
Thanks!
Rich
time stamp will be around 2 minutes ago
Naveen A
a mobile application and seeing this issue more and more frequently to
the point that application is not functioning properly, its hard for
use to provide any specific ip data as the carriers are most likely
proxying the requests from the device.
It is not limited to a specific api call either, it is a systemic
issue across a wide range of calls we make.
There was a ticket related to the issue in the bug tracker for search,
but it has been closed and I think it should be re-opened as it is
still a problem
http://code.google.com/p/twitter-api/issues/detail?id=968
Any feedback would be appreciated.
Rich
becoming unusable with constant XML errors
On Sep 7, 4:51 am, Naveen A <knig...@gmail.com> wrote:
> We are seeing this HTML META REFRESH as well from our clients. We are
> a mobile application and seeing this issue more and more frequently to
> the point that application is not functioning properly, its hard for
> use to provide any specific ip data as the carriers are most likely
> proxying the requests from the device.
>
> It is not limited to a specific api call either, it is a systemic
> issue across a wide range of calls we make.
>
> There was a ticket related to the issue in the bug tracker for search,
> but it has been closed and I think it should be re-opened as it is
steve.knoblock
status using curl and it returns the 200 HTML and then the status
intermittently. If I specify JSON I still get the HTML on the errors
and JSON data on the status. This is really affecting our website.
steve.knoblock
using curl. It gives the 200 "error" one minute and then the status
response the next. It does not matter if I request JSON it still
returns the HTML.
d h
guytom
jb007nd
Safari can’t open the page “feed://twitter.com/statuses/user_timeline/
18918483.rss”. The error is: “The feed could not be loaded because the
content is not in a known feed format.” (PubSub:2) Please choose
Safari > Report Bugs to Apple, note the error number, and describe
what you did before you saw this message.
After hitting refresh, the feed will be fixed and my PHP parser will
correctly parse the pages.
-j
On Aug 9, 12:27 am, Chris Babcock <cbabc...@asciiking.com> wrote:
> This is what the 200 response is looking like:
>
> Connection: Close
> Pragma: no-cache
> cache-control: no-cache
> Refresh: 0.1
> Content-Type: text/html; charset=iso-8859-1
>
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/1999/REC-html401-19991224/strict.dtd">
> <!-- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
> "http://www.w3.org/TR/html4/strict.dtd"> -->
> <HTML>
> <HEAD>
> <META HTTP-EQUIV="Refresh" CONTENT="0.1">
> <META HTTP-EQUIV="Pragma" CONTENT="no-cache">
> <META HTTP-EQUIV="Expires" CONTENT="-1">
> <TITLE></TITLE>
> </HEAD>
> <BODY><P></BODY>
> </HTML>
>
> real 0m0.100s
> user 0m0.002s
> sys 0m0.004s
> Date: Sun, 09 Aug 2009 07:17:05 GMT
> Server: hi
> Last-Modified: Sun, 09 Aug 2009 07:17:05 GMT
> Status: 200 OK
> ETag: "d3498c2414150299df3cc1f6bb73b92c"
> Pragma: no-cache
> Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0
> Content-Type: application/xml; charset=utf-8
> Content-Length: 302
> Expires: Tue, 31 Mar 1981 05:00:00 GMT
> X-Revision: 5a9a0d1ff0ba64c181510974278cfccc10e77d0b
> X-Transaction: 1249802225-83448-6420
jb007nd
To get the feed working again, I have to pull up the feed on Safari,
and it will show an error. If I hit refresh, the page will pull new
feeds and my PHP pages which parse the feed also gets refreshed.
>
> Connection: Close
> Pragma: no-cache
> cache-control: no-cache
> Refresh: 0.1
> Content-Type: text/html; charset=iso-8859-1
>
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/1999/REC-html401-19991224/strict.dtd">
> <!-- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
> "http://www.w3.org/TR/html4/strict.dtd"> -->
> <HTML>
> <HEAD>
> <META HTTP-EQUIV="Refresh" CONTENT="0.1">
> <META HTTP-EQUIV="Pragma" CONTENT="no-cache">
> <META HTTP-EQUIV="Expires" CONTENT="-1">
> <TITLE></TITLE>
> </HEAD>
> <BODY><P></BODY>
> </HTML>
>
> real 0m0.100s
> user 0m0.002s
> sys 0m0.004s
> Date: Sun, 09 Aug 2009 07:17:05 GMT
> Server: hi
> Last-Modified: Sun, 09 Aug 2009 07:17:05 GMT
> Status: 200 OK
> ETag: "d3498c2414150299df3cc1f6bb73b92c"
> Pragma: no-cache
> Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0
> Content-Type: application/xml; charset=utf-8
> Content-Length: 302
> Expires: Tue, 31 Mar 1981 05:00:00 GMT
> X-Revision: 5a9a0d1ff0ba64c181510974278cfccc10e77d0b
> X-Transaction: 1249802225-83448-6420
Jonathan Smith
It happens very inconsistently during a normal session, but I can
almost always reproduce it if I let the client sit for a while and
then try.
Is almost as if the server can't authenticate the request fast enough
and throws back an empty html page by default.