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

Re: SYN_REPLY

From: Roberto Peon <grmocg@gmail.com>
Date: Wed, 27 Feb 2013 10:45:23 -0800
Message-ID: <CAP+FsNfp=wtRVR0dQVe_YcPp0yzQU545THv5byObRdsyOUwPSg@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: (wrong string) ™ˆ™˜Œ) <willchan@chromium.org>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
The we're wasting bytes on responses. Bleh. Worse, now we can't simply
examine the length field to figure out what to do. Double-eww.
In any case, spending a bit in the flags, is far more costly than spending
the fractional bit out of the opcode space, which is what is done today!

Something I could go with, given the previous change would be to also
change the name of SYN_STREAM to HEADERS_WITH_PRIO
and leave HEADERS as it is.

How does that sound?


-=R


On Wed, Feb 27, 2013 at 10:20 AM, Martin Thomson
<martin.thomson@gmail.com>wrote:

> On 26 February 2013 20:16, Roberto Peon <grmocg@gmail.com> wrote:
> > Taking the priority out of SYN_STREAM would only bloat things on the
> wire,
> > since the client will always want to state priority for a new stream. I
> > don't support removing priority from SYN_STREAM.
>
> What if HEADERS contained priority?  Is your objection to removing
> priority from SYN_STREAM, or removing priority from the first frame in
> the stream.
>
> Here's a more concrete proposal, albeit slightly radical.
>
> Remove SYN_STREAM and SYN_REPLY.
> Have stream-level flags that appear in ALL messages.
>  1. last frame in stream (the existing FIN bit)
>  2. stream priority (a new one)
> The 'stream priority' flag indicates that the first 4 bytes of the
> frame payload includes a priority.  This should (or SHOULD) be set on
> the first frame of any stream.
>
> Then a typical stream looks like:
>  - a HEADERS frame with the 'stream priority' flag set, plus a priority
>  - a bunch of data frames
>  - maybe some other frames
>
Received on Wednesday, 27 February 2013 18:45:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 February 2013 18:45:53 GMT