Re: Status of comment RC-2

On 2012-09-25, at 11:46, Andy Seaborne wrote:
> 
> 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.

OK, I think I got the wrong end of the stick.

> 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.

I think at this point display is all we can expect.

> 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.

Something informative, suggesting that people return text/plain (or whatever is the consensus) seems beneficial, I'm not sure about anything normative.

> And it mildly conflicts with SPARQL 1.0.

Yeah, but so does common practice (as I understand it). Totally ignoring the fact that common practice is mildly different from what's written in SPARQL 1.0 doesn't seem ideal either.

- Steve

-- 
Steve Harris, CTO
Garlik, a part of Experian
+44 7854 417 874  http://www.garlik.com/
Registered in England and Wales 653331 VAT # 887 1335 93
80 Victoria Street, London, SW1E 5JL

Received on Tuesday, 25 September 2012 15:43:09 UTC