On 4/15/09 4:44 PM, Doug Williams wrote:
More details would certainly help track down the problem. Headers,
response bodies, etc.?
Here's a network trace:
GET /statuses/followers.xml?page=2 HTTP/1.0
Accept: */*
Host: twitter.com
User-Agent: Tcl http client package 2.5.5
Authorization: Basic **redacted**
HTTP/1.1 200 OK
Date: Wed, 15 Apr 2009 20:55:13 GMT
Server: hi
Last-Modified: Wed, 15 Apr 2009 20:55:13 GMT
Status: 200 OK
X-RateLimit-Limit: 20000
ETag: "fc8ddb8b92bc3f4d9e00a8e17e2f4898"
X-RateLimit-Remaining: 19991
Pragma: no-cache
Cache-Control: no-cache, no-store, must-revalidate, pre-check=0,
post-check=0
Content-Type: application/xml; charset=utf-8
X-RateLimit-Reset: 1239832182
Content-Length: 179501
Expires: Tue, 31 Mar 1981 05:00:00 GMT
X-Revision: 4e5faab3f91d5f0786eb4ec3d3fca729cb2c6f93
X-Transaction: 1239828913-49046-26028
Set-Cookie: lang=en; path=/
Set-Cookie: lang=en; path=/
Set-Cookie: _twitter_sess=**redacted**; domain=.twitter.com; path=/
Vary: Accept-Encoding
Connection: close
<?xml version="1.0" encoding="UTF-8"?>
<users type="array">
<user>
...
<truncated>false</truncated>
<in_reply_to_status_id>1527164155</in_reply_to_status_id>
<in_r
The bytes received do not match the Content-Length header's byte count.
As you can see, the response abruptly ends.
On the wire, I'm seeing a bunch of duplicate ACK's and retransmits, then
finally my end sends a [FIN,ACK] and Twitter's end responds with an [RST].
Help?
--
Dossy Shiobara | [email protected] | http://dossy.org/
Panoptic Computer Network | http://panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)
