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.
Announcement
Collapse
No announcement yet.
X
-
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?
Leave a comment:
-
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.
http://webui.sourcelabs.com/tomcat/issues/27122
Leave a comment:
-
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.
Leave a comment:
-
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.
Leave a comment:
-
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.
Leave a comment:
-
We have many web applications inside the same tomcat and using the same Apache, none of them puts those headers.
Only this webapp that has smartclient libraries has all requests with those headers.
Response Headers Value
(Status-Line) HTTP/1.1 200 OK
Date Wed, 08 Apr 2009 13:21:55 GMT
Server Apache/2.2.11 (Unix) mod_jk/1.2.27
Pragma No-cache
Cache-Control no-cache
Expires Wed, 31 Dec 1969 19:00:00 EST
Last-Modified Mon, 06 Apr 2009 13:50:07 GMT
Content-Length 51742
Keep-Alive timeout=5, max=78
Connection Keep-Alive
Leave a comment:
-
You're not using our NoCache servlet, so something other than SmartClient is setting those headers. You need to identify it.
Take a look at any security settings you may have on your servlet container. Some servlet containers disable caching by default in HTTPS for various mime types, or for all files.
If you are using Apache in addition to a servlet container, look through your Apache settings.
Leave a comment:
-
Attaching web.xml, the FusionChart swf URL's are fine.
Attaching web.xml, the FusionChart swf URL's are fine, it works perfectly fine in FireFox.
The issue is only on IE when accessing the URL as HTTPS.
The only issue we have here is the Cache-Control and Pragma headers included in each req/resp.Attached Files
Leave a comment:
-
SmartClient's NoCache servlet will set those, however, it is not enabled by default in the web.xml provided as an example for production use (smartclientRuntime/WEB-INF/web.xml) and is not enabled for Flash even in the development settings (smartclientSDK/WEB-INF/web.xml). Maybe you enabled it for all URLs?
Also, you previously claimed that SmartClient was looking for the FusionChart .swf at the wrong URL. Was this incorrect?
Leave a comment:
-
Found the reason, why chart is not loading in IE with SSL.
It looks like all request from SmartClient is setting this value, is this true?
If so how to override or remove it.
Pragma No-cache
Cache-Control no-cache
We need to remove this entry inorder to have the FusionChart flash to work in IE with SSL, please refer the below URL
http://kb.adobe.com/selfservice/view...rnalId=fdc7b5c
Leave a comment:
-
Subash, the first thing we did was sanity check that SectionStacks and FusionCharts work normally in IE with a Linux+HTTPS server. And it works fine.
A difference in browser behavior does not at all imply a SmartClient bug, you can easily create such a difference by misconfiguring something or misusing something.
You clearly expect that we are miraculously going to hand you a fix. This is not going to happen because the problem is on your end. We have provided pointers to the tools you need to use to figure out what you've done wrong, and you need to take those recommended steps, or no progress will be made.
So, once again, use Fiddler to find out if there are media requests or requests for Flash files that aren't working, and if there are and its not obvious what's wrong, post complete information here.
Leave a comment:
-
Still same problem.
We did looked for SectionStack and external CSS, we are not using any external CSS or TD as you mentioned.
It's definitely something to do with SmartClient framework that does things differently for Firefox and Internet Explorer.
As I mentioned earlier everything is fine in Firefox and Chrome, but only IE is having issue, we also tried setting the expires headers to future still same issue in IE.
Leave a comment:
-
The image files are named window_L.png and so forth and the Skinning Guide explains why. But why you would be looking at media for Window we're not sure, since we already explained that a SectionStack is what's missing media. Look in Fiddler for requests for SectionHeader/*.
In general, can you please use your judgement to put forward anything that might be relevant? We're spending a tremendous amount of time with you troubleshooting what is almost certain to be an Apache misconfiguration or similar on your part, unrelated to SmartClient.
Clearly any 404 for media in the Fiddler logs is interesting. Complete information for the "Session was aborted.." report you are seeing is also obviously relevant.
Leave a comment:
-
Fiddler output
For flash URL it says this,
Session was aborted by the client, Fiddler, or the Server.
I'm just curious how the code works fine in FireFox but having so many issues in IE.
We tried different skins, all skin have issues with curved edges for window and when we looked in load_skin.js, the code that has edges properties
edgeImage: "[SKINIMG]Window/window.png",
There is no image named window.png in Window dir of BlackOps skin.
Leave a comment:
Leave a comment: