You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Solas, Nathan" <na...@mediabeacon.com> on 2020/09/28 15:15:44 UTC

RemoteIpValve doesn't maintain context in worker thread after startAsync

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.

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

Posted by Mark Thomas <ma...@apache.org>.
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org