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 09:45:24 +0100
Message-ID: <50616F24.6010609@epimorphics.com>
To: public-rdf-dawg@w3.org

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


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.

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.

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.

Received on Tuesday, 25 September 2012 08:46:55 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:07 UTC