RE: The deep difference between request/response and fire-and-forget
Rich Salz <[email protected]>
| Newsgroups | gmane.text.xml.distributed |
|---|---|
| Message-ID | <[email protected]> |
> 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 [email protected] *