- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 7 Oct 2021 11:41:12 +1100
- To: Lucas Pardue <lucaspardue.24.7@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
> On 7 Oct 2021, at 11:06 am, Lucas Pardue <lucaspardue.24.7@gmail.com> wrote: > > My question was also loaded towards the segment of people that use HTTP and never put it in an open spec because they have no need for broad interop. For example, if x-custom-thing was used between internal services then there could be benefit in trying to align all header handling towards structured headers without having to go and think hard about writing a spec about it. Trying to define some generic framework for those folks is likely going to fail so the I-D does right to avoid that trap. But a clear statement along the lines of "the approaches in this document could be applied to other HTTP fields" might stop a team bickering about the practicalities of such a switch. I think it depends very much on what they want to use it for. For example, my primary use case is binary encoding of headers, but that has an explicit fallback mechanism to use if the field doesn't parse as SF successfully. So it's effectively transparent. Likewise for a Fetch extension that allowed some headers to be manipulated as SF; as long as the string-based API were still available, nothing should break just because the SF API is introduced and used for some fields. If OTOH someone with, say, a HTTP API exposed to customers suddenly starts treating an incoming field as SF when it was previously defined more loosely, some things are likely to break. With that context, I agree. I'll try to expand the doc along these lines, sort of an applicability statement. Thanks! -- Mark Nottingham https://www.mnot.net/
Received on Thursday, 7 October 2021 00:41:29 UTC