1. Specific mode for verifying peer certificate

Current 'mode' for verifying peer certificate is a global option, it's good to have specific mode among different sites hosted on a same machine. If the mode is non-empty, it would be the preference when making the decision to verify peer or not. Otherwise, the global mode will take effect.
# Client certification level should be:

0 no client certificates
1 client certificates optional
2 client certificates required
CONFIG proxy.config.ssl.client.certification_level INT 0

2. Optimization on TLS record size

The client can decipher the data only once it has received a full record over SSL. The record size can have significant impact on the page load time performance of the application. No limitation on record size means that clients might have to download up to 16KB of data before starting to process them, whereas very small records incur a larger overhead due to record framing. The suggestion is to configure the TLS record size to fit into a single TCP segment, this can improve page load times on browsers located over high latency or low bandwidth networks.
- ref: http://www.igvita.com/2013/10/24/optimizing-tls-record-size-and-buffering-latency/
Status: https://issues.apache.org/jira/browse/TS-2365

Session size is configurable, whereas application can not specify a session time out threshold. The default is 300 seconds. In some cases, applications need to reduce or increase the caching time, it's good to be configurable.

When verifying peer certificates, A few customers expect to obtain the specific cert data (i.e. subject, issuer info) and forward them to origin servers. It's better to expose API to extract peer certificate data.
Status: https://issues.apache.org/jira/browse/TS-2210

A few customers expect a size threshold for client request over ssl from protecting system perspective. If the max requested data exceed the threshold, server will reject the client connection.