Re: [whatwg/fetch] Stop censoring fragments (#696)

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