Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No JSON in header value #17

Merged
merged 3 commits into from
Mar 23, 2017
Merged

No JSON in header value #17

Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
6b2f9b1
No JSON in header.
msramek Mar 22, 2017
c751de3
Updated the ABNF definition and parsing algorithm.
msramek Mar 23, 2017
99507b6
Improved the ABNF definition, fixed the failure mode in parsing.
msramek Mar 23, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
116 changes: 41 additions & 75 deletions index.src.html
View file
Original file line number Diff line number Diff line change
@@ -27,6 +27,7 @@ <h1>Clear Site Data</h1>
text: response; url: concept-response
text: header list; for: response; url: concept-header-list
text: HTTP-network fetch; url: http-network-fetch;
text: extracting header list values
type: interface
text: Request; url: concept-request
type: attribute
@@ -153,9 +154,6 @@ <h1>Clear Site Data</h1>
text: token; url: section-3.2.6
text: quoted-string; url: section-3.2.6
text: #rule; url: section-7
spec: HTTP-JFV; urlPrefix: https://greenbytes.de/tech/webdav/draft-ietf-httpbis-jfv-02.html
type: grammar
text: json-field-value; url: rfc.section.2
spec: PSL; urlPrefix: https://publicsuffix.org/list/
type: dfn
text: registered domain; url: #
@@ -168,11 +166,6 @@ <h1>Clear Site Data</h1>
"title": "Secure Contexts",
"publisher": "W3C"
},
"HTTP-JFV": {
"authors": [ "Julian Reschke" ],
"href": "https://greenbytes.de/tech/webdav/draft-ietf-httpbis-jfv-02.html",
"title": "A JSON Encoding for HTTP Header Field Values"
},
"CHANNELID": {
"authors": [ "Dirk Balfanz", "Ryan Hamilton" ],
"href": "https://tools.ietf.org/html/draft-balfanz-tls-channelid",
@@ -240,7 +233,7 @@ <h4 id="example-signout">Signing Out</h4>
They can do so by sending the following HTTP header in the response:

<pre>
<a>Clear-Site-Data</a>: { "<a>types</a>": [ "<a>cache</a>", "<a>cookies</a>", "<a>storage</a>", "<a>executionContexts</a>" ] }
<a>Clear-Site-Data</a>: <a>cache</a>, <a>cookies</a>, <a>storage</a>, <a>executionContexts</a>
</pre>
</div>

@@ -276,7 +269,7 @@ <h4 id="example-targeted">Targeted Clearing</h4>
preflight, and would return the following header for the actual request:

<pre>
<a>Clear-Site-Data</a>: { "<a>types</a>": [ "<a>cache</a>", "<a>cookies</a>", "<a>storage</a>", "<a>executionContexts</a>" ] }
<a>Clear-Site-Data</a>: <a>cache</a>, <a>cookies</a>, <a>storage</a>, <a>executionContexts</a>
</pre>
</div>

@@ -293,7 +286,7 @@ <h4 id="example-keepcookies">Keep Critical Cookies</h4>
includes all the types except for "<a>cookies</a>":

<pre>
<a>Clear-Site-Data</a>: { "<a>types</a>": [ "<a>cache</a>", "<a>storage</a>", "<a>executionContexts</a>" ] }
<a>Clear-Site-Data</a>: <a>cache</a>, <a>storage</a>, <a>executionContexts</a>
</pre>
</div>

@@ -311,7 +304,7 @@ <h4 id="example-killswitch">Kill Switch</h4>
following HTTP header in a response to wipe out local sources of data:

<pre>
<a>Clear-Site-Data</a>: { "<a>types</a>": [ "<a>cache</a>", "<a>cookies</a>", "<a>storage</a>", "<a>executionContexts</a>" ] }
<a>Clear-Site-Data</a>: <a>cache</a>, <a>cookies</a>, <a>storage</a>, <a>executionContexts</a>
</pre>

Note: Installing a Service Worker guarantees that a request will go out to
@@ -352,34 +345,20 @@ <h3 id="header">
[[!RFC5234]]:

<pre class="abnf" link-type="grammar" dfn-type="grammar">
Report-To = <a>json-field-value</a>
; See Section 2 of [[HTTP-JFV]], and Section 2 of [[RFC7159]]
Clear-Site-Data = "Clear-Site-Data" ":" <a>clear-site-data-value</a>
<dfn>clear-site-data-value</dfn> = OWS 1#((<a>data-type</a> | <a>extension-type</a>) OWS)
<dfn>data-type</dfn> = "<dfn>cache</dfn>" | "<dfn>cookies</dfn>" | "<dfn>storage</dfn>" | "<dfn>executionContext</dfn>"
<dfn>extension-type</dfn> = 1*(ALPHA | "-")
</pre>

The header's value is interpreted as an array of JSON objects, as described in
Section 4 of [[HTTP-JFV]].

Each object in the array represents a clearing action that the user agent MUST
undertake, and will be parsed as defined in [[#parsing]].

The following subsections defined the initial set of known members in each
JSON object the header's value defines. Future versions of this document may
define additional such members, and user agents MUST ignore unknown members
when parsing the header.

<h4 id="types-member">
The `types` member
</h4>
[[#fetch-integration]] and [[#parsing]] describe how the
<a>Clear-Site-Data</a> header is processed.

The <dfn>`types`</dfn> member is an array of keywords designating the kinds
of data that the server wishes the user agent to remove. The member's value
MUST be an array, and that array MUST contain only strings; any other types
will result in a parse error.

The following are the initial set of known types which may be specified in
the member's array value. Future versions of this document may define
additional types, and user agents MUST ignore unknown types when parsing the
header:
The <a grammar>data-type</a> grammar defines an initial set of known data
types which can be cleared using this API. See their descriptions below.
Future versions of the header can support additional datatypes, which MUST
comply with the <a grammar>extension-type</a> grammar. User agents MUST
ignore unknown <a grammar>extension-type</a>s whhen parsing the header.

: "<dfn>`cache`</dfn>"
:: The "`cache`" type indicates that the server wishes to remove locally
@@ -397,7 +376,7 @@ <h4 id="types-member">
`https://example.com`: to be cleared:

<pre>
<a>Clear-Site-Data</a>: { "<a>types</a>": [ "<a>cache</a>" ] }
<a>Clear-Site-Data</a>: <a>cache</a>
</pre>
</div>

@@ -416,7 +395,7 @@ <h4 id="types-member">
`https://example.com` to be cleared:

<pre>
<a>Clear-Site-Data</a>: { "<a>types</a>": [ "<a>cookies</a>" ] }
<a>Clear-Site-Data</a>: <a>cookies</a>
</pre>
</div>

@@ -436,7 +415,7 @@ <h4 id="types-member">
`https://example.com` to be cleared:

<pre>
<a>Clear-Site-Data</a>: { "<a>types</a>": [ "<a>storage</a>" ] }
<a>Clear-Site-Data</a>: <a>storage</a>
</pre>
</div>

@@ -453,7 +432,7 @@ <h4 id="types-member">
`https://example.com` to be neutered and reloaded:

<pre>
<a>Clear-Site-Data</a>: { "<a>types</a>": [ "<a>executionContexts</a>" ] }
<a>Clear-Site-Data</a>: <a>executionContexts</a>
</pre>
</div>

@@ -474,9 +453,7 @@ <h3 id="dom-api">JavaScript API</h3>
current origin:

<pre>
navigator.storage.<a method>clear</a>({
<a dict-member>types</a>: [ "cache" ],
});
navigator.storage.<a method>clear</a>([ "cache" ]);
</pre>
</div>

@@ -488,24 +465,21 @@ <h3 id="dom-api">JavaScript API</h3>
"executionContexts"
};

dictionary StorageClearOptions {
required sequence&lt;StorageClearType&gt; types;
};
typedef sequence&lt;StorageClearType&gt; StorageClearTypes;

partial interface StorageManager {
Promise&lt;void&gt; clear(StorageClearOptions options);
Promise&lt;void&gt; clear(StorageClearTypes types);
};
</pre>
<dl dfn-for="StorageManager">
<dt><dfn method lt="clear(options)">clear(options)</dfn></dt>
<dt><dfn method lt="clear(types)">clear(types)</dfn></dt>
<dd>
Clears data based on the values in the |options| argument.
Clears data based on the values in the |types| argument.
Returns a Promise that resolves when clearing is complete. If no
{{StorageClearOptions/types}} are specified, all data types will be
cleared.
types are specified, all data will be cleared.

<pre class="argumentdef" for="StorageManager/clear(options)">
options: The data to clear.
<pre class="argumentdef" for="StorageManager/clear(types)">
types: The data types to clear.
</pre>
</dd>
</dl>
@@ -531,7 +505,7 @@ <h3 id="fetch-integration">Fetch Integration</h3>

Note: While the fetch `credentials flag` is intended to restrict the
modification of cookies, <a>`Clear-Site-Data`</a> applies the same restriction
to all <a>types</a> for the sake of consistency.
to all types for the sake of consistency.
<section>

<section>
@@ -543,26 +517,19 @@ <h4 id="get-types">
Which data types ought to be removed for |response|?
</h4>

1. If |response| does not contain a <a>`Clear-Site-Data`</a> header, return
an empty list.

2. Let |types| be an empty list.

3. Let |list| be the result of executing the algorithm defined in Section 4
of [[!HTTP-JFV]] on the value of |response|'s <a>`Clear-Site-Data`</a>
header. If that algorithm results in an error, return an empty list.
1. Let |types| be an empty list.

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

1. If |item| does not have a <a>`types`</a> member, skip to the next
|item|.
3. If |header| is `null`, return failure.

2. For each |type| in |item|'s <a>`types`</a> member's value:
4. For each |type| in |header|:

1. If |type| is <a>`cache`</a>, <a>`cookies`</a>, <a>`storage`</a>,
or <a>`executionContexts`</a>, append |type| to |types|.
1. If |type| is <a>`cache`</a>, <a>`cookies`</a>, <a>`storage`</a>,
or <a>`executionContexts`</a>, append |type| to |types|.

Otherwise, skip to the next |type|.
Otherwise, skip to the next |type|.

5. Return |types|.

@@ -594,10 +561,10 @@ <h3 id="clear-response">
timeline entry indicating success.

<h3 id="clear-api">
Clear data for |options|
Clear data for |types|
</h3>

Given a {{StorageClearOptions}} (|options|), this algorithm
Given a {{StorageClearTypes}} (|input-types|), this algorithm
determines what needs to be cleared, returns a Promise, and executes the
request asynchronously.

@@ -611,14 +578,13 @@ <h3 id="clear-api">

4. Let |types| be an empty list.

5. If |options|' {{StorageClearOptions/types}} is an empty sequence:
5. If |input-types| is an empty sequence:

1. Append `cache`, `cookies`,
`storage`, and `executionContexts` to
|types|.

6. Otherwise, for each {{StorageClearType}} |type| in
|options|' {{StorageClearOptions/types}} property:
6. Otherwise, for each {{StorageClearType}} |type| in |input-types|:

1. Append |type| to |types|.