- From: Martin Thomson <mt@lowentropy.net>
- Date: Mon, 30 Aug 2021 13:18:00 +1000
- To: ietf-http-wg@w3.org
On Fri, Aug 27, 2021, at 16:28, Julian Reschke wrote:
> Which of course leads us to the question about how this format could in
> theory be extended in the future in a backwards-compatible way.
I think that the most sensible approach is to give up on forward-compatibility and define a new format. Given the likelihood that we uniformly define midlers (or midders or whatever[1]) across the live protocols, that seems like a fairly safe bet. The alternative is to carry something that exists just on the off chance we'd need it later, which I think is a good way to guarantee that the extension point will be broken when we get around to needing it[2].
On the general topic of extensibility, adding fields is a well-trodden path that could get us a long way (see also below).
> > This I think we can accommodate. Other pseudo header fields can be added as if they were regular fields, using the same rules as h2. That is, pseudo header fields go first. Should that be documented?
>
> I guess so (although I'm not a fan of that extension point :-).
I was similarly not a fan. I'm now somewhat more accepting of it, given that pseudo-fields are where the protocol as a whole ended up going.
Conveniently, I already had text on that, so I think we're good:
Pseudo-fields that are defined by protocol extensions MAY be included. Field lines containing pseudo-fields MUST precede other field lines; a message that contains a pseudo-field after any other field is invalid; see {{invalid}}.
[1] For some reason, "midders" and "Scabbers" (Ron Weasley's rat familiar from Harry Potter) are inextricably linked in my mind.
[2] See https://intarchboard.github.io/draft-use-it-or-lose-it/draft-iab-use-it-or-lose-it.html
Received on Monday, 30 August 2021 03:18:39 UTC