Re: Call for Proposals re: #314 HTTP2 and http:// URIs on the "open" internet

On 20/11/13 7:38 PM, Michael Sweet wrote:
> Piotr,
> On Nov 20, 2013, at 11:36 AM, Piotr Galecki <> wrote:
>> I've been following this very interesting discussion as an observer.
>> We all agree that since HTTP/2.0 message formats are not backwards compatible with HTTP/1.x
>> the proxies processing HTTP/2.0 requests will cause problems and break end-to-end HTTP/2.0.
> I think “we all agree” is a prevailing assumption, but given my experience with HTTP Upgrade to TLS for CUPS I don’t think all hope is lost.
> Instead of assuming that it won’t work because WebSockets failed, I am now trying to collect real information and do some testing to see what exactly doesn’t work and why.  If we can find a path that allows clients to upgrade successfully or detect when it won’t work then we will have both the reliability needed to deploy it AND the information needed to document the failure modes for the spec.
Hi Michael

That info will be interesting. I worry, though, that it's a huge 
undertaking to get a complete picture because of the long tail.

A little over four years ago Marsh Ray and Martin Rex independently 
found a security problem in TLS (all versions). Marsh, acting 
responsibly, talked to the TLS WG chairs, and together they convened a 
secret meeting of the implementers of the major SSL libraries, because 
really, how many SSL libraries can there be out there? So they had 
Microsoft, and OpenSSL, and NSS, and Opera, maybe a few others (we never 
got the full details on those meetings).

When the story broke, it turned out that there were dozens of SSL 
libraries. We have one, SAP has one. There's a few open source ones. 
Fixing the problem required fixing all of them, so it could not be done 
in secret, even if it hadn't broke before they planned it. SSL libraries 
are obscure things. If you look at HTTP clients, there's also dozens of 

Proxies are probably the worst of the bunch. If we define proxy as any 
middlebox that does anything to the HTTP protocol other than just pass 
packets along (I like to think of them as broken routers), I'm sure 
there's over a hundred products and versions out there. Some are 
obsolete. Some haven't been patched in years. Some are discontinued 
products that are out of service. Some are by companies that have gone 
out of business. Any one of them might fail in an unpredictable way, and 
you won't be able to test them all.

Any one of them might respond might forward the Upgrade header, and then 
when seeing something unexpected (like HTTP/2), lose state for the 
connection without sending any RST or FIN. The user experience from this 
is a blank window waiting several seconds for a timeout. This won't 
happen all the time. It probably won't happen 95% of the time. But the 
browser vendors are worried for a reason.


Received on Wednesday, 20 November 2013 19:50:57 UTC