RE: The deep difference between request/response and fire-and-forget

I would say that if closing the connection (wow, I originally typed that
as if close thing connection..) without waiting for a response is
invalid HTTP, THEN that means that HTTP can't do Fire and Forget AND
that an application that would be built on Fire and Forget couldn't be
deployed on HTTP.  To which I conclude this is yet another leaky
abstraction.  

I'm strongly against standardizing any MEP that can't be deployed on
HTTP.  That would be very very strange to standardize an MEP and not
standardize any bindings for that MEP.  It doesn't pass the giggle test
at all..

Another interesting related question: If it's illegal to close without
reading the return HTTP response, does that mean that an HTTP
intermediary MUST wait for the next node's response to faithfully pass
back?  Imagine intermediary closes with 202, but next node responds with
200 and body.  If it was legal to close without reading, then an
intermediary could interpret the close as signaling that it could also
close after sending..

Dave


> -----Original Message-----
> From: Rich Salz [mailto:[email protected]]
> Sent: Monday, January 23, 2006 1:23 PM
> To: David Orchard
> Cc: [email protected]
> Subject: Re: The deep difference between request/response and
fire-and-
> forget
> 
> > After this little bit of analysis, it seems that the only reason to
have
> > the 2 different MEPs is specify what a connection close after send
> > means, specifically what the next state is.  For faf, connection
close
> > after send means Success.  For r-ore that is different than faf,
> > connection close after send would mean Fail.
> >
> > However, I think that we can hit the 80/20 by providing a r-ore mep
and
> > specifying that connection close after send results in Success.
> 
> Last week I would have agreed.
> 
> Having been (re)educated by our HTTP guru, I now realize that closing
> the connection after sending your HTTP request, but without reading
the
> return HTTP response, is a breakage of HTTP...  ergo, don't do that.
> 
> 	/r$
> 
> --
> SOA Appliance Group
> IBM Application Integration Middleware
> * This address is going away; please use [email protected] *