<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?" Silverlight thinks that flash's crossdomain.xml format is yummy. **`crossdomain.xml`** <?xml version="1.0"?> <!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd"> <cross-domain-policy> <allow-http-request-headers-from domain="*" headers="*"/> </cross-domain-policy> ClientHttpWebRequest does **NOT** request nor accept compressed response. Note the 'Transforms' UI. **XHR** ![alt text][1] **ClientHttpWebRequest** ![alt text][2] [1]: https://i.sstatic.net/Cc0nt.png [2]: https://i.sstatic.net/2YnF9.png