W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2012

Re: Status of comment RC-2

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Tue, 25 Sep 2012 11:46:12 +0100
Message-ID: <50618B74.4090506@epimorphics.com>
To: Steve Harris <steve.harris@garlik.com>
CC: public-rdf-dawg@w3.org


On 25/09/12 11:28, Steve Harris wrote:
> On 2012-09-25, at 09:45, Andy Seaborne wrote:
....
>>
>> I think making a change to adapt to one, or a very few, toolkits
>> (which might change anyway) is a bad principle.  It is not "many
>> cases".  HTTP has a mechanism; inventing another at the last minute
>> another to duplicate the functionality of HTTP is a bad idea.
>
> Reading http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html doesn't
> seem to encourage custom status lines to me. It says you MAY replace
> "reason phrases" by local equivalents.

or discourage :-)

> When we return error message their often quite verbose, and not
> appropriate to fit in a status line. The longest recommended reason
> phrase is 4 words long.

Agreed.

>> SPARQL 1.0 protocol didn't say anything about this.
>>
>> So it is not clear to me that making the change does in fact help
>> at all.  I do know it makes server side harder (servlets).
>>
>> HTML errors message are the default setup for Apache httpd, tomcat
>> and many other servers.  If we are not fixing the text, then the
>> text is for display and text/plain is not a good choice
>> (internationalisation issues for example).  Conneg applies.
>
> FWIW, 4store returns text/plain; charset=UTF-8. I think we used to
> return SPARQL Results XML, but consensus seemed to be around
> text/plain.
>
>> The best course of action is to submit a patch to the toolkit(s)
>> that does not expose the HTTP status line so that they do - that
>> will benefit lots of people.
>
> I don't agree that packing error messages into the status line is a
> good idea. Seems like an abuse of the protocol to me.
>
> I'm also surprised if most toolkits allow you to change the status
> text.

All the ones I have used do but, yes, the text is not really of much weight.

But that's not the proposal as I understand it.

My understanding is that the proposal is to normatively describe a
mechanism for passing back error messages.

It is not clear what for - as there is no definition of the error
messages its not for a programme to parse out (a json structure would be
easier anyway!) so I can only assume it's for display.  Existing servers 
(aside from specialied SPARQL endgines :-) send HTML by default.

So I don't see a proposal on the table at this point other than a vague 
"send text/plain in the body".  I think that is more harm than good to 
give it any weight.

And it mildly conflicts with SPARQL 1.0.

	Andy
>
> - Steve
>
Received on Tuesday, 25 September 2012 10:48:09 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:49 GMT