Re: Design Issue: HEADERS+PRIORITY "MUST be used" for each stream that is created??

I think I disagree on that point and say that I think it's much safer
if we require that streams be initiated with only headers-bearing
frames.

Imagine, for instance, that a sender sends along a DATA frame with a
new, previously unused stream identifier. Without an associated
headers frame I have absolutely no context with which to determine
what I need to do with that DATA frame. Likewise if I receive an
RST_STREAM that references a previously unused stream identifier. If
there's absolutely nothing that I can reliably do with it, or not
reliable way that I can interpret it without additional context, then
we should not allow it.

- James

On Fri, Apr 26, 2013 at 1:12 PM, Martin Thomson
<martin.thomson@gmail.com> wrote:
> The requirement for HEADERS+PRIORITY should only apply to the HTTP
> request/response exchange, not everything.  Tier 3 and all that.
>
> On 26 April 2013 11:47, James M Snell <jasnell@gmail.com> wrote:
>> In the current draft (-02), under the definition of HEADERS+PRIORITY,
>> we say that the frame "MUST be used for each stream that is created"..
>>
>> Is this really true? This is inconsistent with other parts of the spec...
>>
>> Elsewhere we say that streams are created by sending any frame that
>> references an unused stream ID.
>>
>> We also say that PUSH_PROMISE frames are followed up by a HEADERS
>> frame (not HEADERS+PRIORITY).
>>
>> I believe the intent here is that streams ought only to be created
>> when sending a HEADERS, HEADERS+PRIORITY or PUSH_PROMISE frame that
>> references an unused stream ID.
>>
>> A DATA frame that references a previously unused Stream ID ought to
>> result in a PROTOCOL_ERROR.
>>
>> (which brings up an interesting question: what happens if I receive an
>> RST_STREAM that references a previously unused stream id? Based on the
>> rules so far, that would mean the stream ID would be closed before
>> there is ever a chance to use it... possible DOS vector?)
>>

Received on Friday, 26 April 2013 20:44:01 UTC