Am 2020-05-22 um 13:26 schrieb Mark Thomas:
On 21/05/2020 23:30, Osipov, Michael wrote:
<snip/>
Output will be sent privately.
Got it. Tx.
Looking at the direct case.
It looks like you have debug logging enabled for everything. You only
need it for the org.apache.coyote.http2 package.
grep "http2" catalina.2020-05-21.log | less
gives a nice clear view of what is happening which is roughly:
22:34:29 Client sends request headers and ~64k of body on stream 1
22:34:29 Server sends 401 response and resets stream 1
22:34:29 Client resends request with authorization header but NO body
22:34:31 Server tries to read request body
22:34:51 Server times out trying to read request body
22:34:51 Server sends 500 response due to timeout and resets stream 3
It looks like the response to stream 3 includes an authorization challenge.
I think something isn't quite right with the authentication process.
Which authenticator are you using?
Would expect to see a second challenge form the server or should the
client be authenticated once the first auth header has been processed?
What is triggering the read of the body here?
Why isn't the client sending the body?
I have made some progress on the topic with curl and HttpClient.
RFC 7230, 6.5 says:
A client sending a message body SHOULD monitor the network connection
for an error response while it is transmitting the request. If the
client sees a response that indicates the server does not wish to
receive the message body and is closing the connection, the client
SHOULD immediately cease transmitting the body and close its side of
the connection.
curl perfectly manages the situation of 6.5 by using non-blocking I/O
[1]. As for HttpClient, it does not handle this because of [2], [3],
blocking I/O limitation. It then suffers from section 6.6:
If a server performs an immediate close of a TCP connection, there is
a significant risk that the client will not be able to read the last
HTTP response. If the server receives additional data from the
client on a fully closed connection, such as another request that was
sent by the client before receiving the server's response, the
server's TCP stack will send a reset packet to the client;
unfortunately, the reset packet might erase the client's
unacknowledged input buffers before they can be read and interpreted
by the client's HTTP parser.
So I at least believe that according to 6.5 Tomcat has to include
"Connection: close" on the response.
As for the HTTP/2 issues, I will create separate threads when I have
gathered the appropriate data.
Michael
[1] https://curl.haxx.se/mail/archive-2020-05/0054.html
[2] https://stackoverflow.com/a/9176445/696632
[3]
http://mail-archives.apache.org/mod_mbox/hc-httpclient-users/202005.mbox/%3Cc43e2056-a95c-2070-3b9c-dd081a5f5235%40apache.org%3E
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
