Am 2020-05-22 um 18:51 schrieb [ext] Osipov, Michael:

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?

I am using my SPNEGO authenticator which is publically available [1] and based on the code which I have donated many years ago.

Would expect to see a second challenge form the server or should the
client be authenticated once the first auth header has been processed?

No, from a server's perspective the authentication has been completed already, but the client failed to provide the body.

What is triggering the read of the body here?
 >
Why isn't the client sending the body?

That's a good question. I need to ask fellow curl committers, this maybe a bug in curl.

I am looking at this with another client now, HttpClient 5.0. Even w/o authentication. the situation is even worse:
...

I found one issue with HttpClient and Tomcat via HTTP/1.1. I have decrypted the TLS traffic [1]. I can see that HttpClient sends the headers also with a 4 KiB large chunk of the ZIP file. In return a Tomcats send the 401 response with:
> Keep-Alive: timeout=300
> Connection: keep-alive

The client keeps sending in 8 KiB large blocks. After 2 134 016 written bytes there is a TLS alert: Close Notify. A few packets later: RST.

I would expect to see here: "Connection: close".

If necessary, I can provide the pcap and the keylog file.


[1] https://github.com/neykov/extract-tls-secrets

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to