Yes Subash, let us remind you again, we have multiple applications running on HTTPS+Linux+IE, none of them have the problems you are running into, this problem is unique to your deployment.
If you actually want to fix this problem, please stop telling us it's a general SmartClient problem and follow the troubleshooting steps we recommend.
These headers look as though the request never went through a SmartClient servlet. You may find that Apache is serving these files directly. You could kill the servlet engine process entirely and try accessing the .swf to test this - if that works, Apache is serving the file directly.
Otherwise, you could disable the CompressionFilter in your web.xml, which is the only SmartClient-provided servlet involved in the request even if it makes it to the servlet engine, as a means of conclusively demonstrating it's not SmartClient-related.
If you actually want to fix this problem, please stop telling us it's a general SmartClient problem and follow the troubleshooting steps we recommend.
These headers look as though the request never went through a SmartClient servlet. You may find that Apache is serving these files directly. You could kill the servlet engine process entirely and try accessing the .swf to test this - if that works, Apache is serving the file directly.
Otherwise, you could disable the CompressionFilter in your web.xml, which is the only SmartClient-provided servlet involved in the request even if it makes it to the servlet engine, as a means of conclusively demonstrating it's not SmartClient-related.
Comment