This is a better fix for the server side.
The difference is that this one will give up after 10 seconds rather than
getting stuck forever.
Although this is unlikely to make anything worse (unlike previous version),
I'm not sure that it is optimal, and frankly, I don't understand the use of
the protocol well enough (yet) to decide how it should be adjusted, if at
all.
For instance, I am using the number of bytes read as the mechanism for
determining if the entire request has been read, and I'm using 1 byte as
the threshold. What happens if the request is 100 bytes long and we read 17
bytes? How can we tell that we have read to the end of the entire request?
Does a request always terminate with '\r' or '\r\n'? I'm not sure if it
does or not, and frankly, it may depend on the implementation of the
client. The two lines immediately following the bulk of this patch suggest
that requests may not always end in '\n'.
If someone can say for certain that a request will *always* have a '\r' in
the last or second-to-last byte, then ideally, we could read until we find
that byte, and then continue.