Re: [fetch] Clarify the hooks into RFC6265 (#221)

> @@ -2909,11 +2919,14 @@ <h3 id="http-network-fetch"><span class="secno">5.6 </span>HTTP-network fetch</h
>   <!-- XXX xref HTTP cache -->
>  
>   <li>
> -  <p>If <var>credentials flag</var> is set and <var>response</var>'s
> -  <a href="#concept-response-header-list" title="concept-response-header-list">header list</a> contains one or more
> -  <a href="#concept-header" title="concept-header">headers</a> <a href="#concept-header-name" title="concept-header-name">named</a>
> -  `<code title="">Set-Cookie</code>`, update the cookies. <a href="#refsCOOKIES">[COOKIES]</a>
> -  <!-- XXX proper hook? -->
> +  <p>If <var>credentials flag</var> is set and the user agent is not configured to block cookies for
> +  <var>httpRequest</var> (see <a href="https://tools.ietf.org/html/rfc6265#section-7">section 7</a> of
> +  <a href="#refsCOOKIES">[COOKIES]</a>), then run the "set-cookie-string" parsing algorithm (see
> +  <a href="https://tools.ietf.org/html/rfc6265#section-5.2">section 5.2</a> of
> +  <a href="#refsCOOKIES">[COOKIES]</a>) on the <a href="#concept-header-value" title="concept-header-value">value</a>
> +  of each <var>header</var> <a href="#concept-header-name" title="concept-header-name">named</a> `<code title="">Set-Cookie</code>`
> +  contained in <var>response</var>'s <a href="#concept-response-header-list" title="concept-response-header-list">header list</a>, and
> +  <var>response</var>'s <a href="#concept-response-url" title="concept-response-url">url</a>.

> The algorithm defined in the RFC doesn't seem to take two arguments.

It needs `request-uri` at the bottom in order to call into the storage model. I agree that it's not written in a way that makes its requirements clear. If you squint a bit, you'll see that this algorithm is executed "When a user agent receives a Set-Cookie header field in an HTTP response", and intends to retain that context through the algorithm. Given the way things in Fetch are structured, we need to provide that context somehow. Passing in the URL seems like the clearest way of doing so. When we spin up 6265bis, I'd be happy to tweak that text to make the requirements clear.

> This algorithm will also segfault if we ever support putting cookies in synthetic responses.

That would allow a service worker to set cookies for some other origin, wouldn't it? That seems like a bad thing to support. I can add a comment to that effect?

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/221/files#r53760985