Force timeout factor should be greater than 1

[gitsang]

https://github.com/zeromicro/go-zero/blob/422f401153b06526e187498c242254ac37ebc88d/rest/engine.go#L282-L296

If set factor less than 1, server will return nothing, but close connection directly.

It's weird for client to receive nothing.

# curl -ivvv -XPOST localhost:8888/v1
* About to connect() to localhost port 8888(#0)
*   Trying ::1...
* Connected to localhost (::1) port 8888(#0)
> POST /v1 HTTP/1.1
> User-Agent: curl/7.29.0
> Host: localhost:8888
> Accept: */*
>
* Empty reply from server
* Connection #0 to host localhost left intact
curl: (52) Empty reply from server

Beside, this timeout is get from global config. If I set global time to 3s, and another handler time out to 30s. Connection will always be closed in 3*factor second. Handler timeout would be disabled.

[gitsang]

感觉这个因数设置为 <1 并不合适，应该让服务有机会返回超时，而不是提前关闭连接，而且 <1 还有可能导致一些原本可以发完的请求或响应发送失败。也可能造成日志里都是 200，客户端却收不到响应。

考虑到 http 的 SetTimeout 操作是从 header 读取结束就开始的，实际到达服务，肯定会少个几毫秒，应该将因数设置为大于 1，这样服务才有机会返回超时信息。

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

---

I feel that setting this factor to <1 is not appropriate, it should give the service a chance to return a timeout instead of closing the connection in advance, and <1 may also cause some requests or responses that could have been sent to fail to be sent. It may also cause 200 in the log, but the client does not receive a response.

Considering that the HTTP SetTimeout operation starts from the end of the header reading, the actual arrival of the service will definitely be a few milliseconds less, and the factor should be set to be greater than 1, so that the service has a chance to return the timeout information.

[gitsang]

https://github.com/zeromicro/go-zero/issues/2140

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.