Re: "Secure" proxies for HTTP URIs [was: new version trusted-proxy20 draft]

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 <squid3@treenet.co.nz> 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
>
>
>