- From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
- Date: Wed, 27 Nov 2013 22:18:15 +0100
- To: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>
- Cc: "Nicolas Mailhot" <nicolas.mailhot@laposte.net>, "Adrien de Croy" <adrien@qbik.com>, "Yoav Nir" <synp71@live.com>, "HTTP Group" <ietf-http-wg@w3.org>
Le Mer 27 novembre 2013 21:58, Stephen Farrell a écrit : > > > On 11/27/2013 08:40 PM, Nicolas Mailhot wrote: >> >> Le Mar 26 novembre 2013 21:09, Adrien de Croy a écrit : >>> >>> I don't see any point in using a CONNECT style of approach if you trust >>> the proxy. What sort of connection is that? If TLS, then why not just >>> use a GET https:// approach. >>> >>> As for using a mandatory proxy on the server end, I don't really see a >>> requirement for that. People use reverse proxies for sure, but they >>> just appear from the outside to be a server. I think if we allowed >>> assertion of mandatory proxy use outside a trusted environment (e.g. >>> the >>> user's LAN) then we would have major problems getting it accepted. >> >> I had the case of an entity that used an authenticating proxy to protect >> outside access to their internal webapps. So getting access for our >> users >> to their apps would have required chaining two proxies >> >> web client on corp1 lan → corp1 outbound auth proxy → Internet → corp2 >> inbound auth proxy → webapp on corp2 land >> >> And of course corp1 and corp2 secrets were not shared, only users with >> dual affiliation had a login on both proxies. > > I'm not sure how that actually works with http/1.1 - does it > really? I freely admit we could not get it to work which made those dual-affiliated users greatly cross with IT. We would definitely be interested in upgrading our hardware to http/2 if it could solve such use-cases, we do not enjoy making users miserable. Cheers, -- Nicolas Mailhot
Received on Wednesday, 27 November 2013 21:18:45 UTC