HTTP Response Header - partly added by Processwire?

[Joe]

Hello everyone!

Maybe this has been answered somewhere here, but since I couldn´t find it I´ll be happy if someone can point me in the right direction.

I´m trying to set up a Processwire-powered site´s .htaccess file to optimize caching. I have to say that I´m not very Apache-savvy, so I might have missed something obvious. My question basically is if Processwire sets some of the HTTP Response Header fields and if so, how can they be adapted?

Actually, I just see "Set-Cookie: wire=..." - that must obviously have been set by Processwire - what might it be intended for - the admin when logged in?

Currently I get this HTTP Response Header:

Date: Thu, 17 Oct 2013 19:39:11 GMT
Server: Apache
X-Powered-By: PHP/5.3.27
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: wire=7438ab55c68e6ffd657ff61e13c9ee9d; path=/
Cache-Control: max-age=7200, must-revalidate, no-transform
Vary: User-Agent,Accept
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8

The second cache control entry has been set by my .htaccess file - Cache-Control: max-age=7200

Where would the first one - "Cache-Control: no-store, no-cache ..." come from? Could it have been created by Processwire in some way? Or is it an Apache setting I have failed to override? (Nothing was set by Meta tags in a template file.)

There is no other .htaccess file further up the tree. Here is what I have added to the standard .htaccess file that comes with the Processwire installation. (added at the top):

# -----------------------------------------------------------------------------------------------
# ADDED BY JOE
# -----------------------------------------------------------------------------------------------

# Prevent some of the mobile network providers from modifying the content of
# your site: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.5.

<IfModule mod_headers.c>
	Header set Cache-Control "max-age=7200, must-revalidate"
	Header unset Last-Modified
	Header unset Pragma
</IfModule>

# Prevent mobile transcoding and caching

<FilesMatch "\.(htm|html|php|css|cgi|pl|jpg|jpeg|gif|png)$">
   <IfModule mod_headers.c>
		Header append Cache-Control "no-transform"
		Header append Vary "User-Agent, Accept"	 
   </IfModule>
</FilesMatch>

 ExpiresActive On
 ExpiresDefault A604800

AddType application/xhtml+xml .xhtml
DefaultType application/xhtml

# -----------------------------------------------------------------------------------------------
# END OF JOE´S ADDITION
# -----------------------------------------------------------------------------------------------

As an attempt to get rid of the double listing for Cache-Control I had put "Header unset Cache-Control" at the top for a test, but this did not seem to change anything, so I removed it again.

I will appreciate any hints, in particular about whether this is just a general .htaccess/Apache configuration issue I could learn about elsewhere or if it actually has something to do with Processwire.

Thanks.

EDIT :

To try and get rid of "Pragma: no-cache" I have added the following at the top of .htaccess:

Header unset Pragma
FileETag None
Header unset ETag

... no change

[Ben]

The first instance of the Cache-Control headers is from a session_start() - it's not Processwire per se, it's PHP initializing a session.

http://www.php.net/manual/en/session.configuration.php#ini.session.cache-limiter

EDIT: You may be better off only modifying the caching on css/js/images and letting the html pass unmodified - especially when a session is active. That can be done with a FilesMatch wrapper similar to the one used prior:

<FilesMatch "\.(jpg|jpeg|png|gif|js|css)$">
    <IfModule mod_headers.c>
        Header set Cache-Control "max-age=7200, must-revalidate"
        Header unset Last-Modified
        Header unset Pragma
    </IfModule>
</FilesMatch> 

[Joe]

The first instance of the Cache-Control headers is from a session_start() - it's not Processwire per se, it's PHP initializing a session.

http://www.php.net/manual/en/session.configuration.php#ini.session.cache-limiter

Oh, that´s good to know! Do you know off-hand how I can remove "no-store, no-cache" from there? Or change this line or make it disappear? Or is there a good reason it must be there?

...I wonder if this can be done in the .htaccess file or maybe it has to be done in a php file? The page´s template file maybe?

[Ben]

You can modify your php.ini to use a different cache-limiter from the default "nocache". The others ("public","private") use different values, though they do still set the cache control. You're better off sticking with the default nocache option, if possible - it will be more predictable since that is what 99% of the PHP world is using.

If you want to optimize caching for performance reasons, the most common strategy is to aggressively cache media (css/js/images) to the client and cache html responses on the server-side (either by proxy, the standard caching module, or the procache).

Limiter Options:

http://www.php.net/manual/en/function.session-cache-limiter.php

[Joe]

@ Ben:

Yes it´s to get maximum performance for a mobile-optimized site. I´ll look into that, thank you!

[Joe]

The first instance of the Cache-Control headers is from a session_start() - it's not Processwire per se, it's PHP initializing a session.

As a test I put a "hello world" test.php into the same folder Processwire resides in (with the same .htaccess in place). When calling it I get this response header:

Date: Fri, 18 Oct 2013 05:04:40 GMT
Server: Apache
X-Powered-By: PHP/5.3.27
Cache-Control: max-age=604800, max-age=7200, must-revalidate, no-transform
Expires: Fri, 25 Oct 2013 05:04:40 GMT
Vary: User-Agent,Accept
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

Whereas, calling a Processwire-created page (same directory) I get:

