You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a very small ask, and should be considered lowest priority for the Nextcloud team.
Currently requests for the resource paths /index.php/.well-known/nodeinfo or /index.php/.well-known/webfinger return the following JSON: {"message":"nodeinfo not supported"} / {"message":"webfinger not supported"}
Along with an HTTP 404 code.
This is not the correct usage of 404. 404 is meant to indicate that the web server could/did not find the requested resource at that path.
It does not mean that the requested resource is not supported by the server.
The proper return code for this purpose should be a 501 (Not Implemented). Or, if any client code does not actually care about status codes and purely checks the JSON output, then it would be best to make these resources return a 200 code (since the resource was actually found - a JSON was returned, that counts).
The text was updated successfully, but these errors were encountered:
I'm not sure why you think that section 10.4.5 is applicable? The server has not found anything matching the Request-URI
webfinger/nodeinfo does return something at the request URI, it's a JSON that says unsupported.
This status code is commonly used when the server does not wish to reveal exactly why the request has been refused
This does not apply either, nextcloud server is returning a JSON saying why its refused.
The server supports the request (GET) - thats what that status code is for to check if the HTTP method is supported
Webfinger is implemented but not enabled.
Back to point 1: A webserver MUST not respond with 501 on GET and HEAD methods, both are required to be implemented and a 501 is not possible on those methods.
So the 404 is pretty valid as it communicates the client that this endpoint is not found / available.
1. The server supports the request (GET) - thats what that status code is for to check if the HTTP method is supported
2. Webfinger is implemented but not enabled.
Back to point 1: A webserver MUST not respond with 501 on GET and HEAD methods, both are required to be implemented and a 501 is not possible on those methods.
So the 404 is pretty valid as it communicates the client that this endpoint is not found / available.
The issue I am getting at is that the web server doesn't care whether or not the backend supports a feature or not. All the web server knows is that it received a request for /index.php/.well-known/webfinger and found a JSON to return to the client. From the web servers perspective, this should be a HTTP 200 OK.
A request was received and data was returned. Thats 200.
I'm not sure why HTTP 404 is even required when a JSON is returned with whether or not the feature is supported. Seems to me like the HTTP codes should be reserved for diagnosing whether or not the web server itself is functioning. A 404 for /index.php/.well-known/webfinger should indicate something is broken, then if its 200, check the JSON and see if webfinger is enabled/supported.
This is a very small ask, and should be considered lowest priority for the Nextcloud team.
Currently requests for the resource paths
/index.php/.well-known/nodeinfo
or/index.php/.well-known/webfinger
return the following JSON:{"message":"nodeinfo not supported"}
/{"message":"webfinger not supported"}
Along with an HTTP
404
code.This is not the correct usage of 404. 404 is meant to indicate that the web server could/did not find the requested resource at that path.
It does not mean that the requested resource is not supported by the server.
The proper return code for this purpose should be a 501 (Not Implemented). Or, if any client code does not actually care about status codes and purely checks the JSON output, then it would be best to make these resources return a 200 code (since the resource was actually found - a JSON was returned, that counts).
The text was updated successfully, but these errors were encountered: