Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I’ve banned query strings

chrismorgan.info

Post reply on HN
Print view View original

101–110 of 317 posts

Re: I’ve banned query strings

#101

Post by kyralis »

legitster wrote: post #40
keane wrote: post #34

Earlier quoted context omitted.

Yes, query strings often enable useful features! But Chris's post, "no unauthorised query strings", is only regarding third parties adding them.

But... like... that's a weird hill to die on. > 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. You abuse your users by adding that to the link. The reason is that the referrer headers are a usability and privacy nightmare. It's weird for the author to jump to such a conclusion. This referral information is being done purely as a courtesy to the webhost. If…

There's a referrer header, if the client wishes to send it. If they don't, the "courtesy to the web host" is done at the expense of the client. This particular web host takes umbrage at other sites taking advantage of their clients that way, which seems reasonable to me.

Re: I’ve banned query strings

#102

Post by kyralis »

rglover wrote: post #55
willthefirst wrote: post #33

I mean…the site that broke should know what to do with arbitrary query strings. If your site breaks when someone puts in an invalid query string, that’s on you?

This. Query strings are a standard feature and have many more purposes beyond tracking.

Yes, and if the site actually used query strings, then it would of course accept them. Why does it have any reason to accept invalid query strings?

Re: I’ve banned query strings

#103

Post by gwern »

gojomo wrote: post #85
gwern wrote: post #17

Query strings break unpredictably, and that alone is enough to ban them by third parties, especially for something as minor as referral tracking. Example: The Browser is a well known link aggregation paid periodical. I subscribe, and every 1 in 10 or 20 links I clicked, it'd just break outright and I'd have to tediously edit the URL to fix it (assuming the website didn't do a silent ninja URL edit and make it impossi…

I don't see how your example, The Browser (thebrowser.com), supports your argument that ad-hoc query-string additions are so prone-to-breaking that 3rd parties should ban them. In fact, the example seems to suggest the opposite: a 17+ year successful paid subscription business – to which you appear to be a generally-satisfied customer! – receives enough "business value" from the practice, despite its failure modes, t…

> Improving their probe of the risk-of-failure was enough.

The point was it was dangerous in a way they didn't even realize was an issue, for a thin business rationale. Unless you are going to do thorough tests and understand the risk you are taking (which they did not, as evidenced by screwing it up systematically at scale for years), you should not be doing it.

And it's not obvious that they are correct in their tightened-up testing, because even if a link is correct at the time they test it, it could break at any time thereafter.

> to which you appear to be a generally-satisfied customer!

No matter what _X_ is, _X_ would have to be a pretty epic screwup to make a customer unsubscribe solely over that! I never claimed it was such a major epic screwup that it could do that. So that is an unreasonable criterion: "well, you didn't outright quit, so I guess it can't be that bad." Indeed, but I never said it was, and somewhat bad is still bad; I was in fact fairly annoyed by the random breakage, and at the margin, everything matters. If TB did a few other things, in sum, they could potentially convince me to let my subscription lapse. An annoyance here, a papercut here, and pretty soon a generally-satisfied customer is no longer so satisfied...

Re: I’ve banned query strings

#104

Post by gritzko »

gritzko wrote: post #100
mikeocool wrote: post #74

Earlier quoted context omitted.

I dunno, it seems like the fact that we arrived at a fairly standard structure for URL paths that works pretty well is not a bad outcome. Seems a lot better than the other potential world we could lived in, where paths were a black box and every web server/framework invented their own structure for them.

In my current project I use URIs to refer to absolutely any entity in a git(-ish) repo. Files, branches, revisions, diffs, anything. URI turns out to be a really good addressing scheme for everything. Surprise. But the most used and abused element is always the path. Query takes a lot of that mess away. Might have been unmanageable otherwise. https://github.com/gritzko/beagle

In fact, GitHub URIs are a good example of overusing paths: https://github.com/gritzko/beagle/blob/a7e17290a39250092055f...

  - user gritzko,
  - project beagle, 
  - view blob, 
  - commit a7e17290a39250092055fcda5ae7015868dabdb4, 
  - file path VERBS.md
... all concatenated indiscriminately.

Re: I’ve banned query strings

#105

Post by culi »

franciscop wrote: post #19
culi wrote: post #14

Earlier quoted context omitted.

There are addons to remove unnecessary params from the worst offending sites: https://www.google.com/search?q=clearurls+addon

Thanks for removing the rest on that google link, the one I get after switching to "images" and back to "web" is this monstrosity: https://www.google.com/search?newwindow=1&sca_esv=8061bd9cb1... Edit: which luckily and sensibly Hacker News cuts short since it's 463 characters

Yeah I removed the rest of the link as an example of how much cleaner the urls can be with that addon haha. I was being meta

Re: I’ve banned query strings

#106

Post by halayli »

nrds wrote: post #62
jedimastert wrote: post #20

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…

Wait until you realize that the difference between path and query string is entirely arbitrary and decided by the server. Query strings should never have existed. They are an implementation detail of CGI webservers that leaked all over everything and now smells really bad.

Nothing you said here is correct. Paths, query strings, and fragments are all well defined entities. https://datatracker.ietf.org/doc/html/rfc3986#section-3.3

Re: I’ve banned query strings

#107

Post by dspillett »

Maybe an alternative would be to inconvenience people following such links still, but somewhat less.

Instead of responding with an error, give a page that states “The link you followed to get here appears to have had some tracking gubbins added, in case you are a bot following arbitrary links, and/or using random URL additions to look like a more organic visit, please wait while we run a little PoW automaton deterrent before passing you on to the page you are looking for.” then do a little busy work (perhaps a real PoW thingy) before redirecting. Or maybe don't redirect directly, just output the unadorned URL for the user to click (and pass on to others). This won't stop the extra gubbins being added of course, but neither will the error and this inconveniences potential readers less.

Re: I’ve banned query strings

#108

Post by qiller »

jedimastert wrote: post #20

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.

Re: I’ve banned query strings

#110

Post by Sander_Marechal »

Semiapies wrote: post #84
wongarsu wrote: post #63

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…

If you're routing like it's 1999, sure, 404. On the other hand, if it's a CRUD app and you're filtering a list of entities by various field values? Returning that no items matched your selection (or an empty list, if an API) makes more sense than a 404, which would more appropriate for an attempt to pull up a nonexistent entity URI.

There is no reason you can return that "no items matched your selection" with a 404 HTTP response code instead of a 200.
Post reply on HN