<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    -----BEGIN PGP SIGNED MESSAGE----- <br>
    Hash: SHA256 <br>
     <br>
    I agree in general, but there are some considerations.<br>
    <br>
    1. Compressed content is almost always becomes unique. Which leads
    to a dramatic decrease in the cache hit ratio.<br>
    <br>
    2. Compression actually became a de facto standard on the Internet.<br>
    <br>
    3. Project ecap-gzip looks dead for over three years as squidguard.
    There is no active maintainers and we have to dig in sources myself.
    Solution compatibility do not actually confirm or not the Squid
    team. While independent tests confirm the compatibility and show
    good results.<br>
    <br>
    4. The structure of Squid-3 actually included a third-party utility
    purge. What prevents the same way include ecap-gzip directly in
    code, without ecap usage?<br>
    <br>
    It is not about exotic functionality demanded a bunch of geeks. It
    is about having the widest distribution of functionality, more than
    90% of servers on the Internet are using compression. This is not a
    whim of the user. This is servers default behaviour. And I believe
    that the caching proxy default is to use all that as part of the
    standard, to obtain the highest possible degree of caching.<br>
    <br>
    WBR, Yuri<br>
    <br>
    PS. Amos, I generally agree that we talk functionality, which "will
    not be implemented neve because we do not want to do that." But you
    will agree that my arguments are essential.<br>
    <br>
    27.08.15 9:49, Amos Jeffries пишет:<br>
    <span style="white-space: pre;">> On 27/08/2015 8:50 a.m., Yuri
      Voinov wrote:<br>
      >><br>
      >> Btw,<br>
      >><br>
      >> when Squid will directly support gzip, inflate
      compression itself?<br>
      ><br>
      > Thats a tough question. "When someone does it." is the sadly
      true cliche.<br>
      ><br>
      > Transfer-Encoding with gzip is what Squid as a proxy is
      actually<br>
      > expected to do by the protocol. But neither Squid nor most
      other<br>
      > software implement it so its not got much demand. I'm working
      on it as a<br>
      > hobby task and a favour for a customer who cant get signoff
      on big costs<br>
      > for such a low-gain feature. So small steps at a time and
      still a ways<br>
      > off at this rate.<br>
      >  (exactly *when* is sponsor dependent. Anyone want to front
      up a few<br>
      > weeks or months of full-time developer paycheck to see it
      happen by Jan<br>
      > 2016 or some deadline like that?)<br>
      ><br>
      ><br>
      > But what most of you are talking about with this gzip
      question is<br>
      > actually Content-Encoding:gzip as used by browser and origin
      servers.<br>
      > Recoding that on the fly is content adaptation. An eCAP
      service plugin<br>
      > already exists and was the right way to go IMHO. I'm not sure
      what<br>
      > happend to the plugins author. Theres still lots of
      optimization stuff<br>
      > to be done in that area.<br>
      ><br>
      > Normalizing the Accept headers before Vary processing is
      simpler change.<br>
      > But again needs someone interested in doing it, and is
      possibly better<br>
      > suited to the eCAP adaper doing in prep for its reply
      transformations.<br>
      > This Vary stuff does have a fair few bugs and missing bits so
      its not<br>
      > quite clean sailing or would have happened years ago.<br>
      ><br>
      ><br>
      > So lots to be done. But nobody with money has enough interest
      right now<br>
      > in seeing it happen. Whats the phrase, "free as in freedom,
      not beer".<br>
      ><br>
      > Amos<br>
      > _______________________________________________<br>
      > squid-users mailing list<br>
      > <a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a><br>
      > <a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a></span><br>
    <br>
    -----BEGIN PGP SIGNATURE-----
<br>
    Version: GnuPG v2
<br>
     <br>
    iQEcBAEBCAAGBQJV3tzpAAoJENNXIZxhPexGofcIAMUA+huUxU4q+x0Q4zWQu6pf
<br>
    Oy/5+xzAyYIpTwV4yptmuvn9sjn6dkeF5jfNnkERdvNvS/jWU3dVxCs5CkpWnmV8
<br>
    guKCycyh+dDLsDisp2+xi46UnZQNNcpvpJgxnjNK84Mft44SNtHPX4+upXi9B276
<br>
    UjXwjkOjhcBll+kRiNJKlYMyd9p/5parOG01SWPXhUBiI0ON0QS5mQ8cJdyA6Dsa
<br>
    quxv8iL/3BCfT71rEgOYSHYb5JmZIBGtIIb4oVAtytBgPOTCJCJZOf8CSLd8x33t
<br>
    GlfhV9nocAFjndQ1N2tSPyQ4EKQEmmLsHlHlnyGgSPMdx23et4CdMoaRh0tp49c=
<br>
    =8Dx/
<br>
    -----END PGP SIGNATURE-----
<br>
    <br>
  </body>
</html>