- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Fri, 25 Nov 2016 12:08:31 +1100
- To: Mark Nottingham <mnot@mnot.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, Mike West <mkwst@google.com>, "Emily Stark (Dunn)" <estark@google.com>
On 24 November 2016 at 16:40, Mark Nottingham <mnot@mnot.net> wrote: > I sketched in a whitelist because site-wide headers are the exception, not the rule, and the designer of the header should really opt into it. Requiring a known prefix and whitelisting existing headers gives you that. I don't see much value in them then. As I said, sites are perfectly capable of generating rubbish. Add that to the bad taste that having people claim large swathes of the header field name space leaves if you like. >> You don't describe the consequences if someone puts a Date header >> field in a site-wide resource. You only say not to. > > Where do I say not to? By saying that the header field has to be on the whitelist, you implicitly forbid inclusion of other header fields. But you don't define rules for what to do if you see a header field that is not on the whitelist. Do you throw out the whole .wk resource? > It says append. I suppose I could monkey-patch Fetch, if there's interest. Although in many ways, this kind of happens at a layer "below" Fetch. Append works for me, but you aren't clear enough. And I think that you will find that Fetch (or is it just fetch?) wants control over this stuff.
Received on Friday, 25 November 2016 01:09:04 UTC