Timeline for SIlverlight 3 ClientHttp vs BrowserHttp stack: no cross domain policy means no gzip for Silverlight
Current License: CC BY-SA 2.5
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 14, 2010 at 5:18 | vote | accept | Sky Sanders | ||
| Jul 14, 2010 at 4:46 | history | edited | Kevin Montrose | CC BY-SA 2.5 |
added 224 characters in body
|
| Jun 14, 2010 at 5:31 | comment | added | Sky Sanders |
So, silverlight is sending accept-encoding = identity which equates to no encoding and apparently the servers are honoring it. Which is a good thing. If it stops, a lot of (valuable) hours of development time for an unknown number of devoted SO aficionado will be lost.
|
|
| Jun 14, 2010 at 4:47 | comment | added | Kevin Montrose |
@code poet - behavior is "honor accept-encoding, but if omitted assume gzip". Either way a Content-Encoding is set accordingly.
|
|
| Jun 14, 2010 at 4:32 | comment | added | Sky Sanders | If you force gzip you will break Silverlight 3 (and possibly 4) clients. Unless there is a 'strict in what you issue, relaxed in what you accept' feature in the SL stack that I haven't tested. When I get a moment I will build a server that only pushes gzip and see how the SL stack handles it. | |
| Jun 14, 2010 at 4:29 | comment | added | Sky Sanders | I am not sure you are picking up what I am putting down: Silverlight ClientHttp stack does not support gzip. That is the code we are talking about here. But Soapi is here: [email protected]/bitpusher/soapi - I am pushing on documentation and last minute adjustments but I generally only push compilable code. Open the vs9 solution - I haven't reviewed the vs10 solution in the last few hours and since I am linking files I promise it is broken. Soapi.SL.Tests is what you are looking for. | |
| Jun 14, 2010 at 4:19 | comment | added | Kevin Montrose | @code poet - yeah... you're gonna have to accept gzip compressed content. We're not compromising on that, its 2010, the future is now, etc. etc. Technically, we should be 406'ing non-compressed requests; but that breaks tons of proxies (we found this out the hard way) so we do something non-standard to work around others who are breaking standards. There's no perfect solution. Also - I think I might know what's causing this gzip problem, will try and have a fix out for it tomorrow evening. No promises on the time-frame, and I would still like your code to test with. | |
| Jun 13, 2010 at 18:52 | comment | added | Sky Sanders | And PLEASE, do not succeed in your efforts to ignore internet standards by forcing gzip. That would simply be all kinds of wrong on all kinds of levels and not what I would expect from the Stack Overflow team. | |
| Jun 13, 2010 at 18:44 | comment | added | Sky Sanders | Kevin, the headers are from fiddler. | |
| Jun 13, 2010 at 13:41 | history | edited | Kevin Montrose | CC BY-SA 2.5 |
added 712 characters in body; added 63 characters in body
|
| Jun 13, 2010 at 13:29 | comment | added | Kevin Montrose |
@code poet - I'm like 99% sure that Siverlight is just hiding its handling of the Content-Encoding header from you, we jump through some hoops to never return uncompressed content. Send me the code and I'll investigate to be sure.
|
|
| Jun 13, 2010 at 11:46 | comment | added | Sky Sanders | it is in the late hours for me and my initial report was specious but there may be something in the update to consider. | |
| Jun 13, 2010 at 11:03 | history | answered | Kevin Montrose | CC BY-SA 2.5 |