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

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