You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[BUG] When using both HTTP services and WebSocket in Iris, the responseWriter for HTTP requests can be used concurrently and make the program crash
#2479
Open
DOLLook opened this issue
Jul 10, 2024
· 0 comments
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.
The text was updated successfully, but these errors were encountered:
DOLLook
changed the title
[BUG]
[BUG] When using both HTTP services and WebSocket in Iris, the responseWriter for HTTP requests can be used concurrently
Jul 10, 2024
DOLLook
changed the title
[BUG] When using both HTTP services and WebSocket in Iris, the responseWriter for HTTP requests can be used concurrently
[BUG] When using both HTTP services and WebSocket in Iris, the responseWriter for HTTP requests can be used concurrently and make the program crash
Sep 6, 2024
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:
// do something
ctx.Next()
})
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.
The text was updated successfully, but these errors were encountered: