W3C home > Mailing lists > Public > public-webappsec@w3.org > September 2016

Re: Quoted Referrer-Policy values

From: Mike West <mkwst@google.com>
Date: Wed, 7 Sep 2016 17:59:53 +0200
Message-ID: <CAKXHy=cMWMc_MDSd0LtPvp4T9g56cgz7m1SjWt3HeWNYQ_=LHQ@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: "Emily Stark (Dunn)" <estark@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Francois Marier <francois@mozilla.com>, Franziskus Kiefer <fkiefer@mozilla.com>
On Wed, Sep 7, 2016 at 5:32 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Wed, Sep 7, 2016 at 2:08 PM, Mike West <mkwst@google.com> wrote:
> > I think the more general question is how we'd like to define header
> syntax
> > going forward. The HTTP WG in the IETF seems less keen on JSON than I'd
> > originally thought (http://httpwg.org/http-extensions/jfv.html being
> more of
> > an indication that "Some structure would be nice!" rather than a ringing
> > endorsement of JSON in and of itself). Still, my impression is that JSON
> is
> > something that developers understand, and have lots of tooling to
> support.
>
> However, JSON on the web thus far is bound to UTF-8. In HTTP you'd be
> bound to code points in the range U+0000 to U+00FF, inclusive (with
> some whitespace and maybe control code point exceptions, unclear). So
> it's not a straightforward mapping nor could you use your normal
> serialization tools, etc.
>
> I tend to agree that HTTP should get a better story for header
> parsing, but if the HTTP WG is not behind this strategy and it has
> some complications, I'm not sure why we should try to push it through.
>

1. We're defining more headers than anyone else at the moment, so we should
probably have an opinion.

2. Quoting things is fairly agnostic; it leaves room for a number of more
structure options that barewords don't. It's also super low-cost. Seems
like a reasonable baby step.

-mike
Received on Wednesday, 7 September 2016 16:00:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:57 UTC