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

111–120 of 317 posts

Re: I’ve banned query strings

#111

Post by zaphar »

1shooner wrote: post #18
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…

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.

But, this is robust? I mean it's pretty clearly stating that you are visiting an unsupported URL. It provides direction on what to do about it to the user. It does not crash the browser or the server. In pretty much every dimension this is highly robust.

Re: I’ve banned query strings

#112

Post by zaphar »

vel0city wrote: post #79
hananova wrote: post #58

Earlier quoted context omitted.

If you insist on knowing, include a different url in both that goes to the same place and use your damn server logs. You don’t need google analytics and whatever.

Isn't putting in a different query string "including a different url that goes to the same place"? Isn't this functionally the exact same?

presumably you control the urls you are sending in the email. As a result if you want to use query strings that's fine. The issue only arises when you use query strings to implement tracking on someone else's site instead.

Re: I’ve banned query strings

#113

Post by brightball »

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.

Yea, empty response at a valid path. Isn’t 204 the code for it?

Lots of REST libraries that I’ve used treat any 400 response as an error so generating a 404 when for an empty list would just create more headaches.

Re: I’ve banned query strings

#114

Post by sroussey »

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…

Oh no, looks like my old forum software urls.

Re: I’ve banned query strings

#115

Post by stouset »

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.

The point was that returning a 404 for unexpected query strings doesn’t just happen to okay per the specs, but that there is significant historical precedent for doing so based on application design that was common in the past.

Re: I’ve banned query strings

#116

Post by sroussey »

qiller wrote: post #108
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.

What’s do you mean by correctly?

Re: I’ve banned query strings

#117

Post by em-bee »

gritzko wrote: post #104
gritzko wrote: post #100

Earlier quoted context omitted.

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.

what would be a better way of doing that? i am not disagreeing, but i just can't think of any way to improve on this. put everything into the query part? i prefer to use the query only for optional arguments. in this example the blob argument is the only thing that doesn't fit in my opinion.

Re: I’ve banned query strings

#118

Post by sroussey »

halayli wrote: post #106
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.

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

It’s a string between ? and # isn’t well defined. Or it is and it says very little.

Re: I’ve banned query strings

#119

Post by iainmerrick »

gritzko wrote: post #104
gritzko wrote: post #100

Earlier quoted context omitted.

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.

Back in the day there was an attempt to introduce "matrix URIs" as a more structured alternative to query strings: https://www.w3.org/DesignIssues/MatrixURIs.html

Of course there's nothing to stop you using URIs like this (I think Angular does, or did at one point?) but I don't think the rules for relative matrix URIs were ever figured out and standardised, so browsers don't do anything useful with them.

Re: I’ve banned query strings

#120

Post by susam »

cosmicgadget wrote: post #32
SoftTalker wrote: post #10

Earlier quoted context omitted.

FTA: It is also a bit like web rings except that the community network is not restricted to being a cycle; it is a graph and it is flexible.

Is it not a random walk? Might sound pedantic but if there is graph structure I am interested.

I'll start with the clarification that the moderators have changed the URL of the original post from https://susam.net/no-query-strings.html> to https://chrismorgan.info/no-query-strings>. Hopefully, this will prevent any confusion about why we are discussing random walks in a post about query strings. Now let me answer your question.

> Is it not a random walk? Might sound pedantic but if there is graph structure I am interested.

The network is a directed graph. Every Wander Console declares a few other consoles as its neighbours. The person setting up the console decides who they want to list as their neighbours. So if we call the network graph X, then the set of vertices is:

  V(X) = the set of all URLs that point to Wander Consoles
and the set of directed edges is:

  E(X) = {(u, v) in V(X) : u declares v as its neighbour}
The traversal between consoles is not strictly a random walk. If I could call it something, I would call it randomised graph exploration with frontier expansion. On each click of the 'Wander' button, the tool picks one console at random from the set of discovered consoles and visits that console. It then fetches the neighbours declared by that console and adds any newly discovered consoles to the set.

The difference from a random walk is that the next console is not chosen from the neighbours of the last visited console. It is chosen from the whole set of consoles discovered so far. In other words, each click expands the known part of the graph, but the console used for that expansion is selected randomly from all discovered consoles, not just from the last console visited.

Post reply on HN