W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Question on HTTP 408

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>
Message-ID: <20140604185534.GD3154@1wt.eu>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC