HTTP/2 not compatible with filrefox on haproxy 1.8.3?


We are using things like “document.location.href = ‘/main.html’;” in our login page (login.html). And it’s ok if we only use the http/1.1.

But when we enabled the http/2 by upgrade the haproxy to 1.8.3 and add “alpn h2,http/1.1” to the config file, then the firefox (we’ve tested 49 and 58) will failed to jump to the new page (e.g.: the request to get the new page will never return). IE (7-11) and Chrome are all ok with this new configuration.

Is this a h2 compatibility issue between firefox and haproxy ?

Here is the screen shot:


Can be reproduced here:
user: yk002
pass: 123


This should be fixed by the following patch (which will be in 1.8.4):;a=commitdiff;h=646d23d1b502bc07a4a846f2ca7d332506b3087e

Patch it manually, pull from latest 1.8 git, use a snapshot or wait for the 1.8.4 release


OK, so we’ll degrade to http/1.1 and wait the 1.8.4 release. Thank you lukastribus :slight_smile:


@lukastribus BTW: We found that IE6 also stuck on the page loading stage, is this caused by the same bug?


No, definitely not, IE6 does not support HTTP/2. That also includes IE7 till IE10. Only IE11 on Windows 10 supports HTTP/2, so if you see the issue in IE10 and older, this bugfix won’t affect you.

I would also suggest that you try those test builds, because this may be a totally different issue.


OK, I’ll give it a try :slight_smile:


We have been upgrade our haproxy to the version 1.8.4, firefox work fine now. But I found another problem: the low version chrome (48 & 49) failed to open our web page if h2 is enabled (report a xhr send error). It’s fine if h2 is disabled.

Is it another known bug of haproxy 1.8.4?


So supported Chrome release work fine? Chrome 49 is 2 years old and completely out of date and unsupported, I wouldn’t spend any time working on interoperability issue on this one.


Yes, chrome 64 work fine, but many third party browsers are still using old chromium core, for example: and many others.

In addition, newer versions of chrome seems not compatible with Windows XP, so some users using XP are still staying at the old version (AFAIK, chrome 49 is the last verion support XP?).

We have been tested that after h2 support is enabled on nginx (Tengine), chrome 47, 48, 49 are working fine, so I think it is a problem of haproxy :slight_smile:


Both Chrome 49 and Windows XP are obsolete and unsupported, if you still use them then you are in big trouble.

Thats 1) a naive assumption and 2) irrelevant because I don’t think anyone is willing to spend time on this, given how useless it is.

If you find a the exact root cause of this issue and have a proposal on how to fix this, we will be all ears. But I’m not gonna invest any time in troubleshooting a 2 year unsupported browser.


No, lukastribus, not me. But we can’t control our customer’s behavior.

Customer is GOD, god want to use old system and old browser, They all have a variety of reasons, so what should we do? Business is not purely academic. :sunglasses:


I am aware of that. Like I said, if you can track this down to a specific behavior and/or provide a patch, I’m sure we will consider it. I just can’t be bothered to spend my time troubleshooting a 2 year unsupported browser.


Ok, we have collected a detailed error report as below (there is a HTTP2_STREAM_ERROR):

1908: URL_REQUEST Time: 2018-02-22 22:26:00.423t=5377 [st=  0] +REQUEST_ALIVE  [dt=139]
t=5377 [st=  0]    URL_REQUEST_DELEGATE  [dt=0]
t=5377 [st=  0]   +URL_REQUEST_START_JOB  [dt=138]
                   --> load_flags = 33024 (MAYBE_USER_GESTURE | VERIFY_EV_CERT)
                   --> method = "GET"
                   --> priority = "MEDIUM"
                   --> url = ""
t=5377 [st=  0]      URL_REQUEST_DELEGATE  [dt=0]
t=5377 [st=  0]      HTTP_CACHE_GET_BACKEND  [dt=0]
t=5377 [st=  0]      HTTP_CACHE_OPEN_ENTRY  [dt=18]
                     --> net_error = -2 (ERR_FAILED)
