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

151–160 of 317 posts

Re: I’ve banned query strings

#151

Post by em-bee »

arjvik wrote: post #126
em-bee wrote: post #117

Earlier quoted context omitted.

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.

Every object in git (commit, tree, revision of a single file) has a hash that is guaranteed unique within a repository (otherwise many more things than a web UI would break) and likely also globally. I can understand wanting to isolate repositories to prevent hash collisions from causing problems, but within a repo everything has a universally unique ID. edit: for instance, that specific VERBS.md is represented by th…

that's not what i meant. i was trying to suggest that the string "blob" does not fit. why is it there? why is it needed?

    https://github.com/gritzko/beagle/a7e17290a39250092055fcda5ae7015868dabdb4/VERBS.md
this should be sufficient to represent the file.

"blob" is like a descriptor of the value that follows. it would be like doing this:

    https://github.com/user/gritzko/project/beagle/blob/a7e17290a39250092055fcda5ae7015868dabdb4/file/VERBS.md
this actually irks me every time i see it in a github url

Re: I’ve banned query strings

#152

Post by nofriend »

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…

Standards are just commonly accepted behaviour that somebody chose to write down somewhere. There are a great number of commonly accepted behaviours that nobody's ever bothered to encode into a formal standard, but where failure to follow the accepted practice will result in widespread breakage. There are also a great many "standards" that you would be a fool to follow to the letter. In the OP case, the only thing that will break is people trying to visit their site, who will presumably simply press the back button on their browser and go about their day. They can decide for themselves if that is an acceptable casualty. But it isn't definitionally acceptable because no standard says it isn't (nor would is suddenly become unacceptable because a standard said it was...)

Re: I’ve banned query strings

#153

Post by em-bee »

altairprime wrote: post #133
gritzko wrote: post #104

Earlier quoted context omitted.

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.

That’s not an indiscriminate hierarchy. Grouping data by user is common and normal in computing: /home laid precedent decades ago. Project directories are an extremely common grouping within a user’s work sets. Yeah, some of us just dump random files in $HOME, but this is still a sensible tier two path component. The choice to make ‘view metadata-wrapped content in browser HTML output’ the default rather than ‘view r…

actually, instead of the object hash, you could also use the commit-hash. then the filename would be mandatory, but the url would be more readable and usable: give me the file VERBS.md as it is at commit

Re: I’ve banned query strings

#154

Post by wodenokoto »

So my understanding is, he is annoyed that other website adds a query string such as "?ref=origin.com" to links pointing to authors website.

How does this benefit the other website? How does this hurt the authors website?

I am completely confused about the behavior of both side here.

I get that when I run an ad-campaing I want google to add a utm-query string, so I can track which campaign users arrived from - but then the origin and the destination are working together. Here the origin just adds stuff for no reason. Why?

Re: I’ve banned query strings

#155

Post by HumanOstrich »

brightball wrote: post #113
Semiapies wrote: post #84

Earlier quoted context omitted.

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.

Libraries that automatically throw errors for status codes in the 400 and 500 ranges are pretty obnoxious (looking at you, axios). It adds unnecessary overhead, complexity, and bad ergonomics by hijacking control flow from the app.

Responses with status codes in the 400 range are client errors, so the client shouldn't retry the same request. So a 404 is appropriate despite how annoying a library might be at handling it. Depending on which language/ecosystem you are using, there are likely more sane alternatives.

Re: I’ve banned query strings

#156

Post by saimiam »

nofriend wrote: post #149
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…

> It should be immediately obvious that in that scheme 404 is indeed the correct answer to unknown query parameters That's not obvious at all. If I receive json data that contains a property I'm not aware of, i don't reject the entire document for that reason. In the case of query strings, extra query parameters might be used by other parts of the stack besides yours, so rejecting the entire document because someone…

> 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 fuzzy behaviour from the website but that’s a choice, not a practice.

Re: I’ve banned query strings

#157

Post by lispwitch »

cobbzilla wrote: post #140
stirfish wrote: post #87

Earlier quoted context omitted.

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.

and what server software is running this code in 1995?

CL-HTTP or AOLserver

Re: I’ve banned query strings

#158

Post by carsoon »

legitster wrote: post #35
phoronixrly wrote: post #25

Earlier quoted context omitted.

Oh, I have a couple - the users did not agree on being tracked (these query params are tracking information), and the site administrator does not want incoming traffic to be tracked. I know the latter can be hard to understand, but I for example sure as hell do not want to have any info in my logs that can be used to harm my users. On a more personal note, I hate it when I go to copy a link to send via a message, and…

>(these query params are tracking information) Query strings are useful for way more than just tracking. Saving and servicing search queries is a way more common use case. So assuming it's only useful for tracking is very misleading. Query strings are probably the least invasive tracking. They are transparent, obvious, and anonymous. Users are free to strip out and edit query strings if they don't want them. More to…

Yeah I do not see an alternative way to easily copy paste links with things like filter settings saved.

Filters especially make sense as query params as they are non sequential but still visually readable as to what they do.

URL slugs make sense for sequential pages that are hierarchical but make no sense for non hierarchical data/routes.

Services can force tracking into links by encoding the whole url into a shortlink that makes it impossible to just remove the tracking alone as everything is encoded into a shorter non editable string.

Re: I’ve banned query strings

#159

Post by zzo38computer »

Query strings do have uses (such as for searching files and some other kind of dynamic files), but you shouldn't add them to URLs that should not expect them. So, I agree that they would be right to refuse requests with UTM and other stuff added like that.

I think 404 probably makes the most sense as the response if a query string is not expected but is present anyways, although 400 might also be suitable.

Re: I’ve banned query strings

#160

Post by sowbug »

em-bee wrote: post #151
arjvik wrote: post #126

Earlier quoted context omitted.

Every object in git (commit, tree, revision of a single file) has a hash that is guaranteed unique within a repository (otherwise many more things than a web UI would break) and likely also globally. I can understand wanting to isolate repositories to prevent hash collisions from causing problems, but within a repo everything has a universally unique ID. edit: for instance, that specific VERBS.md is represented by th…

that's not what i meant. i was trying to suggest that the string "blob" does not fit. why is it there? why is it needed? https://github.com/gritzko/beagle/a7e17290a39250092055fcda5ae7015868dabdb4/VERBS.md this should be sufficient to represent the file. "blob" is like a descriptor of the value that follows. it would be like doing this: https://github.com/user/gritzko/project/beagle/blob/a7e17290a39250092055fcda5ae701…

They are following the /key/value/key/value pattern, but the first two pairs in a GitHub URL are fixed to user and project, which lets them omit the key names. I could see them not being willing to hardcode the third pair to blob.

Back when GitHub URLs were kind of cool, github.com/user/gritzko/project/beagle would have been much less cool than just github.com/gritzko/beagle.

Post reply on HN