Describe the bug
When using both HTTP services and WebSocket in Iris, the responseWriter for HTTP requests can be used concurrently, leading to various strange issues with HTTP responses. For example, responses for different requests might get written into the same request, causing unexpected behavior. Seriously, in some case, like write requestid in the response header, it will write the header concurrently and make the program crashed.
To Reproduce
Steps to reproduce the behavior:
app:=iris.New()
app.UseRouter(requestid.New())
app.Get("/hello", func(ctx iris.Context) {
// do something
ctx.Next()
})
Desktop (please complete the following information):
OS: windows, golang:1.21.6-alpine run in docker
iris.Version
v12.2.10
Additional context
Initially, I noticed that sometimes the context obtained through websocket.GetContext(conn) was the context from a regular HTTP request. Then, I found the #1856 issue, which reported that the websocket might retrieve the wrong context. This problem was solved by adding a manualRelease field to the context. However, in my test , this issue still persists.
To tackle this, I attempted to isolate the context pools used by HTTP and websocket by having them operate under two separate instances of the iris app, like httpApp:=iris.New() for http service, wsApp:=iris.New() for websocket service. and run them in one program. After doing so, the problem of retrieving incorrect contexts did not occur anymore. Yet, under high concurrency, HTTP requests started experiencing response mix-ups.
Further investigation led me to discover that the responseWriter within the context is retrieved from a global cache pool. When I modified the global cache to have an independent responseWriter pool for each instance of the iris app, all problems were resolved.
Describe the bug When using both HTTP services and WebSocket in Iris, the responseWriter for HTTP requests can be used concurrently, leading to various strange issues with HTTP responses. For example, responses for different requests might get written into the same request, causing unexpected behavior. Seriously, in some case, like write requestid in the response header, it will write the header concurrently and make the program crashed.
To Reproduce Steps to reproduce the behavior:
Desktop (please complete the following information):
iris.Version
Additional context Initially, I noticed that sometimes the context obtained through websocket.GetContext(conn) was the context from a regular HTTP request. Then, I found the #1856 issue, which reported that the websocket might retrieve the wrong context. This problem was solved by adding a manualRelease field to the context. However, in my test , this issue still persists.
To tackle this, I attempted to isolate the context pools used by HTTP and websocket by having them operate under two separate instances of the iris app, like httpApp:=iris.New() for http service, wsApp:=iris.New() for websocket service. and run them in one program. After doing so, the problem of retrieving incorrect contexts did not occur anymore. Yet, under high concurrency, HTTP requests started experiencing response mix-ups.
Further investigation led me to discover that the responseWriter within the context is retrieved from a global cache pool. When I modified the global cache to have an independent responseWriter pool for each instance of the iris app, all problems were resolved.