<strike>I notice that even if I send `accept-encoding=gzip` the response does not seem to be compressed.</strike> ( it is late and i was conflating 'accept' with 'accept-encoding')
<strike>
Should we expect, in the 1.0 timeframe to be getting gzipped responses and therefore expect to need to set that header?
I would like to know in order to make some design decisions.
</strike>
---
**ADDITIONAL INFO**
Kevin, here is some data for consideration in response to your response.
From **XMLHttpRequest**
<pre>
GET /0.8/badges?key=NLIXkFCt8Eu-oq1Mzw3pgg&jsonp=jsonp1276425901091 HTTP/1.1
Host: api.stackoverflow.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.70 Safari/533.4
Referer: http://soapi.info/code/js/stable/soapi-explore-beta.htm
Cache-Control: max-age=0
Accept: */*
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: __qca=P0-473080984-1269917382233; usr=t=puUW6SFMp0Sx&s=IgtyKFGnWUKz; __utmz=140029553.1276424207.947.185.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=sztupy%20codeproject; __utma=140029553.1848660693.1269917382.1276411100.1276424207.947; __utmc=140029553
HTTP/1.1 200 OK
Server: nginx
Date: Sun, 13 Jun 2010 11:17:08 GMT
Content-Type: application/json; charset=utf-8
Connection: keep-alive
Cache-Control: private
Content-Encoding: gzip
X-AspNetMvc-Version: 2.0
X-RateLimit-Max: 10000
X-RateLimit-Current: 9223
X-AspNet-Version: 2.0.50727
Content-Length: 5918
[binary data]
</pre>
From **Silverlight ClientHttpRequest** which does not actually allow setting the accept-encoding header and does *not* support gzip.
<pre>
GET /0.8/users/242897/comments/160173?key=qgAq_KfDu0KYzlNG-qaTuw HTTP/1.1
Accept: */*
Accept-Encoding: identity
User-Agent: Mozilla/4.0 (compatible; MSIE 8.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)
Host: api.stackoverflow.com
Connection: Keep-Alive
HTTP/1.1 200 OK
Server: nginx
Date: Sun, 13 Jun 2010 11:17:03 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: 9232
X-AspNet-Version: 2.0.50727
Content-Length: 2430
{
"total": 3,
"page": 1,
"pagesize": 30,
"comments": [
</pre>
I was mistaken in the details of my initial report as I was setting the 'accept' header, not accept-encoding (this is not supported by silverlight).
But the end result is that I am *not* sending (not able to send) 'accept-encoding=gzip' and I *am* getting uncompressed responses from the server. This, while ultimately not what we want, is the correct result.
The issue I am having is that using the browser stack in silverlight will enable gzip but is crippled in every other area and is sub-optimal to say the least.
Using the .net stack enables, amongst other critical functionality, parsing of the rate limit headers. This is a known issue in SL3 and is not to change. I am not sure about SL4, I haven't dug deep enough yet.
And regarding 'you can't get a response that isn't compressed; you can only choose between gzip & deflate' - the sessions above disagree, and rightly so.
If the server was to disregard accept-encoding headers and force compression it would simply 'break the internet'.
So I guess we can chalk this question up as a head's up that SL3 clients are likely to be pulling text.
I am going to spend (likely waste) some time working with the browser stack and try to get an acceptable implementation going but I don't have high hopes.
**MO'N'BETTA INFO**
Groggy me, making a lot of noise but saying little: The reason that I have to use the ClientHttp stack is that the api has no crossdomain policy file and the BrowserHttp stack fails.
So, I guess the question can evolve to "Is there a reason that a cross domain policy file is not present?"