Don't timeout if socket is paused?

[ronag]

This is a bit different than how it works in node but I think it would make sense to not error if we have a socket timeout while the socket is paused due to back pressure? e.g. if the user is reading very slowly that is not an error with the request per se?

Not sure how this would interact with pipelining.

As an alternative I would like to be able to override socketTimeout on a per request basis.

Thoughts?

[ronag]

@mcollina @szmarczak

[mcollina]

You'd still need to error after all data has been processed. I'm not sure it's worth to handle this case.

[ronag]

You'd still need to error after all data has been processed.

How do you mean?

[mcollina]

Let's unwind a bit. Is the socket paused because of backpressure of data? Is a request in flight?

[szmarczak]

IMO timeout is a timeout no matter whether the stream has been paused or not.

[ronag]

IMO if the socket is paused any timeout is an error in user space, not in the request. I don't think the issue here is whether it's a timeout or not, rather is it a timeout in the request or not?

e.g. if I have a proxy and the client is preloading a file and chooses to wait with reading from it after creating the connection I think it should be up to the client to timeout or not, not the proxy (yes there should be an upper limit on the request time).

Take for example loading a video, where the first few frames are loaded and then waits for the user to press play.

[ronag]

Is the socket paused because of backpressure of data? Is a request in flight?

It's paused because the reader is currently not interested in more data.

[ronag]

I would at least like to be able to set different timeouts depending on whether it's the sender or receiver, e.g. in a proxy I would have a low timeout time for upstream sender but high timeout for the receiver.

[szmarczak]

Take for example loading a video, where the first few frames are loaded and then waits for the user to press play.

That's a very good point, makes sense. I agree from now on.

[ronag]

@kmamal @delvedor @Ethan-Arrowood opinions?

[Ethan-Arrowood]

Iirc isn't this a type of dos attack? Malicious user creates a bunch of slow/paused requests to a service, and with out the timeout said service will become clogged then not able to serve anymore requests. Maybe this is something different; sorry if I have it wrong!

But also I really like this idea for the sake of a video example you shared previously.

[ronag]

Iirc isn't this a type of dos attack? Malicious user creates a bunch of slow/paused requests to a service, and with out the timeout said service will become clogged then not able to serve anymore requests

Yes, but I think that should be handled on a higher level by having a longer request timeout or limit on number of sockets per client. It's a quite common and valid practice to have those connections for e.g. long polling with couchdb.

EDIT: Also this a problem for the server, not the client.
EDIT: I guess long polling has a heartbeat so it's not strictly a problem for them.

[ronag]

I think this can be resolved by

• Keeping, change default to 0, deprecating or removing socketTimeout.
• Implement a bodyTimeout on the higher level API's