My final implementation calls it alow-plain, since as I was implementing this I realized that this could make sense in a non-transparent mode as well.
https://github.com/apache/trafficserver/pull/9574 On Sun, Mar 19, 2023 at 9:47 PM Alan Carroll <a...@network-geographics.com> wrote: > > 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 >
