Client: Some HTTP/2 requests are never sent #11965
Assignees
Labels
Bug
For general bugs on Jetty side
Comments
|
I created the following repository to try to reproduce this problem: https://github.com/lorban/h2-sharepoint-11965 and I get the following output which shows everything is working as expected when I run H2SharepointTest which contains your reproducer: Did I miss something? |
|
You're right, now it also works for me. Anyway, I found another server that does show the reported behavior: https://cashdesk-hochschwarzwald.stage.peaksolution.com On a related note, I now also tried to replicate this with the original sharepoint URL by using Conscrypt, changing the first few lines like this: Security.addProvider(new OpenSSLProvider());
var sslContextFactory = new SslContextFactory.Client();
sslContextFactory.setProvider("Conscrypt");
var connector = new ClientConnector();
connector.setSslContextFactory(sslContextFactory);
...But then I get this exception: The exception appears after "request begin" is logged. After that, nothing happens and the client seems to be waiting forever. Do I need to change some security configuration, or does the server use outdated ones? |
|
The conscrypt folks had a discussion about Interesting to read the other issues that reference that above issue. Google cloud, palantir, grpc, and more all have encountered this issue. |
lorban
added a commit
that referenced
this issue
Jul 3, 2024
…eption in SslEndPoint.fill() Signed-off-by: Ludovic Orban <lorban@bitronix.be>
lorban
added a commit
that referenced
this issue
Jul 3, 2024
… fill() is called with an empty buffer Signed-off-by: Ludovic Orban <lorban@bitronix.be>
|
I could reproduce the problem with the https://cashdesk-hochschwarzwald.stage.peaksolution.com/ URL, and it is caused by a genuine bug in the Jetty client's TLS negotiating code. This PR contains a fix, as well as some related improvements: #11999 Thanks for the report! |
lorban
added a commit
that referenced
this issue
Jul 4, 2024
Signed-off-by: Ludovic Orban <lorban@bitronix.be>
lorban
added a commit
that referenced
this issue
Jul 4, 2024
Signed-off-by: Ludovic Orban <lorban@bitronix.be>
lorban
added a commit
that referenced
this issue
Jul 10, 2024
#11965 make EMPTY_BUFFER not read-only anymore Signed-off-by: Ludovic Orban <lorban@bitronix.be>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Jetty version(s)
Jetty 12.0.10
Jetty Environment
core
Java version/vendor
(use: java -version)openjdk version "21.0.3" 2024-04-16 LTS
OpenJDK Runtime Environment Temurin-21.0.3+9 (build 21.0.3+9-LTS)
OpenJDK 64-Bit Server VM Temurin-21.0.3+9 (build 21.0.3+9-LTS, mixed mode, sharing)
OS type/version
Windows 11
Description
When using the Jetty 12 HttpClient to send a request to certain servers via HTTP/2, the request never completes. In fact, the request is only queued, but sending the request never even begins.
This only happens with some servers, which do support HTTP/2.
How to reproduce?
The above snippet creates a HttpClient that supports both HTTP/1.1 and HTTP2, and makes a request to "https://microsoft.sharepoint.com". Several events are logged, so we see that the request is only ever queued, but never sent.
When forcing the client to use HTTP/1.1, either by removing support for HTTP/2, or by using
version(HttpVersion.HTTP_1_1), everything works as expected.Also, the following curl command sends the same request, also using HTTP/2, and works fine:
curl "https://microsoft.sharepoint.com" --http2The text was updated successfully, but these errors were encountered: