Caching of stylesheets
Posted: Thu Aug 04, 2011 6:07 pm
Hi,
following a discussion concerning traffic usage in the german corner of the forum I looked into the way serendipity delivers CSS stylesheets. Currently the stylesheet has an Expires header which allows the browser to cache the stylesheet for 1 hour. After that period the browser will request the stylesheet again and the backend will transmit the whole stylesheet again.
I tried to find a way that the stylesheet could be delivered with an ETag header that would allow the server to answer successive requests with an 304 Not Modified saving bandwidth and time to parse the stylesheet again.
The change is almost working and I could supply a patch. Obviously the 304 response should not have a response body to really save the bandwidth. Looking at serendipity.css.php it seemed obvious: the file contents of the stylesheet is copied to a variable $out, serendipity_plugin_api::hook_event() is called for $css_hook and then $out is printed.
But is seems some plugins (I can confirm nl2br and karma) do not use the hook to append their styles to the supplied variable but instead simply print it. That obviously makes it impossible to intercept the output and suppress it when sending the 304. Is that the correct way to generate CSS output by plugins or has it simply been overlooked? Am I missing something obvious?
Regards,
Stefan
following a discussion concerning traffic usage in the german corner of the forum I looked into the way serendipity delivers CSS stylesheets. Currently the stylesheet has an Expires header which allows the browser to cache the stylesheet for 1 hour. After that period the browser will request the stylesheet again and the backend will transmit the whole stylesheet again.
I tried to find a way that the stylesheet could be delivered with an ETag header that would allow the server to answer successive requests with an 304 Not Modified saving bandwidth and time to parse the stylesheet again.
The change is almost working and I could supply a patch. Obviously the 304 response should not have a response body to really save the bandwidth. Looking at serendipity.css.php it seemed obvious: the file contents of the stylesheet is copied to a variable $out, serendipity_plugin_api::hook_event() is called for $css_hook and then $out is printed.
But is seems some plugins (I can confirm nl2br and karma) do not use the hook to append their styles to the supplied variable but instead simply print it. That obviously makes it impossible to intercept the output and suppress it when sending the 304. Is that the correct way to generate CSS output by plugins or has it simply been overlooked? Am I missing something obvious?
Regards,
Stefan