- From: Steve Harris <steve.harris@garlik.com>
- Date: Tue, 25 Sep 2012 11:28:43 +0100
- To: Andy Seaborne <andy.seaborne@epimorphics.com>
- Cc: public-rdf-dawg@w3.org
On 2012-09-25, at 09:45, 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. 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. 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. > 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. - 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 11:03:23 UTC