- From: 陈智昌 <willchan@chromium.org>
- Date: Tue, 21 May 2013 13:32:50 -0300
- To: James M Snell <jasnell@gmail.com>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-ID: <CAA4WUYhDhoS+BNknRnYLAOXfWzumcjkWnQnM=NkNM8oqqE=atw@mail.gmail.com>
We discussed this previously and Roberto and I were both against the removal of the priority field from the HEADERS+PRIORITY frame: http://lists.w3.org/Archives/Public/ietf-http-wg/2013JanMar/1065.html, even considering stream reprioritization. I support adding a new additional PRIORITY frame for stream reprioritization. That said, I'm in no hurry to write anything into the spec. On the SPDY end we're planning on experimenting with prioritization and when we have something to present with detailed explanations why, we will do so. We presented the general ideas previously in the last interim meeting and haven't finished implementation and experimentation. Unless there's a reason this needs to be in the current http/2 draft sooner rather than later, I'd rather punt on this discussion until we have implementation experience that can guide this debate. I believe everyone recognizes that people are interested in reprioritization. If we need to put something in the spec, let's just add a new frame and then revisit changing HEADERS+PRIORITY later. On Tue, May 21, 2013 at 1:10 PM, James M Snell <jasnell@gmail.com> wrote: > https://github.com/http2/http2-spec/issues/99 > > With regards to the discussion over stream re-prioritization, I suggest: > > 1. Drop the HEADERS+PRIORITY frame type. > 2. Create a new separate PRIORITY frame type whose payload is the > Priority value, no frame-specific flags. > 3. The PRIORITY frame becomes the only way to set/change the priority > for a stream. > > If it is necessary to allow an endpoint to establish the priority of > stream prior to actually initiating the stream, we can allow sending a > PRIORITY frame before the initial HEADERS frame. Doing so would > effectively reserve the stream id (in the same general manner > PUSH_PROMISE does). > > The advantages of this approach are: > > 1. It eliminates any possible confusion and complexity about when to > use HEADERS+PRIORITY vs. HEADERS > 2. It provides a single way of setting/change stream priority (as > opposed to using HEADERS+PRIORITY plus a separate CHANGE-PRIORITY > frame) > >
Received on Tuesday, 21 May 2013 16:33:22 UTC