gen_tcp:recv - last segement when closed port

[Per Hedeland]

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

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

--Per