RE: Providing a short name for single-request-response MEP

Hi Mark,

The question that table 11 poses is, in the event that the given status
codes are returned, what is or should be their significance in the context
of a SOAP message exchange. The 202 status code allows an entity body...
which if present, if present, should signify (somehow) the status of the
request (extract below).

On the whole I'd be ok about saying nothing about status code 202 *if* it
were something that were never going to arise in a conforming
implementation.

In the context of a SOAP message exchange, when should a 202 status code be
generated (possibly never) and if generated how should it affect the
completion of the message exchange - eg. should any accompanying entity be a
SOAP message? should SOAP defined a content model for such a message, or is
it application dependent or is it a form of fault?

The tables were first drafted in October last year... it's a pity the
discussion they were intended to provoke is only just beginning to happen.

Regards

Stuart
--

<rfc2616>
10.2.3 202 Accepted

   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. There is no facility for re-sending a status code from an
   asynchronous operation such as this.

   The 202 response is intentionally non-committal. Its purpose is to
   allow a server to accept a request for some other process (perhaps a
   batch-oriented process that is only run once per day) without
   requiring that the user agent's connection to the server persist
   until the process is completed. 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.
</rfc2616>

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: 24 April 2002 03:44
> To: noah_mendelsohn@us.ibm.com
> Cc: Mark Baker; chris.ferris@sun.com; henrikn@microsoft.com;
> john_ibbotson@uk.ibm.com; marc.hadley@uk.sun.com;
> martin.gudgin@btconnect.com; moreau@crf.canon.fr; skw@hplb.hpl.hp.com;
> xml-dist-app@w3.org
> Subject: Re: Providing a short name for single-request-response MEP
> 
> On Tue, Apr 23, 2002 at 09:37:18PM -0400, 
> noah_mendelsohn@us.ibm.com wrote:
> > The SOAP MEP makes very clear that the SOAP response is
> > just that, the response to SOAP processing.  I believe
> > that our HTTP binding only handles the case where the
> > response is returned reasonably promptly, on the
> > still-open connection. 
> 
> Promptness isn't the issue, it's "when is a response a response" 8-).
> 
> And actually, what the binding says is incorrect.
> 
> http://www.w3.org/2000/xp/Group/2/04/11/soap12-part2-1.55.html
> #http-reqbindwaitstate
> 
> For a HTTP 202 response, it says;
> 
> "The Request Message has been received and processed. The entity body
> of the HTTP response MAY contain a Response Message."
> 
> which is incorrect, because a 202 response indicates only that the
> message has been accepted, not processed.  This means that the SOAP
> processing model cannot be assumed to have kicked in, which breaks
> the MEP in not nice ways.
> 
> At this point in time, I suggest that the easiest way out would
> probably be to remove any mention of the 202 code.
> 
> MB
> -- 
> Mark Baker, Chief Science Officer, Planetfred, Inc.
> Ottawa, Ontario, CANADA.      mbaker@planetfred.com
> http://www.markbaker.ca   http://www.planetfred.com
>

Received on Wednesday, 24 April 2002 05:28:15 UTC