Re: HTTP Status Codes for QueryRequestRefused

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.

>> because I have no more confidence that I'm going to convince you  
>> than  you probably have of convincing me. Or, put another way, I'm  
>> very  unlikely to be convinced of yr position, at least not w/out  
>> something  new.
>
> It is clear that you will not change the document.

I don't think that's especially fair or charitable.

I said I wasn't likely to be convinced by yr reading. And it's clear  
that I'll change the document if or when the WG says that's the  
design it wants. Or, if or when you convince me.

Let's see how much we can agree on. I think:

1. In HTTP bindings WSDL faults are serialized by (hence: constrain  
the meaning of) particular HTTP status codes
2. Hence, our design constrains the meaning of 400 and 500.
3. Implementers are free, given the text of WSDL and the HTTP spec,  
to return any other HTTP status code in any situation warranted by  
the meaning of the HTTP spec
4. If a service returns any HTTP status code other than 400 or 500,  
it's isn't actually returning a WSDL fault at all.
5. If a service receives a request with an illegal SPARQL query  
string, it should return MalformedQuery (hence: 400) and must not  
return 2xx.
6. If a service receives a request it refuses to process, it must  
return QueryRequestRefused (hence: 500).
7. If a service, or any intermediate host, returns any HTTP status  
code other than 400 or 500, it has not returned a WSDL fault at all.
8. Our spec shouldn't constrain what other HTTP status codes can be  
returned, because HTTP spec already covers this.
9. The two WSDL faults we've defined apply (equally!) to SOAP and to  
HTTP bindings.

Seems to me that the only thing we actually disagree about is what  
"refuses" in (6) means. You take it very broadly; basically,  
everything but MalformedQuery is the service refusing to process. I  
don't take it that broadly.

That means, I think, that we either need to make "refuses" more  
explicit, which we can do in many ways, or to redefine the fault  
completely, or to drop it.

Cheers,
Kendall
--
You're part of the human race
All of the stars and the outer space
Part of the system again

Received on Tuesday, 10 January 2006 18:36:45 UTC