We have deployed according to the steps in #322.
However, we have a problem that only seems to affect some clients:
$ curl -v 'https://stag.foo.com/'
* Trying <ip>...
* TCP_NODELAY set
* Connected to stag.foo.com (<ip>) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=stag.foo.com
* start date: Feb 23 01:50:57 2021 GMT
* expire date: May 24 01:50:57 2021 GMT
* subjectAltName: host "stag.foo.com" matched cert's "stag.foo.com"
* issuer: <bar>
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fd84900d600)
> GET / HTTP/2
> Host: stag.foo.com
> User-Agent: curl/7.64.1
> Accept: */*
>
* http2 error: Remote peer returned unexpected data while we expected SETTINGS frame. Perhaps, peer does not support HTTP/2 properly.
* Connection #0 to host stag.foo.com left intact
curl: (16) Error in the HTTP2 framing layer
* Closing connection 0
Notice the error:
* http2 error: Remote peer returned unexpected data while we expected SETTINGS frame. Perhaps, peer does not support HTTP/2 properly.
Most clients do not experience this, however:
% curl -v 'https://stag.foo.com/'
* Trying <ip>...
* TCP_NODELAY set
* Connected to stag.foo.com (<ip>) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: CN=stag.foo.com
* start date: Mar 15 02:07:24 2021 GMT
* expire date: Mar 29 02:07:24 2021 GMT
* subjectAltName: host "stag.foo.com" matched cert's "stag.foo.com"
* issuer: <bar>
* SSL certificate verify ok.
> GET / HTTP/1.1
> Host: stag.foo.com
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Accept-Ranges: bytes
< Content-Length: 3618
< Content-Type: text/html
< Date: Mon, 15 Mar 2021 17:48:39 GMT
< Etag: "604f7271-e22"
< Last-Modified: Mon, 15 Mar 2021 14:42:57 GMT
< Server: nginx/1.15.12
<
* Connection #0 to host stag.foo.com left intact
<!DOCTYPE html><html lang=en>...</html>* Closing connection 0
The difference from the failing output appears to start here:
Therefore, when the request succeeds, it's because the client falls back to HTTP/1.1. When the request fails, it's because the client attempts to use HTTP/2, which the server claims to support but fails to do so.
The solution appears to be either:
- Force HTTP/1.1, or
- Enable HTTP/2
How can we configure this stack to force HTTP/1.1 or enable HTTP/2?
We have deployed according to the steps in #322.
However, we have a problem that only seems to affect some clients:
Notice the error:
Most clients do not experience this, however:
The difference from the failing output appears to start here:
Therefore, when the request succeeds, it's because the client falls back to HTTP/1.1. When the request fails, it's because the client attempts to use HTTP/2, which the server claims to support but fails to do so.
The solution appears to be either:
How can we configure this stack to force HTTP/1.1 or enable HTTP/2?