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

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

From: James M Snell <jasnell@gmail.com>
Date: Fri, 26 Apr 2013 13:43:14 -0700
Message-ID: <CABP7RbeAb71vTmnGbR65wVepyT=WykdRcRNFYDuWoprWD7+2gg@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:10 UTC