Date: Fri, 18 Oct 2013 05:11:20 GMT
Server: Apache
X-Powered-By: PHP/5.3.27
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: wire=9733c48fefb32525b13afd64c356c5c9; path=/
Cache-Control: max-age=7200, must-revalidate, no-transform
Vary: User-Agent,Accept
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8

So the lines:

• Expires: Thu, 19 Nov 1981 08:52:00 GMT
• Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
• Pragma: no-cache
• Set-Cookie: wire=9733c48fefb32525b13afd64c356c5c9; path=/

...are all set by Processwire php-scripts I would guess.

The php.ini and the .htaccess file should be the same for both the test.php and the Processwire page, since they are both in the same place.

I´m confused...  session_cache_limiter would have been set by a Processwire php-script then? I can´t find where though.

Edited October 18, 2013 by Joe

[Joe]

So I did another test: I saved the source code from a Processwire-created page on the site as a file "test2.php" and put it into the same directory again. It came with the same headers as the other test.php  This page looks and works the same as the one outputted by Processwire directly and it is in the same directory on the server, yet the header is different.

Edited October 18, 2013 by Joe

[Joe]

So I see that in in /site/config.php I can change a few things about sessions. When I change the value for $config->sessionName this does change the cookie´s name showing up in the header.

What I am wondering is: is it really necessary to start a session and set the cookie at all when a visitor just looks at the website? (...assuming there are no functions on it that require a cookie.) My understanding is that sessions/cookies would only be necessary when editing the site, so it should possible to show the pages to visitors without them...

Edited October 18, 2013 by Joe

[Ben]

Joe, I don't know if there's a way to kill the session in Processwire - it could be one of the assumptions the framework is based upon, and therefore not optional. Someone more familiar with internals can speak to this, but yes, many websites can run fine without cookies. You could try to "unset" set-cookie, cache-control, expires, and pragma using mod_headers to get the response session-free and client-cacheable. I've never unset a header, and then set it to something else so I don't know how apache will handle resetting cache-control. Another option, albeit extreme, is to generate a static site from PW using wget. This will only work if the site rarely changes, but will ultimately be the most optimized way to deliver the site.

FWIW - the reason I recommended not caching html to the client is that once it is out there, it's impossible to invalidate. Where a server-side cache can invalidate the cached page when updated through the admin, a client side cache will not check for updates and it can lead to trouble. The html itself is generally a very small file (relative to the download of images, css, js), so the performance gains are minimal. Looking at your headers, you could also get a nice performance bump using mod_deflate to gzip the transfer of text (html, css, js).

Hopefully this helps.

[Joe]

I don't know if there's a way to kill the session in Processwire - it could be one of the assumptions the framework is based upon, and therefore not optional.

Well, I don´t understand the inner workings too well, but it really appears like sessions and cookies are not optional. This seems logical for the admin area, but for the public-facing site cookies are often not needed and it should be possible to not send them.

Using the information on http://processwire.com/api/variables/session/ I tried to turn off the session in site/config.php - but no effect. Maybe it could be done, but in a different file? Just as a test I removed @session_start(); in wire/core/Session.php, but that just leads to an error, PW doesn´t run.

Just had a thought: if I got the pro-cache module? It says it serves pages as if they were static html. I suppose with that I could also keep cookies from being sent / sessions from being started if not needed. However since it is a commercial module I would just get it once I know more about it, have to look at it more closely, anyone know more about it?

Edited October 18, 2013 by Joe

[interrobang]

I can't say anything about HTTP Response Header tweaking, but if you don't need sessions on your pages it sounds like a perfect candidate for Ryan's excellent ProCache Module. It creates static versions of your pages und you won't have any headers set by php, as no php will be involved when delivering the pages from the cache.

I use ProCache on most of my pages, and the performance is really great, especially when combined with some of the best practices from HTML5-Boilerplates .htaccess file.

[Joe]

@interrobang:

.Thanks. Since you seem to know the ProCache Module well, can I ask you a few more things about it:

• So it actually creates static html files and stores them somewhere?
• And if so: can it be set up so they are in another directory than the Processwire installation? On another server even?

What I´m getting at is whether that way one could actually store a static version of the site that exists independently of Processwire?

• I see that the license is per year: That means you have to pay the amount again every year per site that uses it?

Thank you

[interrobang]

Yes, ProCache caches the pages in a folder and adds a redirect rule to your .htaccess, but I don't think it's possible to store these files on another folder. And the cache files are only created on the first request. This mean you have to visit each page once to have a static Version of your whole site.

If you just want a static version of your site I recommand using a sitegrabber or wget and upload these files to your server.

I think the licence is valid forever, but you only get updates in the first year. Once installed you can keep ProCache running forever on the site. At least this is how I understood the licence, better ask Ryan if you want to know for sure.

[Joe]

If you just want a static version of your site I recommand using a sitegrabber or wget and upload these files to your server.

Well, I actually had the following setup in mind:

The site is created and maintained by Processwire. It is stored as a static version, which is the public-facing site. Whenever a change is made the static image gets updated. You could "unplug" Processwire at any time and would always be left with the last version of the site that has been published.

It´s just an idea, might be hard to set up. I just thought maybe with ProCache you could do that quite easily. Also obviously this could only be done with non-interactive presentation sites, but that´s what I was wondering about.

[adrian]

Here are a couple of related posts that might be worth a read:

http://processwire.com/talk/topic/2989-module-that-outputs-a-static-site/

http://processwire.com/talk/topic/4327-dental-practice-web-site/