Hey, On Mon, Apr 20, 2020 at 11:28 PM Soni L. <fakedme+http@gmail.com> wrote: > you'd still have a reverse proxy that's terminating TLS and talking HTTP > with the backend. > > you'd just also have a way for that reverse proxy to pass a raw TLS stream > through, so the client can talk HTTPS with the backend when needed. it'd > still be in the middle of the connection and fully capable of terminating > it if it detects potentially abusive behaviour. > > On 2020-04-20 7:20 p.m., Brian Campbell wrote: > > That's really quite different than the intended scope of the draft, which > was/is a reverse proxy that's terminating TLS (from the client's > perspective anyway) and taking HTTP with the backend. > > I'm with Brian on this; CDN/reverse proxies provide an offload of HTTP processing from the origin that brings advantages such as performance, scale, and security. Although it could be technically possible to pass through TLS (pretty much covered by CONNECT already), the concept negates the value proposition of a CDN architecture. I think Brian's document has more value with the scope that he has described. Cheers Lucas
Received on Monday, 20 April 2020 22:59:37 UTC