RE: 2xx/202 and "a priori"

In most cases, RFC 2616 talks about a request being "fulfilled".
Regardless of whether one takes "fulfilled" to mean "processed", if a
request wasn't processed then HTTP wouldn't be an application protocol
but merely a transport. A HTTP 2xx means more than just an ACK, it does
mean that the request was fulfilled.

>Even ignoring what 10.2 says, the "2" has to mean the same thing
>for all 2xx response codes.  Any extension response code can not be
>interpreted to mean "succeeded", since the code may mean something
>like 202.  This interpretation is consistent with RFC 2616, from
>everything I've read, specifically 10.2.

For better or for worse, 202 was one of the very first HTTP status
codes. One could argue that it would be more appropriate as a 3xx class
than a 2xx but that is too late and has been so for a long time. This
doesn't really affect the role of status codes in HTTP, however.

>> The solution you point out is of course exactly the same as the "Ext"
>> mechanism in RFC 2774  but the reason that was introduced was because
>> many CGI scripts disregard the method name entirely. This is not
really
>> the case here as you are not going to throw HTTP/SOAP messages at
>> arbitrary URIs.
>
>Is this an assumption that we can make?  I was not assuming this,
>but I would agree that if we could assume this, that this issue
>goes away.

This is really what people do with HTTP already - they do have some
information about what a POST entity body looks like, or how to compose
a URI query string used in a GET, etc. The notion of not requiring a
priori knowledge is targeted at the amount of information needed in
order to start communicating. In HTTP, one can get bootstrapped with a
URI and a GET request. There is no reason why that wouldn't work for
SOAP endpoints as well.

Henrik

Received on Monday, 6 May 2002 23:16:09 UTC