Re: HTTP based async request-response

On Feb 3, 2005, at 10:52 AM, michael.eder@nokia.com wrote:

> I agree, just like the functionality of Retry-After header
> because I am not sure just saying to keep trying to pull the response
> is a good option.
>
OK, that's what I intended in my original mail, sorry if that wasn't 
clear.

Marc.

>
> -----Original Message-----
> From: public-ws-async-tf-request@w3.org
> [mailto:public-ws-async-tf-request@w3.org]On Behalf Of ext Marc Hadley
> Sent: February 03, 2005 09:43 AM
> To: Eder Michael (Nokia-NRC/Boston)
> Cc: Anish.Karmarkar@oracle.com; public-ws-async-tf@w3.org
> Subject: Re: HTTP based async request-response
>
>
>
> I think 303 is closer to the semantic we want to convey than 503:
>
> 10.5.4 503 Service Unavailable
>
>     The server is currently unable to handle the request due to a
>     temporary overloading or maintenance of the server. The implication
>     is that this is a temporary condition which will be alleviated 
> after
>     some delay. If known, the length of the delay MAY be indicated in a
>     Retry-After header. If no Retry-After is given, the client SHOULD
>     handle the response as it would for a 500 response.
>
> 10.3.4 303 See Other
>
>     The response to the request can be found under a different URI and
>     SHOULD be retrieved using a GET method on that resource. This 
> method
>     exists primarily to allow the output of a POST-activated script to
>     redirect the user agent to a selected resource. The new URI is not 
> a
>     substitute reference for the originally requested resource. The 303
>     response MUST NOT be cached, but the response to the second
>     (redirected) request might be cacheable.
>
> Note that Retry-After can be used with 303 and 503.
>
> Marc.
>
> On Feb 3, 2005, at 7:40 AM, michael.eder@nokia.com wrote:
>
>> 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
>> --
>>
>>
> ---
> Marc Hadley <marc.hadley at sun.com>
> Web Technologies and Standards, Sun Microsystems.
>
>
>
---
Marc Hadley <marc.hadley at sun.com>
Web Technologies and Standards, Sun Microsystems.

Received on Thursday, 3 February 2005 16:14:46 UTC