Document use of `req.originalUrl` for Reverse Proxy.

[CodeMan99]

I had the same issue as #53 & #87.

Can we please document the use of req.originalUrl in the README?

[dougwilson]

Sure, feel free to pull request the documentation you feel would be appropriate:+1:

[rweigel]

I have a app that sits behind a reverse proxy so that http://server/appname serves data from an express app that is listening on http://localhost:4444/.

The following worked (make it the first express route)

let proxyAppPath = "/appname";
app.use(function (req, res, next) {
  req.originalUrl = proxyAppPath + req.url;
  next();
})

Note that if someone decides to change the reverse proxy URL to say http://server/BetterAppName, the directory listing will not longer work unless proxyAppPath is updated. The reverse proxy does not provide information in the headers from which proxyAppPath can be determined, so this seems to be about the best I can do aside from creating a custom template (discussed below).

I don't think this is a good solution - even if the proxy provided the needed header information, the links in a serve-index directory listing could break if the proxy software changes and different headers are used.

Given that adding an option to serve-index of, say, absoluteDirPaths which is by default true and when false uses var path = []; as mentioned in #53 seems not simple * based on the discussion, for documentation, I would suggest an example of how to get relative paths by creating a custom template as this seems to be the only robust solution. I suppose the template function would be essentially a copy of the existing template with a line or two modified.

* Given that relative links in directory listings and responses of directory listings for URLs with and without a trailing slash work in apache by default, it can be done. It seems that apache sends a 301 when a URL is missing a trailing slash and the path associated with the URL maps to a file system directory. But implementing this would probably require substantial changes and tests.

[CodeMan99]

I don't think this is a good solution - even if the proxy provided the needed header information, the links in a serve-index directory listing could break if the proxy software changes and different headers are used.

The "x-original-url" is something you must manually setup in your proxy server. There are known solutions for both nginx & apache. As such, the manual header is an acceptable solution.

---

For example.

• serve-index configured with base path of "/tmp/files"
• The request path is "/example/folder/"
• The proxy server sets x-original-url as "/example/folder"
• express application receives request at path "/folder"
• serve-index reads "/tmp/files/folder" and returns a template "mounted" on "/example" because it parsed that information from x-original-url

Now change the proxy location to "/passalong"

• serve-index is still configured with base path of "/tmp/files"
• The request path is "/passalong/folder"
• The proxy server set x-original-url as "/passalong/folder"
• express application receives request at path "/folder"
• serve-index reads "/tmp/files/folder" and returns a template "mounted" on "/passalong" because it parsed that information from x-original-url

Note the only change was the proxy location. Everything else did not change.

[rweigel]

I agree that x-original-url is a good option if you have control of the proxy server.