>> WebServer -> Tomcat
>>
>> 1) SEND HEADERS + REQUEST to TC
>> 2) SEND DATA (eventually) to TC
>>
>> 3) WAIT TOMCAT REPLY
>>
>> 4) SEND BACK HEADERS + REPLY TO BROWSER
>>
>> Next in ajp14
>>
>> WebServer -> Tomcat
>>
>> 1) SEND GENERAL HEADERS + REQUEST to TC
>> 2) SEND DATA (eventually) to TC
>>
>> 3) WAIT TOMCAT REPLY OR TOMCAT ENQUIRIES
>> 3a) IF ENQURIES, REPLY TO TC ENQUIRIES
>> ie CERTIFICATE CHAIN which may be more than
>> x certs....
>>
>> 4) SEND BACK HEADERS + REPLY TO BROWSER
>
>For example:
>request.getAttribute("javax.servlet.request.X509Certificate");
>1 - Tomcat send a message to the webServer - Want X509Certificates -
Exact
>2 - WebServer reads its enviromnemt (or send the client a
>request for the client
>certificate *).
Ok
>3 - WebServer answer with the received cerficate.
Tout à fait :)
>Why? because it is the servlet application that decides it
>needs the client
>certificate. Actualy that is a parameter in httpd.conf that
>makes it very
>difficult to use.
>
>*) Must be possible because mod_ssl allows per-directory context for
>SSLVerifyClient require.
Yep, yep .....
JFC you understand me perfezctly :)
