- From: Anne van Kesteren <notifications@github.com>
- Date: Fri, 25 Apr 2025 04:18:50 -0700
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fetch/issues/1167/2830134900@github.com>
annevk left a comment (whatwg/fetch#1167) I think at this point it would probably be ill-advised to change the `Response.prototype.url` getter to no longer set 'exclude fragment'. So the proposal here would be to add `Response.prototype.hash` that returns this's URL's fragment. We'd also not make it impact the cache API. So: - It would not impact any existing properties. - It would not impact `responseObject.url` in service workers (I'm assuming you did not mean to type server workers). But it will impact `responseObject.hash`. It would contain the fragment of the request, modulo redirects and such. - It would not be transmitted to the server. It merely exposes something on the response that is currently hidden. - It would not impact the processing model of fragment-based features. Those already have access to the fragment. But with this you could implement your own fragment-based feature in a service worker. - It won't impact `XMLHttpRequest` as that has its own logic. We'd have to separately expose it there. As for #1175, that's a somewhat separate problem as to how we want to deal with fragments in service workers. https://github.com/whatwg/fetch/pull/696#discussion_r577929526 goes into this a bit. There's currently no way for a service worker to influence the fragment of a response and there are some issues with requests exposing the fragment to the service worker. This proposal merely exposes a getter on responses so it doesn't change any of that. -- Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/issues/1167#issuecomment-2830134900 You are receiving this because you are subscribed to this thread. Message ID: <whatwg/fetch/issues/1167/2830134900@github.com>
Received on Friday, 25 April 2025 11:18:54 UTC