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