Good to know that! I have my gzip filter, immediately after the UTFEncoding
filter and the rest.

So I never faced this issue:)

Regards,
Haroon



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

> I think I have figured out the problem.  It appears to be filter orders.  I
> have my gzip filter in my resin-web.xml.  I thought and assumed that
> resin-web.xml take priority over web.xml, but I was wrong.  I then found
> that app-defaults.xml indicates the loading order.
> So basically, my gzip filter has been loading as the last filter out of all
> the other filter (ie. grails filter, spring framework filters, etc).  Most
> of these filters don't modify the content except for probably one of them
> (one that has to do with .html files is my guess).  It's too late and I
> don't really care which one is the culprit, but I think I found my solution.
>
> Thanks for all the help. :)
>
> Chris
>
> On Jul 11, 2008, at 4:01 AM, Chris Chen wrote:
>
> 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
>
>
>
> _______________________________________________
> 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