"It’s my website: I can do what I want with it. "
Right on! It's so liberating having your own wee corner of the internet.
I’ve banned query strings
181–190 of 317 posts
Re: I’ve banned query strings
#182Earlier quoted context omitted.
Yea, empty response at a valid path. Isn’t 204 the code for it? Lots of REST libraries that I’ve used treat any 400 response as an error so generating a 404 when for an empty list would just create more headaches.
Libraries that automatically throw errors for status codes in the 400 and 500 ranges are pretty obnoxious (looking at you, axios). It adds unnecessary overhead, complexity, and bad ergonomics by hijacking control flow from the app. Responses with status codes in the 400 range are client errors, so the client shouldn't retry the same request. So a 404 is appropriate despite how annoying a library might be at handling…
Generally true although 429 is often used for rate limiting so a back off and retry is appropriate. 409, 412, 428 may also be retriable depending on the specific semantics of the given situation. 421 apparently shows up commonly in HTTP/2 connection reuse and is retriable. 423 and 425 too potentially.
It would have been nice if there was an actually grouping of retriable and not retriable but in reality it’s a complete mess.
But at a minimum beware of 429. That’s not a permanent outage and is a frequent one you might get that needs a careful retry.
Re: I’ve banned query strings
#183Earlier quoted context omitted.
That’s not an indiscriminate hierarchy. Grouping data by user is common and normal in computing: /home laid precedent decades ago. Project directories are an extremely common grouping within a user’s work sets. Yeah, some of us just dump random files in $HOME, but this is still a sensible tier two path component. The choice to make ‘view metadata-wrapped content in browser HTML output’ the default rather than ‘view r…
But the path misses param names (or types?). E.g who said the hex-encoded part is a commit hash? Maybe it's a tree hash, or just weird ref. Query strings are more verbose as force to give each param a name.
Which target audience of github needs extra verbosity in the commit hash, though? Once you know it you know it; if you don’t know git you aren’t the target audience; etc. Saying /user=foo is no better than ?user=foo if your audience can work it out without confusion from your unadorned paths. We have a great deal of history with filesystems showing that people are capable of keeping up with paths that lack key names if exposed to and familiar with them, and if the filesystem isn’t being constantly randomized.
Re: I’ve banned query strings
#184Earlier 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.
Make sure you use URL-safe base64 or the portions that looks like a path can get mangled
MII//epi
Is converted to MII/epi
Re: I’ve banned query strings
#185> 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 t…
$ curl -s 'https://httpbingo.org/get?' | jq .url "https://httpbingo.org/get" This may require further investigation.
Might be shell expansion? zsh uses `?` for filename expansion, others might as well: https://zsh.sourceforge.io/Doc/Release/Expansion.html#Filena...
Though I forget if any shell does stuff like that in quotes. Or printing oddities.
Re: I’ve banned query strings
#186Earlier 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.
A response code of 204 seems more appropriate but the problem is you're not allowed to send further information, which would make that descriptive response... not descriptive enough.
I think of it like this:
/users/ returns a 404 in an API means that this resource does not exist. As in, this is not a part of the API.
/users/123 returns a 404 means this user record does not exist.
Yes this means that a 404 is context dependent but in a way that makes it easier for a human to think of and reason about.
Re: I’ve banned query strings
#187You 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…
At the risk of naming an Eldritch horror, IIRC it was Cold Fusion that first adopted something like an MVC-in-querystring routing system in the late 90s or early 00s, and that eventually spread when FCGI caught on and users of other languages got used to long-running middleware processes. It seemed hella elegant at the time.
Re: I’ve banned query strings
#188Earlier 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…
The first layer of any web security should never be checking someone against a list, unless this can be done in less than a few milliseconds. It should only be sanity checking for basic compliance. In the analogy, this first layer should be denying entry to obviously drunk people, zebras, and a stampede of protesters.
Re: I’ve banned query strings
#189[dead]
Re: I’ve banned query strings
#190Earlier 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…
> 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…
[deleted]