- From: Jungkee Song <notifications@github.com>
- Date: Tue, 28 Aug 2018 16:10:21 -0700
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Tuesday, 28 August 2018 23:10:42 UTC
jungkees commented on this pull request. > @@ -3402,6 +3395,13 @@ optional <i>CORS flag</i> and <i>CORS-preflight flag</i>, run these steps: </ul> <p>then return a <a>network error</a>. + + <li> + <p>If <var>actualResponse</var>'s <a for=response>URL</a>'s <a for=url>fragment</a> is null, + then set <var>actualResponse</var>'s <a for=response>URL</a>'s <a for=url>fragment</a> to + <var>request</var>'s <a for=request>current URL</a>'s <a for=url>fragment</a>. + + <p class=note>Without this step, the fragment would end up getting lost due to the Cache API. Cache API stores a response without stripping its fragment. It ignores fragments in terms of matching. So, if a newly fetched response has a different fragment than the one in Cache, that new response replace the old record. Shouldn't we serve the fragment as-is in the response's url even if its served from the cache? Response's url should always win even if fetch didn't send out the request to the network. Using a request's url's fragment for cached responses seems odd to me. HTTP Cache doesn't store fragments? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/pull/696#discussion_r213500916
Received on Tuesday, 28 August 2018 23:10:42 UTC