RE: HTTP based async request-response

In that case, what I notice is that table 17 says "the HTTP request
SHOULD be retried" (not MUST). So a client could just always consider
the 3XX response to be a fault, and still claim to be compliant with the
binding you describe. I am not sure this could be a problem.

Ugo

> -----Original Message-----
> From: Marc Hadley [mailto:Marc.Hadley@Sun.COM] 
> Sent: Wednesday, February 02, 2005 2:51 PM
> To: Ugo Corda
> Cc: public-ws-async-tf@w3.org
> Subject: Re: HTTP based async request-response
> 
> 
> On Feb 2, 2005, at 5:44 PM, Ugo Corda wrote:
> 
> > So, if I understand your proposal well, in a WSDL 
> request/response the 
> > "out" message could be bound to a SOAP 1.2 Response MEP. But what 
> > would the "in" message be bound to?
> >
> Actually I think the whole thing is bound to the SOAP 1.2  
> request-response MEP - note that table 17 in [1] already 
> supports 3XX  
> status codes so you just need to follow what the HTTP spec 
> says to do  
> for 303 as I outlined.
> 
> Marc.
> 
> [1]  
> http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#http- 
> reqbindwaitstate
> 
> > Ugo
> >
> >> -----Original Message-----
> >> From: public-ws-async-tf-request@w3.org 
> >> [mailto:public-ws-async-tf-request@w3.org] On Behalf Of Marc Hadley
> >> Sent: Wednesday, February 02, 2005 1:46 PM
> >> To: public-ws-async-tf@w3.org
> >> Subject: HTTP based async request-response
> >>
> >>
> >>
> >> 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.
> >>
> >> 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.
> >>
> >> Marc.
> >>
> >> ---
> >> 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 Wednesday, 2 February 2005 23:04:45 UTC