This ticket is created from the following discussion on the mailing list:

https://groups.google.com/g/undertow-dev/c/gEsLkOciOIU/m/Xxty07gYAQAJ

------------------------
So I wanted to test and see if I could use a predicate rule to specify a resource handler, basically like an alias (virtual directory).  FWIW, I normally use a custom ResourceManager to implement web aliases, but I wanted to try this out.
 
path-prefix(/foo)-> resource(location='C:/sandbox/mySite/bar/',allow-listing=true)
 
This sort of works, but the issue is when I hit 
http://localhost/foo/test.txt
it will not serve the file 
C:/sandbox/mySite/bar/test.txt
but instead tries to serve
C:/sandbox/mySite/bar/foo/test.txt

because "foo" is still part of the path.  
 
Ok, no problem.  So attempt number 2 where I swap out the request URI to be the "remaining" text.  More boilerplate, but works more like a virtual directory:
 
path-prefix(/foo)-> { set(attribute=%U,value=${remaining}); resource(location='C:/sandbox/mySite/bar/',allow-listing=true) }
 
This allows the URL above to serve the expected file, BUT when I hit
http://localhost/foo/
to get a directory listing of the folder, the links in the web page are broken as they point to `/test.txt` which is an absolute URI which doesn't not exist.  
 
It seems that a simple workaround for this would be to use a relative path in the HTML of the directory listing page.  Therefore, if I'm viewing the contents of /foo/ in my browser and I click on "test.txt", then the browser would navigate to /foo/test/txt without caring what the server side request URI looks like.  This would just require removing the path and the leading slash prior to the file name in the directory listing's HTML output.