请问默认状态下 FastAPI 的 GET 请求超时时间是多少？

[Richard14]

按照 fastapi 官网提供的代码，按默认设置搭建的简易服务器，想问一下如果某个操作特别耗时（比如耗时五分钟才能得到结果），用户在浏览器里发出这个请求以后太长时间没有响应是不是会被阻断？

还是说 http 默认会有一个心跳来确保这个请求可以无限延长？

这种行为是谁说了算的，是 http 协议里规定的，还是客户端 chrome 浏览器决定最大超时时间，还是后端的 nginx 决定最大超时时间，还是 uvicorn 决定最大超时时间？

网上搜了搜没什么相关信息。。

[mimzy]

我有的任务经常会跑半小时以上，直接请求 uvicorn 没断过。

[janxin]

连接双方都可以决定什么时候关闭。不过为什么不考虑 long-polling 呢？

[wangyu17455]

关键词 tcp keepalive ，http1.1 没有心跳这种东西

[Vegetable]

浏览器和 nginx 都可能会后，nginx 应该是一分钟左右，浏览器更长。uvicorn 和 fastapi 应该是没有这方面限制。

[est]

gunicorn 有个默认 60 秒。

[ospider]

这种应该用 FastAPI/Starlette 的 BackgroundTask 异步执行，然后前端轮询 /websocket 查询进度。

[Richard14]

@est
@Vegetable
@wangyu17455 谢谢回答，所以很清晰了，tcp 默认有心跳确保长连接，http1.1 无限制，nginx 默认一分半，gunicorn 默认 1 分钟，uvicorn 和 starlette 默认无限制，所以要确保连接需要修改 nginx 和 gunicorn 的默认设置，另外浏览器也有限制但是比较长。

所以 chrome 具体是多长来着，好像有模糊的印象听谁以前说过是五分钟还是多少

[ClericPy]

既然明白了, 我啰嗦一个题外话: HTTP 被设计为适合较短的无状态请求, 没必要做成这种特别长的方式(虽然我以前也很喜欢, 不过后来都改成最长 block 60 秒或者异步任务). 至于那个心跳说的应该是 HTTP 1.1 客户端上 Keep-Alive 的方式, 举个例子就是 requests 库用 with Session 上下文保留连接避免多次握手的开销

[albertni]

http 返回一个查询 id 之后轮询更符合范式吧