Hi!


I'm having a weird but a bit known problem. When I make a request to a web application from flash and the response xml is compressed with gzip Flash fails to receive the answer. Apparetly IE6 never pass the flashplayer the response.

http://bugs.adobe.com/jira/browse/FP-330

anyone knows a solution for this?

I'm using a servlet to generate the xml.

thanks a lot in advance.
Polaco.

a great community.

[Nutrox]

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:

header( "Pragma: ", true );
header( "Cache-Control: ", true );

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.

[Polaco]

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!

[Polaco]

I have seen this post:
[AS3] URLLoader data?

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:

...
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);
... 

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.

[Polaco]

please delete this accidental post

[Nutrox]

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...

var req:URLRequest = new URLRequest();
// setup your request here

var loader:URLLoader = new URLLoader();
loader.dataFormat = URLLoaderDataFormat.BINARY;
loader.load( req );
loader.addEventListener( Event.COMPLETE, dataHandler );

function dataHandler( e:Event ):void
{
	var data:ByteArray = loader.data;
	
	try
	{
		// attempt to decompress the data
		data.uncompress();
	}
	catch( err:Error )
	{
		try
		{
			// attempt to decompress the data again
			data.uncompress( CompressionAlgorithm.DEFLATE );
		}
		catch( err:Error )
		{}
	}
	
	// grab the text from the byte array
	var text:String = data.readUTFBytes( data.length );
	
	// you should now be able to create your XML object
	var xml:XML = new XML( text );
	
	// keep things tidy
	loader.data.length = 0;
	loader.data = null;
	loader.removeEventListener( Event.COMPLETE, dataHandler );
}

[Polaco]

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.

[Nutrox]

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?

[Polaco]

Yes Nutrox it makes some sense...
But if I was receiving the data compressed why in IE6 was not working and in Firefox did? 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.b...-flex-and.html
the other questions remains a bit confusing

[Nutrox]

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.

[Polaco]

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 .

[Nutrox]

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.

[Polaco]

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.

[Nutrox]

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.

request.method = URLRequestMethod.POST;
request.data = new ByteArray(); // required for POST requests

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.

[Polaco]

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.

[Nutrox]

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.

[Polaco]

well.. so I really don't understand
As I posted before, this is the header we were receiving
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 that was failing on IE6 not in Firefox.. it has the Content-Encoding set.

[Nutrox]

I don't know what is happening with that then, even if I test with those headers IE6 still decompresses the data before it reaches Flash. You will just have to try things again I guess.

[Polaco]

Ok Si, i guess maybe a diferent IE6 version maybe a service pack or something could have fixed your IE?
The IE6 version is: 6.0.2900.2180.xpsp_sp2_gdr.070227-2254
UpdateVersions: SP2
We have tested it during 2 days, completly sure that it was happenig.
Anyway it's great to know that it always decompresses it and that I could use zlib to compress data sent specifically to flash client just in case I need it.

thanks a lot again!

Polaco

[Nutrox]

Some more notes:

AIR won't automatically decode gzip or deflate encoded data even though the requests/responses are being pushed through WebKit, WebKit doesn't send an Accept-Encoding header to the server either.

So... it seems that unless you are running a SWF file in a browser you won't be able to do anything with gzip encoded data sent from a server because ActionScript can only encode/decode data using the zlib and deflate algorithms. You might be able to find a gzip encoder/decoder class someone has made though.

SWF running in a browser
gzip and deflate encoded data is automatically decoded by the browser before being passed to ActionScript (as long as the Content-Encoding header is sent from the server).

All other situations
No automatic decoding is done as far as I can tell, you need to decode the data in ActionScript.

Note on AIR
The URLLoader will dispatch a HTTP_RESPONSE_STATUS event ( HTTPStatusEvent ) that will contain an array of headers sent from the server. You could roll through the headers to determine the encoding of the data if you don't know what it will be.

[Nutrox]

One thing you could do is use a local PHP file to load the data from the service, decode it, and then send the decoded data to Flash (or re-encoded it using zlib). So instead of loading the data directly from the service you do it via a PHP file. At least that way you will know exactly what Flash will be receiving.

[Polaco]

I think you could write an article about all this on your web when it comes back.


ps:I have been doing some tests with java and AMF protocol (serialization/deserialization) , couldn't try it from flex yet.
But seems that could be very useful in some scenarios (at least for me).
pps: I'm going off topic

[Fernando]

ie6 doesn't support gziped content.

[Nutrox]

Well I don't know what has happened to my IE6 then because it handles gzip encoded content fine, it even tells the server it can...

["HTTP_ACCEPT_ENCODING"]=> string(13) "gzip, deflate"

This PHP script that is generating gzip encoded data is also being read/displayed by IE6...

<?php

header( "Pragma: ", true );
header( "Cache-Control: ", true );
header( "Expires: Sat, 01 Jan 2000 00:00:00 GMT", true );
header( "Content-Transfer-Encoding: binary", true );
header( "Content-Type: application/xml", true );

ob_start();
var_dump( $_SERVER );
$raw = ob_get_clean();

$data = "<data>"
      . "<time>" . time() . "</time>"
      . "<message>This is just a little test file.</message>"
	  . "<raw><![CDATA[{$raw}]]></raw>"
      . "</data>";

$data = gzencode( $data );

header( "Content-Encoding: gzip" );
header( "Content-Length: " . strlen( $data ) );

echo( $data );

?>

IE6 version: 6.0.2900.2180.xpsp_sp2_rtm.040803-2158

[Fernando]

My reply was not complete. It doesn't work on ie6 if sp2 is not installed. The better to do is avoid gzip for ie6.

http://support.microsoft.com/default...&Product=ie600

[Nutrox]

Makes sense.

IMO it is better to avoid gzip and deflate completely when working with Flash, if you want to transfer compressed content then use zlib and you will know the data will be compressed when it reaches Flash.

[silverdog]

I had this same problem (ie6+ flash + gzip on iis) and ran accross this thread looking for a solution.

The thread gave me some hints and I ended up finding a solution. So I figured I would join and post to help someone else out in the future.

I did not want to simply turn compression off because it has great benefits for bandwidth....

Ie6 typically seems quite happy with gzip compression, but for some reason flash has issues with it when a no cache header is sent back from the server.

So if you change this header from the server
Cache-Control:no-cache
to
Cache-Control: private

things will work. Not exactly sure why, but that seems to make ie6 give the correct decompressed stream to flash. I tested with the sp1 version of ie6, so I'm pretty sure it resolves it for all versions.