Subject: RE: Secure Proxy definition [was: "Secure" proxies for HTTP URIs]

From: "Nicolas Mailhot" <[email-masked]>
Date: Sat, 1 Mar 2014 09:51:10 +0100

Le Ven 28 février 2014 08:23, [email-masked] a écrit :
> Hi
>
> +1 for  Salvatore proposal of including “Secure proxy” definition in the
> core spec.
> +1 for peter proposal of including discovery mechanism for HTTP URIs in
> the core spec too.

+1

You can't do proxies in isolation separate from the main spec, if the
other participants in the http2 dialog ignore the proxy bits or implement
them as an afterthought there will be misundertandings, quirky connexions,
angry users and support calls (and they won't be addressed solely to proxy
operators).

-- 
Nicolas Mailhot

---

From: Peter Lepeska <[email-masked]>
Date: Mon, 3 Mar 2014 08:57:16 -0500

Thinking on this a bit more I realize that there is no need to redirect in
the case that I am describing where the proxy is in path and already sees
all traffic. In a sense the proxy wants to do an "Upgrade" to HTTP/2 for
traffic between itself and the UA. However, since some browsers do not
support HTTP/2 in plain text, it is also necessary to switch to TLS --
that's the problem I think we need to solve.

Peter

On Fri, Feb 28, 2014 at 1:58 AM, Amos Jeffries <[email-masked]> wrote:

> On 27/02/2014 11:39 a.m., Peter Lepeska wrote:
> > I was assuming the forward proxy was in a position to modify HTTP
> responses
> > and so it would add the header. But you are right that it's probably
> better
> > to use a 3XX status code for this. But in that case, what if the proxy is
> > optional and the UA decides it wants to go direct? Or what if the UA
> > doesn't support the new 3XX status code?
> >
> > Adding the header to responses just says -- "Hey I'm here and if you want
> > to go HTTP2 Secure Proxy mode with me feel free". Of course, a proxy
> could
> > also require its use by blocking port 80 access.
>
> I was trying to point out that is should be a 5xx code for the same
> reasons that 511 exists as part of the 401/407/403/511 set.
>
> So that we will have pairs of temporary/permanent redirects for the
> 302/303 (repeat using GET as method), 301/308 (repeat with same method),
> and 305/512 (use proxy) instructions respectively.
>
> Or perhape the see-proxy redirects are both better renumbered as 512/513
> so that clients not supporting the status or even simply choosing not to
> obey it will display the payload safely as an error page for users about
> why their Internet is broken.
>
> Amos
>
>
>

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Mon, 3 Mar 2014 15:38:42 +0100

Le Lun 3 mars 2014 14:57, Peter Lepeska a écrit :
> all traffic.

Actually the general case is that the proxy is not in path. If this case
is specified cleanly then an in-path proxy becomes just an out-of-path
that happens to be located in-path.

And I'm not sure it will be worth adding the complexity of a different
optimised in-path variant if out-of-path is good enough for everyone.

Regards,

-- 
Nicolas Mailhot

---

From: Roland Zink <[email-masked]>
Date: Mon, 03 Mar 2014 15:27:40 +0100

Something like in RFC2817, which allows the server to send an upgrade 
header? Both mandatory (426 upgrade required) and optional upgrade is 
described.

Roland

On 03.03.2014 14:57, Peter Lepeska wrote:
> Thinking on this a bit more I realize that there is no need to 
> redirect in the case that I am describing where the proxy is in path 
> and already sees all traffic. In a sense the proxy wants to do an 
> "Upgrade" to HTTP/2 for traffic between itself and the UA. However, 
> since some browsers do not support HTTP/2 in plain text, it is also 
> necessary to switch to TLS -- that's the problem I think we need to 
> solve.
>
> Peter