W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: Upgrade status for impl draft 1

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 26 Feb 2013 14:57:48 +1100
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <8DBA3603-0BBF-4619-95FC-F494F841E394@mnot.net>
To: Willy Tarreau <w@1wt.eu>

On 26/02/2013, at 2:54 PM, Willy Tarreau <w@1wt.eu> wrote:

> Hi Mark,
> 
> On Tue, Feb 26, 2013 at 11:56:09AM +1100, Mark Nottingham wrote:
>> 
>> On 22/02/2013, at 6:02 PM, Willy Tarreau <w@1wt.eu> wrote:
>> 
>>> I'm still having a problem with the principle behind 2b : when you
>>> pass through transparent intercepting proxies, by definition you're
>>> not aware of it. So even if 2a worked for the first connection, it
>>> does not preclude that 2b will work for the second one. Nor the DNS
>>> will BTW.
>> 
>> Sorry, I wasn't clear; that would be for cases where you had a high degree of
>> confidence that not only was HTTP/2.0 able to be spoken, but where you have
>> an even higher degree of confidence that HTTP/1.x is NOT; e.g., a separate
>> port (that you might have discovered through DNS, for example).
> 
> Then if that's to be used on a different port, we probably don't need
> to check how servers respond to this magic on port 80.

My motivation is to fail on misconfiguration (e.g., telling Apache to listen on the wrong port, forwarding to a back-end that doesn't speak 2.0), and to clearly identify the protocol being spoken.

To me, it's a bonus if sending the magic helps fail the upgrade early, but I don't find the multiple code paths terribly convincing; we're talking about emitting a handful of bytes on the client side, and checking a handful on the server side.

Cheers,


--
Mark Nottingham   http://www.mnot.net/
Received on Tuesday, 26 February 2013 03:58:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 26 February 2013 03:58:18 GMT