This seems reasonable, although I'd call it "tr-allow-plain" to indicate that plain text HTTP is enabled along with TLS. As noted, this is similar in flavor to the existing "tr-pass" except instead of blind tunneling, it tries plain text HTTP. We can allow both with a preference for plain text HTTP. So
1. If client HELLO, do TLS 2. if "tr-allow-plain" and it looks like HTTP (e.g. there is the string "HTTP/1.0" or "HTTP/1.1", do plain text HTTP 3.if "tr-pass" then blind tunnel. -----Original Message----- From: SUSAN HINRICHS <shinr...@ieee.org.INVALID> Sent: Sunday, March 19, 2023 8:00 PM To: dev@trafficserver.apache.org Subject: [api] Add tr-try-plain port descriptor I would like to propose another port descriptor, tr-try-plain. The current list is recorded in the documentation link below. https://docs.trafficserver.apache.org/admin-guide/files/records.config.en.html#proxy-config-http-server-ports With this port descriptor, if the TLS client hello does not work for a TLS connection, this descriptor indicates that ATS should attempt to process the connection as a non-TLS HTTP connection. This is useful for our dynamic transparent case. If our policy has traffic on a random port, e.g. 5555, we cannot know whether that traffic should be TLS or or non-TLS. If the SSL port is decorated with tr-try-plain, we can start with TLS processing and then attempt non-TLS. I have a patch against 9.1.x that implements this logic against the tr-pass port descriptor. While changing the tr-pass logic works for us, we should probably have another descriptor to preserve the original logic. I'd appreciate comments before I set up a PR. Thanks, Susan
