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


From: Manger, James H <James.H.Manger@team.telstra.com>
Date: Wed, 14 Aug 2013 16:24:52 +1000
To: Martin Thomson <martin.thomson@gmail.com>, James M Snell <jasnell@gmail.com>
CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <255B9BB34FB7D647A506DC292726F6E1152A7AA11A@WSMSG3153V.srv.dir.telstra.com>
> On 13 August 2013 02:21, James M Snell <jasnell@gmail.com> wrote:
> > I've been told that [HEADERS interleaving] wasn't an option and that
> > continuation frames MUST be contiguous...
> > although I personally don't buy it.
From: Martin Thomson [mailto:martin.thomson@gmail.com]
> As long as HEADERS depend on some sort of state, then it is easier to
> require exclusive access to that state (mutex style) rather than deal
> with potential concurrency issues.  Until it is proven otherwise, it
> might be reasonable to assume that any scheme permitting interleaving
> is only going to be more complicated than the current scheme.  I am, of
> course, happy to be shown a scheme that enables interleaving without
> increasing complexity.

A mutex on HEADERS state should not prevent interleaving with DATA on other streams.

Even a mutex feels unnecessary. Break a huge header (lots of name/value pairs) into parts (each part is still a collection of name/value pairs so it looks like a header); then send the parts using the compress-into-a-frame process. Now interleaving around a frame for a part has no more restrictions than interleaving around a frame for a complete header.

There is one extra complexity: to support single header name/value pairs that can't fit in a frame.

James Manger
Received on Wednesday, 14 August 2013 06:25:39 UTC

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