The config is several thousand lines long and includes a bunch of material
non-public info, but if there are parts you think may be relevant I can try
to snip them out.

The HAProxy version (as noted in the subject of the e-mail) is 1.8.14
(which is, I believe, the latest 1.8 release).

Chrome treats HTTP/2 as SPDY and shows the SPDY error page when an HTTP/2
protocol error occurs.

I think this may actually have been a configuration issue on a single
server (looking at the logs in a bit more detail); I'm going to do some
more testing to see what's different there.

On Tue, Oct 23, 2018 at 3:23 PM Aleksandar Lazic <al-hapr...@none.at> wrote:

> Hi.
>
> SPDY is not HTTP/2 .
>
> Please can you share the config and the haproxy version.
>
> Best regards
> Aleks
>
> ------------------------------
> *Von:* James Brown <jbr...@easypost.com>
> *Gesendet:* 24. Oktober 2018 00:13:37 MESZ
> *An:* HAProxy <haproxy@formilux.org>
> *CC:* jared <ja...@easypost.com>
> *Betreff:* Lots of PR state failed connections with HTTP/2 on HAProxy
> 1.8.14
>
> I tested enabling HTTP/2 on the frontend for some of our sites today and
> immediately started getting a flurry of failures. Browsers (at least
> Chrome) showed a lot of SPDY protocol errors and the HAProxy logs had a lot
> of lines ending in
>
> https_domain_redacted/<NOSRV> -1/-1/-1/-1/100 400 187 - - PR-- 49/2/0/0/0
> 0/0
>
> There were no useful or interesting errors logged to syslog. No sign of
> any resources being exhausted (conntrack seems fine, etc). The times varied
> but Ta was always low (usually around 100ms). I have not been able to
> reproduce this issue in a staging environment, so it may be something "real
> browsers" do that doesn't show up with h2load et al.
>
> Turning off HTTP/2 (setting "alpn http/1.1") completely solves the problem.
>
> The following timeouts are set on all of the affected frontends:
>
>     retries 3
>     timeout client 9s
>     timeout connect 3s
>     timeout http-keep-alive 5m
>     tcp-request inspect-delay 4s
>     option http-server-close
>
> Additionally, we set maxconn to a very high value (20480).
>
> Backends generally have timeout server set to a largeish value (90-300
> seconds, depending on the backend).
>
> Anything jump out at anyone?
> --
> James Brown
> Systems & Network Engineer
> EasyPost
>


-- 
James Brown
Engineer

Reply via email to