- 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>
> 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