Re: [Resin-interest] Filter's dispatcher defaults
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. > > > > > true > > > > > > *.pdf > *.zip > /* > > > > > > Regards, > Haroon > > 2008/7/11 Chris Chen <[EMAIL PROTECTED]>: > >> Thanks for the reply, >> my configuration comes directly from the documentation: >> >> >> >> >> 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 di
Re: [Resin-interest] Filter's dispatcher defaults
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. class="com.caucho.filters.GzipFilter"> true *.pdf *.zip /* Regards, Haroon 2008/7/11 Chris Chen <[EMAIL PROTECTED]>: Thanks for the reply, my configuration comes directly from the documentation: class="com.caucho.filters.GzipFilter"/> 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
Re: [Resin-interest] Filter's dispatcher defaults
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. class="com.caucho.filters.GzipFilter"> true *.pdf *.zip /* Regards, Haroon 2008/7/11 Chris Chen <[EMAIL PROTECTED]>: Thanks for the reply, my configuration comes directly from the documentation: class="com.caucho.filters.GzipFilter"/> 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-Encodinggzip Content-Typetext/html; charset=UTF-8 Content-Length 85824 DateFri, 11 Jul 2008 08:39:45 GMT Yet, I am getting this error. I think it's so
Re: [Resin-interest] Filter's dispatcher defaults
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. class="com.caucho.filters.GzipFilter"> true *.pdf *.zip /* Regards, Haroon 2008/7/11 Chris Chen <[EMAIL PROTECTED]>: Thanks for the reply, my configuration comes directly from the documentation: class="com.caucho.filters.GzipFilter"/> 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-Encodinggzip Content-Typetext/html; charset=UTF-8 Content-Length 85824 DateFri, 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 REQUE
Re: [Resin-interest] Filter's dispatcher defaults
Good! Lemme know if it works after you disable caching... 2008/7/11 Chris Chen <[EMAIL PROTECTED]>: > 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. > > > > > true > > > > > > *.pdf > *.zip > /* > > > > > > Regards, > Haroon > > 2008/7/11 Chris Chen <[EMAIL PROTECTED]>: > >> Thanks for the reply, >> my configuration comes directly from the documentation: >> >> >> >> >> 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-Encodinggzip >>> Content-Typetext/html; charset=UTF-8 >>> Content-Length 85824 >>> DateFri, 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 >>> > config? I had this issue regarding filter dispatchers when >>> > configuring Confluence. >>> > >>> > -Chris >>> > >>> > >>> > ___ >>> > resin-interest mailing list >>> >
Re: [Resin-interest] Filter's dispatcher defaults
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. class="com.caucho.filters.GzipFilter"> true *.pdf *.zip /* Regards, Haroon 2008/7/11 Chris Chen <[EMAIL PROTECTED]>: Thanks for the reply, my configuration comes directly from the documentation: class="com.caucho.filters.GzipFilter"/> 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-Encodinggzip Content-Typetext/html; charset=UTF-8 Content-Length 85824 DateFri, 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 > 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/mailma
Re: [Resin-interest] Filter's dispatcher defaults
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. true *.pdf *.zip /* Regards, Haroon 2008/7/11 Chris Chen <[EMAIL PROTECTED]>: > Thanks for the reply, > my configuration comes directly from the documentation: > > > > > 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-Encodinggzip >> Content-Typetext/html; charset=UTF-8 >> Content-Length 85824 >> DateFri, 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 >> > 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
Re: [Resin-interest] Filter's dispatcher defaults
Thanks for the reply, my configuration comes directly from the documentation: class="com.caucho.filters.GzipFilter"/> 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-Encodinggzip Content-Typetext/html; charset=UTF-8 Content-Length 85824 DateFri, 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 > 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
Re: [Resin-interest] Filter's dispatcher defaults
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-Encodinggzip > Content-Typetext/html; charset=UTF-8 > Content-Length 85824 > DateFri, 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 > > 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
Re: [Resin-interest] Filter's dispatcher defaults
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-Encodinggzip Content-Typetext/html; charset=UTF-8 Content-Length 85824 DateFri, 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 > 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] Filter's dispatcher defaults
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 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
