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


From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 21 Feb 2013 15:34:01 -0800
Message-ID: <CABkgnnUc4C2wTKX9naV9Ver7H9gTnqP84n_8+3QKDRXFyP04jA@mail.gmail.com>
To: Roberto Peon <grmocg@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Yes, SYN_STREAM has the priority.

The point is that if you just start using streams (as you do), then a
stream "start" message is only necessary if there are once-only things
to say about the stream.  By that measure, SYN_REPLY has no value.

You wanted to reprioritize, so maybe you could just define PRIORITIZE.
 A stream would optionally start with PRIORITIZE and then HEADERS.
That would be enough.  The response could just use HEADERS.

(On an tangentially related point, I don't see how we could have a
single header with a value that spans two frames in the current
scheme, perhaps you can keep this in mind when you propose an edit for

On 21 February 2013 15:11, Roberto Peon <grmocg@gmail.com> wrote:
> or rather, it doesn't have one, but the former follows from this :)
> -=R
> On Thu, Feb 21, 2013 at 3:11 PM, Roberto Peon <grmocg@gmail.com> wrote:
>> The SYN_REPLY doesn't need a priority field.
>> -=R
>> On Thu, Feb 21, 2013 at 3:04 PM, Martin Thomson <martin.thomson@gmail.com>
>> wrote:
>>> I'm looking at the HTTP/2.0 streaming layer and it's not clear to me
>>> what value SYN_REPLY adds.
>>> SYN_STREAM establishes priority for a stream (and that's all!).
>>> SYN_REPLY doesn't have the power of refusal, that's what RST_STREAM is
>>> for.
>>> There's no need to have a special declaration that a stream is
>>> starting, the first message on a stream should be a clear enough
>>> indication of that.
>>> It does carry headers, but HEADERS does a bang-up job of that.  In all
>>> other respects, SYN_REPLY and HEADERS are identical.
>>> Do we even need the SYN_REPLY frame type?
Received on Thursday, 21 February 2013 23:34:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:10 UTC