t=5395 [st= 18]      HTTP_CACHE_CREATE_ENTRY  [dt=13]
t=5408 [st= 31]      HTTP_CACHE_ADD_TO_ENTRY  [dt=0]
t=5408 [st= 31]      URL_REQUEST_DELEGATE  [dt=0]
t=5408 [st= 31]     +HTTP_STREAM_REQUEST  [dt=5]
t=5408 [st= 31]        HTTP_STREAM_REQUEST_STARTED_JOB
                       --> source_dependency = 1914 (HTTP_STREAM_JOB)
t=5413 [st= 36]        HTTP_STREAM_REQUEST_BOUND_TO_JOB
                       --> source_dependency = 1914 (HTTP_STREAM_JOB)
t=5413 [st= 36]     -HTTP_STREAM_REQUEST
t=5413 [st= 36]     +HTTP_TRANSACTION_SEND_REQUEST  [dt=3]
                       --> :authority:
                           :method: GET
                           :path: /GatherFiles?file_list=%2Fcss%2Fabout.css%7C%2Fcss%2Fresize.css%7C%2Fcss%2Fselectbgdataview.css&common_header=%0D%0A&ver=402743509
                           :scheme: https
                           accept: text/css,*/*;q=0.1
                           accept-encoding: gzip, deflate, sdch
                           accept-language: zh-CN,zh;q=0.8
                           cookie: [53 bytes were stripped]
                           user-agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36
t=5416 [st= 39]     +HTTP_TRANSACTION_READ_HEADERS  [dt=99]
t=5515 [st=138]        HTTP2_STREAM_ERROR
                       --> description = "ABANDONED (stream_id=63):"
                       --> status = -3
                       --> stream_id = 63
                     --> net_error = -3 (ERR_ABORTED)
t=5515 [st=138]   -URL_REQUEST_START_JOB
                   --> net_error = -3 (ERR_ABORTED)
t=5515 [st=138]    URL_REQUEST_DELEGATE  [dt=1]
t=5516 [st=139] -REQUEST_ALIVE
                 --> net_error = -3 (ERR_ABORTED)

The full log can be found at here:
you can import it to chrome within this page: chrome://net-internals

Let me know if you need some more information :slight_smile:


I read the 1.8.4 release announce ( and found this:

  • several H2 minor issues (DATA padding incorrectly accounted for in
    the connection window, DATA frames for closed streams not properly
    accounted, RST sometimes in response to an RST). None of them has
    a real visible impact in practice so I preferred to issue 1.8.4
    first to address the pending issues.

So it seems a “already known issue” and may be fixed on 1.8.5+ ?


I think the only good solution for this is to have your service listen on two different ports, one that listens to HTTP1.X and one that listens to H/2

I’m in a similar situation where i have to support older browsers. I have HAProxy in front of nginx which listens on 80 and 81 (SSL Terminates at HAProxy) andd then a simple decider config would look like:

frontend https
  mode tcp
  bind ssl crt /etc/haproxy/certs alpn h2,http/1.1 ecdhe secp384r1
  timeout http-request 10s
  #send all HTTP/2 traffic to a specific backend
  use_backend http2-nodes if { ssl_fc_alpn -i h2 }
  #send HTTP/1.1 and HTTP/1.0 to default, which don't speak HTTP/2
  default_backend http1-nodes

backend http1-nodes
  mode http
  balance roundrobin
  default-server inter 1s fall 2

  server web01 check send-proxy
  server web03 check send-proxy

backend http2-nodes
  mode tcp
  balance roundrobin
  default-server inter 1s fall 2

  server web01 check send-proxy
  server web03 check send-proxy

Then in Nginx you define two ports, which would look prettty similar in apache or what ever your webserver is.

server {

  listen 80 proxy_protocol;
  listen 81 http2 proxy_protocol;


According to our test, chrome 47, 48, 49 are working fine with http2 mode on nginx (Tengine) with h2 support enabled. So you may let the browser connect to nginx directly if using nginx as the reverse proxy is an option in your case.


I do it this way b/c we have hundreds of domains and its easier to manage certs and just have nginx run on server_name _, so we terminate at HAProxy, if you have ssl on nginx, it will auto downgrade to 1.1 if the client does not handle H2. Sorry i put a server name in the example, that was misleading.


No, nginx (Tengine) can talk with chrome 49 using h2 without ANY degradation. See the attachments.


new users can only put one image in a post…