Live data from Hacker News

I’ve banned query strings

chrismorgan.info

241–250 of 317 posts

Re: I’ve banned query strings

#241
post #39

Earlier quoted context omitted.

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

This is because of a deeply annoying default in Apache, where for "security reasons" the underlying script doesn't get to see auth details that might already be handled by Apache. At some point they added the CGIPassAuth directive[1] but all kinds of other workarounds are floating around on the internet.

[1]: https://httpd.apache.org/docs/2.4/en/mod/core.html#cgipassau...

Re: I’ve banned query strings

#242
post #39

Earlier quoted context omitted.

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

[deleted]

Re: I’ve banned query strings

#243
post #238

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…

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

All 4xx errors are client errors.

400 is the general “bad request” client area, indicating something is wrong with the request but not being specific about what.

404 is simply a more specific client error: it means the client asked for a resource that couldn’t be found.

Re: I’ve banned query strings

#244

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…

I’m broadly anti-tracking: it’s generally against the interests of the individual. Query string additions are commonly used to track things. You can see that lots of people don’t want that by the existence of Firefox features like “copy clean link” and Extended Tracking Protection which proactively strips some like UTM parameters. Some sites happily participate in what I will glibly call the tracking economy. They ma…

I understand being for privacy, but on the flip side, information about you can result in a better experience. E.g. in the case of tracking where a person comes from, that can help those two websites improve by coordinating with each other in some way. Or your ads might actually show you something you didn't know you existed that you end up buying. That's probably better than seeing ads you likely have zero interest in. I'll admit it's creepy when an ad is incredibly tuned to your recent internet activity, though.

Re: I’ve banned query strings

#245

This url worked fine: https://chrismorgan.info/no-query-strings#:~:text=So%20I%E2%... but this one was too long: https://chrismorgan.info/no-query-strings?a=1

Doh! The part past the # does not go to the sever, so that wasn't a longer URL. How about: https://chrismorgan.info/%6e%6f-%71%75%65%72%79-%73%74%72%69...

Indeed, that's not a query string! The #, and following text, is a fragment, is client-side only, and isn't the subject of the blogpost. Neither is percent encoding, which is just another way to send the exact same path from your browser to the server.

Note that it has nothing to do with the length of the URL. That's just the error message he's chosen to use, because "4xx stop pissing about with my URLs" doesn't exist in the spec.

Re: I’ve banned query strings

#247

Earlier quoted context omitted.

I’m broadly anti-tracking: it’s generally against the interests of the individual. Query string additions are commonly used to track things. You can see that lots of people don’t want that by the existence of Firefox features like “copy clean link” and Extended Tracking Protection which proactively strips some like UTM parameters. Some sites happily participate in what I will glibly call the tracking economy. They ma…

I understand being for privacy, but on the flip side, information about you can result in a better experience. E.g. in the case of tracking where a person comes from, that can help those two websites improve by coordinating with each other in some way. Or your ads might actually show you something you didn't know you existed that you end up buying. That's probably better than seeing ads you likely have zero interest…

I started writing a follow-up half an hour before you posted, since the parent comment has been unusually highly voted. I dropped it again, but now you’ve given me something to respond to.

I say I’m broadly anti-tracking. I think it’s clear by this point to anyone with a skerrick of wisdom that the logical extreme of tracking is bad. But for a long way it seems innocuous. So how far do you go before declaring it unacceptable?

I hold myself to higher standards than I will hold others. For myself, I find it is most reliable not to start. I will occasionally show others this attitude or try mildly to recommend it, but largely that’s up to them.

I hate ads (in which I include billboards, newspaper ads, display ads, search ads, Facebook ads, sponsored posts, and a whole lot more; but not first-party stuff, and if it includes content not directly related to what you’re selling, it will probably be exempt too). I block ads as far as I can. Therefore I will never foist ads on others: t’were hypocrisy to do otherwise.

I like clean URLs and also hate precise tracking. Therefore if I send a newsletter-style email, it will include plain URLs that don’t track. So I can’t measure “campaign success”? C’est la vie. I’ll survive. I don’t want to scale anyway. I want people to respond by email, and respond to them. People are what matter in this life, even if I find computers far easier to deal with.

I dislike tracking where it is not functionally necessary. I confess that I haven’t yet taken this to the logical extreme of not recording server logs at all. I won’t ask clients what they are and where they’re from, but if they tell me, I will still record it for now, I guess. I might go more extreme on this in the future. But when some third party tries to force others to tell things unwittingly… that I don’t like.

Re: I’ve banned query strings

#250

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.

Another reason not to return a 404 in that case is that chances there will be monitor tooling in place that will treat a 404 as an "error" that will show up in your alerting, but would not be ideal; it will just be noise.
Post reply on HN