gen_tcp:recv - last segement when closed port
Mon Mar 13 11:04:33 CET 2006
"Valentin Micic" <valentin@REDACTED> wrote:
>Did I read your message -- yes I did. Maybe I could ask the same question?
>I was not describing persistent connection -- client closes the connection
>after receiving the response.
You described a scenario (and quoted the corresponding RFC) that not
just presumes the existence of persistent connections, but where they
are the default - hence the need to use 'Connection: close' when you
don't want them.
The point here is that without a reliable Content-Length: header, "after
receiving the response" <=> "the server has closed the connection".
>The point I've been trying to make was that "initial success of web" had to
>rely on something more consistent
Good luck in making that point - since it provably didn't. There *are*
problems with this approach, see the caveat in my statement - but they
are not attributes of TCP or the standard socket API.
> More I think of
>it, more convinced I get that Connection header has been introduced to
>accommodate Mickeysoft, whilst persistent connection was just a side effect
Well, conspiracy theories and M$-bashing is always fun, but I think you
need a reality check here...
> Thus, the rest of the world uses *close*, and IE uses *keepalive* by
...and here. *Everything* uses persistent connections today.
>But I'd like to end this debate, as I'm finding myself more wanting to prove
>you wrong, than to contribute meaningfully -- and I don't like doing that.
>Can we agree that world is not ideal place, and that TCP, in all its
>implementations, is far from being perfect.
Sure - but it's not relevant here.
More information about the erlang-questions