The server-side implementation will be configured by default to support OCSP stapling. The same security property that disables stapling on the client side can be used to disable support on the server side. Servers with OCSP stapling support disabled will ignore status_request and/or status_request_v2 extensions.

Server-side population of either status_request or status_request_v2 in the ServerHello message will depend on how the client as asserted these extensions. In general the same request extension in the ClientHello will be returned in the ServerHello, with the following exceptions:

Servers receiving both status_request and status_request_v2 extensions in the ClientHello will assert status_request_v2 in the ServerHello.

Servers receiving status_request_v2 extensions in the ClientHello with both "ocsp" and "ocsp_multi" types will assert "ocsp_multi" in the ServerHello.
        In the case where status_request_v2/ocsp_multi is selected, different threads should be used to fetch each response.

OCSP responses should be cached whenever possible. Clients that do not specify nonces in their status_request[_v2] extension may receive a cached response.
        Cached reponses should not be used if current time is later than the nextUpdate field.
        Cached responses with no nextUpdate field may be kept in the cache for a pre-determined lifetime (see Tunables below).
        Servers receiving status_requests with the nonce extension must not return cached responses in the CertificateStatus message.

Server side stapling support will be tunable through different security properties. Tunable items may include:
        Timeouts for contacting the OCSP responder
        Use of a static URL for the OCSP responder rather than use of the AIA extension on the certificate
        Cache lifetime (in seconds) for OCSP responses

The ServerHello class may need new methods so the status_request and/or status_request_v2 extension can be added to the ServerHello.