RE: SYN_REPLY

Also +1.

And I find that calling SYN_STREAM HEADERS+PRIORITY restore some of the symmetry we lost with SYN_REPLY.

Hervé.

> -----Original Message-----
> From: Amos Jeffries [mailto:squid3@treenet.co.nz]
> Sent: jeudi 28 février 2013 04:26
> To: ietf-http-wg@w3.org
> Subject: Re: SYN_REPLY
> 
> On 28/02/2013 10:12 a.m., Hasan Khalil wrote:
> > 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.
> >
> 
> +1. Same here for those changes.
> 
> > -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.
> 
> I disagree on the need for server-initiated streams, Push can work fine
> without turning HTTP semantics into BEEP semantics. But that is a side issue I
> think we will discuss later or elsewhere.
> 
> Amos

Received on Thursday, 28 February 2013 17:23:56 UTC