Re: SOAP 1.1 One-way HTTP Binding doc

Marc,

Good question.

Given that a 202 response is not related to the *processing* of the 
request message, one could 
conclude that any SOAP envelope carried in the 202 Accepted response might 
not necessarily
have a relationship with the request message at all. However, given what 
Mark observed, I suspect
that we might do well to specify that at a minimum, the SOAP processing 
w/r/t SOAP headers
MUST be performed before any response is generated, so as to ensure that 
if a mU fault
is generated, it can be transmitted on the HTTP response (with a 500).

So, my inclination would be (b)

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295

public-ws-addressing-request@w3.org wrote on 01/31/2006 10:22:51 AM:

> 
> 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.
> > 
> 
>