- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Tue, 25 Sep 2012 09:45:24 +0100
- 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 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. 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. Andy
Received on Tuesday, 25 September 2012 08:46:55 UTC