RemoteIpValve doesn't maintain context in worker thread after startAsync

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

RemoteIpValve doesn't maintain context in worker thread after startAsync

Solas, Nathan
I'm using RemoteIpValve to capture protocolHeader x-forwarded-proto and upgrade the request to secure when SSL is terminated at the load balancer - so far so good.

When using theServletRequest.startAsync() and then passing the work to a threadpool executor, it seems the RemoteIpValve.invoke finally{} block executes first and undoes all the changes to the Request object. The result is by the time the worker picks up the request, it's demoted back to http and nothing works.

This was noted in 2017 with no answers, but the internet is pretty quiet about others facing this:
https://marc.info/?l=tomcat-user&m=150971153905722&w=2

Maybe I'm not understanding how this should work? Seems right to me... Thanks for any information,
Nate

Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment.
Reply | Threaded
Open this post in threaded view
|

Re: RemoteIpValve doesn't maintain context in worker thread after startAsync

markt
On 28/09/2020 16:15, Solas, Nathan wrote:
> I'm using RemoteIpValve to capture protocolHeader x-forwarded-proto and upgrade the request to secure when SSL is terminated at the load balancer - so far so good.
>
> When using theServletRequest.startAsync() and then passing the work to a threadpool executor, it seems the RemoteIpValve.invoke finally{} block executes first and undoes all the changes to the Request object. The result is by the time the worker picks up the request, it's demoted back to http and nothing works.
>
> This was noted in 2017 with no answers, but the internet is pretty quiet about others facing this:
> https://marc.info/?l=tomcat-user&m=150971153905722&w=2
>
> Maybe I'm not understanding how this should work? Seems right to me... Thanks for any information,
> Nate

You'll probably have more luck with the Filter than the Valve. One of
the advantages the Filter has is that it can warp the request and/or
response.

Mark



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]