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

On 1/23/06, Rich Salz <[email protected]> wrote:
>
> > 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.

I don't have any stake in the outcome of this discussion, but there's
no "breakage" when the connection is closed, because HTTP 1.1 cleanly
separates message semantics from connection state (HTTP 1.0, not so
much, though with responses, not requests).  Worst case, closing the
connection is an inefficient use of resources (the TCP connection),
and it trades-off determinism for simplicity of implementation. 
That's it, AFAICT.

Mark.