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 Proxy. 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? Cheers
Received on Sunday, 16 February 2014 21:25:15 UTC