Re: Status of comment RC-2

On Sep 25, 2012, at 4:45 AM, Andy Seaborne wrote:

> 
> 
> On 24/09/12 22:32, Gregory Williams wrote:
>> On Sep 24, 2012, at 4:50 PM, Andy Seaborne wrote:
>> 
>>> Do we have a concrete example of such a limitation in existing software?
>> 
>> I know perl's Plack framework ignores http status messages that applications try to set:
>> 
>> https://github.com/plack/psgi-specs/issues/23
>> 
>> and the discussion on that page suggests that Ruby's Rack system has the same limitation. That being said, the discussion on that page also seems to indicate that the developer is open to fixing it in the future.
>> 
>> .greg
> 
> Thanks.
> 
> 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.

I agree with this, and it was my line or reasoning with Richard. However, just because I'm familiar with only these two cases doesn't mean there aren't a lot more (I didn't specifically ask Richard about his experience here).

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

I'm not sure the case for conneg is all that clear. Do clients commonly send accept headers for the error case?

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

Agreed.

.greg

Received on Tuesday, 25 September 2012 13:49:53 UTC