Re: SOAP 1.1 One-way HTTP Binding doc

On 1/31/06, David Hull <dmh@tibco.com> wrote:
>  We've been pretty clear for a while that empty 202 means "ack".  I'm
> hearing that non-empty 202 is meant for things like WS-RX acks, but I'm not
> sure this is nailed down.  There seems to be some possibility that a 202
> with a SOAP envelope could also be a real response.

It's still a response, just not the result of processing the request.

So if you took a SOAP envelope and sent it as an HTTP response with a
202 code, it would mean something entirely different than if sent back
with a 200 code... in the same way that a SOAP fault sent with 200
means something entirely different than a SOAP fault

>  If 202 can be a real response, then one would have to use something besides
> 202 to figure out what's really going on (e.g., whether the message consists
> only of WS-RX headers and similar).  In this case 202 isn't really carrying
> any information and why bother allowing for it?  On the other hand, if 202
> means something in particular, then what exactly does it mean?

Just what it says in the HTTP spec.

>  As far as I can tell, the value in non-empty 202 is telling the SOAP stack
> "Hey, this is just infrastructure stuff.  Don't pass it along to the
> application."  We can't say that here, but we could (probably) say it
> elsewhere.

202, like 200, is a symbol with application layer semantics, and as
such, it should be exposed to the application (plus the SOAP 1.2 HTTP
binding is a *transfer* binding).  In the case of 202, the application
needs to know that no subsequent message which includes "the results
of processing" of the initial request, is necessarily forthcoming (and
won't be without additional agreement).

BTW, I just noticed this part of the 202 spec which should probably be
highlighted;

  "The entity returned with this
   response SHOULD include an indication of the request's current status
   and either a pointer to a status monitor or some estimate of when the
   user can expect the request to be fulfilled."

Which suggests that a URI could be returned upon which the application
could invoke GET to determine the state of the processing of the
request (anybody remember CORBA "Futures"?).

Mark.

Received on Monday, 30 January 2006 23:36:45 UTC