Re: [Resin-interest] 304 status
Thanks Serge, the document proved to be just what we needed. We fixed our issues with a somewhat brain dead proxy as follows a) making sure Apache was serving documents and images directly (and not delegating to Resin) b) Activating mod_expires and using the Expires directives to tell the stupid proxy to keep images, css and so on in cache for a day c) Removing a vary: user-agent header that was preventing compressed content from being. We believe this to be a bug in the proxy. Luckily the largish css and js files we wanted compressed do not vary by user agent. Jean-François Lamy Teximus -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Serge Knystautas Envoyé : 17 mai 2007 13:08 À : General Discussion for the Resin application server Objet : Re: [Resin-interest] 304 status Jean-François, This is the best write-up I've seen on how browsers and proxy servers cache: http://www.mnot.net/cache_docs/ ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] 304 status
On May 18, 2007, at 5:02 AM, Alex Sharaz wrote: Other times I get the 304 status code. We've got random occurrences where setting a browser to auto detect proxy settings doesn't work and i'm wondering if these occurrences could coincide with the 304 status codes I can see in the logs. I suppose the question is. Can i reconfigure something to get rid of the 304 entries in the logs? I'm a little confused. I can add a bug report to allow filtering of 304 in the logs, but I'm not sure if there's another issue you're reporting. -- Scott Alex -Original Message- From: [EMAIL PROTECTED] [mailto:resin-interest- [EMAIL PROTECTED] On Behalf Of Scott Ferguson Sent: 17 May 2007 18:45 To: General Discussion for the Resin application server Subject: Re: [Resin-interest] 304 status On May 17, 2007, at 10:02 AM, Jean-Francois Lamy wrote: I am trying to understand how resin, apache and proxies interact with respect to caching. I have a jsp page which is meant to be always dynamic; headers are used to prevent it from being cached. However, the page loads js, css, and various images, which I would like to be cached. Currently, the browser (IE7) requests those items, and Resin returns 304 (up-to-date) status. The browser is NOT set to force request at each page. This generates a lot of requests, which are painful when going through proxies. What are the headers for the JSP page? With no caching headers, Resin doesn't cache at all, i.e. no-cache is the default. So the 304 is strange, unless the headers are telling Resin to cache. (Serge's recommendations are good ones for general understanding of HTTP caching, but the described behavior seems odd.) -- Scott Is there a recipe for forcing the JSP to always reload (my JSPs are served through a dispatching servlet which does an include, and therefore servlet is able manipulate the headers), and yet let the browser know that the js and css it has in cache are just fine ? Jean-François Lamy Technologies Teximus inc. www.teximus.com +1 514.878.1577 (Canada) +33(0) 8.70.44.49.02 (Europe) ___ 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** *** To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html ** ***___ 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] 304 status
Sorry didn't phrase that properly. If a client makes a request for wpad.dat, is there any way of always returning a copy of the file instead of an http status 304 message? Alex -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ferguson Sent: 22 May 2007 16:49 To: General Discussion for the Resin application server Subject: Re: [Resin-interest] 304 status On May 18, 2007, at 5:02 AM, Alex Sharaz wrote: Other times I get the 304 status code. We've got random occurrences where setting a browser to auto detect proxy settings doesn't work and i'm wondering if these occurrences could coincide with the 304 status codes I can see in the logs. I suppose the question is. Can i reconfigure something to get rid of the 304 entries in the logs? I'm a little confused. I can add a bug report to allow filtering of 304 in the logs, but I'm not sure if there's another issue you're reporting. -- Scott Alex -Original Message- From: [EMAIL PROTECTED] [mailto:resin-interest- [EMAIL PROTECTED] On Behalf Of Scott Ferguson Sent: 17 May 2007 18:45 To: General Discussion for the Resin application server Subject: Re: [Resin-interest] 304 status On May 17, 2007, at 10:02 AM, Jean-Francois Lamy wrote: I am trying to understand how resin, apache and proxies interact with respect to caching. I have a jsp page which is meant to be always dynamic; headers are used to prevent it from being cached. However, the page loads js, css, and various images, which I would like to be cached. Currently, the browser (IE7) requests those items, and Resin returns 304 (up-to-date) status. The browser is NOT set to force request at each page. This generates a lot of requests, which are painful when going through proxies. What are the headers for the JSP page? With no caching headers, Resin doesn't cache at all, i.e. no-cache is the default. So the 304 is strange, unless the headers are telling Resin to cache. (Serge's recommendations are good ones for general understanding of HTTP caching, but the described behavior seems odd.) -- Scott Is there a recipe for forcing the JSP to always reload (my JSPs are served through a dispatching servlet which does an include, and therefore servlet is able manipulate the headers), and yet let the browser know that the js and css it has in cache are just fine ? Jean-François Lamy Technologies Teximus inc. www.teximus.com +1 514.878.1577 (Canada) +33(0) 8.70.44.49.02 (Europe) ___ 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** *** To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html ** ***___ 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* To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html *___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] 304 status
o.k. fair enough doesn't matter then many thanks alex -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ferguson Sent: 22 May 2007 17:11 To: General Discussion for the Resin application server Subject: Re: [Resin-interest] 304 status On May 22, 2007, at 8:59 AM, Alex Sharaz wrote: Sorry didn't phrase that properly. If a client makes a request for wpad.dat, is there any way of always returning a copy of the file instead of an http status 304 message? The 304 is a response requested by the client, i.e. the client sends If-Modified-Since or If-None-Match headers. If the wpad.dat hasn't changed, a caching-header-aware servlet will return a 304 instead of the data. Resin's FileServlet understands those headers, so will return a 304 if the file hasn't changed. -- Scott Alex -Original Message- From: [EMAIL PROTECTED] [mailto:resin-interest- [EMAIL PROTECTED] On Behalf Of Scott Ferguson Sent: 22 May 2007 16:49 To: General Discussion for the Resin application server Subject: Re: [Resin-interest] 304 status On May 18, 2007, at 5:02 AM, Alex Sharaz wrote: Other times I get the 304 status code. We've got random occurrences where setting a browser to auto detect proxy settings doesn't work and i'm wondering if these occurrences could coincide with the 304 status codes I can see in the logs. I suppose the question is. Can i reconfigure something to get rid of the 304 entries in the logs? I'm a little confused. I can add a bug report to allow filtering of 304 in the logs, but I'm not sure if there's another issue you're reporting. -- Scott Alex -Original Message- From: [EMAIL PROTECTED] [mailto:resin-interest- [EMAIL PROTECTED] On Behalf Of Scott Ferguson Sent: 17 May 2007 18:45 To: General Discussion for the Resin application server Subject: Re: [Resin-interest] 304 status On May 17, 2007, at 10:02 AM, Jean-Francois Lamy wrote: I am trying to understand how resin, apache and proxies interact with respect to caching. I have a jsp page which is meant to be always dynamic; headers are used to prevent it from being cached. However, the page loads js, css, and various images, which I would like to be cached. Currently, the browser (IE7) requests those items, and Resin returns 304 (up-to-date) status. The browser is NOT set to force request at each page. This generates a lot of requests, which are painful when going through proxies. What are the headers for the JSP page? With no caching headers, Resin doesn't cache at all, i.e. no-cache is the default. So the 304 is strange, unless the headers are telling Resin to cache. (Serge's recommendations are good ones for general understanding of HTTP caching, but the described behavior seems odd.) -- Scott Is there a recipe for forcing the JSP to always reload (my JSPs are served through a dispatching servlet which does an include, and therefore servlet is able manipulate the headers), and yet let the browser know that the js and css it has in cache are just fine ? Jean-François Lamy Technologies Teximus inc. www.teximus.com +1 514.878.1577 (Canada) +33(0) 8.70.44.49.02 (Europe) ___ 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* * *** To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html * * ***___ 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** *** To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html ** ***___ 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* To view the terms under which this email
Re: [Resin-interest] 304 status
Jean-François, This is the best write-up I've seen on how browsers and proxy servers cache: http://www.mnot.net/cache_docs/ Then once you know what you want in headers, this page is a good discussion of the various browser and server-side caching features in Resin 3.1: http://www.caucho.com/resin-3.1/doc/proxy-cache.xtp What you want is certainly very doable and hopefully straight-forward after reading these docs. The first site also links to an online tool that can test whether you've got the headers working right. -- Serge Knystautas Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] Jean-Francois Lamy wrote: I am trying to understand how resin, apache and proxies interact with respect to caching. I have a jsp page which is meant to be always dynamic; headers are used to prevent it from being cached. However, the page loads js, css, and various images, which I would like to be cached. Currently, the browser (IE7) requests those items, and Resin returns 304 (up-to-date) status. The browser is NOT set to force request at each page. This generates a lot of requests, which are painful when going through proxies. Is there a recipe for forcing the JSP to always reload (my JSPs are served through a dispatching servlet which does an include, and therefore servlet is able manipulate the headers), and yet let the browser know that the js and css it has in cache are just fine ? Jean-François Lamy Technologies Teximus inc. www.teximus.com +1 514.878.1577 (Canada) +33(0) 8.70.44.49.02 (Europe) ___ 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] 304 status
On May 17, 2007, at 10:02 AM, Jean-Francois Lamy wrote: I am trying to understand how resin, apache and proxies interact with respect to caching. I have a jsp page which is meant to be always dynamic; headers are used to prevent it from being cached. However, the page loads js, css, and various images, which I would like to be cached. Currently, the browser (IE7) requests those items, and Resin returns 304 (up-to-date) status. The browser is NOT set to force request at each page. This generates a lot of requests, which are painful when going through proxies. What are the headers for the JSP page? With no caching headers, Resin doesn't cache at all, i.e. no-cache is the default. So the 304 is strange, unless the headers are telling Resin to cache. (Serge's recommendations are good ones for general understanding of HTTP caching, but the described behavior seems odd.) -- Scott Is there a recipe for forcing the JSP to always reload (my JSPs are served through a dispatching servlet which does an include, and therefore servlet is able manipulate the headers), and yet let the browser know that the js and css it has in cache are just fine ? Jean-François Lamy Technologies Teximus inc. www.teximus.com +1 514.878.1577 (Canada) +33(0) 8.70.44.49.02 (Europe) ___ 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
