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

From: James M Snell <[email-masked]>
Date: Fri, 26 Apr 2013 11:47:37 -0700

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?)

---

From: Martin Thomson <[email-masked]>
Date: Fri, 26 Apr 2013 13:12:58 -0700

The requirement for HEADERS+PRIORITY should only apply to the HTTP
request/response exchange, not everything.  Tier 3 and all that.

---

From: James M Snell <[email-masked]>
Date: Fri, 26 Apr 2013 13:43:14 -0700

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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 26 Apr 2013 13:49:32 -0700

> reliable way that I can interpret it without additional context, then

I believe that this is exactly the scenario that the websockets
binding will take advantage of.  (Maybe there is some need to expose
some header information there, but that's a case that needs to be made
for that specific use of the framing layer.)

---

From: James M Snell <[email-masked]>
Date: Fri, 26 Apr 2013 13:54:16 -0700

Well, until that case is made, we don't have very many good reasons to
allow DATA frames with preceding headers-bearing frames. Also, keep in
mind that it's perfectly legal to send a HEADERS frame with an empty
set of HEADERS. It the WebSockets case does not require any preceding
headers (which I rather doubt), it would still be simple enough to
send an empty HEADERS frame to establish the stream before sending the
DATA frames.

---

From: Roberto Peon <[email-masked]>
Date: Sat, 27 Apr 2013 14:44:00 -0700

The WS case may actually require headers as we do need to announce (per WS
'connection') the URL of the endpoint to which it is attaching/connecting.
-=R

---

From: James M Snell <[email-masked]>
Date: Sat, 27 Apr 2013 23:17:51 -0700

Minor correction on my note... I meant to say we don't really seem to have
a good reason to allow data frames *without* preceding header bearing
frames.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Sun, 28 Apr 2013 14:54:05 -0700

My connection is spotty right now in Buenos Aires, or else I'd pull up the
websocket over spdy proposal from the Google team and also the
spdy-dev@discussion on it. In all cases, a SPDY SYN_STREAM (now HTTP/2
HEADERS+PRIORITY) was used to initiate the stream. I think Roberto's right
about announcing the endpoint (requires the full URL, due to connection
sharing, scheme, and path). I think it's reasonable to require a stream
creation frame (HEADERS+PRIORITY or HEADERS) for each stream before data is
sent.

On Sat, Apr 27, 2013 at 11:17 PM, James M Snell <[email-masked]> wrote:

>> The WS case may actually require headers as we do need to announce (per
>> WS 'connection') the URL of the endpoint to which it is
>> attaching/connecting.
>> -=R
>>
>>