- From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Date: Fri, 9 Aug 2019 08:26:49 +0300 (EEST)
- To: HTTP Working Group <ietf-http-wg@w3.org>
- CC: Kari Hurtta <hurtta-ietf@elmme-mailer.org>, Matthew Kerwin <matthew@kerwin.net.au>, HTTP Working Group <ietf-http-wg@w3.org>, Lucas Pardue <lucaspardue.24.7@gmail.com>, Brad Lassey <lassey@chromium.org>, Dmitri Tikhonov <dtikhonov@litespeedtech.com>
> < ⋯ > > > > In Montreal we also discussed a possible experiment where the H2 PRIORITY > > > frame contents would be repurposed, which requires a compatible server to > > > read it correctly. In this case the signal would be more like "will send in > > > an RFC7540-incompatible format". > > Yes, it makes sense to allocate new type number for PRIORITY when frame > content is repurposed. > > Also is make sense to allocate new type number for HEADERS when > "Stream Dependency" or "Weight" field of HEADERS frame conrent is repurposed. > > That avaind dance about on what point on time change of "Stream Dependency" / "Weight" field" > field happens. Then there is also third possibility: Invent new field for new stype priority information (say "PRIORITY2"). Indicate presense of PRIORITY2 field with (currently) reserved bit from Flags field (which is on part 9-octet header of all frames). There is unused flags bit available for both HEADERS and PRIORITY frame. And fourth possibility is indicate repurpose of current "Stream Dependency" / "Weight" field" with (currently) reserved bit from Flags field. These possibilities also avoid dance on what point on time change of "Stream Dependency" / "Weight" field" field happens. / Kari Hurtta
Received on Friday, 9 August 2019 05:27:26 UTC