ETag validation error

[alharawi3]

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:

Code: Select all

ETag: 2eb75e75328b680528385b44aeb09890

Valid syntax is:

Code: Select all

ETag: "2eb75e75328b680528385b44aeb09890"

or, for "weak" ETags

Code: Select all

ETag: W/"2eb75e75328b680528385b44aeb09890"

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

Code: Select all

if( $etag == "W/\"$id\"") {

and line 134 to

Code: Select all

JResponse::setHeader( 'ETag', "W/\"$etag\"", true );

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?

[alharawi3]

Hi there,
Well, after futher investigations it seems that the wrong content-type bug is related to line 55-56 of /librairies/joomla/cache/handler/view.php.

[Raton]

I was doing some cleanups/fixes in the joomla http headers, mainly to set a data character set on my sites to stop pagespeed/yslow etc. complaining about it and found your thread, nice finding alharawi3 posts like these deserve more replies.

[alharawi3]

Happy to see that my bug finding was helpful!