- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 28 Apr 2020 18:27:22 +1000
- To: James Peach <jorgar@gmail.com>
- Cc: ietf-http-wg@w3.org
Hi James, You've got it right. "Reverse proxy" is just a colloquialism (because many of them started as "forward" proxy products). Cheers, > On 28 Apr 2020, at 12:59 pm, James Peach <jorgar@gmail.com> wrote: > > >> On Apr 28, 2020, at 12:44 PM, James Peach <jorgar@gmail.com> wrote: >> >> Hi all, >> >> I have an reverse proxy Envoy configuration where each SNI server name is attached to exactly one virtual host routing table. If this configuration is deployed with a wildcard certificate however, browser clients will re-use the TLS connections for server name A to send requests for origin B, due to connection reuse, https://httpwg.org/specs/rfc7540.html#reuse. In this configuration, envoy generates a 404 because the configuration for servername A doesn’t have any routes for B. >> >> I believe that in this situation, generating a 421 response should cause the client to not re-use the connection for a different (but wildcard-matching) hostname. However, the spec also says that a proxy must not generate a 421. I wasn't able to track down any rationale for why a proxy must not generate a 421; would it be considered inappropriate in this kind of configuration? Or is it OK, since from the client’s perspective, the reverse proxy is the origin? >> >> The example use case for 421 status in section 9.1.1 is a TLS-terminating middlebox, which matches my scenario pretty closely. To my reading, this conflicts with the "MUST NOT be generated by proxies” requirement in 9.1.2. > > To answer my own question (I think) ... the reverse proxy is a "gateway", not a “proxy”, so the MUST NOT doesn’t apply here. > > J > -- Mark Nottingham https://www.mnot.net/
Received on Tuesday, 28 April 2020 08:27:45 UTC