Re: HTTP Status Codes for QueryRequestRefused

On Jan 6, 2006, at 10:45 AM, Seaborne, Andy wrote:

> Your reasons are that the document does not say anything about  
> other HTTP codes.

My reason is that silence is equivalent to permissibility. Or, put  
another way, I don't agree that a WSDL description proscribes  
anything, least of all every possible, legal HTTP status code or,  
say, header. I've never heard anyone say that about WSDL. I've heard  
people say the opposite, which is the reason it's called WS*D*L  
instead of WS*P*L.

>   My reading is that the document does talk about them by exclusion  
> because it says:
>
> """
> QueryRequestRefused
>
> This fault message must be returned when a client submits a request  
> that the server is unable or unwilling to process, perhaps because  
> of resource consumption or other policy considerations.
> """
>
> The "must be returned" means that for any condition (other that  
> MalformedQuery) QueryRequestRefused is to be used, restricting the  
> use of HTTP conditions such as "403 - Forbidden".

I don't agree... "is to be used *when the server is unable or  
unwilling to process the request"... I think, however, I will drop  
the "unable or" bit. QueryRequestRefused is supposed to be used for  
queries that the service refuses to answer, as opposed to ones it  
cannot answer (because, say, they are illegal). The doc explicitly  
says that there is no implication in QueryRequestRefused that  
subsequent invocations of the same operation will also be refused.

It's not supposed to be the catchall fault to be used in every other  
case except malformedness. If the document says that, I believe  
that's a bug. (I don't believe the document says that, but this  
confusion suggests it's not clear enough.)

>   Server errors like the front-end generated 502 also fall into  
> that category.
>
> if a SPARQL Protocol service supports HTTP bindings, it must  
> support the bindings as described in sparql-protocol-query.wsdl.
> """
> so that depends on whether the WSDL is prescriptive as to the range  
> of faults that that interface can return.  My understanding is the  
> WSDL is a complete description of the interface.

It's not a complete description in the sense of being prescriptive.  
How could it be? We're mostly (ignoring SOAP for a minute) using WSDL  
to describe some HTTP URIs and some subset of messages that software  
processes that are somehow connected to those URIs will consume or  
produce. But unless otherwise stated, the underlying semantics of any  
binding still apply. That includes, in the HTTP case, other HTTP  
status codes and headers and so on.

Consider an example. I have a service "fully described" (whatever  
that means -- here, yr using it as a synonym of "prescribed") by WSDL  
with HTTP bindings. Upon receiving a legal In Message, the service  
returns a legal Out Message, but it includes headers like this:

Date: Fri, 06 May 2005 20:55:11 GMT
Server: Apache/1.3.29 (Unix)
Connection: close

Under yr view, I should be able to find in the "fully described" WSDL  
for this interface the place where it says that an Out Message must  
include a Date: and Server: header. But it's not there because WSDL  
doesn't fully prescribe all underlying HTTP semantics or bits or  
bobs. Which leads me to conclude that implementers can return 403 or  
502 to their heart's content. Without us saying, in suitable spec- 
ese, "implementers can return 403 or 502 to their heart's content".

(So, for example, as I understand SOAP, you can do all sorts of  
arbitrary, intermediate message routing between endpoints. And, while  
I don't believe anyone's really implemented all of that, I do not  
think WSDL forbids any of that by not explicitly saying, in a "full  
description", that it may happen. Of course it may! Why aren't we  
also making an explicit statement about all of that?)

> You have mentioned that is not your reading of the document so  
> maybe just clarifying with some text will fine.  The minimum change  
> that would clear this up might be to clarify it in the HTTP section  
> with something like:

I prefer this:

"A SPARQL Protocol service may employ the full range of HTTP status  
codes consistent with the usage of QueryRequestRefused and  
MalformedQuery as describe in section 2.1.4."

But the reason I *don't* want to say this, ideally, is that it may  
suggest a wrong implication, namely, that in all *other* areas of  
HTTP semantics, except for status codes, the WSDL *does* constrain  
what implementers can do. WSDL is just a description of some  
messages, types, and how those are connected to HTTP things. But by  
singling this status code issue out, but not saying the equivalent  
thing across other parts of HTTP, the implication that status codes  
are special in this regard may be communicated.

I'd prefer something like this:

"Note that while this document uses WSDL 2.0 to describe SPARQL  
Protocol, there is no obligation on the part of   any implementation  
to use any particular implementation strategy, including the use of  
any WSDL library or programming language framework."

Which is already in the document. Maybe it can be broadened a bit to  
include the general issue you raise. Thus,

"Note that while this document uses WSDL 2.0 to describe SPARQL  
Protocol, there is no obligation on the part of any implementation to  
use any particular implementation strategy, including the use of any  
WSDL library or programming language framework, nor is there any  
limitation on the usage or semantics of the concrete protocols --  
HTTP and SOAP -- for which bindings are given, other than the  
explicit descriptions of behavior given in the bindings themselves."

That covers status codes and everything else in SOAP or HTTP.

Cheers,
Kendall

Received on Friday, 6 January 2006 17:04:22 UTC