Re: HTTP Status Codes for QueryRequestRefused

Kendall Clark wrote:
> 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.

I checked with WSDL CR:
http://www.w3.org/TR/wsdl20/#meaning

"""
A WSDL 2.0 service description indicates how potential clients are intended to 
interact with the described service.
"""
so other interactions (and I would include other sattus codes because status 
cdoes are visible as WSDL faults) that are not in the service description are 
not intended.

> 
> 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".

I can see two differences here:

1/ Date: etc are not visible to the client executing a SPARQL request as per 
the WSDL description.  Here I agree with you that not mentioned can mean it's 
open.

2/ Faults are in the WSDL description so 1 does not apply.

The description says "this rec intends that you use status codes 400 and 500".

> 
> (So, for example, as I understand SOAP, you can do all sorts of  
> arbitrary, intermediate message routing between endpoints.

This is not relevant as it is not visible to the client.

> 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.

That text does not work for me because it is about implementation and status 
codes aren't implementation - they are on-the-wire protocol.  It's a starting 
point though.


> 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.

That is better although it seems to read agains the meaning of a WSDL 
description as being the intended interaction.

What I'd like is to see that distinction between the SPARQL protocol and the 
underlying protocol to be drawn out.  It is this lack of layering that I see 
as leading to alternative readings as to what it applies to.  Because the WSDL 
#meaning is the "intended interaction" and SPARQL defined some faults, those 
become the intended ones.

"This document uses WSDL 2.0 to describe SPARQL
Protocol.  This does not replace any control or status
information associated with the transmission of a SPARQL request
nor receipt of the results of such a request."

	Andy

> 
> Cheers,
> Kendall
> 
>

Received on Friday, 6 January 2006 17:34:46 UTC