W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

Re: New Version Notification for draft-nottingham-site-wide-headers-01.txt

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 25 Nov 2016 13:21:16 +1100
Cc: Mike West <mkwst@google.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <E68A0643-97A4-447F-B59F-D3B66AE8BBEA@mnot.net>
To: Emily Stark <estark@google.com>

> 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.


Mark Nottingham   https://www.mnot.net/
Received on Friday, 25 November 2016 02:21:49 UTC

This archive was generated by hypermail 2.3.1 : Friday, 25 November 2016 02:21:51 UTC