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

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 <jasnell@gmail.com> wrote:

> 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.
> On Apr 27, 2013 2:44 PM, "Roberto Peon" <grmocg@gmail.com> 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
>>
>>
>> On Fri, Apr 26, 2013 at 1:54 PM, James M Snell <jasnell@gmail.com> wrote:
>>
>>> 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.
>>>
>>>
>>> On Fri, Apr 26, 2013 at 1:49 PM, Martin Thomson
>>> <martin.thomson@gmail.com> wrote:
>>> > On 26 April 2013 13:43, James M Snell <jasnell@gmail.com> wrote:
>>> >> 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.
>>> >
>>> > 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.)
>>>
>>>
>>