Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HttpRequests are mutable in filters #5491

Open
4 tasks done
johnowl opened this issue May 24, 2021 · 1 comment
Open
4 tasks done

HttpRequests are mutable in filters #5491

johnowl opened this issue May 24, 2021 · 1 comment
Labels
type: improvement A minor improvement to an existing feature

Comments

@johnowl
Copy link

johnowl commented May 24, 2021

Task List

  • Steps to reproduce provided
  • Stacktrace (if present) provided
  • Example that reproduces the problem uploaded to Github
  • Full description of the issue provided (see below)

Steps to Reproduce

  1. Create two filters that changes the request
  2. In the third filter you can read the updated request

Expected Behaviour

HttpRequests should be immutable, the only property mutable is the attributes field.

Actual Behaviour

HttpRequests are mutable in a specific scenario.

Environment Information

  • Operating System: Darwin
  • Micronaut Version: 2.5.4
  • JDK Version: 19.6.0

Example Application

https://github.com/johnowl/micronaut-api-gateway/

yawkat added a commit that referenced this issue Apr 1, 2022
When a filter calls chain.proceed with a new request, that request should be used for further processing.
Replacing the request is still not fully working even with this change, so #5491 is not fully fixed. RoutingInBoundHandler still does not consider the new request, because most of the request processing happens before the filter is applied. In the test case of this patch, this manifests as the response text still being "initial" even though the request has been replaced.
@yawkat
Copy link
Member

yawkat commented Apr 1, 2022

Partial fix in #7174 (similar to #5487). I'm not sure we can or should support the full use case of replacing the request in the filter, though.

@yawkat yawkat added the type: improvement A minor improvement to an existing feature label Apr 1, 2022
sdelamo pushed a commit that referenced this issue Apr 5, 2022
When a filter calls chain.proceed with a new request, that request should be used for further processing.
Replacing the request is still not fully working even with this change, so #5491 is not fully fixed. RoutingInBoundHandler still does not consider the new request, because most of the request processing happens before the filter is applied. In the test case of this patch, this manifests as the response text still being "initial" even though the request has been replaced.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: improvement A minor improvement to an existing feature
Projects
None yet
Development

No branches or pull requests

2 participants