I Will Not Add Query Strings to Your URLs
48 points by susam
48 points by susam
Thank you for describing how my posts have been useful to you. I write my detailed reviews for a variety of reasons:—
I really value the occasional appreciative comment that I get from random people. Detailed appreciation like yours makes me feel even more warm and fuzzy.
(Here’s a really funny thing: back in January I discovered your site and particularly heartily approved of “more purple links, please”; and now today I learn that apparently I unwittingly inspired your position!)
I published my new website yesterday, and I’m intending to start publishing a lot more reviews, in various media. I wrote a bit about my plans in this direction last month: https://lobste.rs/s/vpdpkq/llm_reviews_cargo_crev#c_8uk441.
I was a little surprised that you already had another example of a page allergic to added query strings.
Looks like, of that site, that page alone uses the query string for subpage routing—?1, ?2, ?3 and ?4.
Other pages there will tolerate query strings. Fun.
Definitely against the spirit of URLs, as sequential pagination is clearly hierarchical in nature, but I suppose ?page=1 and such is rather common.
When I was deciding what status to return, I was concerned 404 might have side-effects from improper assumptions. But perhaps my concern wasn’t warranted:
I somehow forgot how much of the web doesn’t use the path meaningfully at all!
What? You didn't consider returning "418 I'm not a teapot" response for unauthorized query strings?
It was several months ago. I definitely considered all the 4xx codes, and that would have included 418 despite its not being registered. I don't remember what I thought about it, but evidently I didn’t consider it seriously.
I use it on my gopher server for when a web bot makes an HTTP request to it. It's an odd enough response that it does keep them at bay.
Love it. Wander console is growing wonderfully and I think the level of care Susam shows here is a large part of why it works.
I've seen a couple variants of undesired query strings in my URLs. The Programmer Weekly newsletter adds it, but also has a referrer header, so it's redundant.
Another appears to have a unique ID for each subsciber, which I don't want at all. Awkwardly there is no referrer, so I don't even know what site is doing it.
/blog/modeling-on-demand-pricing/?ck_subscriber_id=<unique-id>
If I wanted to know I'd look at the Referer header; and if it isn't there, it's probably for a good reason
I'd love to agree... But Referer has been somewhat between broken and useless for years. That's the only reason any of this exists.
Why did I add it anyway? I succumbed to popular demand.
Did you? It was a single throwaway comment with 5 upvotes on an unrelated issue. It wasn't much of a fight before succumbing ;-)
Did you? It was a single throwaway comment with 5 upvotes on an unrelated issue. It wasn't much of a fight before succumbing ;-)
I am not sure what 'throwaway comment' means in this case. That comment was by someone who had cared enough to try out my software, set it up on their website and make their website part of the community network. I would not dismiss that as 'throwaway'.
When this project had only about ten users and a suggestion for a new feature had five upvotes, it did feel like popular demand to me.
My projects are usually small tools I create as a hobby. With a few exceptions, most of them do not have a lot of users. So when I receive feature requests or bug reports, whether they are reported on a related issue or an unrelated one, they matter to me. I may not always work on them, but I make a mental note of which ones received more demand than the others.
5 upvotes in a 10-user community is half the entire userbase, which is pretty loud. :)
The one upside the ?via= thing had over the http Referer header is that you can't necessarily set the related Referrer-Policy header on a dumb static hosting website. But OTOH I think you might be able to set it via a <meta http-equiv="Referrer-Policy" value="..."> anyway.
If you were going to stick URL parameters on things, I would suggest using utm_source=... rather than via=... because the UTM parameters are already used indiscriminately all over the place all over the web anyway so lots of software is resilient to them. Bonus side effect for using UTM parameters is that for people who have things like Firefox extensions for automatically stripping tracking parameters from links, those extensions will work for the tracking parameter(s) that you are adding to the links since the parameter names are the same.
The fact that the UTM parameters look and feel icky as hell is... justified. It might justifiably put people off turning the feature on. It might have justifiably put you off implementing it.
Other people whose projects and users also matter to them do ask for more justification of feature requests :-) in this case the 'request' was worded as a question–should we add this? And the upvotes could be interpreted as also wanting to know the answer to the question. And the question was asked as a comment on an unrelated repo issue. For a serious feature request, I would have the expectation that they would open a separate issue.
Of course, at the end of the day it's your project and you can do whatever you like with it, but I think the request fell short of popular demand :-)
Yes, other maintainers may very well ask for more justification. They may also have a different temperament or a different appetite for process. As you mentioned, you would, quite understandably, expect a separate issue for a feature request. But I am not you. Furthermore, from my perspective, the original comment already contained enough justification:
[...] so they know that the traffic is coming from a wander
I was only describing how the comment and the upvotes felt in the context of my small hobby project with a handful of users.
The comment was meaningful to me even though it appeared under an unrelated issue. It came from someone who had cared enough to try out my software, set it up on their website and join the community network. Five upvotes on the comment, all of which were from people who had set up the software on their websites, mattered to me.
One could interpret those upvotes as people wanting to know the answer to a question. One could also interpret them as interest in the feature. We can't know which interpretation is correct without asking the upvoters. Both interpretations may be correct. But even if my interpretation was incorrect, I don't think it was unreasonable. It is clear that the request fell short of popular demand by your standards. It did not fall short by my admittedly much smaller standards.