Hi Joseph:

In message <1533079791.45.0.56676864532.issue2550750@psf.upfronthosting.co.za>,
Joseph Myers writes:
>Joseph Myers added the comment:
>
>There was some inconclusive discussion of this patch two years ago.  Is
>it OK to push with an appropriate CHANGES.txt entry?

The problem as I see it is client had a failure to download
something. The client may never be able to download it because it
takes longer than the defaultimeout to send it. With your patch, this
failure is invisible to the admin.

My memory is hazy, but I think timeout was while sending the response
to a request. So it was large files, long tickets etc. especially on
slow links, low power devices (e.g. cell phones). 

Ideally when the error is raised the server should restart/continue
the send using a larger timeout value up to some maximum. But I am
not sure that is possible.

IIRC from my socket programming decades ago what is probably happening
under the hood is the socket is in non-blocking mode and EAGAIN or
EWOULDBLOCK is being returned. On each return, some timer is checked.
If the timer is exceeded it raises timeout, if not more data is sent.

I think we would need to operate at the EAGAIN or EWOULDBLOCK
level to continue the transfer. But my guess is the socket is dead
by the time we see the timeout.

I think setting a larger timeout (using settimeout()) before the reply
is sent to the client is what is needed. So we have different timeouts
for the accept, request, response and close parts of the client
communication.

If we can't do the ideal thing, would making the defaultimeout value
settable in config.ini be a better way to handle this. That way the
admin can try to avoid the error by increasing the timeout. This has
the downside of making a DOS easier. With this the admin will still
get a notice if the timeout is exceeded.

To go with the settable defaultimeout value, (now that random() works
8-)) only send email occasionally (say 10% of the time) but log every
failure to the log file.

One thing that would be useful, if it is not already in the code, is
to report the url that caused the timeout. I am not sure if it's
available though.

In any case that's why I have your patch shelved in my development
repo and never pushed it.

Does that clarify my concerns and possibly better ways to handle this
issue?