- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 25 Nov 2016 13:21:16 +1100
- To: Emily Stark <estark@google.com>
- Cc: Mike West <mkwst@google.com>, HTTP Working Group <ietf-http-wg@w3.org>
> On 25 Nov. 2016, at 3:08 am, Emily Stark <estark@google.com> wrote: > > > > On Thu, Nov 24, 2016 at 2:10 AM, Mark Nottingham <mnot@mnot.net> wrote: >> One other thing -- >> >> If we take an approach that doesn't allow fallback to headers for new features, it's going to be important to get broad buy-in from implementers. Otherwise, it'll raise the friction for those new features. >> >> For example, if Expect-CT were to adopt it, and browsers were now required to make an extra fetch to implement the spec, some might not like that, and resist implementing it. > > A feature could always define its own fallback to headers, couldn't it? It could, but doing so would raise implementation cost; either on the client side (requiring clients that support the JSON form to also always support the header form, always, or the server side (requiring sites to always host the JSON and send the headers, unless the client says it has the JSON). Putting the requirement on the client probably makes more sense (they're less diverse), but then if you want to take advantage of the JSON syntax, you'd have two parsers, and the possibility of divergence in their behaviour. None of this is a deal killer IMO, just worth noting. Once the JSON format enjoys wide adoption in browsers, new features can stop specifying the header fallbacks. If that takes a long time, or never completes (e.g., one browser decides not to do the JSON), it'd be a suboptimal outcome. Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Friday, 25 November 2016 02:21:49 UTC