[
https://issues.redhat.com/browse/WFLY-13924?page=com.atlassian.jira.plugi...
]
Richard Opalka commented on WFLY-13924:
---------------------------------------
This have been fixed with WildFly Core upgrade. Output I'm getting with WildFly commit
id fa68fad0acc746fd3cd669d75710a9e9455c3bc4 :
---
curl -k
https://localhost:8443 -vvv >/dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying ::1:8443...
* connect to ::1 port 8443 failed: Connection refused
* Trying 127.0.0.1:8443...
* Connected to localhost (127.0.0.1) port 8443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [94 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [694 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [333 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=localhost
* start date: Oct 13 13:47:51 2020 GMT
* expire date: Oct 11 13:47:51 2030 GMT
* issuer: CN=localhost
* SSL certificate verify result: self signed certificate (18), continuing anyway.
* 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
} [5 bytes data]
* Using Stream ID: 1 (easy handle 0x5644a0de8b10)
} [5 bytes data]
GET / HTTP/2
Host: localhost:8443
user-agent: curl/7.69.1
accept: */*
{ [5 bytes data]
* Connection state changed (MAX_CONCURRENT_STREAMS == 4294967295)!
} [5 bytes data]
< HTTP/2 200
< last-modified: Tue, 13 Oct 2020 13:44:18 GMT
< content-length: 1504
< content-type: text/html
< accept-ranges: bytes
< date: Tue, 13 Oct 2020 13:47:52 GMT
<
{ [1504 bytes data]
100 1504 100 1504 0 0 5063 0 --:--:-- --:--:-- --:--:-- 5063
* Connection #0 to host localhost left intact
---
HTTP2 is not working with Oracle JDK8 u261
------------------------------------------
Key: WFLY-13924
URL:
https://issues.redhat.com/browse/WFLY-13924
Project: WildFly
Issue Type: Bug
Components: Security, Web (Undertow)
Affects Versions: 20.0.0.Final, 20.0.1.Final, 21.0.0.Beta1
Reporter: Jan Stourac
Assignee: Flavia Rainone
Priority: Blocker
Fix For: 21.0.0.Final
There seems to be some problem with HTTP2 support with new Oracle JDK8 u261 and WildFly
since {{20.0.0.Final}} version. When request against server is executed, then HTTP2 is not
established and communication remains via HTTP/1.1.
There is no such issue when I use {{WildFly 19.0.0.Final}}. Also, if I switch back to
an older Oracle JDK8 u241, there is no such issue even with newer WildFly versions.
This all seems to be tied with backport of ALPN support into the Oracle JDK8 recently and
also work in following issue UNDERTOW-1726.
There seems to be a workaround available - to define
'-Dio.undertow.protocols.alpn.jdk8' during the server startup. With this property
configured, the issue seems to disappear (as such, blocker priority of this may be
discussed).
*What is the issue here:*
This is a change in default behavior of the server (HTTP2 not working with Oracle
JDK8u261+ since WildFly 20.0.0.Final). We should try to resolve this without default
behavior change if possible. Only in case there is really no other solution, we need to
document such thing.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)