Flash
 Data Communication

I ran into a similar problem once when generating gzip compressed web pages, IE6 choked on them. I don’t have the source code at hand at the moment, and I’m not sure this will help in your situation, but as far as I can remember I had to “empty” the Pragma and Cache-Control headers (this actually solves a lot of other IE/cache/session related problems).

In PHP the headers are emptied like this:

The boolean value is telling PHP to replace any Pragma and Cache-Control headers that may have already been set (this tends to happen with sessions and cookies etc, and possibly on some servers that serve GZIP compressed content). You also need to set the Content-Encoding and Content-Transfer-Encoding headers to “binary” and “gzip” respectively I believe.

However, if you are using AS3 you should be able to load the XML file using a Loader (dataFormat set to binary) and decompress it once it has been loaded, you avoid IE6’s stupidity completely that way.

I’m already using AS3 and URLLoader so I am able to use the binary dataFormat. But, what happens if in one enviroment IIS is set to compress the data with gzip and compressing it’s disabled in other one? I must have two swf files one using a Loader with binary as dataFormat and other with the Loader set to use text as dataFormat?
Also what happens in other browsers that don’t have this issue?

thanks a lot Nutrox!

I have seen this post:
http://www.ultrashock.com/forums/actionscript/as3-urlloader-data-91018.html

but I don’t get it completely. What data format should I use if I don’t know what it’s comming?
Can I detect the dataFormat incoming using “instanceof” ? eg:
  urlLoader.data instanceof ByteArray

How can I set the Loader to recieve any data? If I recieve gzipped data I have to decompress it using AS?

.. I have also seen on this page:
http://blog.dannypatterson.com/?p=133#more-133
the following piece of code:
[AS]
...
var request:URLRequest = new URLRequest();
request.url = “YOUR_SERVICE_ENDPOINT”;
request.method = URLRequestMethod.POST;
request.contentType = “text/xml; charset=utf-8″;
request.requestHeaders.push(new URLRequestHeader(”SOAPAction”, “YOUR_SOAP_ACTION”));
request.requestHeaders.push(new URLRequestHeader(”Accept-Encoding”, “gzip”));

var loader:URLLoader = new URLLoader();
loader.dataFormat = URLLoaderDataFormat.BINARY;
loader.addEventListener(Event.COMPLETE, onResult, false, 0, true);
loader.load(request);
...
[/AS]

If I set
request.url = to my servlet url
and
Accept-Encoding to text
could this force the iis to not compress the data?

thanks again!

Polaco.

please delete this accidental post

Ideally you will know what format the incoming data is using, the service you are using should have that in their API docs or allow you to request a specific format using header information. You can load any data as binary though (it gets pushed into a byte array) so you could try something like this…

Hi Nutrox!

We have continued looking at the problem, we have found that the IIS was using an old version of the ISAPI dll files that comes with BEA Weblogic 8.1, this dlls were changing the response in some way and compressing it with gzip.
The replaced files were:

iisforward.dll
iisproxy.dll

So with the old files the response header was:

Response:HTTP/1.1 200 OK
Cache-Control:no-cache
Connection:close
Date:Wed, 12 Nov 2008 12:20:33 GMT
Conten-Type:text/html; charset=ISO-8859-1
Server:Miscrosoft-IIS/6.0
X-Powered-By:ASP.NET
X-Vignette-RespondedWith:AJAX
Content-Encoding:gzip
Vary:Accept-Encoding
Transfer-Encoding:chunked

and with the new ones:

Response:HTTP/1.1 200 OK
Content-Type: text/html;charset=ISO-8859-1
X-Vignette-RespondedWith:AJAX
Transfer-Encoding:chunked
Cache-Control:no-cache

So now, if we want to compress the data with gzip we must do it from the servlet and we are sure that the response will be compressed data, and so build our swf to behave acordingly ( as you stated that I should know the incoming data format).

mmm this makes me willing to do some experimetns to try to gzip data and send it to flash.
Also some new doubts has arisen..
If the browser should decompress the gzipped data, has sense to wait for a binary response? Can flash specify when wants the response compressed or not and the browser then will not uncompress it?
What will happen if incoming compressed text uses the is ISO-8859-1 charset and not UTF ?
Will “data.readUTFBytes( data.length )” work properly?
Is it posible to compress a Value Object in AMF format and send it to flash and then use myByteArray.readObject() to uncompress it and bind it to an AS3 object without using Blaze or things like that?

