Reverse proxy allow modification of target request URI

[Brad Wood]

I'm helping a CommandBox user convert some Tuckey rewrite filter rules to Undertow's predicate language.  Here is the Tucky example they provided me:

<rule> <from>^/test/(.*)</from> <to last="true" type="proxy">http://test.com/$1</to> </rule>

My first thought was just to use the reverse-proxy() handler, but upon further inspection, the ProxyHandler doesn't allow the target requestURI to be completely overridden or to contain exchange attributes.  But in this case we want the target requestURI to be rewritten using a value from the predicate context.  

My questions are:

• Is this possible and I'm just missing it?
• If it's not possible, should the ProxyHandler be enhanced to allow it?
• Or should another handler be created instead that allows for this?

For what it's worth, this specific use case I'm looking at doesn't have a need for load balancing target hosts, but that's not to say it's not a valid use case.  I'm also not sure how we'd add this functionality and still be backwards compat  Currently if I have a proxy set up like so:

reverse-proxy({'http://localhost:5678/foo'})

And I proxy a request with an original URI of /bar/ then the target URL ends up being

http://localhost:5678/foo/bar

So the original requestURL just gets appended to any URI already present in the proxy host.  To be able to provide the same sort of generic proxy available in other engines like Tuckey, we'd need the ability to 

• Completely override the target requestURI
• Allow resolution of exchange attributes in the URL such as ${1} 

Thoughts?

Thanks!

~Brad

Developer Advocate

Ortus Solutions, Corp 

E-mail: br...@coldbox.org

ColdBox Platform: http://www.coldbox.org 

Blog: http://www.codersrevolution.com

[Stuart Douglas]

On Thu, 11 Nov 2021 at 02:09, Brad Wood <bdw...@gmail.com> wrote:

I'm helping a CommandBox user convert some Tuckey rewrite filter rules to Undertow's predicate language.  Here is the Tucky example they provided me:

<rule> <from>^/test/(.*)</from> <to last="true" type="proxy">http://test.com/$1</to> </rule>

My first thought was just to use the reverse-proxy() handler, but upon further inspection, the ProxyHandler doesn't allow the target requestURI to be completely overridden or to contain exchange attributes.  But in this case we want the target requestURI to be rewritten using a value from the predicate context.  

You should be able to re-write the request URI, and then the proxy handler will target the rewritten URI.

 

My questions are:

• Is this possible and I'm just missing it?
• If it's not possible, should the ProxyHandler be enhanced to allow it?
• Or should another handler be created instead that allows for this?

For what it's worth, this specific use case I'm looking at doesn't have a need for load balancing target hosts, but that's not to say it's not a valid use case.  I'm also not sure how we'd add this functionality and still be backwards compat  Currently if I have a proxy set up like so:

reverse-proxy({'http://localhost:5678/foo'})

And I proxy a request with an original URI of /bar/ then the target URL ends up being

http://localhost:5678/foo/bar

Basically something like this should do it:

set-attribute(%U, /bar)

reverse-proxy({'http://localhost:5678'}

 

Stuart

So the original requestURL just gets appended to any URI already present in the proxy host.  To be able to provide the same sort of generic proxy available in other engines like Tuckey, we'd need the ability to 

• Completely override the target requestURI
• Allow resolution of exchange attributes in the URL such as ${1} 

Thoughts?

Thanks!

~Brad

Developer Advocate

Ortus Solutions, Corp 

E-mail: br...@coldbox.org

ColdBox Platform: http://www.coldbox.org 

Blog: http://www.codersrevolution.com

--
You received this message because you are subscribed to the Google Groups "Undertow Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to undertow-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/undertow-dev/CALbQ1on3XyOVj0rtGSC7p7sF93oCTVXKgUkgNdCa%2BPaHwA5iKA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Brad Wood]

I can confirm rewriting the requestURI prior to the proxy does cause the proxy to use the rewritten URI.  What that wouldn't allow for, would be each proxy endpoint to use a different rewritten URI.  Not sure how big of a deal that is, especially considering my current use case only requires a single proxy endpoint.

In related news, I may send a pull with some additional debug/trace logging to the proxy logger.  There's some code paths that lead to a 503 response code but don't log what happened.  

Thanks!

~Brad

Developer Advocate

Ortus Solutions, Corp 

E-mail: br...@coldbox.org

ColdBox Platform: http://www.coldbox.org 

Blog: http://www.codersrevolution.com

[Flavia Rainone]

This is very old and I'm not sure if it is one of the PRs sent to Undertow or not. But, yes, if you haven't done so and still have the debug trace logging, you can send them. This is useful to everyone that uses Undertow, specially if there is a 503 response that cannot be accounted for in debug or trace logging right now.

[Brad Wood]

Sorry, I didn't get around to adding that logging in at the time, and now that it's been a few months, I'd have to dig back into it to refresh my memory on those code paths.  

I would still like to see my original suggestion taken up despite Stuart's workaround of rewriting the URL, a lot of people coming from Apache or Tuckey are going to expect to be able to use placeholders directly in the proxy URL, and allow each proxy endpoint to be rewritten separately.  The only real problem there being backwards compat.

Thanks!

~Brad

Developer Advocate

Ortus Solutions, Corp 

E-mail: br...@coldbox.org

ColdBox Platform: http://www.coldbox.org 

Blog: http://www.codersrevolution.com

To view this discussion on the web visit https://groups.google.com/d/msgid/undertow-dev/425ccd94-3c90-474d-bfe4-6ca6eb7b2ad4n%40googlegroups.com.