Code change:
origin and passes the CORS check (https://fetch.spec.whatwg.org/#cors-check). <del> 9.3.2.1. </del> <ins> 9.3.3. </ins> <del> On the client-side, same-origin determination is defined in the fetch spec (https://html.spec.whatwg.org/multipage/browsers.html#origin). </del> <ins> As with any usage of compressed content in a secure context, a potential timing attack exists if the attacker can control any part of the dictionary, or if it can read the dictionary and control any part of the content being compressed, while performing multiple requests that vary the dictionary or injected content.  Under such an attack, the changing size or processing time of the response reveals information about the content, which might be sufficient to read the supposedly secure response. </ins> <del> On the server-side, a request with a "Sec-Fetch-Site:" request header with a value of "same-origin" is to be considered a same-origin request. </del> <ins> In general, a server can mitigate such attacks by preventing variations per request, as in preventing active use of multiple dictionaries for the same content, disabling compression when any portion of the content comes from uncontrolled sources, and securing access and control over the dictionary content in the same way as the response content.  In addition, the following requirements on a server are intended to disable dictionary-aware compression when the client provides CORS request header fields that indicate a cross- origin request context. </ins> <del> For any request that is same-origin: </del> <ins> The following algorithm will return FALSE for cross-origin requests where precautions such as not using dictionary-based compression should be considered: </ins> <del> Response MAY be used as a dictionary. </del> <ins> If there is no "Sec-Fetch-Site" request header then return TRUE. </ins> <del> Response MAY be compressed by an available dictionary. </del> <ins> if the value of the "Sec-Fetch-Site" request header is "same- origin" then return TRUE. </ins> <del> 9.3.2.2. </del> <ins> If there is no "Sec-Fetch-Mode" request header then return TRUE. </ins> <del> For requests that are not same-origin (same-origin), the "mode" of the request can be used to determine the readability of the response. </del> <ins> If the value of the "Sec-Fetch-Mode" request header is "navigate" or "same-origin" then return TRUE. </ins> <del> For clients that conform to the fetch spec, the mode of the request is stored in the RequestMode attribute of the request (https://fetch.spec.whatwg.org/#requestmode). </del> <ins> If the value of the "Sec-Fetch-Mode" request header is "cors": </ins> <del> For servers responding to clients that expose the request mode information, the value of the mode is sent in the "Sec-Fetch-Mode" request header. </del> <ins> If the response does not include an "Access-Control-Allow- Origin" response header then return FALSE. </ins> <del> If a "Sec-Fetch-Mode" request header is not present, the server SHOULD allow for the dictionary compression to be used. </del> <ins> If the request does not include an "Origin" request header then return FALSE. </ins> <del> If the mode is "navigate" or "same-origin": </del> <ins> If the value of the "Access-Control-Allow-Origin" response header is "*" then return TRUE. </ins> <del> Response MAY be used as a dictionary. </del> <ins> If the value of the "Access-Control-Allow-Origin" response header matches the value of the "Origin" request header then return TRUE. </ins> <del> Response MAY be compressed by an available dictionary. If the mode is "cors": For clients, apply the CORS check from the fetch spec (https://fetch.spec.whatwg.org/#cors-check) which includes credentials checking restrictions that may not be possible to check on the server. If the CORS check passes: Response MAY be used as a dictionary. Response MAY be compressed by an available dictionary. Else: Response MUST NOT be used as a dictionary. Response MUST NOT be compressed by an available dictionary. For servers: If the response does not include an "Access-Control-Allow- Origin" response header: Response MUST NOT be used as a dictionary. Response MUST NOT be compressed by an available dictionary. If the request does not include an "Origin" request header: Response MUST NOT be used as a dictionary. Response MUST NOT be compressed by an available dictionary. If the value of the "Access-Control-Allow-Origin" response header is "*": Response MAY be used as a dictionary. Response MAY be compressed by an available dictionary. If the value of the "Access-Control-Allow-Origin" response header matches the value of the "Origin" request header: Response MAY be used as a dictionary. Response MAY be compressed by an available dictionary. If the mode is any other value (including "no-cors"): Response MUST NOT be used as a dictionary. Response MUST NOT be compressed by an available dictionary. </del> <ins> return FALSE. </ins> 10.

Related discussion:
text: I was reading them as things a client would verify after receipt of the Response, since we usually don't rely on a bad client sending "I'm good" information in request header fields. [BTW, this is why the main HTTP specs always target requirements to a role instead of making them neutral requirements on a message.] In that case, these are definitely normative requirements, similar to conditional requests. HTTP servers don't normally parse CORS header fields, since pre-flights and such are handled by back-end applications (not httpd).
I'll make another pass over the CORS language tomorrow to make it clearer and make sure it only covers the parts that servers need to handle for fetch-compliant clients. The client bits can and should be in fetch.