202 in current implementation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

202 in current implementation

Yves Lafon

Dave,
As you mentionned that you know implementations using 202, do you know
what is their behaviour when there is an unmet mustUnderstand?
(sending back the mU fault instead of a 202, or is it completely hidden)
Also, do all implementations you know do the same?
Thanks,

--
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."

Reply | Threaded
Open this post in threaded view
|

RE: 202 in current implementation

Glen Daniels-2


A data point:

> As you mentionned that you know implementations using 202, do
> you know
> what is their behaviour when there is an unmet mustUnderstand?
> (sending back the mU fault instead of a 202, or is it
> completely hidden)

Apache Axis (and I believe Axis2 as well) sends a MU fault instead of
the 202.

--Glen

Reply | Threaded
Open this post in threaded view
|

RE: 202 in current implementation

Yves Lafon

On Fri, 31 Mar 2006, Glen Daniels wrote:

>
> A data point:
>
>> As you mentionned that you know implementations using 202, do
>> you know
>> what is their behaviour when there is an unmet mustUnderstand?
>> (sending back the mU fault instead of a 202, or is it
>> completely hidden)
>
> Apache Axis (and I believe Axis2 as well) sends a MU fault instead of
> the 202.

Thanks Glen!
This behaviour is more in sync with the ROR spirit, than just sending back
a 202, so if we decide to settle on the use of 202 (and I think that it's
where we are heading to), I propose to add this clarification on the mU
fault:
"If a mU fault has to be sent as part of the initial processing of the
request, it should be sent back to the originator instead of using a HTTP
202 return code."

--
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."

Reply | Threaded
Open this post in threaded view
|

RE: 202 in current implementation

noah_mendelsohn

Yves Lafon suggests:

> "If a mU fault has to be sent as part of the initial processing of the
> request, it should be sent back to the originator instead of
> using a HTTP
> 202 return code."

>From the definition for 202 [1]

"The request has been accepted for processing, but the processing has not
been completed.  The request might or might not eventually be acted upon,
as it might be disallowed when processing actually takes place."

So, I think we want to be careful not to commit the processor to having
done mU checking before sending a 202.  I think we might therefore say:

"In conformance with the HTTP specification, a 202 response allows for the
possibilities that any or all of the SOAP processing, or else no SOAP
processing, might have been done at the time the response is sent.  If
SOAP processing has been done, and if such processing has resulted in a
fault (including mustUnderstand faults), that fault SHOULD be returned
with a status code of 200, not 202.  If SOAP processing is deferred until
after a 202 response has been sent, then the disposition of any resulting
SOAP faults is beyond the scope of this specification. "

Maybe the wording could be tightened, but I think this makes clearer that
a 202 does not commit the receiver to having done any processing.  If WSDL
or WSA bindings to SOAP wish to mandate that mU checking be done before
deciding on the status code, then those specs may so specify.   I don't
think SOAP should preclude any options allowed by HTTP.

Noah

[1] http://www.faqs.org/rfcs/rfc2616.html

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------





Reply | Threaded
Open this post in threaded view
|

RE: 202 in current implementation

Yves Lafon

On Fri, 31 Mar 2006, [hidden email] wrote:

>
> Yves Lafon suggests:
>
>> "If a mU fault has to be sent as part of the initial processing of the
>> request, it should be sent back to the originator instead of
>> using a HTTP
>> 202 return code."
>
>> From the definition for 202 [1]
>
> "The request has been accepted for processing, but the processing has not
> been completed.  The request might or might not eventually be acted upon,
> as it might be disallowed when processing actually takes place."
>
> So, I think we want to be careful not to commit the processor to having
> done mU checking before sending a 202.  I think we might therefore say:

Well, if the processor doesn't do that, then the output is not a reply as
in "SOAP request reply with optional envelope", but more one way.

It is still possible ton consider this as being a underlying protocol gateway
(ie: not linked to the SOAP processing) from HTTP to JMS for example.

  >
> "In conformance with the HTTP specification, a 202 response allows for the
> possibilities that any or all of the SOAP processing, or else no SOAP
> processing, might have been done at the time the response is sent.  If
> SOAP processing has been done, and if such processing has resulted in a
> fault (including mustUnderstand faults), that fault SHOULD be returned
> with a status code of 200, not 202.  If SOAP processing is deferred until
> after a 202 response has been sent, then the disposition of any resulting
> SOAP faults is beyond the scope of this specification. "

So to summarize "if you get a 202, you can't conclude anything unless you
know the state machine of the targeted service"
Also a fault should be returned using a 4xx or 5xx.

> Maybe the wording could be tightened, but I think this makes clearer that
> a 202 does not commit the receiver to having done any processing.  If WSDL
> or WSA bindings to SOAP wish to mandate that mU checking be done before
> deciding on the status code, then those specs may so specify.   I don't
> think SOAP should preclude any options allowed by HTTP.

Well, it seems to stretch a bit the definition or RoR, but as we will not
produce a pure one way for HTTP, that might be the most pragmatic
solution, especially as there are already implementations around.

--
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."

Reply | Threaded
Open this post in threaded view
|

Re: 202 in current implementation

Anish Karmarkar
In reply to this post by noah_mendelsohn

[hidden email] wrote:

