I have now narrowed the situation down to the file extension. Specifically, Gzip is causing encoding problems when the file extension ends with .html. I renamed the same file to some other extension and the file get encoded and decoded properly with no problems.

Yet, when the filter tries to encode/decode files with HTML extensions, somehow, the file is not encoded right. What could possibly be going on here?

My only guess right now is that there may be other filters running before mine. I will turn on deep logging to see if I can catch something in the resin log.

-chris


On Jul 11, 2008, at 3:48 AM, Chris Chen wrote:

I just disabled resin caching proxy and tested it. Some response headers are now going through and it appears that caching is working better at the moment.

However, the system is still unable to decode that specific GWT cache.html file. No matter what happens, this file is somehow not being encoded properly or something.

In fact, trying to encode any of the GWT-generated cache.html files just won't work. It seems like it's a very specific problem with these files. And they're not even gzipped.

I should try a test where I gzip it unzip it myself to see what happens.

-Chris


On Jul 11, 2008, at 3:33 AM, Chris Chen wrote:

I am using your configurations and it's working, but only because the responses are not getting encoded.

I think this may be caused by the load balancer web tier that I have running. I believe you are probably on the right track on that one. I have resin cache enabled on both the web and the app tiers. It's likely that somehow the caching mechanism on the web tier is causing havoc. Looks like I will have to dig a little deeper into the caching mechanism of resin. I am going to disable caching to see if things are ok first.

-Chris


On Jul 11, 2008, at 3:11 AM, Haroon Rasheed wrote:

Also I would like to know, whether your server is running under a LoadBalancer? if yes... please send the details on the same...

Please try the following configuration and lemme know if this helps.

<!--gzip changes start-->
<filter filter-name="gzip" filter- class="com.caucho.filters.GzipFilter">
   <init>
     <use-vary>true</use-vary>
   </init>
</filter>

<filter-mapping filter-name="gzip">
   <url-pattern>
     <exclude-pattern>*.pdf</exclude-pattern>
     <exclude-pattern>*.zip</exclude-pattern>
     <include-pattern>/*</include-pattern>
   </url-pattern>
</filter-mapping>

<!--gzip changes end-->

Regards,
Haroon

2008/7/11 Chris Chen <[EMAIL PROTECTED]>:
Thanks for the reply,

my configuration comes directly from the documentation:

<filter filter-name="gzip" filter- class="com.caucho.filters.GzipFilter"/>
        <filter-mapping filter-name="gzip" url-pattern="/*"/>

The interesting thing is that other files seem to zip fine. I am consistently hitting encoding issues with this particular GWT cache.html file. Gzip and Resin appears to be returning the code just fine. Yet somehow I am getting content encoding errors from Safari, Firefox, and now-tested Curl (I was trying to use curl to figure out what exactly is the problem, but no go).

The files are all accessed through SSL if that has any relevance. I'm also running under Linux

-Chris


On Jul 11, 2008, at 2:32 AM, Haroon Rasheed wrote:

Chris,

We have been using gzip filter on production servers for the past 8 months, and didn't face any such issues. Please send the gzip filter configuration from web.xml, lemme see if anything is different in your conf?

Thanks & regards,
Haroon


2008/7/11 Chris Chen <[EMAIL PROTECTED]>:
Actually,

I have a further problem using GzipFilter.

I enabled it using no dispatcher, which according to Servlet Spec 2.4,
means that it defaults to only REQUEST.

When I started using the GzipFilter, I noticed a few things

1) Gzip appears to work on static files that are served through
FileServlet, so that takes care of mostly the JS, CSS, and image files.

2) However,  when it comes to the primary pages served by Grails,
these do not get compressed. I have a feeling that this is because of
the internal forwarding that's going on with the URL Mapping, GSP
servlet, etc. So my question is - is it safe to enable GzipFilter for
FORWARDed requests in the dispatcher?

3) I am using GWT (google web toolkit) and it serves out javascript
files.  There is a nocache.js file and then there are cache.html
javascript files. It appears that the nocache.js files are downloaded
properly, but my primary cache.html files are being compressed
improperly for some reason.  Here's the request:

GET /v1/gwt/com.bbb.Mail/ 1B5800A70AEC91E23D018344A2E80852.cache.html
HTTP/1.1

The error I get on Firefox is "Content Encoding Error: The page you
are trying to view cannot be shown because it uses an invalid or
unsupported form of compression."
The error I get on Safari is "cannot decode raw
data" (NSURLErrorDomain:-1015)

The response header for this request looks like everything is ok:

(Status-Line)   HTTP/1.1 200 OK
Server  Resin/3.1.5
Etag    "ClNcVcwhyDQ"
Last-Modified   Fri, 11 Jul 2008 08:13:24 GMT
Cache-Control   private
Content-Encoding        gzip
Content-Type    text/html; charset=UTF-8
Content-Length  85824
Date    Fri, 11 Jul 2008 08:39:45 GMT

Yet, I am getting this error.  I think it's something caused by
GzipFilter, but then I'm not sure what could have went wrong here.
This file should have been served directly from FileServlet.

Scott, do you have any ideas?

-Chris

On Jul 11, 2008, at 1:11 AM, Chris Chen wrote:

> This is a question aimed at Resin's support team.
>
> I'm wondering what the defaults for a Filter's dispatcher setting is. > This is only valid for 2.4 webapps. So if I were to exclude these > parameters, does this mean that Resin 3.1.5 will filter all types of
> dispatched requests?
>
> I ask this because I'm looking at the example configuration for the > GzipFilter and I'm not sure if it filters only on REQUEST or the other > ones as well. Should I be worried if I don't include the <dispatcher>
> config?  I had this issue regarding filter dispatchers when
> configuring Confluence.
>
> -Chris
>
>
> _______________________________________________
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest



_______________________________________________
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

_______________________________________________
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest


_______________________________________________
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest


_______________________________________________
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

_______________________________________________
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

_______________________________________________
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

_______________________________________________
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Reply via email to