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

So, if I read you correctly, you're advocating:

* SOAP envelopes can only be encapsulated in POST requests and 200
  responses, when the HTTP binding is used

* Other methods and status codes may be used as their semantics
  dictate, but these uses are not defined by the SOAP 'core'

Is this correct?



On Wed, Jul 18, 2001 at 02:41:26PM -0400, Mark Baker wrote:
> 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.


-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)

Received on Wednesday, 18 July 2001 14:52:47 UTC