W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

Re: p1: Via and gateways

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Wed, 24 Apr 2013 02:09:31 +1200
Message-ID: <5176961B.6080907@treenet.co.nz>
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.

Received on Tuesday, 23 April 2013 14:10:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:10 UTC