Thanks for the detailed information. I have a better sense of the scenarios now. What about HTTP/2? Will the business logic or scenarios get changed for HTTP/2? Could the change apply to HTTP/1.1 as well?
Xuelei On Mar 5, 2021, at 5:43 AM, arjan tijms <arjan.ti...@gmail.com<mailto:arjan.ti...@gmail.com>> wrote: Hi, On Fri, Mar 5, 2021 at 2:05 AM Xue-Lei Fan <xuelei....@oracle.com<mailto:xuelei....@oracle.com>> wrote: Does it mean that when switch to HTTP/2, the concern is not valid any longer? Or there is an alternative solution? Sorry for the questions, I know little about servlet. I'm trying to understand the requirement of this feature. Mark Thomas (Tomcat maintainer) recently explained this on the Servlet mailing list. I think it explains the requirement quite well, so I'll copy/paste it: "The sequence of events in the test is as follows: - Client connects. - TLS handshake, no client authentication. - Client sends request - Server parses it and maps it to a web application - Server compares request to security constraints - Security constraints require CLIENT-CERT - Request fails because server cannot trigger post-handshake authentication (Even if the server did support PHA, the client doesn't so it will fail there instead). My reading of the spec is that the ability to create per URL security constraints strongly implies that renegotiation / PHA needs to be supported. The existence of this test supports that view." The above is for HTTP/1.1, which is an important supported target of Servlet. Hope the above helps. Kind regards, Arjan Tijms
