[dokuwiki] Re: Compressing JS and CSS output

Hi Chris/List

Full quoting for context. Answers inline.

> Fri Jan 23 06:50:10 WST 2009  Andreas Gohr <andi@xxxxxxxxxxxxxx>
>  * fixed multiple gzip/sendfile problems in css and js dispatchers FS#1571
>  - Avoid double compression when gzip_output is enabled
>  - Only compress when gzip_output is enabled
>  - Do not use x-sendfile for compressed content (content-encoding is not
> supported)
>  - Make sure the script terminates after using x-sendfile
>  - Moved gzip browser support check to init.php
> Shall I pull this patch? (1/1)  [ynWvpxdaqjk], or ? for help: y
>
> I think we have different web server setups.
>
> I prefer to let the webserver organise the compression rather than enable
> php's own output compression. So right now, I don't use dokuwiki's own
> $conf['gzip_output'] option.
>
> I did some tests a short while ago to check on the fly compression versus
> precompressed using Apache 2.2.  Apache was bandwidth limited sending the
> precompressed files at very low cpu utilization.  With on the fly
> compression, it was not bandwidth limited (it couldn't fill a 100Mb
> connection) and cpu was very high.
>
> So, I guess I am asking if we can have a config option that allows for
> precompressed js and css files, but doesn't require the use of php's own
> output compression.  Say:
> 0 - no compression
> 1 - all compressed if browser can accept gzip
> 2 - pre-compressed js and css (but not ob_gzhandler) if browser can accept
> gzip

I see. That could make sense. Do we consider this a bug? ;-)

> Also, x-sendfile should be content agnostic.  If the correct headers are set
> prior to x-sendfile, the webserver doesn't care what the file is and because
> the correct headers have been set the browser handles the file correctly
> when it arrives. I have a successful test setup using the previous code with
> Lighttpd + x-sendfile + precompressed files.

It should but isn't. At least the Apache implementation (which I used
to test last night) isn't. To quote from the docs at
http://tn123.ath.cx/mod_xsendfile/

"The Content-Encoding header - if present - will be dropped, as the
module cannot know if it was set by intention of the programmer or the
handler. E.g. php with output compression enabled will set this
header, but the replacement file send via mod_xsendfile is most likely
not compressed."

An unfortunate assumption of programmers being stupid :-( So we can't
reliably use xsendfile and gzip compression on the same time. That's
why I changed the implementation the way I did.

> Feel free to move this to the list if you like.

done.

Andi


-- 
splitbrain.org
-- 
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist

Other related posts: