-
-
Notifications
You must be signed in to change notification settings - Fork 110
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Consider requiring servers to respond to unknown APIs with a 400/404 #339
Comments
tbh this sounds like we're redundantly saying that servers should be http compliant, but it wouldn't hurt to spell it out. |
I guess the point is to clarify whether you should return a 40x or a 501 (https://tools.ietf.org/html/rfc7231#section-6.6.2). There's an argument that says 501 is a better match. |
Its fun that MDN thinks 501 is for when you can't handle the method, and that you can't return a 501 for GET or HEAD |
501 doesn't look like a proper response for "other problems" anyway. I'm afraid it boils down to an argument whether asking for extended functionality that the server doesn't support is a problem of the client or one of the server. I'd say that 501 is a good response for work-in-progress things supposed to be there as defined by The Spec but, well, not implemented yet, and 40x would be proper for completely off-the-wall requests not defined in a spec. That would also deliver the right message to the client: "Yeah, this thing should be here but is not, sorry" vs "We have no idea what you're asking of". |
This came up in matrix-org/synapse#11602 and it was suggested I poke at this again. By leaving this unspecified the ecosystem has diverged:
Synapse has some code to handle the differences between homeserver implementations for querying over federation. This is needed for e.g. the Currently I suspect that all servers and clients need to implement something similar to Synapse's logic to function properly -- leaving this unspecified has real-world impact. |
This would apply to all identity, push, and homeservers. It would allow things calling (new) APIs and being able to differentiate between the server not implementing the API vs other problems
The text was updated successfully, but these errors were encountered: