This content has been marked as final. Show 4 replies
An HTTP server should only gzip data if the client sends "Accept-Encoding: gzip". So, either AIR is lying, claiming it will accept gzip encoding, or the server is sending data encoded in a format it wasn't told was legal. A packet sniffer will tell you which case is true. I'm betting on the server being broken.
Keep in mind, gzip encoding was something added later on in the HTTP standards process, not something that's been expected to be available from day 1. While all modern desktop web browsers support gzip encoding now, there are more kinds of web clients in the world than just plain old web browsers.
So, rather than try to decompress the data on your side, I'd see if you can't fix the server first.
Well, it seems URL i want to downlaod, or rather server API is requiring i set "Accept-Encoding gzip". So it seems in its (AIRs) current form i cannot download this xml file in Adobe AIR/Ajax. This puts me between the Gears, if you know what i mean.
I also tried to workaround this problem, maybe by simple calling some native windows app (like wget or something) to d/l the xml for me, but it seems AIR is not capable of any native exec calls. Life suxx, and then U die.....
Sorry Adobe, seems you have lost me here.... :(
I agree, it would be nice to have gzip encoding support in AIR's browser component. But, I looked at what my AIR app sends when it requests a web page, and it's not claiming to the remote server that it can support gzip. If the server is sending the content gzipped anyway, it's almost certainly broken. Web servers aren't supposed to dictate encodings. Clients say what they're capable of receiving, and servers send the data in that format if they're capable of sending any of the requested formats.
I see only one exception in the spec. Section 14.3 says the server is allowed to send what it likes if the client doesn't say what it wants (true for AIR) and it cannot support the default, which is to say, sending the raw data as it is on disk. So, is that the case? Can this server really not send raw data, to anyone, ever? If so, it's violating the spirit of the web, to the point that I'd say it's broken, even if the spec does allow it. And if the server really is capable of sending the raw data, it's really broken for insisting on sending it compressed when the client hasn't told it that it can handle it; this would actually be against the spec, not just against the spirit of the spec.
It would seem a more sensible use of your time to fix the server than to go and learn another technology just to work around its brokenness.
(You can also override the User agent string, if that works to induce your server to cough up ungzipped data.)