Hi Mark,

Well, anything is 100% better than nothing. Is this " - - 
[31/Jul/2019:16:45:16 +0100] "-" 400 -" going to be followed by any reason or 
error-code that can point to the reason of failure? Anything that distinguishes 
it from a 'regular' 400 error originating after the handshake? I'd have to pass 
it by the compliance experts, but maybe even just this would be enough to 
convince them I don't need  to use the javax.net.debug=ssl:handshake 

What version will this be in?

Mark Boon
From: Mark Thomas <ma...@apache.org>
Sent: Wednesday, July 31, 2019 8:47 AM
To: users@tomcat.apache.org <users@tomcat.apache.org>
Subject: Re: Can Tomcat log handshake failures, and where?

On 30/07/2019 08:28, Mark Thomas wrote:


> Generally, processing needs to get as far as presenting a request line
> before something is added to the access logs. We could look at expanding
> the access logging to include connections that are dropped earlier but
> that might be a sufficiently invasive change that it needs to wait until
> Tomcat 10.

I've done some work on this and it looks promising. The end result is
entries like this in the access log for a failed TLS handshake: - - [31/Jul/2019:16:45:16 +0100] "-" 400 - - - [31/Jul/2019:16:45:16 +0100] "-" 400 - - - [31/Jul/2019:16:45:17 +0100] "-" 400 - - - [31/Jul/2019:16:45:17 +0100] "-" 400 -

Does this meet your requirement?


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

Reply via email to