Re: Returning HTTP codes with HTML descriptions.

+1 to mnot's I-D and big thanks to dret for pointing it out (as I was not aware of this - heck, how many I-Ds does Mark issue per month ??? ;)

> I think the server should honor Accept header when replying with error messaging too

+1

Should we maybe step back a bit and first ask ourself who the primary consumer of the message is? 

At least implicitly, Andrei seems to assume a human the primary consumer (?) - so, one scenario could for example be that the UA renders this message in some meaningful way, presents it to the human user and asks for confirmation or offers choices for next steps to overcome the current situation. In this case I'd certainly want either JSON or HTML and no RDF at all. The former in Ajax setups where the client uses the JSON to fill in UI elements, and the latter for good old, plain rendering.

However, I'm wondering, are there maybe also cases where the primary consumer is not a human user? What would this change? Should we take this into account and would then be RDF/Turtle the 'dominant' representation?

Cheers,
	   Michael

--
Dr. Michael Hausenblas, Research Fellow
DERI - Digital Enterprise Research Institute
NUIG - National University of Ireland, Galway
Ireland, Europe
Tel.: +353 91 495730
http://mhausenblas.info/

On 3 Nov 2012, at 03:46, Steve K Speicher wrote:

> Alexandre Bertails <bertails@w3.org> wrote on 11/02/2012 06:58:11 PM:
> 
>> From: Alexandre Bertails <bertails@w3.org>
>> To: "Wilde, Erik" <Erik.Wilde@emc.com>, 
>> Cc: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>, Andrei Sambra 
> <andrei@fcns.eu>
>> Date: 11/02/2012 06:58 PM
>> Subject: Re: Returning HTTP codes with HTML descriptions.
>> 
>> On 11/02/2012 09:45 PM, Wilde, Erik wrote:
>>> hello.
>>> 
>>> On Nov 2, 2012, at 12:54, "Andrei Sambra" <andrei@fcns.eu
>>> <mailto:andrei@fcns.eu>> wrote:
>>>> For example, applications may not "speak" LDP at start (i.e. misusing
>>>> REST verbs), thus resulting in '405 Method Not Allowed' errors. It 
> would
>>>> be nice to have some HTML describing what they did wrong.
>>> 
>>> instead of just using HTML, i suggest to have a look at
>>> http://tools.ietf.org/html/draft-nottingham-http-problem-01 and see 
> how
>>> well it would fit. i think pretty good. the next version is supposed 
> to
>>> add XML support (i'm working on a schema).
>> 
>> There are some interesting ideas in this spec, but in our case, the
>> client already understands RDF, so I don't see why we would return
>> anything but RDF for "problem details".
>> 
> 
> I think the server should honor Accept header when replying with error 
> messaging too.  This is what I've done in practice, the non-HTML could 
> always refer to some HTML page that could be fetched if additional human 
> readable details where needed.
> 
> 
> Thanks,
> Steve Speicher
> IBM Rational Software
> OSLC - Lifecycle integration inspired by the web -> 
> http://open-services.net
> 
>

Received on Saturday, 3 November 2012 04:48:34 UTC