Subject: Re: [quicwg/base-drafts] Single stream for headers and body (#245)

From: krasic <[email-masked]>
Date: Mon, 26 Jun 2017 15:05:34 -0700

Friendly bump.  

One of the problems with single stream was keeping HPACK state synchronized in the face of stream resets.   The latest QPACK solves it neatly by putting all HPACK updates on a static stream, and reference-only headers on the HTTP stream.   I think this can work for (nearly-)legacy HPACK and QCRAM too.

On the other hand, with the two stream per HTTP exchange regime, we've not heard a good simple solution to support the case of interleaving response data with PUSH_PROMISEs.  The PUSH_PROMISE ordering requirement is just a SHOULD, but it seems pretty lame to not do better.

It would be good to get this resolved as soon as possible (Prague?) because it has significant implementation implications.  My vote would be to switch back to single stream, with the tweak'd HPACK that puts updates on the static stream.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/245#issuecomment-311195427

---

From: ianswett <[email-masked]>
Date: Mon, 26 Jun 2017 15:24:50 -0700

I would support moving towards a single stream, given all the recent pros and cons of 1 vs 2 stream models I've heard.

The request-response paradigm is nice, and if the only cost is some framing, I think it's worth it.  My only real concern about the 1 stream model before was the ability to reset a stream, but if that's been solved(or will be), 1 stream seems better.

The fact it works better for push is a perk, as well as an indication it may be a better architectural approach in general.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/245#issuecomment-311199265