Closed prince-chrismc closed 4 years ago
I think there are two options that don't require to change RESTinio's implementation:
An introduction of is_tls_connection
to request_t
is possible (but I don't yet know is it's a good idea or not, and does it require another step of providing access to some TLS-related information from a connection or not). This idea requires some additional investigation. Unfortunately, we won't have time for it in the next couple of weeks because all our resources are allocated to an urgent project. I'm sorry.
An introduction of
is_tls_connection
torequest_t
is possible (but I don't yet know is it's a good idea or not, and does it require another step of providing access to some TLS-related information from a connection or not).
I would tend to agree with you, is does not feel like the role of the request to know the underlying protocol.
- You pass a flag to your request handlers that indicate a type of connection to be handled. RESTinio's sever can be either non-SSL or SSL.
I don't like this either but it makes much more sense then having it on the request. It's not totally unreasonable that an API knows where its HTTP or HTTPS
This idea requires some additional investigation. Unfortunately, we won't have time for it in the next couple of weeks because all our resources are allocated to an urgent project. I'm sorry.
That is absolutely alright! I appreciate the quick response, it certainly confirmed my suspicion that there was no API for doing this.
I am trying to add support for HSTS, however my
request_handler_t
s are blissfully unaware of the server and what protocol it is configured to run with yet they are the one with the job of building the response dependent on it;s configuration.Would it be possible to have a
bool request_handle_t::is_tls_connection() const
method?We have access to the
connection_id_t
from a request, but I can not find anything meaningful to use that information.Any directions on how I could go about this will be appreciated =)