>> +1 , and a comment on Readme.txt as is a spec compliance issue
>>
>> Until we find a way to cache Client Certificate Chain..
>
>Or we add 2 more messages in ajp13/14 - to get the chain when the user
>request it.
>
>In fact, even the client certificate should be retrieved only
>on demand,
>I assume most pages will not deal with certificates ( except maybe
>some initial page ), and sending even the first cert over the
>wire would
>be wasted.
>
>Long ago we did some tests and looked into a number of servlets - it's
>likely 1/2 of what we send by default can be eliminated ( including
>most of the headers ), very few servlets will do getHeaders(). The
>impact on performance was visible ( with a small penalty for the
>requests using getHeaders == one extra roundtrip ).
>
>I assume that's something for ajp14/warp ( including customization
>of what's send and what's not).
That something I've got in mind for ajp14, written on that
many times allready, with headers and miscs informations
to be asked by tomcat to web-server at getAttributes time
for example :
Currently
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
