Re: Status of comment RC-2

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 UTC