Michael McCallister | 10 Feb 00:37
Favicon

filter out headers for fastcgi cache

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 
(Continue reading)

Favicon
Gravatar

Re: filter out headers for fastcgi cache

On 9 Fev 2012 23h37 WET, mikemc-nginx@... 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
(Continue reading)

Michael McCallister | 10 Feb 06:20
Favicon

Re: filter out headers for fastcgi cache

António P. P. Almeida wrote, On 02/09/2012 04:45 PM:
> On 9 Fev 2012 23h37 WET, mikemc-nginx@... 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
(Continue reading)

Max | 10 Feb 23:54
Picon

Re: filter out headers for fastcgi cache


10 февраля 2012, 03:39 от Michael McCallister <mikemc-nginx <at> terabytemedia.com>:
> 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
(Continue reading)

Michael McCallister | 14 Feb 19:46
Favicon

Re: filter out headers for fastcgi cache

Max wrote, On 02/10/2012 03:54 PM:
> http://wiki.nginx.org/NginxHttpProxyModule#proxy_hide_header
>
> The proxy_hide_header directive does exactly what you described,
> the cookies get stored in the cache, but they are not passed back
> to the client, so this is all you'd need:
>
> # Cache responses containing the Set-Cookie header as well
> fastcgi_ignore_headers Set-Cookie;
>
> # Strip the Set-Cookie header from cached content
> # when passing cached content back to clients
> proxy_hide_header Set-Cookie;
>
> You could also include session cookies in the fastcgi_cache_key
> to make sure new users get the default cached content, while
> everyone else gets their session-specific cached content:
>
> fastcgi_cache_key "$cookie_PHPSESSID$scheme$request_method$host$server_port$request_uri";
>
> Max

Thanks Max!
Max | 15 Feb 01:56
Picon

Re[2]: filter out headers for fastcgi cache


14 февраля 2012, 22:48 от Michael McCallister <mikemc-nginx <at> terabytemedia.com>:
> Max wrote, On 02/10/2012 03:54 PM:
> > http://wiki.nginx.org/NginxHttpProxyModule#proxy_hide_header
> >
> > The proxy_hide_header directive does exactly what you described,
> > the cookies get stored in the cache, but they are not passed back
> > to the client, so this is all you'd need:
> >
> > # Cache responses containing the Set-Cookie header as well
> > fastcgi_ignore_headers Set-Cookie;
> >
> > # Strip the Set-Cookie header from cached content
> > # when passing cached content back to clients
> > proxy_hide_header Set-Cookie;
> >
> > You could also include session cookies in the fastcgi_cache_key
> > to make sure new users get the default cached content, while
> > everyone else gets their session-specific cached content:
> >
> > fastcgi_cache_key
> "$cookie_PHPSESSID$scheme$request_method$host$server_port$request_uri";
> >
> > Max
> 
> Thanks Max!

You're welcome! Just run s/proxy_/fastcgi_/ on the above to get
the fastcgi directives. Those directives are the same in all of
the (fastcgi|proxy|scgi|uwsgi) modules:
(Continue reading)


Gmane