configure the timeout in TRestClient

[RobertoSchneiders]

This is a suggestion

It would be interesting if we could configure the timeouts (ResolveTimeout, ConnectTimeout, ConnectTimeout and ReceiveTimeout ) in the TRestClient.

The defaults timeouts are different between Indy and WinHTTP. Sometimes the default values ​​do not meet the needs. Currently it is not possible change them. Or is it?

To change the timeouts via WinHTTP just use this method: http://msdn.microsoft.com/en-us/library/windows/desktop/aa384061(v=vs.85).aspx

[fabriciocolombo]

Was seeing the similarities between the available connections, and the Indy connection only possess ConnectTimeout and ReadTimeout (ReceiveTimeout) options and do not possess the option to SendTimeout.

WinHTTP and WinInet have the SendTimeout option.

What do you think best, leaving only two options as Indy, or let the 3 options and ignore the SendTimeout setting in Indy?

[RobertoSchneiders]

I would consider WinHttp as default, so I think it would be interesting to create the 3 properties and ignore what does not exist in Indy.

[ronaldhoek]

I agree with Roberto

[RobertoSchneiders]

:thumbsup:

[ronaldhoek]

As far as I understand the 'ReadTimeout' in Indy is also used as the 'SendTimeOut'....

Basicly the 'PUT' (send) is processed the same way as a 'GET':

• Connect
• SendRequest (put/get)
• ReadResponse (put/get)

[fabriciocolombo]

From the Indy version 10.1.5 Printable Manual :

TIdIOHandler.ReadTimeout Property

Indicates the milliseconds to wait for a readable IOHandler connection.
ReadTimeout  is  an  Integer  property  that  represents  the  number  of  milliseconds  to  wait  for   completion  of  a  read  request  using IOHandler  read  methods.

TIdIOHandler.Readable Method
Indicates if the IOHandler is ready to perform a read request.

Looking at the source code, the ReadTimeout property is used in TIdIOHandler.ReadFromSource method, that's called among others from Readln and ReadBytes, but i dont see the ReadTimeout property have been used on Write's methods.

Is there a reliable way to test if the timeout in Indy is also used to SendRequest?

[ronaldhoek]

When sending data using 'PUT' it essentially call 'TIdCustomHTTP.ConnectToHost' (which uses the ConnectTimeOut) with the contentstream (Request.Source) to send to the server.

When using a 'GET' this property is 'nil'.

When looking into the 'TIdCustomHTTP.ConnectToHost' routine, at the end is the following statement:

if ARequest.Source <> nil then begin IOHandler.Write(ARequest.Source, 0, False);

This 'IOHandler.Write()' command essentially maps to 'TIdStackWindows.Send' routine, which essentially uses the (what I think) is the 'TIdStackWindows.WSSend'.

• which call 'IdWinsock2.send'

This does not seem to use any timeout at all - it seems to be able to just 'Send' the data without timeout.

To essentially fully complete the 'PUT' request, it does the same thing as a normal 'GET' - read the server data using the 'ReadTimeOut'

So therefor it 'looks' like it is using this 'ReadTimeOut' to complete 'PUT/POST' requests.

Because - this is a guess - sending data does not use timeouts, therefor it not 'needed' en is essentially the ReadTimeOut the time to wait for the request of the server AFTER the data has been send...

Effectively it does not need a 'SendTimeOut' because it's a combination of the 'ConnectTimeOut' and the time needed to send databytes and the 'ReadTimeOut'.

[Nashev]

For people like me, current proper link to TIdIOHandler.ReadTimeout property documentation online:

http://ww2.indyproject.org/docsite/html/frames.html?frmname=topic&frmfile=TIdTCPClientCustom_ReadTimeout.html