No JSON in header value

[msramek]

Hi @mikewest !

Please have a look! This simplifies the header syntax from a JSON to a list of strings. One thing I wasn't sure how to do was how to refer to the parsing algorithm. The way I understand it, the ABNF definition itself already represents a parsing algorithm, so I just added s there and linked them below.

[mikewest]

Some quick thoughts, thanks for putting this together!

[mikewest]

I'd suggest something like:

Clear-Site-Data = 1#( <a>data-type-value</a> / <a>extension-type-value</a> )
<dfn>data-type-value</dfn> = "<dfn>cache</dfn>" / "<dfn>cookies</dfn>" / "<dfn>storage</dfn>" / "<dfn>executionContext</dfn>"
<dfn>extension-type-value</dfn> = 1*( <a>ALPHA</a> / "-" )

[msramek]

Updated, but with some changes:

-> From what I have read in other specs so far, the definition of a header always includes the key and separator (i.e. "Clear-Site-Data" ":"), not just the value
-> That's why I have the token "clear-site-data-value", which stands for the header value only
-> The "data-type" and "extension-type" tokens do not need the suffix "-value" (they represent the datatypes, not the header value as a whole, so the name is expressive enough)
-> I still think we need to specify OWS; I don't think spaces around tokens should be a syntax error
-> You suggested that alpha is wrapped in anchors; do you want it to link to RFC5234?

[mikewest]

-> From what I have read in other specs so far, the definition of a header always includes the key and separator (i.e. "Clear-Site-Data" ":"), not just the value

I'm following along with things like https://tools.ietf.org/html/rfc7231#section-3.1.2.2 here. I'm sure I've done it differently elsewhere, but this is what I think IETF folks have solidified upon for header ABNF.

-> The "data-type" and "extension-type" tokens do not need the suffix "-value" (they represent the datatypes, not the header value as a whole, so the name is expressive enough)

Sure.

-> I still think we need to specify OWS; I don't think spaces around tokens should be a syntax error

This is part of the # rule in https://tools.ietf.org/html/rfc7230#section-7 which we should be linking to. @annevk suggested elsewhere that we link to https://fetch.spec.whatwg.org/#abnf to make that clear.

-> You suggested that alpha is wrapped in anchors; do you want it to link to RFC5234?

Yes, please. Just copy/paste from https://github.com/w3c/webappsec-csp/blob/master/index.src.html#L101. :)

[msramek]

Ah, alright. I must have read something older then. Updated.

I'm now linking to 7230 for #rule, since it's more detailed (e.g. contains the discussion about OWS). That is helpful at least for a reader like myself.

[mikewest]

I'd replace these two sentences with something like [[#fetch-integration]] and [[#parsing]] describe how the Clear-Site-Data header is processed.

[mikewest]

Maybe something like The <a grammar>data-type-value</a> grammar defines an initial set of known data types which can be cleared using this API. Future versions ..., and then following it up with the list.

[mikewest]

I'd write this in terms of Fetch. That is:

1.  Let |data-types| be an empty list.

2.  Let |header| be the result of [=extracting header list values=] given `Clear-Site-Data`
    and |response|'s [=response/header list=].

3.  If |header| is `null`, return |data-types|.

4.  For each |type| in |header|:

    1.  If |type| matches the <a grammar>data-type-value</a> grammar, and |type| is not
        [=list/contained=] in |data-types|, then [=list/append=] |type| to |data-types|.

[annevk]

You should account for failure too (e.g., x x would be a value that leads to failure). Might also be clearer to call the return variable values rather than header.

[mikewest]

@annevk: The suggestion accounts for failure by adding |type| to |data-types| only if it matches the list of known keywords in data-type-value. Do you think we should do something more than that?

[annevk]

Then you wouldn't have to account for null either. But more importantly, you can't for each failure.

[mikewest]

I think we do have to account for null, because we can't for...each over null. But reading Fetch again, I see your point: step 2 and 4.2 of https://fetch.spec.whatwg.org/#extract-header-list-values can return failure. I guess we'd want to handle that in step 3 as well. Thanks!

[msramek]

Done. Agree with returning failure in level 3, this is what Chromium's implementation actually does (we print an error to the console, we don't just ignore it).

Clarifying question: Is it OK to omit the old step #1 which checked if the header exists? Because if we run the current version of the algorithm on any random response, it will return failure. My interpretation of that would be that the browser outputs a console error every time it doesn't see a Clear-Site-Data header. Or is it assumed from the context that the algorithm is only executed for responses that do have the header?

[mikewest]

Done. Agree with returning failure in level 3, this is what Chromium's implementation actually does (we print an error to the console, we don't just ignore it).

I'd actually suggest changing this to something like "If |header| is `null` or failure, return an empty list.", and adding a note that user agents should inform developers of failure to parse the header. If you "return failure", then you need to handle "failure" in https://w3c.github.io/webappsec-clear-site-data/#clear-response instead. I think it makes more sense to handle it here by returning an empty list, which means the clearing operation will just do the right thing (nothing).

[mikewest]

Clarifying question: Is it OK to omit the old step #1 which checked if the header exists?

Step 1 of https://fetch.spec.whatwg.org/#extract-header-list-values does this check, and returns null, in which case we return an empty list.

[msramek]

Makes sense. Thanks for the explanation! Done.

[mikewest]

Left some small comments, thanks!

[mikewest]

LGTM. I'll rebuild the file for you in a subsequent patch.