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

there are a lot of WinGate versions out there that will ignore (pass not 
strip) Upgrade on outbound, and wait for a message after the 101 back. 
They will in general I think pass back the 101, but probably prevent 
data flowing properly in both directions after that.

We need the ability in writing up RFCs to be able to put 
sections/text/warnings in bold and red so that I would have noticed 
this.  I guess I'm a lazy RFC-reader.  In fact in 1995, when I did the 
initial proxy, I didn't read any spec at all.  Maybe there was none.

How many people that impacts I have no idea sorry.  there was a free 
version for many years.  I'd be inclined to suggest the old ones are 
infrequently used now, but they still pop up at a rate higher than I 
would expect.

I'm also wondering if we may be facing a similar issue with port 443 and 
http/1.1 over TLS.

As more and more MITMs roll out, we're going to have issues with things 
intercepting port 443, and expecting to see http/1.1 not anything else.  
I'd expect this to break NPN/ALPN so maybe that's not an issue (fail 

I do wonder though, with negotiated crypto (e.g. "opportunistic") 
whether we couldn't use port 100 for both http:// and https://

E.g. the base protocol supports negotiated (optional) crypto, and just 
have different requirements for whether crypto is required based on the 
scheme in the URI.  I think the STARTTLS / STLS etc model in 
SMTP/POP3/IMAP works pretty well.  But others may not agree with this.  
Since we're talking about some initial settings negotiation, crypto for 
an entire channel or for streams becomes advertiseable and selectable.


------ Original Message ------
From: "Michael Sweet" <>
To: "Yoav Nir" <>
Cc: "HTTP Working Group" <>
Sent: 21/11/2013 9:12:34 a.m.
Subject: Re: Call for Proposals re: #314 HTTP2 and http:// URIs on the 
"open" internet
>On Nov 20, 2013, at 2:50 PM, Yoav Nir <> wrote:
>>  ...
>>  That info will be interesting. I worry, though, that it's a huge 
>>undertaking to get a complete picture because of the long tail.
>I’m less concerned about getting a 100% complete picture and more 
>wanting to get a general picture based on proxies that are popular 
>and/or known to have issues.
>I am under no illusion (delusion? :) that we will be able to do 
>HTTP/2.0 upgrade over current proxies.
>Rather, I want to know whether a HTTP/2.0 client can successfully 
>continue to function with HTTP/1.1 proxies - can we reliably either a) 
>know that we can attempt an upgrade or b) recover from a failed 
>Answering those questions will determine whether it is feasible to 
>support plain text HTTP/2.0 on port 80 and/or whether we would really 
>need a new URI scheme to differentiate between HTTP/1.x and HTTP/2.0. 
>I’m hopeful that the answer is actually *yes* since the “failure” mode 
>for HTTP/2.0 upgrades is just using HTTP/1.1, vs. WebSockets and other 
>similar extensions that rely on upgrade to work at all.
>In short (and I apologize for paraphrasing): Failure IS an option. We 
>just need to know *how* HTTP/2.0 upgrade will fail to determine if it 
>would prevent implementors from supporting plain text HTTP/2.0 over the 
>Michael Sweet, Senior Printing System Engineer, PWG Chair

Received on Wednesday, 20 November 2013 23:45:55 UTC