Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider requiring servers to respond to unknown APIs with a 400/404 #339

Closed
erikjohnston opened this issue Aug 7, 2018 · 6 comments
Closed
Labels
A-Client-Server Issues affecting the CS API enhancement A suggestion for a relatively simple improvement to the protocol

Comments

@erikjohnston
Copy link
Member

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

@turt2live turt2live added the enhancement A suggestion for a relatively simple improvement to the protocol label Aug 7, 2018
@turt2live
Copy link
Member

tbh this sounds like we're redundantly saying that servers should be http compliant, but it wouldn't hurt to spell it out.

@richvdh
Copy link
Member

richvdh commented Aug 8, 2018

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.

@erikjohnston
Copy link
Member Author

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

@KitsuneRal
Copy link
Member

KitsuneRal commented Aug 12, 2018

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".

@turt2live turt2live added the A-Client-Server Issues affecting the CS API label Sep 6, 2018
@clokep
Copy link
Contributor

clokep commented Dec 20, 2021

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 returns a JSON response with a code of 400 and M_UNRECOGNIZED in the body most of the time
    • It would return a 404 with an HTML body if an unknown prefix (e.g. /_matrix/client/v42) was requested -- note that the above PR should consistently return the JSON response in these cases too.
  • Dendrite and Conduit return an empty text body with a code of 404.

Synapse has some code to handle the differences between homeserver implementations for querying over federation. This is needed for e.g. the v2 vs. v1 join APIs.

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.

@turt2live
Copy link
Member

M_UNRECOGNIZED

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Client-Server Issues affecting the CS API enhancement A suggestion for a relatively simple improvement to the protocol
Projects
None yet
Development

No branches or pull requests

5 participants