W3C home > Mailing lists > Public > xml-dist-app@w3.org > January 2006

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

From: Rich Salz <rsalz@datapower.com>
Date: Tue, 24 Jan 2006 00:08:08 -0500 (EST)
To: David Orchard <dorchard@bea.com>
cc: "xml-dist-app@w3.org" <xml-dist-app@w3.org>
Message-ID: <Pine.LNX.4.44L0.0601240003440.7794-100000@smtp.datapower.com>

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


SOA Appliance Group
IBM Application Integration Middleware
* This address is going away; please use rsalz@us.ibm.com *
Received on Tuesday, 24 January 2006 05:08:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:28 UTC