filter out headers for fastcgi cache
Michael McCallister
mikemc-nginx at terabytemedia.com
Thu Feb 9 23:37:19 UTC 2012
Greetings,
I would like to propose that an additional feature for nginx be
considered related to fastcgi caching: the ability to specify headers
that will not be stored in cache, but will be sent to the client when
the cached version is created (sent to the client responsible for
creating the cached copy). If some solution already exists providing
this functionality, my apologies, I was not able to track one down -
currently assuming one does not exist.
Here is one scenario where such an option would be useful (I am sure
there are others):
A typical scenario where fastcgi caching can be employed for performance
benefits is when the default version of a page is loaded. By "default",
I mean the client has no prior session data which might result in unique
session specific request elements. In the case of PHP, the presence of
session data is typically determined by checking for the presence of a
"PHPSESSID" cookie. So if this cookie does not exist, then it can be
assumed there is no session - an optimal time to create a cached version
of the page in many scenarios. However, many PHP apps/sites/etc. also
create a session in the event one does not exist (a behavior I assume is
not specific to PHP) - meaning the the response typically contains a
Set-Cookie: PHPSESSID.... header. Nginx's default behavior is not to
cache any page with a Set-Cookie header, and that makes sense as a
default - but lets assume for this example that fastcgi_ignore_headers
Set-Cookie; is in effect and the cached version of the default version
of the page gets created. The problem here is that the cached version
created also has the Set-Cookie header cached as well - which causes
problems for obvious reasons (hands out the same session ID/cookie for
all users). Ideally, we could specify to cache everything except the
specified headers - Set-Cookie in this example.
Am I the only one who would find this option useful or are there others?
If this would be found to be useful by others and there is consensus
that such an addition is called for by those with the resources to
implement it, I am not sure if it makes sense to strip the headers prior
storage in cache or when reading from cache - probably whichever is easier.
Thoughts?
Michael
More information about the nginx
mailing list