Repository navigation
Parameters make URL extremely long #6
Description
Problems with long URLs include:
- We may run into browser limits
- Cosmetically the URLs look bad
- Copying and pasting URLs more difficult
Possible solutions:
- Shorten simply by using shorter keys/values (less verbose) - fairly easy to do, but won't shorten that much really and still looks bad
- One extreme is to store a JSON object representing user configuration in a Protocol Buffer, and perhaps simply have a single parameter with a base64 encoded value of the protocol buffer - tons of overhead to set this up and protocol buffer support for JavaScript looks questionable at this point
- Another extreme is to store configuration on a server (kinda like tinyURL generators) in which again, there is a single parameter or the path itself is the key, which can be very small, and this key is used to pass to the lookup server which stores configuration state. Tons of overhead to set this up, but probably nicest user experience (smallest URL).
Activity
slominskir commentedon Jun 9, 2020
Server Side Storage seems like the best option, but challenges include:
slominskir commentedon Apr 3, 2025
Probably okay to trust users on local network to create small ID to huge parameter set record (tinyurl) by clicking button to share tinyurl. Could add IP address as minor audit. Offsite auth would absolutely be required though.
nsjarvis commentedon Aug 27, 2025
Hi Ryan, I was going to make a separate issue about this and then saw it here already. I noticed that when I delete a PV, its properties are not deleted from the url. I have a few favourites bookmarked, so I tend to load up one of those and then change the PVs. Eventually when I have made a number of these changes, the url becomes enormous (as it contains so many args for PVs that were deleted) and the server cannot support it. So if I will be using WAVE for a while, I expect this to happen, so I copy the url into a googledoc so that I can recreate it easily.
Also, the urls could be shortened by leaving out the args that have the default values or for which the user did not set a value.
slominskir commentedon Aug 27, 2025
Yeah, looks like we may need to tweak settings on Tomcat or make URLs smaller. Using the URL you provided in issue #30 from offsite results in:
Might work onsite, since all the Keycloak authentication is skipped in that case and therefore the number of cookies in the header is dramatically smaller too.
slominskir commentedon Aug 27, 2025
After tweaking the URL you provided and already having auth cookie, I was able to view your example. One of the backend requests in the larger URL failed though, explaining the erratic behavior.