gen_tcp:recv - last segement when closed port
Mon Mar 13 00:35:17 CET 2006
"Valentin Micic" <> 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 18.104.22.168:
>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