W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

RE: SYN_REPLY

From: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
Date: Thu, 28 Feb 2013 17:22:04 +0000
To: Amos Jeffries <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <6C71876BDCCD01488E70A2399529D5E5163E0B9C@ADELE.crf.canon.fr>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 28 February 2013 17:23:58 GMT