Somebody's corollary to Murphy's Law: "When a programmer writes logic
into his Perl Twitter app to dump the handle and error objects in YAML
on an error, so he can send the data to Twitter, he stops getting
'Internal Server Error' from Twitter." ;-)

On Jan 12, 10:56 am, "M. Edward (Ed) Borasky" <zzn...@gmail.com>
wrote:
> Oh ... I thought I was doing something wrong. But I was getting
> "Internal Server Error", not 404. Here's what I was doing (Perl, but
> the HTTP should be obvious):
>
>           q => $search_string,
>           geocode => $geocode,
>           rpp => 100,
>           max_id => $max_id,
>           page => $page
>
> On Jan 12, 9:15 am, Mark McBride <mmcbr...@twitter.com> wrote:
>
> > The search team is aware of the problem, I'll let you know when we
> > have more info.
>
> >    ---Mark
>
> >http://twitter.com/mccv
>
> > On Tue, Jan 12, 2010 at 8:38 AM, andy_edn <andygup....@gmail.com> wrote:
> > > RE: Couldn't find Status with ID=7406995447
>
> > > I'm wondering if the geocode search API is completely dead? It started
> > > to go out intermittently yesterday, now it's completely out. Any help
> > > would be much appreciated since we want to demo this app.
>
> > > It's throwing a 404 {"error":"Couldn't find Status with
> > > ID=7406995447"}. We've tried this from various IP addresses and it
> > > doesn't matter. I'll include the request and exact error dump below.
> > > The example I use below was taken directly from the Twitter API
> > > documentation on this page.
>
> > > To reproduce: I took the following URL from that page and tried to
> > > load it using a 
> > > browser:http://apiwiki.twitter.com/Twitter-Search-API-Method%3A-search
>
> > > GET /search.atom?geocode=40.757929%2C-73.985506%2C25km HTTP/1.1
>
> > > HTTP/1.0 404 Not Found
> > > Date: Tue, 12 Jan 2010 16:34:36 GMT
> > > Server: hi
> > > Status: 404 Not Found
> > > X-Served-From: sjc1c004
> > > Content-Type: application/xml; charset=utf-8
> > > X-Served-By: sjc1i009.twitter.com
> > > Content-Length: 111
> > > Vary: Accept-Encoding
> > > Cache-Control: max-age=5
> > > Expires: Thu, 01 Jan 1970 00:00:00 GMT
> > > X-Varnish: 327593908
> > > Age: 0
> > > Via: 1.1 varnish
> > > X-Cache-Svr: sjc1i009.twitter.com
> > > X-Cache: MISS
> > > Connection: close
>
> > > <?xml version="1.0" encoding="UTF-8"?>
> > > <hash>
> > >  <error>Couldn't find Status with ID=7406995447</error>
> > > </hash>
>
> > > On Jan 2, 9:03 pm, John <munz...@gmail.com> wrote:
> > >> I recently switched from using page to max_id to prevent duplicates
> > >> from appearing due to new tweets. But there seems to be an issue when
> > >> hitting the end when doing a search. It results in an error of
> > >> "Couldn'tfindStatuswith ID=[id of tweet]". The id that gets
> > >> returned in the error also doesn't match the ID that I passed in. I
> > >> can reproduce it everytime.
>
> > >> To reproduce: Do a search for "#tests" then take the ID of the last
> > >> tweet and do another search using that as the max_id.
>
> > >> Also search and favorites API methods does not list "max_id" as a
> > >> parameter but they do work correctly with max_id besides the issue
> > >> above. Shouldn't they be included in the docs?

Reply via email to