- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Wed, 24 Apr 2013 02:09:31 +1200
- To: ietf-http-wg@w3.org
On 20/04/2013 11:46 p.m., Amos Jeffries wrote: > On 20/04/2013 6:51 p.m., Willy Tarreau wrote: >> On Sat, Apr 20, 2013 at 04:44:30PM +1000, Mark Nottingham wrote: >>> On 20/04/2013, at 4:23 PM, Willy Tarreau <w@1wt.eu> wrote: >>> >>>> On Sat, Apr 20, 2013 at 02:07:11PM +1000, Mark Nottingham wrote: >>>>> p1 Section 2.3 says: >>>>> >>>>>> However, an HTTP-to-HTTP gateway that wishes to interoperate with >>>>>> third-party HTTP servers must conform to HTTP user agent >>>>>> requirements on the gateway's inbound connection and must >>>>>> implement the Connection (Section 6.1) and Via (Section 5.7.1) >>>>>> header fields for both connections. >>>>> This means that accelerators and CDNs MUST generate a Via header >>>>> on the outbound connection. This isn't widely practiced, and I'm >>>>> not sure it's necessary. Comments? > I've not seen the reply path Via: having much usage to date. But IMHO > with the growing usage of interception proxies for port 443 both > directions will grow in importance as a method of signalling that the > protocol is end-to-end secure (or not). Note that a lot of > vendor-specific hacks such as Frontend-HTTPS, Forwarded-For, > X-Protocol, X-HTTPS etc are simply duplicating information which is > supposed to be relayed in Via protocol-name field. The interesting corollary to come out of all the above is that HTTPS/1.1 protocol-name is never defined or registered anywhere that I can find. So its use will be somewhat non-standard. The use-case for its need is a reverse-proxy receiving port 443 traffic for an unsecured backend or one contacted via means other that TLS over TCP. Amos
Received on Tuesday, 23 April 2013 14:10:02 UTC