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

231–240 of 317 posts

Re: I’ve banned query strings

#231

Post by glitchdout »

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?

Adblockers like umatrix have options like "Spoof Referer header". I have this setting enabled, so adding tracking query strings to URLs would go against my user preference.

Re: I’ve banned query strings

#232

Post by takethebus »

I was just thinking about something like this. Instagram and TikTok are major offenders, not everyone wants their personal info blasted everywhere because they copied a link. It would be great to have an iOS shortcut that automatically removes them, it's something I'm going to look into.

Re: I’ve banned query strings

#235

Post by progbits »

0x62 wrote: post #172
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…

It's marketing for the origin site. The line of thought is that the author sees significant traffic from xyz.com in the ref query string, and considers advertising or partnering with the origin site. Honestly, it is quite useful for niche/startup sites. I have been on both ends of conversations that began from seeing these in web analytics (as someone that saw incoming traffic from a site and reached out, and as some…

> sees significant traffic from xyz.com in the ref query string, and considers advertising

Why? Already getting traffic for free.

Re: I’ve banned query strings

#236

Post by kilburn »

ah1508 wrote: post #227
Sander_Marechal wrote: post #110

Earlier quoted context omitted.

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

If you enter a bookshop and you ask for a book that does not exist then it's definitely your mistake.

If you ask for a book they don't have it's a different matter.

In any case, when you ask for a book in a library you are using their "search" endpoint. The equivalent to opening a books/1 url would be asking for a specific instance of a book by serial number or so. Then it's clear that you made a mistake uf you do that for an unexistent serial number...

Re: I’ve banned query strings

#237

Post by nc0 »

Sniffnoy wrote: post #223
chrismorgan wrote: post #215

Earlier quoted context omitted.

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.)

As far as I know, platforms like YouTube and Twitter prefers using their own "link shorteners" (t.co etc) to track clicks and other metrics.

Re: I’ve banned query strings

#238

Post by Ekaros »

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…

No 400 is correct for bad request. As unknown query parameters is clear client error.

Re: I’ve banned query strings

#239

Post by Ekaros »

dylan604 wrote: post #191
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…

Wouldn't a generic 400 be better. It's not that the page wasn't found, but you've sent something that was not an accepted request. Fix your request and try again is how I've read it, and that's how I use it in the APIs I provide. I prefer it over 406 since it's not my end that can't process it. If your query string is tacking extra stuff trying to break things or just because your request wasn't crafted per the docs,…

406 would be wrong for me. As it is to be used when client sends Accept: header and server cannot fulfil that. HTTP return codes get quite specific when you read the actual description and not just name.

Re: I’ve banned query strings

#240

Post by chrismorgan »

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…

[dead]
Post reply on HN