- From: Lucas Pardue <lucaspardue.24.7@gmail.com>
- Date: Fri, 9 Aug 2019 11:08:52 +0100
- To: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, Matthew Kerwin <matthew@kerwin.net.au>, Brad Lassey <lassey@chromium.org>, Dmitri Tikhonov <dtikhonov@litespeedtech.com>
- Message-ID: <CALGR9oYvjcAnsYr+ZqxZCSidLbidf5n31pvTTe8NgnQkd5r_Ng@mail.gmail.com>
On Fri, Aug 9, 2019 at 6:27 AM Kari Hurtta <hurtta-ietf@elmme-mailer.org> wrote: > > < ⋯ > > > > > 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 > > I'd treat both options as a class of change that RFC 7540 says MUST be negotiated: Extensions that could change the semantics of existing protocol components MUST be negotiated before being used. For example, an extension that changes the layout of the HEADERS frame cannot be used until the peer has given a positive signal that this is acceptable. Changing frame flags relies on implementations both understanding the flag and its meaning, which is difficult to do in an uncoordinated and robust way. For example, adding a field and setting a flag that no one knows to check will likely result in extant HEADERS frame parsers detecting a . size error, resulting in a connection error. That's pretty high risk. Lucas
Received on Friday, 9 August 2019 10:09:26 UTC