Open michielbdejong opened 3 months ago
GET/HEAD
requests still require a 404? (If-Modified-Since
, If-None-Match
to non-existing resource)I think status code 404 should take precedence over 412. The reason for it is because with 404, the client knows that it was removed. The removal of a document gives client more information than modification, because with modification, it could be either:
This allows the client to decide their next course of action with a single request.
Right, if we let 412 take preference or not over 404 for methods that apply server-side changes, then we should probably take the same decision for letting 304 take preference or not over 404 for GET and HEAD.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-None-Match
When the condition fails for GET and HEAD methods, then the server must return HTTP status code 304 (Not Modified). For methods that apply server-side changes, the status code 412 (Precondition Failed) is used.
I see @darkdread's point (and I think @raucao is making the same point in his point 2.) that a 404 is more useful because it gives more specific information than a 412. After all, the information that the precondition failed can be derived from the information that the resource doesn't exist, but the reverse doesn't hold true, so that would in some cases be a waste of roundtrips.
OTOH, 404 is categorised as a "client error" by https://www.rfc-editor.org/rfc/rfc9110#name-client-error-4xx which also feels like the wrong category.
I think the balance is tipping towards letting 404 take preference, but I feel like we don't have a definitive basis for a decision yet.
We could also explicitly leave it up to the server but that would mean some clients would have to write extra code paths to deal with different server behaviours which I think is not nice.
@toomim you know a lot about conditional HTTP requests, what do you think the remoteStorage spec should say about this?
I think a better way to think about HTTP status categories is: Who must act to resolve the issue? For 4xx errors, the client must take action; for 5xx errors, the server (or gateway) must take action. So, 404 isn't an "error" by the client so much as the indication that its model is out-of-date
FWIW, S3 storage favors 404 over 412, when a resource doesn't exist:
NoSuchVersion The version ID specified in the request does not match an existing version. 404 Not Found
from https://docs.aws.amazon.com/AmazonS3/latest/API/ErrorResponses.html
I would favor 404 over 412, when a resource doesn't exist.
I think a better way to think about HTTP status categories is: Who must act to resolve the issue? For 4xx errors, the client must take action; for 5xx errors, the server (or gateway) must take action.
That's a great explanation!
It seems to me like 404 is the way to go then.
As reported via email by Walson Low:
My answer: