this post was submitted on 22 Mar 2025
761 points (100.0% liked)

Programmer Humor

22854 readers
122 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 2 years ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 45 points 1 month ago (23 children)

That's not what HTTP errors are about, HTTP is a high level application protocol and its errors are supposed to be around access to resources, the underlying QUIC or TCP will handle most lower level networking nuances.

Also, 5xx errors are not about incorrect inputs, that's 4xx.

[–] [email protected] 29 points 1 month ago (8 children)

…HTTP is a high level application protocol and its errors are supposed to be around access to resources…

I’ve had fellow developers fight me on this point, in much the same way as your parent post.

“If you return a 404 for a record not found, how will I know I have the right endpoint?”

You’ll know you have the right endpoint because I advertised it—in Open API, in docs, etc.

“But, if /users/123 returns a 404, does that mean that the endpoint can’t be found or the record can’t be found?”

Doesn’t matter. That resource doesn’t exist. So, act appropriately.

[–] prowe45 3 points 1 month ago (5 children)

And it's not even always a simple case of "that resource doesn't exist". A 404 could also mean that the resource does exist but the current authenticated user doesn't have the correct permissions to access it, so it's more like "as far as you know that resource doesn't exist". Some people might argue that 403 should be used for that, but then you're telling potential bad actors that maybe shouldn't even have access to your documentation that they have indeed found a valid endpoint.

[–] [email protected] 1 points 1 month ago* (last edited 1 month ago)

I usually treat a path as a series of dereference operations, each with a potential security precondition. You could protect /secure/... with credential checks, and report 403 at that point, before even looking at the rest of the resource path. It exposes the prefix but not the multiple endpoints that might exist below that point.

load more comments (4 replies)
load more comments (6 replies)
load more comments (20 replies)