- From: Yutaka Hirano <yhirano@google.com>
- Date: Thu, 17 Jul 2014 14:35:44 +0900
- To: Roberto Peon <grmocg@gmail.com>
- Cc: Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>, Martin Thomson <martin.thomson@gmail.com>
- Message-ID: <CABihn6Gf4ZrxON+Vuo21URud5WZnAE-NT7Q8CbmCd=JrDxqzyA@mail.gmail.com>
Thanks, I understand. On Wed, Jul 16, 2014 at 12:15 PM, Roberto Peon <grmocg@gmail.com> wrote: > I'd say that the current stance is that anything which isn't part of the > past set of usecases for http will not be considered for h2. > > This is disappointing, but there it is. It is difficult to do anything > forward looking in committee, regardless of its venue or the talent of its > members. > On Jul 15, 2014 6:55 PM, "Yutaka Hirano" <yhirano@google.com> wrote: > >> I'm a bit behind, can you tell me what you mean by "semantic-free" >> HEADERS? >> It the current stance for extensions (such as WebSocket) "Do not abuse >> HTTP related frames. Instead, define and use extension-specific frames"? >> >> >> >> >> On Wed, Jul 16, 2014 at 8:57 AM, Greg Wilkins <gregw@intalio.com> wrote: >> >>> >>> On 16 July 2014 09:46, Martin Thomson <martin.thomson@gmail.com> wrote: >>> >>>> You can try to start h2 and then upgrade to websockets if the ALPN >>>> negotiation selects http1.1. >>>> >>> >>> Currently this kind if decision is made above the browser in javascript >>> libraries that have to decide if they are going to use websocket or long >>> polling. If they use long polling, for h1 they have to be aware of >>> connection limits and currently some assume 2, while others have been >>> updated to 6. A much higher connection==stream limit will need to be >>> applied if long polling over h2. But these frameworks don't have the >>> ability to take part in h2/upgrade negotiations and any knowledge they get >>> about protocol versions will be late. They probably don't have access to >>> max stream settings, so will be guessing again. >>> >>> Now if h2 had supported websocket semantics from day 1, then these >>> libraries could have just handed over the messages to the browser and it >>> would be up to the browser to work out the best way to transport. >>> >>> Anyway.... I've made my point (several times) that I think it was a >>> mistake for the charter to not support all the current web semantics. I >>> guess that horse bolted a long time ago. >>> >>> cheers >>> >>> >>> >>> -- >>> Greg Wilkins <gregw@intalio.com> >>> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that >>> scales >>> http://www.webtide.com advice and support for jetty and cometd. >>> >> >>
Received on Thursday, 17 July 2014 05:36:11 UTC