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.

I'm not so sure.  Why can't you do HTTP/FaF by saying that the HTTP server
response is consumed (per the HTTP protocol spec) but ignored?

> 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?

It depends on what type of intermediary it is.  See sec 1.4 of RFC 2616.

	/r$

-- 
SOA Appliance Group
IBM Application Integration Middleware
* This address is going away; please use rsalz@us.ibm.com *