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

Resource paths for nodeinfo/webfinger should not return HTTP 404 when the server is not configured for nodeinfo/webfinger #50417

Closed
tunloop opened this issue Jan 25, 2025 · 4 comments
Labels
0. Needs triage Pending check for reproducibility or if it fits our roadmap enhancement

Comments

@tunloop
Copy link

tunloop commented Jan 25, 2025

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

@tunloop tunloop added 0. Needs triage Pending check for reproducibility or if it fits our roadmap enhancement labels Jan 25, 2025
@joshtrichards
Copy link
Member

I can kind of see a 501 making sense, but a 404 does too:

https://datatracker.ietf.org/doc/html/rfc2616#section-10.4.5

Related: #49440

@tunloop
Copy link
Author

tunloop commented Jan 26, 2025

I can kind of see a 501 making sense, but a 404 does too:

https://datatracker.ietf.org/doc/html/rfc2616#section-10.4.5

Related: #49440

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.

@susnux
Copy link
Contributor

susnux commented Jan 26, 2025

It is not really a 501 as:

  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.

@susnux susnux closed this as not planned Won't fix, can't repro, duplicate, stale Jan 26, 2025
@tunloop
Copy link
Author

tunloop commented Jan 26, 2025

It is not really a 501 as:

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0. Needs triage Pending check for reproducibility or if it fits our roadmap enhancement
Projects
None yet
Development

No branches or pull requests

3 participants