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

81–90 of 317 posts

Re: I’ve banned query strings

#81

Post by saintfire »

legitster wrote: post #44
humodz wrote: post #23

The tone of this and Chris's post gives me the impression that it's harmful to include these query parameters, but I don't understand how. Could someone elucidate me? I understand it can mangle some URLs and that's good enough reason not do it, but even then it seems like a minor incovenience.

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.

> If I ever start using any query strings, I’ll allow only known parameters.

They aren't saying the concept of query strings are bad, They're saying unsolicited query strings during referal are the issue.

Re: I’ve banned query strings

#82

Post by abecode »

jameshart wrote: post #70

There’s nothing ruder in hypertext etiquette than giving someone a link to navigate to someone else’s HTTP server, where you have manipulated that URL in some way unsanctioned by the server you are sending them to. You can’t just send arbitrary query string parameters to a server and assume they will just ignore them. Just like you can’t just remove query string parameters and assume the URL will work.

My use case for this is making separate bookmarks in different folders for a single URL:

Example.com/interesting -> bookmark folder one

Example.com/interesting?dummy=t -> bookmark folder two

Re: I’ve banned query strings

#83

Post by cobbzilla »

gpvos wrote: post #73
nrds wrote: post #62

Earlier quoted context omitted.

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.

Query strings existed before CGI did, and the way they're defined to be filled in from web forms is quite useful; I wouldn't want to need Javascript to fit that into path format. There's nothing wrong about having things decided by the server; I don't get that part of your argument at all.

Maybe dumb question: how does the server “decide” anything other than what file to serve? Today we have many choices but back in the day CGI was the first standard way to do it.

So yes query parameters existed before CGI but to use them you had to hack your server to do something with them (iirc NCSA web servers had some magic hacks for queries). CGI drove standardization.

Re: I’ve banned query strings

#84

Post by Semiapies »

wongarsu wrote: post #63
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…

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.

Re: I’ve banned query strings

#85

Post by gojomo »

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, they don't want to stop. Improving their probe of the risk-of-failure was enough.

Seemingly, the practice works often enough, pleasing more destination sites than it angers, that "referral tracking" is not something "so minor".

Re: I’ve banned query strings

#86

Post by lucketone »

ollien wrote: post #37
jampekka wrote: post #16

Earlier quoted context omitted.

"You could argue that I’m abusing 414 URI Too Long. I respond that it’s funnier this way. Other options I considered were: 400 Bad Request, the generic client error code, which is correct but boring; 402 Payment Required, and honestly if you want to pay me to make a particular URL with query string work, I’m open to it; 404 Not Found, but it’s too likely to have side effects, and it doesn’t convey the idea that the r…

I don't think it's an abuse, RFC9110 defines 414 as a response for "refusing to service the request because the target URI is longer than the server is willing to interpret". Since adding a query string involves only adding characters, this seems fine; there's no stipulation as far as I can tell that all pages a server hosts must adhere to the same length. I'd be curious if any well-known clients interpret it that wa…

If the goal is to be misleading, but technically correct, it hits the bullseye

Re: I’ve banned query strings

#87

Post by stirfish »

cobbzilla wrote: post #83
gpvos wrote: post #73

Earlier quoted context omitted.

Query strings existed before CGI did, and the way they're defined to be filled in from web forms is quite useful; I wouldn't want to need Javascript to fit that into path format. There's nothing wrong about having things decided by the server; I don't get that part of your argument at all.

Maybe dumb question: how does the server “decide” anything other than what file to serve? Today we have many choices but back in the day CGI was the first standard way to do it. So yes query parameters existed before CGI but to use them you had to hack your server to do something with them (iirc NCSA web servers had some magic hacks for queries). CGI drove standardization.

    func specialHandler(w http.ResponseWriter, r *http.Request) {
 if time.Now().Weekday() == time.Tuesday {
  http.NotFound(w, r)
  return
 }

     fmt.Fprintln(w, "server made a decision")
    }
Your server can make decisions however you program it to, you know? It's just software.

Forgive the phone-posting.

Re: I’ve banned query strings

#88

Post by 1shooner »

btilly wrote: post #67
1shooner wrote: post #18

Earlier quoted context omitted.

Also from the 414 page: >Complain to whoever gave you the bad link, and ask them to stop modifying URLs, because it’s bad manners. It's ironic that an error response so blatantly violating the robustness principle is throwing shade about bad manners.

Opinions vary on how good an idea the robustness principle is. That is why, for example, the XML standard requires a conforming validator to throw an error on invalid XML. In our modern world, the robustness principle has become an invitation to security bugs, and vendor lock-in. Edge cases snuck through one system on robustness, then trigger unfortunate behavior when they hit a different system. Two systems tried to…

I generally agree, but I don't think XML is the best example. Getting HTML out of XML is considered to have been the right move isn't it? I was pro-XHTML2 at the time but in retrospect, have we suffered much for not sending webpage validation errors to end users?

Re: I’ve banned query strings

#89

Post by hamburglar »

mikeocool wrote: post #74
nrds wrote: post #62

Earlier quoted context omitted.

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.

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.

My next website is going to have the path portion of the URL be a base64 encoded ASN.1 blob.

Re: I’ve banned query strings

#90

Post by thayne »

dredmorbius wrote: post #53
Aardwolf wrote: post #38

> You could argue that I’m abusing 414 URI Too Long. I respond that it’s funnier this way. Other options I considered were: Another option to consider is "418 I'm a teapot": teapots usually also don't support query strings

Just straight "400" ("Bad Request") or "403" ("Forbidden") would also probably be defensible. Odd that there aren't any error response codes specific to URI parameters. Several options which seem like they might be appropriate aren't on close examination: - "406" ("Not Acceptable") which is based on content-negotiation headers. - "409" ("Conflict") which is largely for WebDAV requests. - Others such as 411, 422, and…

I think either 400 or 404 would be fine. 400 because the request isn't in the expected format, 404 because a resource with that query string doesn't exist.
Post reply on HN