gen_tcp:recv - last segement when closed port

[Valentin Micic]

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.
The point I've been trying to make was that "initial success of web" had to 
rely on something more consistent -- the argument is reinforced in HTTP/1.1, 
assuming that it builds on weaknesses identified in predecessor... not that 
anything was wrong with server closing the connection, however, the quote 
I've included implies that practice did not work as planned. If one put 
Microsoft into equation (and world was more Microsoft then than it is today) 
that always had their own set of ideas on how world should work -- it is 
quite feasible that server closure created some problems. 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 
;-). Thus, the rest of the world uses *close*, and IE uses *keepalive* by 
default.

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.

V.


----- Original Message ----- 
From: "Per Hedeland" <hedeland@REDACTED>
To: <valentin@REDACTED>
Cc: <erlang-questions@REDACTED>
Sent: Monday, March 13, 2006 1:35 AM
Subject: Re: gen_tcp:recv - last segement when closed port


> "Valentin Micic" <valentin@REDACTED> wrote:
>>
>>> Anyone who thinks that this procedure might lead to loss of data
>>> (assuming correctly functioning applications and available network
>>> connectivity) will have a hard time explaining the initial success of
>>> the web...
>>
>>How about this: client opens a connection, issues a request, receives a
>>reply and than closes the connection.
>>To quote from RFC 2616, paragraph 8.1.2.1:
>>
>><quote>
>>An HTTP/1.1 client MAY expect a connection to remain open, but would 
>>decide
>>to keep it open based on whether the response from a server contains a
>>Connection header with the connection-token *close*. In case the client 
>>does
>>not want to maintain a connection for more than that request, it SHOULD 
>>send
>>a Connection header including the connection-token *close*.
>></quote>
>>
>>See, not that hard at all ;-)
>
> I'm afraid I have no idea what you're trying to say here - did you
> actually read the message you're replying to? I described the HTTP
> request/response procedure *without* persistent connections - they
> didn't exist at "the initial success of the web", far less HTTP/1.1.
> (Though it seems I was wrong about the request being terminated by
> "simplex close" from the client, even if that would certainly have been
> a possibility - but RFC 1945 effectively specifies server close as the
> only reliable way to know when the response ends.)
>
> --Per
>