RE: HTTP based async request-response

I like the fact that the 503 has the ability to specify when to do the retry in the Retry-After header.
Still not quite certain that this represents all functionality we want with asynchronous messaging, but
still need some more time to think about it.

Michael Eder

-----Original Message-----
From: public-ws-async-tf-request@w3.org
[mailto:public-ws-async-tf-request@w3.org]On Behalf Of ext Anish
Karmarkar
Sent: February 02, 2005 06:13 PM
To: Marc Hadley
Cc: public-ws-async-tf@w3.org
Subject: Re: HTTP based async request-response



I like this proposal for doing a pull using HTTP.
Two comments below.

-Anish
--

Marc Hadley wrote:
> 
> I took an action to outline one approach to async request-response using 
> HTTP. Basically the request is sent as normal as the entity body of a 
> HTTP POST request but instead of returning the response in the HTTP 
> entity body, the server responds with a 303 (See other) status code and 
> includes a Location header that gives a URI from which the response can 
> be retrieved. The client then uses a new HTTP GET request to retrieve 
> the response. E.g.
> 
> Initial request:
> 
> POST /StockQuote HTTP/1.1
> Host: stockquote.example.com
> Content-Type: application/soap+xml
> Content-Length: nnnn
> 
> <env:Envelope xmlns:env="...">
>    ...
> </env:Envelope>
> 
> Response:
> 
> HTTP/1.1 303 See Other
> Location: http://stockquote.example.com/someuniqueidentifier
> Retry-After: 120
> Content-Type: text/html
> Content-Length: 0
> 
> Susequent request to retrieve response:
> 
> GET /someuniqueidentifier HTTP/1.1
> Host: stockquote.example.com
> 
> Response:
> 
> HTTP/1.1 200 OK
> Content-Type: application/soap+xml
> Content-Length: nnnn
> 
> <env:Envelope xmlns:env="...">
>    ...
> </env:Envelope>
> 
> If the response isn't yet ready the server can send back another 303 
> indicating when the request may be retried using the Retry-After header.
> 

Wouldn't it be a 503 (Service Unavailable) with a retry-after header 
rather than 303 (which says redirection)?

> I quite like this approach since it pushes the asynchrony down into the 
> HTTP layer and doesn't require anything new in WSDL or SOAP. The 
> existing SOAP 1.2 HTTP binding supports this usage.
> 

I believe we do need something new in WSDL and in SOAP for this.

1) This requires a new SOAP MEP for the POST part (essentially a one-way 
SOAP MEP). On second thoughts, one could still view this exchange as a 
request-response SOAP MEP with a new binding (there are only two SOAP 
envelopes involved) -- in which case I don't think we necessarily need a 
new SOAP MEP.
2) This requires a new SOAP HTTP binding as the current binding does not 
support the exchange as described in your email. The current binding is 
quite restrictive.
3) This requires a new WSDL binding or at least a feature/extensibility.

But this is a good reuse of the SOAP-response MEP (depending on how we 
structure/layer this) and quite simple (from an impl perspective) to do 
pull over HTTP.

My $.02

-Anish
--

Received on Thursday, 3 February 2005 12:51:51 UTC