There are insufficient support for http3

[wordhui]

After testing, most platform browsers cannot be accessed using http3

• The above tests are conducted at the same time by accessing the same container of the same machine. The network environment is LAN

• All Linux browsers are on the same computer

• All windows browsers are on the same computer

• These browsers can use http3 to access other http3 enabled website

browser	platform	http3 access
edge-102.0.1245.33	windows	no
edge -99.0.1150.55	linux	no
firefox-100.0.2	linux	no
firefox-101.0	windows	yes
chrome-102.0.5005.63	windows	no
chrome -100.0.4896.127	linux	no

Here are some interesting phenomena

• Forced Chrome to access with HTTP3 to make an error

  • Use the following parameters to force chrome to use QUIC access

  • chrome --origin-to-force-quic-on=127.0.0.1:443

  • Chrome will have the following errors

  • ERR_QUIC_PROTOCOL_ERROR

  • Because of this error message, I infer that this is the problem with docker nginx http3, because other http3 websites can run perfectly with the '--origin-to-force-quic-on' parameter

    • https://blog.cloudflare.com/
    • chrome --origin-to-force-quic-on=blog.cloudflare.com:443 Perfect access

There is no problem with the UDP port of the computer

• HTTP3 opens correctly, but insufficient support

• Firefox on Windows can use http3 access to prove this

• The following command can also prove this

• xxxx:~$ netstat -tunlp | grep 443
  tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      1818214/docker-prox 
  udp        0      0 0.0.0.0:443             0.0.0.0:*                           1818228/docker-prox

• Use curl-http3 to access

• docker run --rm --network host ymuski/curl-http3  curl -v https://127.0.0.1/internal_support/api_test --http3 2>&1 | tee /tmp/h3

• output

  • *   Trying 127.0.0.1:443...
    * Connect socket 5 over QUIC to 127.0.0.1:443
    * Sent QUIC client Initial, ALPN: h3-29,h3-28,h3-27
      % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                     Dload  Upload   Total   Spent    Left  Speed
      0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Connected to 127.0.0.1 () port 443 (#0)
    * h3 [:method: GET]
    * h3 [:path: /internal_support/api_test]
    * h3 [:scheme: https]
    * h3 [:authority: 127.0.0.1]
    * h3 [user-agent: curl/7.76.1-DEV]
    * h3 [accept: */*]
    * Using HTTP/3 Stream ID: 0 (easy handle 0x55b032487210)
    > GET /internal_support/api_test HTTP/3
    > Host: 127.0.0.1
    > user-agent: curl/7.76.1-DEV
    > accept: */*
    > 
    < HTTP/3 200
    < date: Wed, 08 Jun 2022 10:52:08 GMT
    < content-type: application/json
    < content-length: 427
    < access-control-allow-origin: *
    < x-frame-options: SAMEORIGIN
    < x-xss-protection: 1; mode=block
    < content-security-policy: object-src 'none'; frame-ancestors 'self'; form-action 'self'; block-all-mixed-content; sandbox allow-forms allow-same-origin allow-scripts allow-popups allow-downloads; base-uri 'self';
    < alt-svc: h3=":443"; ma=5, h3-27=":443"; ma=5, h3-28=":443"; ma=5,h3-29=":443"; ma=5,h3-Q050=":443"; ma=5,h3-Q046=":443"; ma=5,h3-Q043=":443"; ma=5,quic=":443"; ma=5; v="46,43"
    < quic-status: h3
    < 
    { [427 bytes data]
    100   427  100   427    0     0  28466      0 --:--:-- --:--:-- --:--:-- 30500
    * Connection #0 to host 127.0.0.1 left intact
    {"status":"ok",....}

Below is my https.conf file

server {
    # quic and http/3
    listen 443 http3 reuseport;

    # http/2 and http/1.1
    listen 443 ssl http2;

    server_name localhost;

    # openssl-generated pair for local development
    # https://letsencrypt.org/docs/certificates-for-localhost/
    ssl_certificate     /etc/nginx/ssl/localhost.crt;
    ssl_certificate_key /etc/nginx/ssl/localhost.key;

    # Enable all TLS versions (TLSv1.3 is required for QUIC).
    #ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
    ssl_protocols TLSv1.3;

    # 0-RTT QUIC connection resumption
    ssl_early_data on;

    # Add Alt-Svc header to negotiate HTTP/3.
    # m=5： Easy to observe HTTP2-HTTP3 switching process
    add_header alt-svc 'h3=":443"; ma=5, h3-27=":443"; ma=5, h3-28=":443"; ma=5,h3-29=":443"; ma=5,h3-Q050=":443"; ma=5,h3-Q046=":443"; ma=5,h3-Q043=":443"; ma=5,quic=":443"; ma=5; v="46,43"';
    # add_header alt-svc 'h3=":443"; h3-27=":443"; ma=86400, h3-28=":443"; ma=86400, h3-29=":443"; ma=86400';
    add_header QUIC-Status $http3;     # Sent when QUIC was used

    # proxy_set_header Http-Version       $server_protocol;
    location / {
        proxy_pass   https://172.17.0.1:5000;
    }
}

[macbre]

Interestingly, Firefox 100.0 on MacOS works fine:

[macbre]

I believe the issue is in how http3/ is advertised in alt-svc response header.

https://blog.cloudflare.com/ responds with:

alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400

However, still Chrome does not switch to http/3 for localhost traffic...

[macbre]

It seem that browsers have some sort of heuristics deciding whether to use http/3 or fall back to h2.

My production site (that uses the latest version of this image) works fine under http/3.

[wordhui]

It seem that browsers have some sort of heuristics deciding whether to use http/3 or fall back to h2.

My production site (that uses the latest version of this image) works fine under http/3.

I use chrome and Firefox under Linux to access your web address. It really runs on http3 Interestingly, Under Windows, chrome uses http2 access and Firefox uses http3 access.