W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2006

Re: HTTP Status Codes for QueryRequestRefused

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Wed, 11 Jan 2006 15:39:08 +0000
Message-ID: <43C5269C.2040408@hp.com>
To: Steve Harris <S.W.Harris@ecs.soton.ac.uk>
CC: RDF Data Access Working Group <public-rdf-dawg@w3.org>

Steve Harris wrote:
> On Tue, Jan 10, 2006 at 01:36:36 -0500, Kendall Clark wrote:
>>On Jan 10, 2006, at 1:01 PM, Seaborne, Andy wrote:
>>>Other than what?  I am just reading the spec and making an  
>>>interpretation. I'm not advocating a design change.
>>I believe that changing must to should changes the design.
>>One easy way to solve this:  if the WG agrees with you and wants  
>>should, I'll change it immediately. The problem is we are the only  
>>ones who seem to care about this, and I don't agree with you.
> I care, but I dont totally understand the issues (I'm WSDL illiterate). I
> want to be able to send back any reasonable HTTP code for uncommon
> conditions (eg. server segfaults, out of memory), but as far as I can see
> you both think that should be OK.

I certainly hope so.  The argument is now about when a service "refuses" a 
request because the text says:


This fault message *must* be returned when a client submits a request that the 
service refuses to process.

The one I have difficulty is how a security problem (403) is not a refusal by 
the service.

> However, apache returns 500 server errors when something internal goes
> wrong, and as my main HTTP mechanism is apache modules its out of my to
> control to return a non SPARQL 500 if something really bad goes wrong.
> OTOH I could argue that at that stage its just not a SPARQL service, as
> its not capable of processing anything at all.

This sort of condition is one I've encountered and started me off on all this.


> - Steve
Received on Wednesday, 11 January 2006 15:41:13 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:50 UTC