all requests have no content-encoding or have 'gzip,gzip', both of which fail to decompress browser side.

note: the content-encoding header, when it is present, does not seem to be included in the fiddler copy op. but as stated, it is either absent or malformed on all requests.

GET /1.0/users/14/tags?key=qgAq_KfDu0KYzlNG-qaTuw&jsonp=Soapi._jsonp32 HTTP/1.1
Accept: */*
Referer: http://localhost:17742/AlphaQuickStart.htm
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; Tablet PC 2.0; .NET4.0C; .NET4.0E)
Accept-Encoding: gzip, deflate
Host: api.stackapps.com
Connection: Keep-Alive

HTTP/1.1 200 OK
Server: nginx
Date: Sat, 21 Aug 2010 02:29:01 GMT
Content-Type: application/json; charset=utf-8
Connection: keep-alive
Cache-Control: private
X-AspNetMvc-Version: 2.0
X-RateLimit-Max: 10000
X-RateLimit-Current: 9931
X-AspNet-Version: 4.0.30319
Content-Length: 1062

  • seems to be resolved as of now but am leaving question open until word comes from on high. Aug 21, 2010 at 2:43
  • also- i saved the fiddler sessions if needed for reference. Aug 21, 2010 at 2:44

1 Answer 1


The Content-Encoding is [status-norepro], but the empty (or nearly empty) invalid body has been resolved.

  • the body seemed to be full, as in up to 4k of binary data that the browser and fiddler could not decode even when forced. The single character that you see in the fiddler log is a typical result of viewing binary data as text, e.g. rendering agent thinks it is unicode and truncates when it hits a null. The log shown above actually has 1k of binary data. Aug 21, 2010 at 2:59
  • @code poet - ah yes, missed the Content-Length header on first read through. Was a prod-only bug, for even more fun. Aug 21, 2010 at 3:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .