Re: SYN_REPLY

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
delta-coding.)

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