Re: Returning HTTP codes with HTML descriptions.

On 11/2/12 11:46 PM, 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.

Yes, plus the use of <link/> in <head/> as per my earlier comments.

Kingsley
>
>
> Thanks,
> Steve Speicher
> IBM Rational Software
> OSLC - Lifecycle integration inspired by the web ->
> http://open-services.net
>
>
>
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen