Re: #385: HTTP2 Upgrade / Negotiation

On 24/10/2012, at 3:04 PM, James M Snell <jasnell@gmail.com> wrote:
> 
>>>> Does anyone object to us defining such a record (type TBD), as long as it's not the only way to get to HTTP/2 for HTTP URIs?
>>>> 
>>> Defining a new dns record type would be unnecessary and would be the wrong approach. SRV records were made specifically for this kind of use. They're certainly not perfect but inventing a new record type specifically for http2 stuff is even less so.
>>> 
>> We're not talking about defining a new record type, only deciding whether DNS is an appropriate OPTIONAL upgrade path, and EVENTUALLY which existing record type to use.
>> 
>> Everyone, please focus on the questions at hand -- we don't need to have a round of +1s and resulting back-and-forth on an issue that's not even being discussed yet.
>> 
> Ok.. consider this a proposal then ;-)

For what?  I asked a very clear question, and you jumped to the next phase of the discussion prematurely. 

<soapbox>
We need to start to control the discussion here; it was comparatively free-wheeling before we re-chartered, but if it's allowed to meander too much now, we'll get off track. Every message sent to this list is delivered to thousands of mailboxes, and needs to be read by (at least) hundreds of people. The more noise we have on the list, the more likely it is to scare away folks who have valuable input but not much time.

Please understand I'm not picking on you in particular; this is for everyone.
</soapbox>

>>> Hm. I'd be interested to hear from implementers on this. The only advantage that I see is that you'd be able to start multiplexing other requests on the same connection sooner. However, you could also just use SRV, or a different connection if it's not available.
>> 
> Well.. the other advantage is that you upgrade before sending payload data, which is a step up from montenegro-httpbis-http2-negotiation... It's certainly not without it's problems, however. For my money, however, the SRV route is preferable but certainly has it's own range of issues. 

Ack.

> (and, so we're clear, who exactly do you classify as "implementors" here?)

See the charter. 

In this case, it's the people who have to implement the upgrade mechanism, both on the client side and the server side. This includes everyone, but I'll be paying particular attention to the implementations that can "move the needle" and get market adoption. 

In other words, we want this to work for someone when they write a Perl library to do it, but we NEED it to work for that handful of implementations that define the lion's share of traffic on the Web -- again, both client and server.


>>  Alternatively, I firmly believe that a http2 URI scheme as a reasonable fallback needs to be considered as an option here... particularly if we do define a dedicated http/2 default port. Yes, I agree with the whole "we want to do existing http:// and https:// traffic over http/2 transparently" argument and fully understand the challenges of introducing a new URI scheme. However, there will be instances where upgrade negotiation is simply not going to be necessary and for which backwards compatibility with existing infrastructure is going to be unnecessary. For those cases, the ability to pass a URL like "http2://example.org" and have it just automatically understood that it's "http/2 over port whatever" will be extremely useful. A no brainer even. So much so that if the working group here doesn't choose to define it, I'll likely just end up writing it up as an individual submission. That way, when I write.. <form method="post" action="http2://example.org">...</form> the notion that http/2 is being used is explicit and no upgrade discovery/negotiation is required at all. That's what url schemes are for in the first place, right?
>> 
>> I don't see any consensus to do this here; does anyone support James' position, or want to discuss it more?
> 
> 
> You're the one who asked for proposals ;-)

Yes, and you've made yours. If you'd like to add to it, that's fine, but I'm not sure what point you're trying make here.


> ... I believe you're also the one who said, "we don't need to have a round of +1s and resulting back-and-forth on an issue that's not even being discussed yet." ... I brought this up as one of several possible proposals for discussion at some point. I'm not going to argue this particular point of view further right now but it does need to be recognized that http2-without-upgrade-negotiation is definitely something that needs to be considered in-scope.

It's been brought up before, and I'd characterise the reaction of the WG so far as very much against it. This is why I asked for anyone who wanted to support it, to firm up that characterisation. 

Regards,

--
Mark Nottingham   http://www.mnot.net/

Received on Wednesday, 24 October 2012 04:19:58 UTC