Which are orthogonal to QUIC, except that proxies will be even less able to be transparent -- and I consider that an advantage.

If you define something like an INSPECTED_CONNECT method that works over HTTP/1.1 or HTTP/2, it will work over HTTP/QUIC.  If you try to MitM, you'll have all the same problems that exist with TLS MitM today.  I'm sympathetic to the lack of configured proxies' abilities to, with user/client awareness, monitor the contents of transactions which are otherwise encrypted and return meaningful errors.  I'm less sympathetic to middleboxes that act without client awareness or configuration.

-----Original Message-----
From: Alex Rousskov [] 
Sent: Friday, March 10, 2017 1:34 PM
To: Patrick McManus <>
Cc: HTTP working group mailing list <>
Subject: Re: on HTTP/QUIC and HTTPBis

On 03/10/2017 12:38 PM, Patrick McManus wrote:
> there is no fundamental reason a client can't speak QUIC to a proxy in 
> the same way some of them support h2 to the proxy now.

As the recent "how to block h2 without MitM" thread illustrates, "speaking in the same way" is mostly useless when it comes to proxies.
If QUIC folks want to support proxies properly, they have to design the protocol to allow for trusted proxies. Besides politics, there are serious technical problems that neither HTTP/1 nor HTTP/2 solve in that space.


Received on Saturday, 11 March 2017 00:24:25 UTC