- From: Willy Tarreau <w@1wt.eu>
- Date: Wed, 4 Jun 2014 20:55:34 +0200
- To: Daniel Stenberg <daniel@haxx.se>
- Cc: Sébastien Barnoud <sebastien.barnoud@prologism.fr>, Michael Sweet <msweet@apple.com>, "William Chan (?????????)" <willchan@chromium.org>, HTTP Working Group <ietf-http-wg@w3.org>, Matt Menke <mmenke@chromium.org>
On Wed, Jun 04, 2014 at 08:14:47PM +0200, Daniel Stenberg wrote:
> On Wed, 4 Jun 2014, Sébastien Barnoud wrote:
>
> >I have several years ago used customized Curl and GSoap to automaticaly
> >retry requests on such a condition. As this is used for money transfer, it
> >is very important to distinguish retryable errors (connect timeout, ...)
> >from others errors (request timeout, ...). On a close, no retry is
> >possible except if the server replies with this 408. So i agree with you,
> >and i know that some application uses this feature.
>
> But then, curl doesn't read from the connection until after it has sent its
> request (or part of request) so the "problematic" case with getting a
> response before even sending a request will never be noticed.
No problem, it will be noticed *after* the request is sent when the
client waits for the response since it's present in the network buffers.
Look, first case is when network loses packets :
client SYN server
connect() ------------------------------------>
SYN-ACK
<------------------------------------
ACK
------------------------------------> accept() : timer starts.
POST /login
send(req) -----------------X packet lost due to MTU or radio
POST /login
-----------------X packet lost due to MTU or radio
POST /login
-----------------X packet lost due to MTU or radio
HTTP/1.1 408 + FIN
recv(resp) <-----------------------------------
POST /login
-----------------X packet lost due to MTU or radio
RST
close() ------------------------------------>
So as you see, client receives the 408 as a response to the request.
Second case is when there's a preconnect :
client SYN server
connect() ------------------------------------>
SYN-ACK
<------------------------------------
ACK
------------------------------------> accept() : timer starts.
wait...
HTTP/1.1 408 + FIN
<-----------------------------------
POST /login
send(req) ----------------------------------->
recv(resp)
RST
close() ------------------------------------>
Here the 408 is received because it was pending in the network buffers,
which is why people were seeing it in the case of the pre-connect.
Regards,
Willy
Received on Wednesday, 4 June 2014 18:56:02 UTC