> Yves Lafon suggests:
>
>
>>"If a mU fault has to be sent as part of the initial processing of the
>>request, it should be sent back to the originator instead of
>>using a HTTP
>>202 return code."
>
>
>>From the definition for 202 [1]
>
> "The request has been accepted for processing, but the processing has not
> been completed.  The request might or might not eventually be acted upon,
> as it might be disallowed when processing actually takes place."
>
> So, I think we want to be careful not to commit the processor to having
> done mU checking before sending a 202.  I think we might therefore say:
>
> "In conformance with the HTTP specification, a 202 response allows for the
> possibilities that any or all of the SOAP processing, or else no SOAP
> processing, might have been done at the time the response is sent.  If
> SOAP processing has been done, and if such processing has resulted in a
> fault (including mustUnderstand faults), that fault SHOULD be returned
> with a status code of 200, not 202.

The status code in case of fault should be 4xx or 5xx not 200.

>  If SOAP processing is deferred until
> after a 202 response has been sent, then the disposition of any resulting
> SOAP faults is beyond the scope of this specification. "
>
> Maybe the wording could be tightened, but I think this makes clearer that
> a 202 does not commit the receiver to having done any processing.

+1
I certainly would not want to prevent the batching case.

There is one usecase (which has been discussed before) where sending a
202 with an envelope in the response requires MU processing (though I'm
not sure it needs to be reflected in our spec):

The receiver receives the message and sends a WS-ReliableMessaging ack
(which requires a SOAP env in the HTTP entity body of the response) back
to the sender. Per the WS-ReliableMessaging spec, to generate an ack (or
to even know that the envelope in the request was a Reliable message),
the receiver (or RMD in WS-RM parlance) must figure out the ID of the
WS-RM Sequence. This requires that the RMD process the wsrm:Sequence
SOAP header. And per the SOAP processing model, this would require that
the RMD perform the MU check. This of course does not require that the
receiver process other SOAP header or the SOAP body.

-Anish
--

>  If WSDL
> or WSA bindings to SOAP wish to mandate that mU checking be done before
> deciding on the status code, then those specs may so specify.   I don't
> think SOAP should preclude any options allowed by HTTP.
>
> Noah
>
> [1] http://www.faqs.org/rfcs/rfc2616.html
>
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: 202 in current implementation

noah_mendelsohn

Anish Karamarkar writes:

> [hidden email] wrote:
> > Yves Lafon suggests:
> >
> >
> >>"If a mU fault has to be sent as part of the initial processing of the
> >>request, it should be sent back to the originator instead of
> >>using a HTTP
> >>202 return code."
> >
> >
> >>From the definition for 202 [1]
> >
> > "The request has been accepted for processing, but the processing has not
> > been completed.  The request might or might not eventually be acted upon,
> > as it might be disallowed when processing actually takes place."
> >
> > So, I think we want to be careful not to commit the processor to having
> > done mU checking before sending a 202.  I think we might therefore say:
> >
> > "In conformance with the HTTP specification, a 202 response allows for the
> > possibilities that any or all of the SOAP processing, or else no SOAP
> > processing, might have been done at the time the response is sent.  If
> > SOAP processing has been done, and if such processing has resulted in a
> > fault (including mustUnderstand faults), that fault SHOULD be returned
> > with a status code of 200, not 202.
>
> The status code in case of fault should be 4xx or 5xx not 200.


Oops, you're right.  I was busy thinking that it should not be a 202, on which we seem to agree, and didn't remember that for errors we use the http error status codes.

> >  If SOAP processing is deferred until
> > after a 202 response has been sent, then the disposition of any resulting
> > SOAP faults is beyond the scope of this specification. "
> >
> > Maybe the wording could be tightened, but I think this makes clearer that
> > a 202 does not commit the receiver to having done any processing.
>
> +1
> I certainly would not want to prevent the batching case.


Good, we agree.  Thanks!

> There is one usecase (which has been discussed before) where sending a
> 202 with an envelope in the response requires MU processing (though I'm
> not sure it needs to be reflected in our spec):
>
> The receiver receives the message and sends a WS-ReliableMessaging ack
> (which requires a SOAP env in the HTTP entity body of the response) back
> to the sender. Per the WS-ReliableMessaging spec, to generate an ack (or
> to even know that the envelope in the request was a Reliable message),
> the receiver (or RMD in WS-RM parlance) must figure out the ID of the
> WS-RM Sequence. This requires that the RMD process the wsrm:Sequence
> SOAP header. And per the SOAP processing model, this would require that
> the RMD perform the MU check. This of course does not require that the
> receiver process other SOAP header or the SOAP body.


As you say, I don't think this belongs in our spec, at least for this MEP.  If someday someone wants to talk about conversational MEPS, we could, but I'm not in favor of doing so now.  There are in principle lots of places where someone may come upon a SOAP envelope and need for it to be processed as SOAP.  We only "own" the spec for that when it's part of an MEP.  In this case, I think the right way to do it is for us to say that the envelope may be delivered, and for the WSRM folks to write a SOAP binding that says basically:  "The SOAP Request/Response MEP and associated HTTP binding allow for delivery of an optional SOAP envelope with an HTTP status code 202, but neither calls for processing of such a response with the SOAP processing model.  WSRM does begin its processing of such messages by processing them with the SOAP processing model.  Note that if such processing results in a fault, the fault is to be {(sent in a request message back to node XXX), (made available locally but not transmitted to another node)} , or whatever WSRM actually wants.  In short, we deliver the message; they specifiy the SOAP processing.  I don't think this needs to be in an MEP, because it's not directly supported by bindings.  It's a convention layered on Request/Response.

Noah

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------