On Wed, May 26, 2010 at 10:03 AM, reference123 <nginx-forum@nginx.us> wrote:
> Do you do any type of caching with the proxy and if so, have you had
> any issues?  We would like to cache our dynamic asp pages but have
> been cautious because of viewstate and sessions.

We only cache static items with nginx at the moment (images and
JS/CSS). Viewstate and sessions can be incompatible with any form of
caching on a public proxy. Caching a dynamic page only helps if the
same exact page can be safely delivered to multiple users (such as
Wikipedia's pages). You could conceivably add in the session cookie as
part of proxy_cache_key, but that is rather pointless since you can
have the user's own browser cache the page with simple "Cache-Control:
private,max-age=600" set by the ASP.net code (or even by nginx). If it
is a custom per-user response anyway, no reason to cache it on your
proxy, cache it in the browser.

> Finally, do you use more than one backend server and if so have you
> found a good resolution to the Etag issue. I have tried many of the IIS6
> options I found online with no result.  I am getting tempted to block the
> Etag header at the proxy level at this point.

We have synchronized the E-tag seeds to 0 on all of our IIS boxes
(there's an MS knowledge-base article about it). Works like a champ,
but you also have to make sure all of the files have the same last
modified date-stamps on all of your back-ends (ROBOCOPY can do this,
or rsync). You can of course simply also block the Etag header at the
proxy. We didn't do that because we have some Tomcat applications that
set the Etag header dynamically. Apache has similar issues with E-Tags
in its default configuration (they use filesystem inode numbers).


--
RPM

_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx