gen_tcp:recv - last segement when closed port

Per Hedeland hedeland@REDACTED
Mon Mar 13 00:35:17 CET 2006

"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
>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*.
>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.)


More information about the erlang-questions mailing list