RE: HTTP based async request-response

I should add...

Looking at http://www.ietf.org/rfc/rfc2616.txt it is (was) not clear that it can also be used with other codes 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.

      Note: The existence of the 503 status code does not imply that a
      server must use it when becoming overloaded. Some servers may wish
      to simply refuse the connection.


14.37 Retry-After

   The Retry-After response-header field can be used with a 503 (Service
   Unavailable) response to indicate how long the service is expected to
   be unavailable to the requesting client. This field MAY also be used
   with any 3xx (Redirection) response to indicate the minimum time the
   user-agent is asked wait before issuing the redirected request. The
   value of this field can be either an HTTP-date or an integer number
   of seconds (in decimal) after the time of the response.

       Retry-After  = "Retry-After" ":" ( HTTP-date | delta-seconds )

   Two examples of its use are

       Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
       Retry-After: 120

   In the latter example, the delay is 2 minutes.
-----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.

Received on Thursday, 3 February 2005 17:17:19 UTC