-
Notifications
You must be signed in to change notification settings - Fork 303
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
Change translation error (500) to not acceptable (406) #1752
Change translation error (500) to not acceptable (406) #1752
Conversation
What was your use case. Was it text/html to RDFa ? RDFs are defined here Lines 27 to 38 in 83dad06
|
No, anything, that's not in that list Try, e.g.:
500 response is given with This is just a case where server can't provide a Turtle representation of that resource. It should be 406. See also:
200 response is given with |
Then there is an other issue. 406 should already be used. See node-solid-server/lib/handlers/get.js Lines 117 to 121 in 83dad06
|
If the selected representation's media type (what's stored on disk) is not in the list of serializable RDF media types, then no need to try to translate, and so should return 406. Only in the case when one of the RDF media types acceptable by the client that's also in the list of serializable RDF media types translation should be attempted. |
That's what the actual code tries to do and for to be checked reason is not doing in L117 |
What do you think of 65b04bb |
You can add tests in
|
There is the need to change 500 --> 406 in the following test. node-solid-server/test/integration/acl-oidc-test.js Lines 745 to 753 in 83dad06
|
@csarven I created a branch |
moved to #1755 |
The problem is that the server returns a 500 in a situation where it tries to parse a document that it can't parse as RDF, and says "Error translating between RDF formats". This happens when the request (Accept header) includes a media type of a concrete RDF syntax, and the server attempts to parse the document using one of its RDF parsers.
This is not a 500, "unexpected condition" per se. It is an expected condition.
The server should be responding with a 406, not acceptable, because client is asking for a particular representation of the resource (using an RDF media type) and the server is unable to provide one.
I think the flow of code leading up to this can be better / refactored but I didn't want to touch it in this PR.
Message to application developers: your application can get around the current issue (500) by including
*/*
(e.g.,*/*; q=0.1
) inAccept
, which is a reasonably useful thing to do but YMMV. Your application will then get a 200 representation (whatever the native format of the file/resource is on) instead of a 500. If this PR is merged, your application may get a 406 or 200, which is arguably better to work with than a 500.