thanks a lot for your support Nutrox!
Awesome as always

Polaco.

Good here that you have got this fixed.

When it comes to loading files into Flash, the browser will not automatically decompress any compressed data, that only happens to web pages really. If you use the URLLoaded class the loaded file will be in the same format as sent from the server.

Make sense?

Yes Nutrox it makes some sense…
But if I was receiving the data compressed why in IE6 was not working and in Firefox did?:eek: It looks like firefox was uncompressing it or that the header was incorrect and it wasn’t really compressed but instead the header was erroneously set by the IIS and that header error wasn’t a problem for Firefox.
(I was using the URLLoader to go against a servlet that returns a dinamically generated xml)

Will “data.readUTFBytes( data.length )” work properly if charset is ISO-8859-1?

Is it nescesary to set the URLRequestHeader ”Accept-Encoding”, “gzip” for the browser not decompress the response?

Have you ever tried to serialize with AMF a java value object or bean and send it to flash client without using Blaze or something like that or do you think it’s possible?

greetings!:)

ps: I have found this about AMF and Java seems cool http://javadevelopmentforthemasses.blogspot.com/2008/08/amf-serialization-from-java-to-flex-and.html
the other questions remains a bit confusing

Seems a bit strange that the browser is decompressing the data before it gets to Flash, are you sure an old version of the file isn’t being loaded from the cache?

You could also try ZLIB compression (what I mostly use for compressed files loaded into Flash), browsers don’t bother trying to decompress ZLIB compressed files.

Yes Nutrox pretty sure the file is not being cached because the problem was happening on the production enviroment and there it never worked and it was always being compressed by IIS. So anyway if it was being catched it was compressed.
At the begining of this problem I was blaming for this issue the IE6 for not decompressing the response since in Firefox was working and on the response header was the same for both browsers and it said that was gzipped. Now the response it’s not gzipped and works in both browsers, the swf has always been the same, so that’s what leads me to think that the browser is performing an automatic decompression. On the request both browsers has always sent on it’s header “accept-encoding GZIP,Defalte”.
The problem about all this is that doesn’t seems clear when the swf client could be receiving gzipped data and when the browser should decompress it or not.
This must follow some rule .

I will run a few tests today and try to pin-point the problem for you. Strange thing is I have never run into this problem before… then again I always tend to compress files using ZLIB if the files are not web pages.

Hey Si!, please don’t spend your time on this just for me. Since the problem has been solved. The only problem now is that let’s me wondering when or if browsers handle decompression automatically or not. I guess I could search a bit more on the web to look for that.
Anyway if you want to test it ‘coz it’s unclear for you too, the test results will be welcome.

Ok, it seems that the browser WILL automatically decompress incoming data if the Content-Encoding header sent from the server is “gzip” or “deflate”. This happens with IE6, Firefox, and all modern browsers because they automatically send an Accept-Encoding header with every request telling the server they can handle gzip and deflate encoded data. If you set the Accept-Encoding header in Flash I think it will overwrite the default one sent by the browser (I need to confirm that), so you shouldn’t really need to send that header.

One thing to keep in mind, if you do not pass any data to the server with the request you send from Flash it will default to GET and will not send any headers. So, you must send data with POST requests even if it is an empty byte array.

If you are testing things from a local server then you must always make sure you send Content-Encoding headers with the response data.

So to wrap things up, if the service you are using is sending the response as gzip encoded data then you don’t need to do anything in Flash, the data will automatically be converted to text (if running from a browser). If you are running the SWF from the Flash IDE then you will need to send the Accept-Encoding header with the requests and also decompress the data when it is loaded into Flash. No browser, no automatic decompression.

You can save yourself a load of hassle though by using zlib compression, browsers won’t attempt to decompress zlib data.

It will be interesting to find out how AIR handles all of this, so I will look into that today at some point.

ok Si! quite a bit of things to keep in mind. I humbly think that kind of issues should be documented by Adobe so everybody is aware of this different scenarios and possible situations and recommendations.

Also we could confirm that the IE6 has a problem with flash player plugin that not pass to it the gzipped response data decompressed.
Do you agree?

thanks a lot!

ps: please post any weird discovery you could do.

IE6 does decompress gzip and deflate compressed data before it reaches Flash, it is working as expected for me (the same as other browsers). The data won’t be decompressed by a browser (any browser) if the Content-Encoding header hasn’t been sent from the server.