On Mon, Apr 10, 2017 at 6:50 AM, <j...@apache.org> wrote: > Author: jim > Date: Mon Apr 10 11:50:26 2017 > New Revision: 1790806 > > URL: http://svn.apache.org/viewvc?rev=1790806&view=rev > Log: > With v0.60 of https://github.com/google/brotli released, > this is now viable again.
Agreed this is no longer 'being worked' but is again proposed... > --- httpd/httpd/branches/2.4.x/STATUS (original) > +++ httpd/httpd/branches/2.4.x/STATUS Mon Apr 10 11:50:26 2017 > @@ -177,17 +177,6 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: > protocol input, also seems unwise) > jailletc36: needs r1790457 but can be merged afterwards. No > functionnal change. > > -PATCHES/ISSUES THAT ARE BEING WORKED > - [ New entried should be added at the START of the list ] > - > - *) core: Disallow multiple Listen on the same IP:port when listener buckets > - are configured (ListenCoresBucketsRatio > 0), consistently with the > single > - bucket case (default), thus avoiding the leak of the corresponding > socket > - descriptors on graceful restart. > - trunk patch: http://svn.apache.org/r1789220 > - 2.4.x patch: trunk works (modulo CHANGES) > - +1: ylavic > - > *) mod_brotli: Backport of mod_brotli filter > trunk patch: http://svn.apache.org/r1761714 > http://svn.apache.org/r1762512 > @@ -198,8 +187,17 @@ PATCHES/ISSUES THAT ARE BEING WORKED > http://svn.apache.org/r1779699 > 2.4.x patch: http://home.apache.org/~jim/patches/brotli-2.4.patch > +1: jim, jorton, > - -1: wrowe (Premature, waiting on github.com/google/brotli 0.6 release) > - NOTE: Awaiting next release post 0.5.2 I was happy with the state of master as of Friday. I have not reviewed the final release package, however. I was very very happy with the huge documentation improvements today. One key aspect I identified, that --deflate ++brotli is a net loss for our examples, is unacceptable. Increasing the total traffic by ripping out one universal compression method for a solution supported by only half of the clients is, I'm sure you agree, a joke. Brotli can only be added as a supplemental compression scheme in addition to gzip for older clients at this time, particularly since the introduction of this compression adds a large incremental cpu tax on the server. I was disappointed to learn from the docs that input compression is not even supported by the proposed enhancement. The browser clients may not support it, but obviously other significant clients such as svn should be adding it promply, the cpu cost to the clients pushing data is not our worry at all, and the cpu cost of httpd decoding the brotli compression is hardly measurable if not an actual win. I'm amused by your rejection of my completing code review of this submission, Jim. Classy.