Re: SOAP 1.1 One-way HTTP Binding doc

Mark Baker wrote:
> 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
> 
Right, this chimes with my comments on the call last night. The envelope 
returned in the HTTP 202 response is something other than a reply to the 
envelope sent in the HTTP request. The question I'm struggling with is 
whether one can assume that the SOAP processing rules have been followed 
on the request envelope prior to the response envelope being returned or 
not ? E.g. if I include WS-Addr header blocks in the request envelope, 
can I assume that the 202 response envelope will contain the expected 
WS-Addr header blocks (e.g. relationship(msgid)). If the SOAP processing 
rules haven't been followed then what process lead to the generation of 
the 202 response envelope ? We've been using WS-RX as a use case but, 
AFAIK, WS-RX uses header blocks and relies on the SOAP processing model 
too so are we inventing a new two-stage SOAP processing model or what ?

In a nutshell, I think we need to decide whether the 202 response 
envelope is returned:

(a) Before SOAP header block and SOAP Body processing, or
(b) After SOAP header block processing but before SOAP Body processing, or
(c) (for completeness although this seems to contradict the 'Accepted' 
semantics of HTTP 202) After SOAP header block and SOAP Body processing.

Thoughts ?

Marc.

>>  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 Tuesday, 31 January 2006 15:24:01 UTC