https://redmine.lighttpd.net/https://redmine.lighttpd.net/favicon.ico?13667327412015-10-18T19:09:17Zlighty labsLighttpd - Feature #2678: New mod_precompress featurehttps://redmine.lighttpd.net/issues/2678?journal_id=85772015-10-18T19:09:17Zstbuehler
<ul><li><strong>Category</strong> deleted (<del><i>mod_compress</i></del>)</li></ul><p>should be possible to implement with mod_magnet.</p>
<p>plantuml wrote:</p>
<blockquote>
<p><ins>Pros:</ins><br />- you won't have to clean the compress directory</p>
</blockquote>
<p>instead you have to make sure to update both (redundancy is usually bad)</p>
<blockquote>
<p>- since data are precompressed, you save some CPU on first request</p>
</blockquote>
<p>you don't save CPU time, instead you might possibly waste it. you save some latency though.</p>
<blockquote>
<p>- you can use Zopfli (<a class="external" href="https://github.com/google/zopfli">https://github.com/google/zopfli</a>) compression algorithm (which gives better compression ratio).</p>
</blockquote>
<p>completely unrelated afaics.</p>
<blockquote>
<p>Depending on their need, people could choose to use either mod_compress, mod_deflate or mod_precompress.</p>
</blockquote>
<p>There is no mod_deflate in 1.4.x.</p> Lighttpd - Feature #2678: New mod_precompress featurehttps://redmine.lighttpd.net/issues/2678?journal_id=85782015-10-18T19:48:35Zplantuml
<ul></ul><p>Yes, you are right about redundancy.</p>
<p>About Zopfli, I wanted to do something similar to <a class="external" href="http://www.cambus.net/serving-precompressed-content-with-nginx-and-zopfli/">http://www.cambus.net/serving-precompressed-content-with-nginx-and-zopfli/</a></p>
<p>But I've understood that you won't go into that direction.</p>
<p>Thank for your answer.</p> Lighttpd - Feature #2678: New mod_precompress featurehttps://redmine.lighttpd.net/issues/2678?journal_id=85792015-10-18T21:59:28Zdarix
<ul></ul><p>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.</p> Lighttpd - Feature #2678: New mod_precompress featurehttps://redmine.lighttpd.net/issues/2678?journal_id=85802015-10-19T05:18:20Zstbuehler
<ul></ul><p>plantuml wrote:</p>
<blockquote>
<p>About Zopfli, I wanted to do something similar to <a class="external" href="http://www.cambus.net/serving-precompressed-content-with-nginx-and-zopfli/">http://www.cambus.net/serving-precompressed-content-with-nginx-and-zopfli/</a></p>
</blockquote>
<p>Ah right, your point it that one shouldn't run zopfli on the fly, but it would be a good idea for precompress.</p>
<blockquote>
<p>But I've understood that you won't go into that direction.</p>
</blockquote>
<p>I probably won't do it myself, but I'm open to contributions. There is for example this one by darix: <a class="external" href="https://gist.github.com/darix/5025010490bb0ea70099">https://gist.github.com/darix/5025010490bb0ea70099</a>, 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.</p>
<p>darix wrote:</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>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.</p> Lighttpd - Feature #2678: New mod_precompress featurehttps://redmine.lighttpd.net/issues/2678?journal_id=95302016-05-01T07:15:25Zgstrauss
<ul><li><strong>Category</strong> set to <i>3rd party</i></li></ul> Lighttpd - Feature #2678: New mod_precompress featurehttps://redmine.lighttpd.net/issues/2678?journal_id=104772016-09-17T16:28:09Zgstrauss
<ul></ul><p>FYI, the successor to Zopfli is Brotli. <a class="external" href="https://github.com/google/brotli">https://github.com/google/brotli</a> <a class="external" href="https://www.ietf.org/rfc/rfc7932.txt">https://www.ietf.org/rfc/rfc7932.txt</a></p> Lighttpd - Feature #2678: New mod_precompress featurehttps://redmine.lighttpd.net/issues/2678?journal_id=108522017-02-14T05:17:23Zgstrauss
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-5 priority-4 priority-default closed" href="/issues/2736">Feature #2736</a>: Test $HTTP["language"] for preferred language?</i> added</li></ul> Lighttpd - Feature #2678: New mod_precompress featurehttps://redmine.lighttpd.net/issues/2678?journal_id=108542017-02-14T05:18:12Zgstrauss
<ul><li><strong>Category</strong> changed from <i>3rd party</i> to <i>mod_magnet</i></li><li><strong>Target version</strong> set to <i>1.4.46</i></li></ul><p>This is achievable using some custom lua code with lighttpd mod_magnet</p> Lighttpd - Feature #2678: New mod_precompress featurehttps://redmine.lighttpd.net/issues/2678?journal_id=108562017-02-14T06:22:11Zgstrauss
<ul><li><strong>File</strong> <a href="/attachments/1762">content-negotiation.lua</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/1762/content-negotiation.lua">content-negotiation.lua</a> added</li><li><strong>Status</strong> changed from <i>New</i> to <i>Fixed</i></li></ul><p>Attached content-negotiation.lua with code to handle Accept-Language and Accept-Encoding. Lightly tested. YMMV.<br /><pre>
server.modules += ( "mod_magnet" )
magnet.attract-physical-path-to = ( "/path/to/content-negotiation.lua" )
</pre></p> Lighttpd - Feature #2678: New mod_precompress featurehttps://redmine.lighttpd.net/issues/2678?journal_id=108602017-02-14T06:43:17Zgstrauss
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-5 priority-4 priority-default closed" href="/issues/1259">Feature #1259</a>: mod_autoext - Apache-like support for automatically adding extensions</i> added</li></ul>