I ported all of my integration tests to phone 7, which is a flavor of silverlight 3, and found that stackauth is not forcing gzip as expected.

while this simply means that I need to check the first 2 bytes of the result to determine if it is gzipped, this does violate the official api protocol.

Note: wp7/sl3 do not send 'accept-encoding' so this seems to indicate that whatever hoops you have made the other endpoints jump through to force gzip, stackauth was missed.

The reason this became an issue for me is that I cannot read response headers to determine the 'content-encoding' of the response and was relying on the previous assertion that all data will be compressed and when it came back plain text... BOOM!.

As a reference to others, here is how to get what you need regardless of the encoding of the stream.

byte[] data = response.GetResponseStream().ReadFully();
// ReadFully is an extension scribbled out by some guy named skeet
// http://www.yoda.arachsys.com/csharp/readbinary.html

if (data.Length > 2 && data[0]==31 && data[1]==139)
    using (var ms = new MemoryStream(data))
    using (var gzip = new GZipInputStream(ms))
    using (var reader = new StreamReader(gzip))
        json = reader.ReadToEnd();
    json = Encoding.UTF8.GetString(data, 0, data.Length);
  • 2
    Windows Phone 7 doesn't give you access to HTTP headers? Whose dumb design idea was that? Jul 24, 2010 at 16:46
  • @geo - yeah, i am not tickled about it, but the technology is based on a bastardized silverlight3 so those limitations carry over. Jul 24, 2010 at 17:17

1 Answer 1


This should be fixed now.

StackAuth will send down gzip'd content (whether you ask for it or not) just like the API. Content-Encoding is also set, as a debugging aid (for browsers and the like), but bear in mind that proxies love to strip that out so don't rely on its presence*.

*Read: keep doing what you were doing in the first place. :)

You must log in to answer this question.

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