fibbery

为什么这个值这么小，可以自定义设置的么

9

https://github.com/mosn/mosn/blob/887ab91ea5cedfee7a22eb2b553576a16516f839/pkg/network/connection.go#L46

how to use readLimitBody, i want to disable preParseMultipartForm

4

https://github.com/valyala/fasthttp/blob/1242d8af15afca2e1201b7d0e0980c485599550f/http.go#L1183 can export this function , i want to diable preParseMultipartForm

disable pre parse multipartform

1

### Issues associated with this PR #2356 Your PR should present related issues you want to solve. ### Solutions You should show your solutions about the issues in your PR,...

https://github.com/mosn/mosn/blob/9409ffa46969e2389f0debb9b442feb865c8ec08/pkg/stream/http/stream.go#L512 这里解析Http请求直接使用的fasthttp的ReadLimitBody方式，但是这存在一个问题，它这里默认提前对MultipartForm类型进行了body解析，如图：  这里稍微解析出错，可能会导致body解析的内容缺少，然后导致转发的时候缺少body内容。 这里默认情况，作为网关，是不是不应该对body内容进行解析，只做转发即可，用户需要解析form这类的情况，自己再另行处理。 这里更多考虑的是兼容性问题 举例： 目前MultipartForm格式标准如下： ``` POST /upload HTTP/1.1 Host: example.com Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW ------WebKitFormBoundary7MA4YWxkTrZu0gW Content-Disposition: form-data; name="file"; filename="example.txt" Content-Type: text/plain This is an example file. ------WebKitFormBoundary7MA4YWxkTrZu0gW...

downstream reset, response code应该是为4xx, 才符合规范点

2

https://github.com/mosn/mosn/blob/07be2d0d6b9cee511262f85132277fcf937be23b/pkg/proxy/downstream.go#L363

retrystate默认设置处理问题

11

https://github.com/mosn/mosn/blob/f20464f60fe98cc69684bf3d510ce88214227841/pkg/proxy/retrystate.go#LL50C34-L50C35 ``` if retryPolicy.NumRetries() > rs.retiesRemaining { rs.retiesRemaining = retryPolicy.NumRetries() } ``` 这里感觉可以直接改成如下 ``` rs.retiesRemaining = retryPolicy.NumRetries() ``` 由用户自定义即可

集群连接预热功能

1

场景：需要转发请求，但是因为地域原因，延迟比较高。初次使用，还会因为要新建连接，导致延迟更高。所以想做一个连接的预热 需求: 1. 我想在项目初始化的时候，针对特定的集群，做固定数量的连接初始化，减少建立连接的耗时 2. 同时，我想后台定时查询集群下空余连接数量，及时做补充，保持idle client个数在一个固定比例 想请教下有什么好的做法？

pingpong client中的上下文新建，避免和downstream的context混淆

1

### Issues associated with this PR Your PR should present related issues you want to solve. ### Solutions You should show your solutions about the issues in your PR, including...

空闲检测的关闭策略不合理

6

https://github.com/mosn/mosn/blob/45d911be1b39b0cd043002d95d7249e2550f7fd7/pkg/stream/xprotocol/keepalive.go#L228-L231 因为是每次连接读超时的时候进行一个sendKeepAlive，那么下面这种场景会有问题： 1. 连接本身空闲了一段时间，快到关闭的时间了 2. 这时候转发了一个请求到 upstream 3. 这时候刚好触发了最后一次读超时，那么就会导致该连接直接就关闭了。会返回 ConnectedFailure 事件 4. 默认的 retrystate 正好配置了ConnectedFailure进行重试，那么会新建连接再发送一次请求 这种情况会导致出现两次请求，导致触发幂等检测，同时这种空闲检测关闭是不合理的