Lighttpd

Yes, you are right about redundancy.

About Zopfli, I wanted to do something similar to http://www.cambus.net/serving-precompressed-content-with-nginx-and-zopfli/

But I've understood that you won't go into that direction.

Thank for your answer.

it can actually be faster/more efficient to read the compressed file from disk and decompress it on the fly when sending it out to clients which do not understand compression. no idea how well it fits with the event driven model though.

plantuml wrote:

About Zopfli, I wanted to do something similar to http://www.cambus.net/serving-precompressed-content-with-nginx-and-zopfli/

Ah right, your point it that one shouldn't run zopfli on the fly, but it would be a good idea for precompress.

But I've understood that you won't go into that direction.

I probably won't do it myself, but I'm open to contributions. There is for example this one by darix: https://gist.github.com/darix/5025010490bb0ea70099, but I'm not happy with the substring match for Accept-Encoding; I think validator.w3.org (and probably others) send x-gzip and expect x-gzip (and not gzip) in return.

darix wrote:

it can actually be faster/more efficient to read the compressed file from disk and decompress it on the fly when sending it out to clients which do not understand compression. no idea how well it fits with the event driven model though.

A "mod_inflate" or "mod_decompress" would indeed solve the redundancy problem, and should probably also take care of the "mod_precompress" part; I see no problem with the event driven model, although we'd probably want to limit the size somehow.

FYI, the successor to Zopfli is Brotli. https://github.com/google/brotli https://www.ietf.org/rfc/rfc7932.txt