filter out headers for fastcgi cache

[Michael McCallister]

António P. P. Almeida wrote, On 02/09/2012 04:45 PM:
> On 9 Fev 2012 23h37 WET, mikemc-nginx at terabytemedia.com wrote:
>
>> 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
> http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_pass_header
>
> Also, you can capture the session ID and use it in
> fastcgi_cache_key. Like this, for example:
>
> ## Set a cache_uid variable for authenticated users.
> map $http_cookie $cache_uid {
>      default nil; # hommage to Lisp :)
>      ~SESS[[:alnum:]]+=(?<session_id>[[:alnum:]]+) $session_id;
> }
>
> fastcgi_cache_key $cache_uid@$host$request_uri;
>
> --- appa

How does fastcgi_pass_header help in this instance?  From the docs, that 
directive "explicitly allows to pass named headers to the client."  In 
the example, I need to drop the Set-Cookie header from the cached copy.

As far as setting up cache files for each session, that is less useful 
for me (but a cool feature).  The main benefit in caching for me is for 
users that are not logged in (or doing anything that modifies site 
content) since they represent around 75% of page loads and there is no 
user specific variance in the pages themselves.  I would suspect many 
other sites follow a similar usage pattern.