elsloo commented on code in PR #10306:
URL: https://github.com/apache/trafficserver/pull/10306#discussion_r1321874859
##########
doc/admin-guide/files/records.yaml.en.rst:
##########
@@ -4254,6 +4254,14 @@ OCSP Stapling Configuration
Number of seconds before an OCSP response expires in the stapling cache.
+.. ts:cv:: CONFIG proxy.config.ssl.ocsp.request_mode INT 0
+
+ Set the request method to prefer when querying OCSP responders. The default
+ is zero, or POST, and a value of 1 will cause ATS to attempt a GET request.
+ Because the length of the encoded request must be less than 255 bytes per
RFC
+ 6960, Appendix A, ATS will fall back to the POST request method when the
+ encoded size exceeds this limit.
+
Review Comment:
I asked myself the same question when I worked on this initially, and had
originally named the configuration parameter `request_method` and later renamed
to `request_mode` to be more generic. I agree that the RFC is mostly clear on
the behavior here but it isn't absolutely clear (SHOULD vs MUST), and as a
result, we may in the future need another option to support a mixed mode of
some kind bound by a check of some kind to switch between the two request
methods dynamically, or refuse to make a request that exceeds a certain size
and not fall back to POST. I don't think that we should let that concern
override the improvements here, and if someone does have GET requests that
exceed the RFC-defined length, they can a) develop the support for the use of
request methods based on size and their requirements which would lead to a new
mode in configuration, or b) fall back to using POST for all requests.
I would personally prefer to keep this variable generic due to the RFC,
which allows us to retain the variable if we need to extend it in the future.
This is also somewhat of an advanced configuration topic, and most operators
will likely read the documentation if they have any reason to move from POST to
GET.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
