W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

Re: new version trusted-proxy20 draft

From: Thomas Fossati <TFossati@velocix.com>
Date: Sun, 16 Feb 2014 21:24:44 +0000
To: Salvatore Loreto <salvatore.loreto@ericsson.com>, HTTP Working Group <ietf-http-wg@w3.org>
CC: "draft-loreto-httpbis-trusted-proxy20@tools.ietf.org" <draft-loreto-httpbis-trusted-proxy20@tools.ietf.org>
Message-ID: <DA86AAEF6E448540808AFA696EA47E5A71FE36F4@EXB01-MLT.corp.velocix.com>
Hi Sal, thanks for the draft.

On 14/02/2014 18:56, "Salvatore Loreto" <salvatore.loreto@ericsson.com<mailto:salvatore.loreto@ericsson.com>> wrote:
I want to highlight that
the only change asked by this draft in order to support an Explicit Trusted Proxy
is the definition of a new ALPN protocol id value as you can read in the Abstract below.
No other changes to HTTP2 spec neither to the TLS protocol are required.

I think one very important change that you propose (for good reasons, IMHO) is to explicitly separate TLS tunnels that are intended for http URIs from those that are to carry https traffic.

Maybe this bit of information deserves to be stated more clearly in the document?

   Section 3.2 proposes a solution based on the presence of a Captive

This is the only part of your draft where I have a bit of difficulties in understanding the mechanics.

In step (2), in order to distinguish between a genuine HTTP/1.1 request (one that needs no redirection to the Portal) from a "downgraded” HTTP/2.0 request (i.e. one which is the result of a previously tried&failed “h2clr” handshake and has to go to the Portal), the trusted proxy needs to keep some kind of state about the re-trying user agent.

However, at the point the redirection decision is made, the trusted proxy has no other information than IP address of the user agent.

What’s the heuristics that you envisage to make this work in practice?

Received on Sunday, 16 February 2014 21:25:15 UTC

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