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

91–100 of 317 posts

Re: I’ve banned query strings

#91

Post by jameshart »

abecode wrote: post #82
jameshart wrote: post #70

There’s nothing ruder in hypertext etiquette than giving someone a link to navigate to someone else’s HTTP server, where you have manipulated that URL in some way unsanctioned by the server you are sending them to. You can’t just send arbitrary query string parameters to a server and assume they will just ignore them. Just like you can’t just remove query string parameters and assume the URL will work.

My use case for this is making separate bookmarks in different folders for a single URL: Example.com/interesting -> bookmark folder one Example.com/interesting?dummy=t -> bookmark folder two

Use #fragment identifiers then

Re: I’ve banned query strings

#92

Post by jameshart »

gojomo wrote: post #78
jameshart wrote: post #70

There’s nothing ruder in hypertext etiquette than giving someone a link to navigate to someone else’s HTTP server, where you have manipulated that URL in some way unsanctioned by the server you are sending them to. You can’t just send arbitrary query string parameters to a server and assume they will just ignore them. Just like you can’t just remove query string parameters and assume the URL will work.

In fact, you usually can just send arbitrary query string parameters to a server - that's why the behavior is so common, and often useful. Most sites don't mind or break, some sites get value from the behavior in ways hard to replicate in other ways – and those sites that don't like such additions can easily ignore them. And a few lines of code will work better than ineffectually appealing to manners, when the freedo…

Crafting outbound links with your own additions and handing them out to visitors to your site is similar to the practice of writing someone’s phone number on the door of a bathroom cubicle with ‘for a good time call:’ written above it.

You’re handing out someone elses’s contact details, but giving the person you hand them to a completely fabricated expectation for how the interaction will go.

Re: I’ve banned query strings

#93

Post by thayne »

jampekka wrote: post #16
1shooner wrote: post #9

>So I’ve decided to try a blanket ban for this site: no unauthorised query strings. His site returns (I think incorrectly) a 414 if a request includes a query string. If this protest is meant to advocate for the user, who presumably wasn't able to manage that string in the first place, why would you penalize them for it being there? Why not just use it as a cue to tell users how they can make this decision themselves…

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

You could also redirect to the url with the query string dropped.

Re: I’ve banned query strings

#94

Post by thfuran »

dredmorbius wrote: post #53
Aardwolf wrote: post #38

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

I'm willing to pay them $1 for a contact guaranteeing that they won't service such requests. That would make 451 the most appropriate.

Re: I’ve banned query strings

#95

Post by cortesoft »

odie5533 wrote: post #41
cortesoft wrote: post #28

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.

If you are sending out an email, you can use whatever url form you like?

This is talking about links to third party sites, not your own.

Re: I’ve banned query strings

#96

Post by ollien »

lucketone wrote: post #86
ollien wrote: post #37

Earlier quoted context omitted.

I don't think it's an abuse, RFC9110 defines 414 as a response for "refusing to service the request because the target URI is longer than the server is willing to interpret". Since adding a query string involves only adding characters, this seems fine; there's no stipulation as far as I can tell that all pages a server hosts must adhere to the same length. I'd be curious if any well-known clients interpret it that wa…

If the goal is to be misleading, but technically correct, it hits the bullseye

When the goal is "the funniest way", I think that's a hit :)

Re: I’ve banned query strings

#97

Post by paulddraper »

nrds wrote: post #62
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…

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.

How do you figure?

Paths are hierarchical; query strings are name/value.

(Note I speak of common usage.)

You can create a different convention, but that one is pretty dang useful.

Re: I’ve banned query strings

#99

Post by legitster »

phoronixrly wrote: post #46
legitster wrote: post #35

Earlier quoted context omitted.

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

Thank you for explaining to me that query parameters can be used for other purposes apart from tracking. The articles in question though, are railing against query parameters being abused for tracking purposes - passing referers (sic) and UTM by adding them to URLs of sites that neither process them, nor want them.

Referral query strings are not for tracking though. The person putting them on the links gets nothing out of them. There is no PII being shared. They are purely added out of courtesy.

If I am handing out maps to your address, letting people know who is publishing the map is generally a good thing.

This is like saying having a return to sender address on mail is an invasion of privacy.

Re: I’ve banned query strings

#100

Post by gritzko »

mikeocool wrote: post #74
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.

I dunno, it seems like the fact that we arrived at a fairly standard structure for URL paths that works pretty well is not a bad outcome. Seems a lot better than the other potential world we could lived in, where paths were a black box and every web server/framework invented their own structure for them.

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

Post reply on HN