>------- Original Message ------- >From : Arno Garrels[mailto:[EMAIL PROTECTED] >Sent : 9/17/2008 2:09:29 PM >To : twsocket@elists.org >Cc : >Subject : RE: Re: [twsocket] Early web server response
> I don't think it's current THttpCli's behaviour. How to handle > authentication methods depending on keep-alive with POST, if the > connection has to be dropped? Well, according to the RFC, this is not exclusive to authentication methods; *any* request could be "cancelled" at any time if the server decides to not accept it based on the headers. This means that after sending the headers, the client must ("should" according to the RFC) monitor for a response. Section 8.2.4 of RFC 2616 has something to say about this: 8.2.4 Client Behavior if Server Prematurely Closes Connection http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.4 "If an HTTP/1.1 client sends a request which includes a request body, but which does not include an Expect request-header field with the "100-continue" expectation, and if the client is not directly connected to an HTTP/1.1 origin server, and if the client sees the connection close before receiving any status from the server, the client SHOULD retry the request. If the client does retry this request, it MAY use the following "binary exponential backoff" algorithm to be assured of obtaining a reliable response: 1. Initiate a new connection to the server 2. Transmit the request-headers 3. Initialize a variable R to the estimated round-trip time to the server (e.g., based on the time it took to establish the connection), or to a constant value of 5 seconds if the round- trip time is not available. 4. Compute T = R * (2**N), where N is the number of previous retries of this request. 5. Wait either for an error response from the server, or for T seconds (whichever comes first) 6. If no error response is received, after T seconds transmit the body of the request. 7. If client sees that the connection is closed prematurely, repeat from step 1 until the request is accepted, an error response is received, or the user becomes impatient and terminates the retry process. If at any point an error status is received, the client - SHOULD NOT continue and - SHOULD close the connection if it has not completed sending the request message. ===END_OF_QUOTE Perhaps we can implement something like this? -dZ. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be