Earlier quoted context omitted.
and what server software is running this code in 1995?
CL-HTTP or AOLserver
sure looks like VB there, what’s the plugin? Didn’t see anything like that before.
I’ve banned query strings
161–170 of 317 posts
Re: I’ve banned query strings
#162Adding query strings is one of those things that I think a lot of sites could get away with more easily if they were reasonable about it. A link that is "https:// web.site" is fine. A link that is "https:// web.site?via=another.site" is fine. A link that is "https:// web.site?fbm=avddjur5rdcbbdehy63edjur5rdcbbdehy63ednddjur5rdcbbdehy63ednddjur5rdehy63ednddjur5rdcbbdehy63ednddjur5rdcbbdehy63edaaaddjur5rdcbbdehy63edndd…
There are addons to remove unnecessary params from the worst offending sites: https://www.google.com/search?q=clearurls+addon
Newer versions of Firefox also have a "Copy Clean Link" option in the right-click menu.
https://support.mozilla.org/en-US/kb/enhanced-tracking-prote...
Re: I’ve banned query strings
#163IMDB recently went haywire
they added these ugly qses into every click on their site, bonkers: ?ref_=nm_ov_bio_lk
Re: I’ve banned query strings
#164Earlier quoted context omitted.
> It should be immediately obvious that in that scheme 404 is indeed the correct answer to unknown query parameters That's not obvious at all. If I receive json data that contains a property I'm not aware of, i don't reject the entire document for that reason. In the case of query strings, extra query parameters might be used by other parts of the stack besides yours, so rejecting the entire document because someone…
> other parts of the stack As a web developer, you’re the like the guy standing with a clipboard outside a fancy club checking if people requesting entry are allowed or not. Basically, level 1 security. If someone is not on the list, your job is to default to declining them access, not granting them access assuming level 2 security will handle them at a deeper layer. It’s possible that the teams you work with expect…
>It’s possible that the teams you work with expect fuzzy behaviour from the website but that’s a choice, not a practice.
This is how the vast majority of websites work. The practical reason is obvious: when we model the behaviour our code depends on, we want to create the simplest possible model that allows our code to work as expected. Placing requirements on it that our code doesn't actually depend on is useless, unneeded, complexity.
> As a web developer, you’re the like the guy standing with a clipboard outside a fancy club checking if people requesting entry are allowed or not. Basically, level 1 security.
there is no security benefit to filtering out unneeded url parameters.
Re: I’ve banned query strings
#165Earlier quoted context omitted.
"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…
Also from the 414 page: >Complain to whoever gave you the bad link, and ask them to stop modifying URLs, because it’s bad manners. It's ironic that an error response so blatantly violating the robustness principle is throwing shade about bad manners.
The robustness principle was a mistake. The attitude it promulgated is a big reason why interoperability is so difficult.
Re: I’ve banned query strings
#166> curl, for example, seems to illegitimately strip a trailing question mark
(could be only for the command line, didn’t test library usage).
umm what? I don't know what they're actually sending where they think this, but if you think curl is broken you should re-think that maybe you're the one doing something wrong.
Here are some examples showing curl not stripping question marks (obviously), I am very curious what this person was actually seeing
$ curl -s 'https://httpbingo.org/get?' | jq .url
"https://httpbingo.org/get?"
$ curl -s 'https://httpbingo.org/get?path' | jq .url
"https://httpbingo.org/get?path"
$ curl -s 'https://httpbingo.org/get?path,query=bananas' | jq .url
"https://httpbingo.org/get?path,query=bananas"
$ curl -s 'https://httpbingo.org/get????' | jq .url
"https://httpbingo.org/get????"
$ curl -sv 'https://httpbingo.org/????' 2>&1 | grep :path
* [HTTP/2] [1] [:path: /????]Re: I’ve banned query strings
#167You 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…
> in form-urlencoded form, people were not savages
Oh yeah? I remember a lot of semicolons from Perl and other CGI stuff where we would now use ampersands, back in the day, both in the path and in the query. (Sometimes the ? itself would be written ;.)
Re: I’ve banned query strings
#168You 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…
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 responded 404, I somehow completely forgot how much of the web’s history the path has been useless for. Paths have won. No one really starts new things with URLs like /item?id=… any more. Yay!
Re: I’ve banned query strings
#169Earlier quoted context omitted.
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.
My next website is going to have the path portion of the URL be a base64 encoded ASN.1 blob.
So long as it starts with a slash, go ahead! See how long it takes for someone to figure it out.
It’s your website. Have fun with it! Do dumb things! :-)
Re: I’ve banned query strings
#170So 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.