-
Notifications
You must be signed in to change notification settings - Fork 15
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
sending access control rules to the client in 401 body? #167
Comments
@bblfish After discussin it during the last call, do you still see need for more feedback or you can close this issue already? |
Nobody in the call was supportive of the idea, for essentially the reasons given above. |
Do not close an issue without recording a reasonable response to the points raised.
Did you mean to write "server" (instead of "client")? That PR didn't at all hint at including the content of eg. an ACL resource in the response body! What was mentioned was about structured error messages! |
(fixed client-typo) The main objection is that resources that return a 401 will need to return human readable content for say human readable content. That I think is similar to the content-negotiation issues. Of course the HTML could return RDFa come to think of it. The other point is that HTTP/2 has an optimization for returning content in advance when needed - though I heard it had been switched off by chrome. |
I still don't understand the purpose of this issue.. is it to explore the possibility? Did someone suggest it? Where? RFC 7231 says:
Including the required access control rules in the response body wants to give different semantics to the payload than what's intended by 7231. Not "violating" per se if we want to split hairs.. but definitely a stretch. |
Including the access control rules, seems to be compatible with what the text from RFC 7231 says, since the Access Control Rules tell the client what the next steps to follow are. I brought it up, as it is an option. Following the |
Link relation to an ACL resource conveys something different than the response body in a 401. The link relation is not an advertisement for how to resolve the error but indeed a client could make use of it towards resolving the error. I don't find dumping the authorization policies in the response body in and itself hints at "next steps" to resolve the error. If need to, it should be more explicit. As discussed, it could be incorporated into structured error messages (eg. solid/specification#28 ). For the use case specific to invalid or refused credentials (RFC 7235), the structured error message needs to express why the request was rejected. The inner structure / snippet that's to be included as part of the problem detail can be covered in this panel but the main issue on communicating structured error messages I believe should be addressed on the Protocol spec level. |
That is a very good point. There has to be space for expressing that the key is not valid or the credential does not fit, that there is not enough money on the bank account etc... That feels to me like a pretty conclusive argument. So I can see one would want some kind of machine readable response to say things like:
|
When returning a 401 the server can link to the access control resource using Link acl headers as in
The allows the client to fetch the description at that resource, as described in ACLs on ACLs. In HTTP/2.0 the content could be immediately pushed to the client too using "server push", to avoid the delay of a request.
But it is also reasonable to think the server could send the content in the body of the 401 as e.g. is hinted at in Inbox discovery PR).
Argument for pushing the data:
if the client did not connect with the right authentication credentials to begin with, then it did not know or remember the rules, so one might as well send those along.
Things that need to be worked on are:
• Is that going to conflict with other reasonable uses for returning content in a 401?
• Would the content be content-negotiated? How would that work on a 401 on an image, video, ms-word document, or cobol source code resource?
• is it reasonable to assume the client understands Turtle or JSON-LD in all these cases?
• should the returned content in the 401 be thought of as the content of the ACL? (but the the conned issue above)
These types of issues tend to make the simple answer of having the client fetch the ACL document be an easier starting point, especially as HTTP/2.0 server push makes the efficiency gains moot.
Other thoughts?
The text was updated successfully, but these errors were encountered: