Re: Quoted Referrer-Policy values

On 8 September 2016 at 02:26, Anne van Kesteren <annevk@annevk.nl> wrote:
> Yeah, I don't think we can do it in isolation though. We should also
> figure out the parsing for existing headers and figure out some kind
> of holistic strategy. Just using JSON for headers we add (but not
> necessarily all, unless you have a plan for catching all new headers
> that get into browsers) might help, but unless there's agreement we
> can never get to the point where all existing headers are in some
> safelist and everything new gets parsed as JSON.


Here's how I understand the story here, and Anne was present for some
of this discussion, so it's pretty close to the above:

Header fields can define ANY grammar they like, including JSON.  Most
try to follow existing patterns for various reasons.

The HTTP working group is likely to start working on a more efficient
scheme.  That might be more holistic, but we don't know for sure.
Like Anne, I'd prefer that we try to have a broader plan than simply
taking advantage of the current mess and moving piecemeal.

Note that HTTP header fields are defined as being octets.  The fetch
spec (correctly) uses ByteString for these, which could almost allow
for arbitrary octets to be sent.  0xa and 0xd are unlikely to appear,
or be encoded, for similar reasons.  You might find that 0x00 doesn't
work though, for instance, if you use HTTP/2.  I don't have empirical
data on that though.

> Is quoted-string in HTTP case-insensitive? This probably shouldn't be
> if we want actual JSON.

Case-sensitivity is defined on a case-by-case basis.  Most
implementations will pass the octets if you ask for them, but some do
case-folding for some of their "high-level" APIs, for instance, where
cache-control is turned into an EnumSet/bitvector or the like.

Received on Friday, 9 September 2016 05:24:29 UTC