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


From: (wrong string) 陈智昌 <willchan@chromium.org>
Date: Wed, 27 Feb 2013 11:58:54 -0800
Message-ID: <CAA4WUYjRbeGd-TDjB5mTseVXAHhVEWvY2rJgS5-SyHG-+=D_Gw@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Roberto Peon <grmocg@gmail.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
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

> 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.
Received on Wednesday, 27 February 2013 19:59:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:08 UTC