search

solid / specification

Solid Technical Reports
https://solidproject.org/TR/
MIT License
494 stars 44 forks source link

Structured Error Messages #28

Open kjetilk opened 5 years ago

kjetilk commented 5 years ago

In NSS5, we implemented more detailed status messages to give clients more feedback. We should bring this along into the spec.

We have

This was not added in #13 and #26 .

csarven commented 5 years ago

Remind me, what's the implementation based on? Anything to do with https://tools.ietf.org/html/rfc7807 or some other standard or existing convention?

RubenVerborgh commented 5 years ago

Shall we first distill the problem we are addressing?

Then we can look into various solutions. I’m not a big fan of the reason phrase, as this is no longer present in HTTP/2, so will get lost (https://tools.ietf.org/html/rfc7540#section-8.1.2.4).

I think we should instead add details to the body.

acoburn commented 5 years ago

For machine readability, we could also make use of Link headers with rel="http://www.w3.org/ns/ldp#constrainedBy". That could point to an IRI that gives lots of additional information.

I would also note that, for authN and authZ errors, providing lots of additional data can leak security-related information that really shouldn't be conveyed to a client.

RubenVerborgh commented 5 years ago

+1 for the above as a third option.

Regarding security, agreed; this is what we started to convey in https://github.com/solid/specification/pull/13/files#diff-8d72b2ee1631b8eec737030e9b4a3c9cR37-R38 and https://github.com/solid/specification/pull/13/files#diff-8d72b2ee1631b8eec737030e9b4a3c9cR59-R60; we probably want to add more details.

Mitzi-Laszlo commented 5 years ago

Which Panel is this conversation associated to?

RubenVerborgh commented 5 years ago

None. Not all conversations are panel-bound.

kjetilk commented 5 years ago

:+1: to detail errors in RDF

csarven commented 4 years ago

https://github.com/solid/specification/issues/112 generalises this issue with server errors: https://github.com/solid/specification/issues/111 .

We agree on detailed errors in RDF in either response body or link relation (constrainedBy). For interop, we need to have a data model. See also https://github.com/solid/data-interoperability-panel/issues/29 as possible input.

csarven commented 4 years ago

Since the ldp:constrainedBy relation is for client errors, then only the response body in RDF can be used for both client and server errors.

csarven commented 4 years ago

Retracted the need for servers sharing additional error details: https://github.com/solid/specification/issues/111#issuecomment-647486154 .

Edit: Issue #44 covers link relation and resource describing the constraints.

The Security and Privacy Considerations section of the Solid Ecosystem spec ( https://github.com/solid/specification/issues/147 ) should include information along the lines of https://tools.ietf.org/html/rfc7807#section-5

csarven commented 4 years ago

Detailed messages for client errors and a resource describing the constraints are independently useful. They can be used together. For example, it is possible use a URI that is part of the Solid spec defining the constraint ( https://github.com/solid/specification/issues/44#issuecomment-648048614 ) as well as for server-controlled (pre-determined) constraints. Whereas the error message in response body can provide any and specific information in context of the fail.

ThisIsMissEm commented 2 years ago

RFC7807 is now in "last-call": https://twitter.com/httpapi_wg/status/1583141665639899136?s=61&t=R4e3GveO_jnwbe_Vbmq2Vg

Perhaps it'd be an idea to become compatible with that specification? There is also a proposal for publishing a JSON-LD context: https://github.com/ietf-wg-httpapi/rfc7807bis/pull/48