Re: Returning HTTP codes with HTML descriptions.

On 3 Nov 2012, at 11:19, Andrei Sambra wrote:
> Given the context of this WG, I think it's safe to assume the primary consumer will almost always be an agent asking for RDF. I wonder if we're not going to overcomplicate things by trying to support too many formats.
> the interest of keeping things simple, maybe we should just go with RDF/Turtle for now (as a MUST), and leave other formats at the discretion of each implementation (as a SHOULD).

I disagree with any MUST in error handling.

HTTP has built-in error reporting through the status codes. This means that even if the client doesn't understand the body format, it at least can get at least a very general idea of the nature of the problem.

There are many sources where HTTP 4XX and 5XX errors may be generated. Some responsibilities may be handled not by the LDP server but by other intermediaries that sit in front of the LDP server. For example, access control or traffic throttling may be done by proxies or load balancers sitting in front. They will not respond with Turtle by default, and making them do so would be rather difficult. If error messages in Turtle are a MUST, then an LDP server becomes non-conforming if operated in such an environment.

I agree that defining a Turtle vocabulary for error messages would be very beneficial, and the Notthingham draft seems like a good starting point.

I would say:

* Servers SHOULD send entities with helpful error messages along with error responses
* The error messages SHOULD be in the format requested by the client
* Otherwise, they SHOULD be in Turtle
* As a fallback, text/plain is a pretty good compromise because it is reasonably useful both to machines (can be easily displayed in an error message in whatever URI) and to humans (not as pretty as HTML, but understandable).


Received on Monday, 5 November 2012 19:28:55 UTC