261–270 of 317 posts
Earlier quoted context omitted.
What's interesting is that none of these sites have a "search" feature. Which is an important accessibility feature and a clear and legitimate use case for a query string.
My website has search without a query string: https://www.jeremykun.com/
Earlier quoted context omitted.
I’m broadly anti-tracking: it’s generally against the interests of the individual. Query string additions are commonly used to track things. You can see that lots of people don’t want that by the existence of Firefox features like “copy clean link” and Extended Tracking Protection which proactively strips some like UTM parameters. Some sites happily participate in what I will glibly call the tracking economy. They ma…
I understand being for privacy, but on the flip side, information about you can result in a better experience. E.g. in the case of tracking where a person comes from, that can help those two websites improve by coordinating with each other in some way. Or your ads might actually show you something you didn't know you existed that you end up buying. That's probably better than seeing ads you likely have zero interest…
It assumes that “ads” = useful information, but that's rare at best. Most ads focus on stealing your attention and creating a fear of missing out. NordVPN isn't educating you. They just manufacture a need and then hope that you won't invest time in researching a better option.
Why would I give them more leverage to do that?
While I don't take the author's hard stance, I do hate gratuitous query params that result in links that are thousands of characters long. I use this bookmarklet to strip query params before sharing a link: javascript:(()=>navigator.clipboard.writeText(location.origin+location.pathname))();
This corrupts a URL like: https://example.com/?p=20&utm_source=spam to: https://example.com/ when in fact we want the following: https://example.com/?p=20 A possible improvement can be: javascript:(()=>{const u=new URL(location.href);[...u.searchParams.keys()].forEach(k=>{if(k.startsWith('utm_')){u.searchParams.delete(k)}});navigator.clipboard.writeText(u.href)})();
If I did want to support paginated/search pages, I would allowlist only `p` and `q` rather than specifically blocking one type of analytics.
> curl, for example, seems to illegitimately strip a trailing question mark (could be only for the command line, didn’t test library usage). umm what? I don't know what they're actually sending where they think this, but if you think curl is broken you should re-think that maybe you're the one doing something wrong. Here are some examples showing curl not stripping question marks (obviously), I am very curious what t…
$ curl -s 'https://httpbingo.org/get?' | jq .url "https://httpbingo.org/get" This may require further investigation.
There's a flag that would preserve it, but no way to set it from the CLI afaict
edit: I started a discussion here: https://github.com/curl/curl/discussions/21544
You know I was actually really curious about this so I went back to the HTML and URL W3C standards and surprisingly they don't actually have any definitions of format other than being percent encoded. One might conflate query strings with "form-urlencoded"[0] query strings, which is one potential interoperability format, but in general a queries string is just any percent encoded string following a "?" in a url[1], a…
Interestingly, quite a few places that should treat query strings transparently make a lot of assumptions about their structure. We ran into that when picking a new CDN, some providers didn't handle repeat parameters (?a=1&a=2) correctly.
You know I was actually really curious about this so I went back to the HTML and URL W3C standards and surprisingly they don't actually have any definitions of format other than being percent encoded. One might conflate query strings with "form-urlencoded"[0] query strings, which is one potential interoperability format, but in general a queries string is just any percent encoded string following a "?" in a url[1], a…
Back in the day it was reasonably common for CMSs and forums to only have an index.php, and routing entirely by query string (in form-urlencoded form, people were not savages). So you would have index.php?p=home and index.php?p=shop. Or index.php?action=showthread&forum=42&thread=17976. It should be immediately obvious that in that scheme 404 is indeed the correct answer to unknown query parameters In fact lots of si…
Earlier quoted context omitted.
Back in the day it was reasonably common for CMSs and forums to only have an index.php, and routing entirely by query string (in form-urlencoded form, people were not savages). So you would have index.php?p=home and index.php?p=shop. Or index.php?action=showthread&forum=42&thread=17976. It should be immediately obvious that in that scheme 404 is indeed the correct answer to unknown query parameters In fact lots of si…
It's funny to read this like it's archaic knowledge, this is my base mental map of how nicer looking URLs work :)
When the "server" is part of the application, you have a richer routing layer, that you can do with what you want
You know I was actually really curious about this so I went back to the HTML and URL W3C standards and surprisingly they don't actually have any definitions of format other than being percent encoded. One might conflate query strings with "form-urlencoded"[0] query strings, which is one potential interoperability format, but in general a queries string is just any percent encoded string following a "?" in a url[1], a…
Whatwg is for html, try the IEEE http rfcs
Earlier quoted context omitted.
> other parts of the stack As a web developer, you’re the like the guy standing with a clipboard outside a fancy club checking if people requesting entry are allowed or not. Basically, level 1 security. If someone is not on the list, your job is to default to declining them access, not granting them access assuming level 2 security will handle them at a deeper layer. It’s possible that the teams you work with expect…
>It’s possible that the teams you work with expect fuzzy behaviour from the website but that’s a choice, not a practice. This is how the vast majority of websites work. The practical reason is obvious: when we model the behaviour our code depends on, we want to create the simplest possible model that allows our code to work as expected. Placing requirements on it that our code doesn't actually depend on is useless, u…