<div dir="ltr">Hi Alex / Amos,<div><br></div><div>It sounds like its still a long way to get HTTP/2 support released and contributing therefore is not an option in company time. </div><div><br></div><div>Maybe a bit blunt, in our case it means looking for either Squid-workarounds for HTTP/2 servers we have to address (Apple APNS notification server for example), or change to another proxy with HTTP/2 support.</div><div><br></div><div>Best regards,<br>Andrej</div><div><br></div><div> </div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 28, 2019 at 6:28 PM Alex Rousskov <<a href="mailto:rousskov@measurement-factory.com">rousskov@measurement-factory.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2/27/19 10:30 AM, Andrej van der Zee wrote:<br>
<br>
> I understood that http2 is work in progress. <br>
> Is there anything to say about when this might be released? <br>
<br>
IMO, given the way the Squid Project operates right now, the correct<br>
answer to that question is close to "hopefully not in the foreseeable<br>
future": We cannot add quality HTTP/2 support right now, and adding some<br>
hacky version of it would be disastrous for Squid stability, support,<br>
and development. Combined with where the popular clients and origin<br>
servers are going, it may be better to fantasize about HTTP/3 support<br>
instead.<br>
<br>
Based on Factory experience with adding HTTP/2 support to Web Polygraph,<br>
I consider the following (partially overlapping) preconditions as<br>
necessary for serious HTTP/2 (or HTTP/3) work in Squid:<br>
<br>
  1. Proper QA infrastructure.<br>
<br>
  2. Elimination of technical debt that prevents proper restructuring<br>
     of HTTP/2-sensitive code.<br>
<br>
  3. An agreement regarding overall HTTP/2 code architecture.<br>
<br>
  4. An efficient way to accept huge code changes.<br>
<br>
  5. A project lead capable, willing, trusted, and funded<br>
     to orchestrate such a big change from beginning to end.<br>
<br>
Right now, *none* of the above preconditions are satisfied.<br>
<br>
There is slow but steady progress with #1 and areas of #2.<br>
<br>
The situation with #3 and #4 is worse than it was a few years ago -- we<br>
are wasting insane amounts of time on getting much simpler code changes<br>
reviewed and accepted. Many changes require a rewrite before they should<br>
be accepted (and some are indeed rewritten). Nobody can afford to<br>
rewrite a pull request with initial HTTP/2 support!<br>
<br>
We have nobody who can satisfy #5 criteria right now.<br>
<br>
<br>
On 2/27/19 7:27 PM, Amos Jeffries wrote:<br>
<br>
> If anyone wants to jump in and lend a hand my HTTP/2 work is up on <br>
> github. IMO the best tasks to collaborate on would be designing<br>
> cppunit tests<br>
Creating more unofficial code is a bad idea at this time IMO.<br>
<br>
Alex.<br>
_______________________________________________<br>
squid-users mailing list<br>
<a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.org</a><br>
<a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">http://lists.squid-cache.org/listinfo/squid-users</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Andrej van der Zee<br>Oranje-Vrijstaatkade 49<br>1093KS Amsterdam<div>+31-(0)6-8133-9388</div><div><a href="https://www.linkedin.com/in/andrejvanderzee/" target="_blank">https://www.linkedin.com/in/andrejvanderzee/</a><br></div></div></div></div></div>