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

On 1/12/06, noah_mendelsohn@us.ibm.com <noah_mendelsohn@us.ibm.com> wrote:
> I'm not convinced.  Rich and I have agreed that the reason it doesn't work
> isn't quite the one I said in my note last night, but I still believe that
> HTTP is a request/response protocol, and that it's always good practice
> for the receiver of an inbound HTTP request to respond with a status code
> (I.e. a response) as opposed to just closing the connection.  Any HTTP
> experts want to disagree with me on that?

I suppose you could consider it "good practice", but I'm not sure
that's such an important consideration.  What seems much more
important to me is that the interaction-sans-response remains
semantically unambiguous, which it would.

Even if it's the client that closes the connection or otherwise
ignores the response, there's no ambiguity about the meaning of the
interaction.  The only downside, in both cases, is that the resulting
state of the system is indeterminate from the client's POV (modulo
what can be inferred via the use of safe and/or idempotent request
semantics).  But presumably the client is aware of the tradeoffs.  And
in the case of the server closing the connection, the client has to be
prepared for that anyway in the case of a network problem or failure
on the server.

Cheers,

Mark.

Received on Friday, 13 January 2006 15:07:48 UTC