Live data from Hacker News

I’ve banned query strings

chrismorgan.info

51–60 of 317 posts

Re: I’ve banned query strings

#51
post #49
post #45

edit: not true https://news.ycombinator.com/item?id=48077990 "I don’t like people adding tracking stuff to URLs" and "You abuse your users by adding that to the link" and "no unauthorised query strings" and "At present I don’t use any query strings" but for some reason ?igsh, which i'm pretty sure is an instagram tracking parameter, is allowed. weird

?igsh doesn't get through for me, and I don't see any links on the page including it.

oh, it's uBlock Origin (non-lite) removing it without telling me at all. retracted

Re: I’ve banned query strings

#52

Earlier quoted context omitted.

You can read some of the issues people have had with this by reading up on the http referer header: https://en.wikipedia.org/wiki/HTTP_referer There are a lot of reasons I might not want a site to know where I came from to get to their site. It is basically sharing your browsing history with the site you are visiting. Because of this, there have been a lot of updates to the http referer header, with restrictions on w…

If I send out an email campaign, I can't use custom http headers to know that a user arrived from the newsletter.

As your reader, I might not actually want you to know.

Re: I’ve banned query strings

#53

> 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 431 are also for specific conditions which aren't relevant here.

- 300 or 500 errors are inappropriate as this isn't a relocation or server-side failure, it's a client-side request problem.

Teapot or too long seem best bets.

Re: I’ve banned query strings

#54
post #30

Earlier quoted context omitted.

The robustness principle is itself bad manners, in plenty of contexts. If I deliver packages by throwing them at the customer, I really want a customer to tell me "hey, don't throw packages at me!" before I attempt to lob something fragile and breakable, or something heavy at someone fragile and breakable. Otherwise, how am I supposed to learn that I'm doing anything wrong?

This is the point this has delved into internet crankery.

No, it's a fairly uncontroversial take. See https://en.wikipedia.org/wiki/Robustness_principle#Criticism and the "See also" section.

Re: I’ve banned query strings

#56
post #39

> It is a small, decentralised, self-hosted web console that lets visitors to your website explore interesting websites and pages recommended by a community of independent personal website owners. Back in the Stone Age, we called these “Webrings,” but they weren’t as fancy. One of the issues that I faced, while developing an open-source application framework, was that hosting that used FastCGI, would not honor Auth h…

> an open-source application framework, was that hosting that used FastCGI, would not honor Auth headers So you were writing your application as a fcgi-app, and (e.g.) Apache was bungling Auth headers? Can you expand on this? Curious about the technical detail of (I guess) PARAM records not actually giving you what you expect?

I don’t remember, exactly. Long time ago (I stepped away from that project many years ago).

I just remember the auth headers never showing up in the $_SERVER global (it was a PHP app). This was what I was told was the issue. They made it sound like it was well-known.

Re: I’ve banned query strings

#57

> 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

Of course they do. For example you can lower a string from the top to query the fill level. Or you can wrap a string around the pot to query the circumference.

Re: I’ve banned query strings

#58
post #47
post #43

Earlier quoted context omitted.

Do you really need to? Basic statistics will tell you if the email campaign had any significant effect on site visits.

If I release a video and send an email newsletter at the same time, which one caused the traffic increase? Should I invest in making more videos of sending more emails?

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.

Re: I’ve banned query strings

#59
This is genius, kudos Chris.

It also makes me wonder what other noxious online behaviours might be addressed through ... creative ... client-side responses similar to this.

We've already seen, for years, sites attempting to socially-condition people over the use of ad-blockers and Javascript disablers. No reason why the Other Side can't fight back as well.

Re: I’ve banned query strings

#60
While I don't take the author's hard stance, I do hate gratuitous query params that result in links that are thousands of characters long.

I use this bookmarklet to strip query params before sharing a link:

    javascript:(()=>navigator.clipboard.writeText(location.origin+location.pathname))();
Post reply on HN