Closed kspe closed 4 years ago
oh, thanks a lot for the PR! why are those instance variables in the first place, :thinking: I'd even try to get rid of those instance variables. @DonSchado could you take a look? maybe merge this PR, release a patch and then these instance vars should be refactored?
Thanks for raising this issue @kspe very appreciated!
If we inline the html?
method, we could remove all instance vars.
But very interesting, I also don't know if this pattern was just copied over from the former project, but now I believe the issue makes sense in the way rack initializes middleware.
Is #dup
even necessary, when we refactor/remove the internal state?
Is #dup even necessary, when we refactor/remove the internal state?
I think the main issue is that middleware maintains a mutable state in ivars. Without those, it should be safe to remove dup
. The worst thing is that it is hard to test in specs, easier with real applications run locally and bombarded with many requests at a high rate.
Thank you! <3
We've noticed that in high traffic threaded environment (Puma) this middleware shares instance variables memory between threads and occasionally swaps ivars content.
In a worst-case scenario observed for a request from user A the response that was coming back was from a request made by a user B. If
Set-Cookie
header was present user A was immediately logged out and logged in as a user B (completely confusing users).We've observed also a number of other requests/responses swaps which in general were hard to debug e.g. API request calls returning non-API responses.
This PR does not remove using of ivars (
@status
,@headers
,@body
) but rather duplicates the middleware calls. We are using forked repo for a few days now and we do not observe the issue anymore.For more issues similar to this one you can check here , here and here in SO thread.
If this won't be planned for merging after all, maybe at least will save some time for others debugging similar symptoms.