Re: SYN_REPLY

It sounds like we're roughly back to keeping SYN_STREAM (which is basically HEADERS with a priority) and ditching SYN_REPLY for HEADERS.

I'm on board with this.  

-Hasan


On Wednesday, February 27, 2013 at 2:58 PM, William Chan (陈智昌) wrote:

> I'm fine with this but there are details that need to be covered in the spec. When a stream starts, the client MUST use the HEADERS+PRIORITY frame. Otherwise, we need to spec out what happens when you have some streams with unspecified priority and some streams with specified priority. I'd rather just mandate we always include the priority. For clients which don't care about priority, always pick the same arbitrary value.
>  
> PS: I raised a minor point earlier about possibly allowing bidirectional server initiated streams. I don't feel strongly about it, and if an actual use case arises, I'm happy to re-raise later.  
>  
>  
> On Wed, Feb 27, 2013 at 11:51 AM, Martin Thomson <martin.thomson@gmail.com (mailto:martin.thomson@gmail.com)> wrote:
> > OK, here's where I think we're at, in concrete terms:
> >  
> > We have a HEADERS frame.
> > We have a HEADERS+PRIORITY frame that includes an extra 4 bytes up front.
> >  
> > Either can be sent in all the normal places that you would expect to
> > see HEADERS, SYN_STREAM or SYN_REPLY.  Most importantly, when a stream
> > starts.
> >  
> > Pushed streams are unidirectional by virtue of being initiated by the
> > server, not by explicit indication.  The server does not expect data
> > frames from the client and MAY discard them.
>