Re: HTTP response code discussion

On Jan 11, 2006, at 2:33 PM, Mark Baker wrote:

>
> I've been following along ...
>
> Though I mostly side with Kendall, I think he's in error when he
> refers to HTTP 403 as a "transport" level error.  It is an application
> level error, because HTTP is an application protocol.

First, I don't concede that (1) HTTP is always in every usage context  
an application protocol (or that the best way to conceive of it is as  
an application protocol, or (2) that every error defined by an  
application protocol is necessarily an application-level error. In  
short, none of these terms is crisp or isolate enough to bear that  
kind of definitional or rhetorical weight. In particular, the  
distinction between "application" and "transports" is notoriously  
migratory. (So, for example, imagine that HTTP is an application  
protocol for the most part. Further imagine that someone decides they  
want to use HTTP, the application protocol, to transport some other  
kind or level of application, in which case it makes some sense to  
conceive of HTTP as an application protocol in some linguistic  
situations but as a transport protocol in some other linguistic  
situations. It's not *necessarily* one thing or the other. It may be  
both, relative to some set of interests and sensitive to some context.)

More to the point, I may have said that 403 is a transport level  
error, but nothing important rests on my having said it. What I have  
said dominantly is that 403 is merely an *HTTP* status code because  
none of our WSDL overloads it in order to serialize a *WSDL* fault.

Whether HTTP is a transport or an application protocol is not germane  
here. WSDL 2.0 says that WSDL faults are for application level bits.  
Thus, lacking any explicit serialization via any other HTTP code than  
400 or 500, every HTTP code other than 400 or 500 is *not* a WSDL  
fault and, thus, is an HTTP status code. In which case the meaning of  
that code is to be interpreted according to RFC 2116.

> IMO, WSDL's support for describing RESTful services is pretty poor, so
> if you're going to use it I'd highly recommend defining the WSDL
> *after* the HTTP interface is completely defined, so as to prevent
> these problems with WSDL from messing up your messages.

The latest CR draft is much better IMO (that doesn't mean it's  
*great* for this purpose, but it's less poor than it was).

>   So if you
> need a corresponding WSDL fault in order to permit an HTTP 403
> response to be interpreted with QueryRequestConfused semantics, then I
> think that should be defined.

Yeah, if we wanted a WSDL level fault like that, we'd define one and  
serialize it with HTTP 403. But Andy's point, inasmuch as I  
understand it, has been that (1) we can't return anything but 400 or  
500, per our spec; and (2) the use of "refuse" in QueryRequestRefused  
and HTTP 403 is problematic in some way.

No one has shown much interest in defining additional WSDL faults,  
though I have proposed to simply remove QueryRequestRefused altogether.

Thanks for your comments, Mark.

Cheers,
Kendall

Received on Wednesday, 11 January 2006 19:56:07 UTC