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.

Received on Thursday, 3 February 2005 14:42:45 UTC