Uploaded image for project: 'Undertow'
  1. Undertow
  2. UNDERTOW-2216

directory listing paths should be relative


    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • 2.2.25.Final, 2.3.7.Final
    • None
    • None
    • None

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


      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 
      it will not serve the file 
      but instead tries to serve

      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
      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.

            rhn-cservice-bbaranow Bartosz Baranowski
            bdw429s Brad Wood
            0 Vote for this issue
            4 Start watching this issue