No announcement yet.
  • Filter
  • Time
Clear All
new posts

    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.


      Finally resolved.

      We were able to resolve this issue by adding securePagesWithPragma="false" property in tomcat's context.xml.

      It was tomcat that was setting Cache-Control and Pragma as no-cache.

      From your response we were able to tune the application, it would nice if you can post some article on fine tuning SmartClient's framework for production environment.

      Thanks for being patience and answering our queries.


        Thanks for posting the final solution. Can you clarify what application server you are using and whether that was a default setting you had to change?

        Note that SmartClient ships with the recommended production settings pre-configured (in the smartclientRuntime directory). You can always go further with CDN deployment or by putting Apache in front of your Tomcat instance, but the correct settings for SmartClient as such are already there.


          Tomcat 5.5.20 application server.

          We were using Apache 2 + Tomcat 5.5.20 with Netscaler (SSL).

          Here is the link that talks about this solution.


            We found that the CompressionFilter is not compression all resources even if we configured with /* in web.xml.

            There are some mime types are not compressed example anything text/html is not compressed.

            Is there anyway to include the complete list and say compress everything?


              CompressionFilter will avoid compressing certain mime-types if the browser making the request is known to have problems with that mime-type (true of eg CSS in older IE). This never applies to text/html however.

              It will also avoid serving compressed files to a browser that does not advertise the ability to receive compressed content via the Accept-Encoding header, which can happen if you are going through an older HTTP 1.0 proxy.