Re: another approach to status codes, etc. in HTTP binding

Hey again,

(btw, I meant to say "202 (Accepted)", not "203 (Accepted)" previously)

7/18/2001 1:12:44 PM, Mark Nottingham <mnot@akamai.com> wrote:

>
>> In other words, I think we should allow SOAP applications to use HTTP
>> with all the bells and whistles that HTTP provides including using all
>> status codes and header fields. In other words, let HTTP be HTTP :)
>
>What I'm hearing, then, is that the HTTP binding (and bindings in
>general) should be expansive; e.g.,

I agree with the comments above, and spent some time thinking about this several weeks ago, including a (ongoing) 
discussion with Henrik about what to do about 3xx.  My conclusion is that while I definitely want HTTP's features to be 
used, a "SOAP response" only makes sense over a 200, as that's the only time (*) that the app gets a chance to send 
app data, rather than some other response-code-specific data.

For example, if a 201 response code is used (say a POSTed SOAP message resulted in a new resource being created), 
the response contains an entity body which includes URL(s) of where the created resource is located.  This should not 
be a SOAP message, as HTTP is prescriptive about the format of the body in that case (and other similar cases).

(*) 206 may be an exception, as it returns the response, but only part of it.  So a partial SOAP message could be 
returned.  But the chances of that message being a valid SOAP message (i.e. well formed XML) are basically zero, so 
I'm not sure what that means for the use of 206.  But to keep things simple, I think we should stick with just 200 for 
when a SOAP response is to be the payload.  Other response codes can be used when the response does not include 
a SOAP payload.

>* SOAP envelopes can be encapsulated in request messages which have a
>  method which permits an entity body (i.e., POST, PUT)

It should be POST-only.  PUT requires returning a 201 in some cases, and that has issues as described in my example 
above.  In the other cases, PUT doesn't return a body.

>* SOAP envelopes can be encapsulated in response messsages which have
>  a status code which permits an entity body (i.e., 200, 400, 500,
>  etc.)

I would expect that this would only happen when the format of the HTTP response body is not defined by 2616.  I 
haven't thought about this exhaustively for the different response codes, but I believe that this wouldn't be a useful 
feature.

>Thinking aloud, I'd be happy to take this approach *from a
>theoretical standpoint* (more about that later) if we specify that
>transport-related underlying protocol mechanisms (e.g., method,
>status code, etc.) have no effect on how the SOAP message is
>processed; i.e, their semantics are used to get the HTTP message (in
>this case) around, not to hint or affect SOAP processing.
>
>This is because if there were a relationship between protocol
>mechanisms and message processing, there would need to be a mapping
>between them, and this could get ugly quickly.
>
>The upshot of this is that the HTTP binding wouldn't specify ANY
>methods or status codes to use (except for the constraints as above),
>but merely reference the specification.  The onus is on
>implementations to assure that they can handle any messages sent
>their way by a particular binding.
>
>This is a fairly radical change to specifying particular status
>codes for particular SOAP messages, but I'm warming to it. 
>
>Thoughts? 

Ick, ack, phhht!

MB

Received on Wednesday, 18 July 2001 14:41:27 UTC