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

221–230 of 317 posts

Re: I’ve banned query strings

#221

Post by mnahkies »

HumanOstrich wrote: post #155
brightball wrote: post #113

Earlier quoted context omitted.

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…

Completely agree on the axios part - one implication of that is you can't statically type the error response shapes (since exceptions can't be typed). Where as with fetch you can have a discriminated union based on the status code (eg: https://github.com/mnahkies/openapi-code-generator/blob/main...)

Although I do feel like I've seen too many instances of a 404 being used for an empty collection where it would make more sense to return `[]` and treat it as an expected (successful) state.

Re: I’ve banned query strings

#222

Post by ihateolives »

dewey wrote: post #170
wodenokoto wrote: post #154

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 th…

If you have a popular website and you add that parameter the target easily sees who sends them traffic, that could be the base of sponsorships / affiliate arrangements for example.

But you see that anyway from access.log or whatever your server supports and dashboard/analytics shows it anyway? What's the benefit of adding origin to query string?

Re: I’ve banned query strings

#223

Post by Sniffnoy »

chrismorgan wrote: post #215
stickfigure wrote: post #193

This basically boils down to "reject any incoming links from facebook, pinterest, chatgpt, linkedin, twitter, reddit, youtube, etc". I guess sure? There's a once-famous guy who shows goatse to all referring links from HN. I guess if you get enough traffic that you can pick which sources you want to allow, that's a good problem to have.

How much do platforms mangle people’s links? Figured I’d check the ones you mention. (I was actually mildly surprised to be able to find examples in all of them without needing to log in once. I thought LinkedIn and ChatGPT wouldn’t.) Facebook: no. Pinterest: ?utm_source=Pinterest&utm_medium=organic. ChatGPT: ?utm_source=chatgpt.com. (Aside: wow it’s confidently and atrociously wrong if you ask it about me. Ask it ju…

Facebook does, I'm not sure why it didn't in your case. It adds an "fbclid" parameter that is quite long. I just tried it to confirm.

Edit: Perhaps it only mangles links for logged-in users? That raises the possibility that some of the others may also only affect logged-in users.

(Trying with other ones I'm logged in on: Reddit doesn't mangle (obviously), Twitter doesn't mangle.)

Re: I’ve banned query strings

#224

Post by chii »

fpoling wrote: post #196
chrismorgan wrote: post #168

Earlier quoted context omitted.

Yeah, URLs really don’t have much in the way of semantics. Path is clearly intended for hierarchical data and query for non-hierarchical data, and there are strong customs, some commonly supported or even enforced by libraries, but no actual rules. Ultimately, it’s just a string that the server can decide what to do with. The really funny thing about this is that, when I was worrying about possible side effects if I…

Wikipedia web server treats anything after /wiki/ literally as the name of the article. So en.wikipedia.org/wiki/// is the article about C++ style comments

i wonder if it ought to be `/wiki/%2F%2F` instead...

Re: I’ve banned query strings

#225

Post by noduerme »

Most of the sites that still use GET queries around here are the tax collection sites run by local governments, which pass those variables around after you login the way your mom... uh, it's HN, skip the mom joke.

I actually get a lot more annoyed by routing parsers that do the same thing Get requests do only by pretending to be a real URL.

Re: I’ve banned query strings

#226

Post by socalgal2 »

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…

The No-Vary-Search (proposal?)

https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...

effectively lets you specify what parts of a query are relevant. So for example

url?a=b&c=d matches url?c=d&a=b in terms of caching

Re: I’ve banned query strings

#227

Post by ah1508 »

Sander_Marechal wrote: post #110
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.

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

In this case I don't think the status should depend on the number of results. Here are you results, [] is a valid response body when there are no result. Returning 404 if there are no result (GET /books?title=a for instance) is misleading, the caller may think that /books is a non existent route and may conclude that books are reachable via another URI. To me, the querystring has no influence on the response status.

/books/1 could return 200 or 404 depending on the existence of the book#1, here it make sense because if /books/1 does not exist the API must tell it explicitly. However 404 belongs to the 4XX family which means "client error", is it an error to ask for a non existing book ? If you enter in a bookshop and ask for a book they don't have you did not "make a mistake". It's not like if you asked for a chainsaw. But in an API, especially with hypermedia, you are not supposed to request a resource that does not exist (unless the API provides a link to an existing resource that is was deleted before the caller try to reach it).

Re: I’ve banned query strings

#228

Post by rswail »

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.

    204 No Content
for nothing found is both not an error (because 2xx code) but also indicates there was nothing found to match the request.

If it's an API, a 200 with an empty JSON object or array in the body is legitimate as well, but a 204 is explicit.

Re: I’ve banned query strings

#230

Post by GeneralMaximus »

ihateolives wrote: post #222
dewey wrote: post #170

Earlier quoted context omitted.

If you have a popular website and you add that parameter the target easily sees who sends them traffic, that could be the base of sponsorships / affiliate arrangements for example.

But you see that anyway from access.log or whatever your server supports and dashboard/analytics shows it anyway? What's the benefit of adding origin to query string?

Not always.

Some web pages don't send referrers by making all links rel="noreferrer". Mastodon used to do this by default, though now they've changed their stance.

Links opened from non-browser apps don't have any referrer information either. E.g. if somebody shares your link on iMessage, WhatsApp, or Telegram.

Email clients may also strip out referrers, but I'm not entirely sure about this one.

If people read your work via RSS readers, you'll almost certainly not get any referrers. Unless it's a web-based reader like Feedly.

My website gets a lot of traffic marked as "Direct / None" by Plausible. I suspect this is traffic from RSS readers or Mastodon, but I can't be sure. A few times I've considered adding a "?ref=RSS" to all URLs served to RSS readers and "?ref=Mastodon" to everything I post on Mastodon. But like the author of this post, I feel uncomfortable tracking my readers like this.

Post reply on HN