ETag validation error
Posted: Wed Oct 19, 2011 5:21 pm
Hi all,
Since few days, I've try ton understand why Joomla cache plugin doesn't allow a correct ETag validation and don't sent a 304 Not Modified header in response to a If-None-Match request.
What the problem?
Joomla 1.5.X send ETag header when the system cache plugin is activated with browser caching option. But the syntax used is wrong and not standard compiliant because they aren't between brackets ("...") as it should be:
Joomla ETag header:
Valid syntax is:
or, for "weak" ETags
The fact that joomla syntax is wrong obliged users agent to ignore the header. So it is useless and can't be used for if-none-match requests. The server will send again the full content of page, not the 304 header.
I found a solution for that, allow ETag to be valid, and If-None-Match requests return the correct 304 Not Modified header. This allow caches to cache efficiently the page and save page load, CPU, server load and bandwidth. The site seems to be faster when visited a second time (I've custom a bit the Expires and Control-Cache headers in /librairies/joomla/environnent/response.php
The modification
In /librairies/joomla/cache/handler/page.php
change line 50 to
and line 134 to
I use weak ETags because they are more usefull with dynamic content than strong one.
But there is an other problem: when the system cache plugin is activated, the content-type header is locked to "text/html" wathever the page's content is (feeds, pdf, raw...).
When you activate it with empty cache, the first time the page is loaded, the content type header is correct, with the associate charset, send to the client, and the plugin store a copy of the page in the /cache/page/ folder. Once the page is request again, the plugin look in the page cache folder and sent the stored copy with the bad content-type header: text/html without any charset content associate.
When the plugin is desactivated and the cache is empty, the content-type is correct: text/html; charset=utf-8 / application/rss+xml; charset=utf-8 / application/atom+xml; charset=utf-8 / application/xml; charset=utf-8 / application/pdf; charset=utf-8 / etc.
I can't find where the bug is located, but I'm quite sure is related to the /plugins/system/cache.php file.
Any idea?
Since few days, I've try ton understand why Joomla cache plugin doesn't allow a correct ETag validation and don't sent a 304 Not Modified header in response to a If-None-Match request.
What the problem?
Joomla 1.5.X send ETag header when the system cache plugin is activated with browser caching option. But the syntax used is wrong and not standard compiliant because they aren't between brackets ("...") as it should be:
Joomla ETag header:
Code: Select all
ETag: 2eb75e75328b680528385b44aeb09890
Valid syntax is:
Code: Select all
ETag: "2eb75e75328b680528385b44aeb09890"
Code: Select all
ETag: W/"2eb75e75328b680528385b44aeb09890"
I found a solution for that, allow ETag to be valid, and If-None-Match requests return the correct 304 Not Modified header. This allow caches to cache efficiently the page and save page load, CPU, server load and bandwidth. The site seems to be faster when visited a second time (I've custom a bit the Expires and Control-Cache headers in /librairies/joomla/environnent/response.php
The modification
In /librairies/joomla/cache/handler/page.php
change line 50 to
Code: Select all
if( $etag == "W/\"$id\"") {
Code: Select all
JResponse::setHeader( 'ETag', "W/\"$etag\"", true );
But there is an other problem: when the system cache plugin is activated, the content-type header is locked to "text/html" wathever the page's content is (feeds, pdf, raw...).
When you activate it with empty cache, the first time the page is loaded, the content type header is correct, with the associate charset, send to the client, and the plugin store a copy of the page in the /cache/page/ folder. Once the page is request again, the plugin look in the page cache folder and sent the stored copy with the bad content-type header: text/html without any charset content associate.
When the plugin is desactivated and the cache is empty, the content-type is correct: text/html; charset=utf-8 / application/rss+xml; charset=utf-8 / application/atom+xml; charset=utf-8 / application/xml; charset=utf-8 / application/pdf; charset=utf-8 / etc.
I can't find where the bug is located, but I'm quite sure is related to the /plugins/system/cache.php file.
Any idea?