Search and Hash in URLs
Sometimes we parameterize a #URL to specify in detail what to display.
- The "search" (after a "?") can be used by the server but also by the client, e.g., for routing in a single-page application.
- The "hash" (after a "#") is only available to the client, where it is normally used to scroll to a particular element of a page. But it can also be used for client-side routing.
@w3c @tag #WebStandards #WebDevelopers
1/3
2/3
Now I have a use case with client-side routing parameters where
A. I would prefer to keep the parameters in the client for data-protection reasons, and
B. I would still like to use the hash for scrolling within the page.
So where to put the parameters? Due to (A) I don't want them in the search and due to (B) I don't want them in the hash.
Any ideas, #WebDevelopers ?
Or at @w3c @tag #WebStandards ?
3/3
Well, I can put both the routing parameters and the scroll target in the hash and implement the scrolling in JS. But that feels more complex than necessary.
Is there a standard solution for this? Or should we have yet another URL component that
- is only available to the client and
- does not interfere with the scrolling functionality of the hash component?
Thanks for your reply, @jyasskin. I'm afraid you're right.
Currently I'm essentially following the first of these choices. A while ago I actually experimented with the service-worker approach but gave it up because the service worker could only be started after the first request and so the query of the first request was not hidden.
Oh, and I forgot to mention: Omitting the parameters from the request to the server is not only privacy-friendly but also cache-friendly.
The HTTP No-Vary-Search response header specifies a set of rules that define how a URL's query parameters will affect cache matching. These rules dictate whether the same URL with different URL parameters should be saved as separate browser cache entries.
@jyasskin @tag
Yes, that would help if I had to use query parameters for some reason. (Assuming a blink-based browser and access to the server configuration to add the header line.)
Fortunately this is not needed if the parameters stay on the client side (either in the hash or with a service worker stripping the query). So the page in question can be hosted by a plain static web server.
Heribert Schütz
Jeffrey Yasskin