Caddy: CanGoUp appears broken in fileserver module

[CHTJonas]

From reading the source below, it appears there should be a "Go up" link on all directory listings which have a parent directory which itself is also browsable by the user.

https://github.com/caddyserver/caddy/blob/2b90cdba52e2a4f160cdef829425bc01fbaa0d04/modules/caddyhttp/fileserver/browsetpl.go#L336-L348

However it appears this is broken and that CanGoUp is always false for some reason. This in turn means that the link to the parent directory is not shown when I'd expect it to be.

Hope all the Caddy maintainers had a good Christmas and wishing you all a Happy New Year!

[mholt]

Thanks for opening an issue! We'll look into this.

It's not immediately clear to me what is going on, so I'll need your help to understand it better.

Ideally, we need to be able to reproduce the bug _in the most minimal way possible_. This allows us to write regression tests to verify the fix is working. If we can't reproduce it, then you'll have to test our changes for us until it's fixed -- and then we can't add test cases, either.

I've attached a template below that will help make this easier and faster! This will require some effort on your part -- please understand that we will be dedicating time to fix the bug you are reporting if you can just help us understand it and reproduce it easily.

This template will ask for some information you've already provided; that's OK, just fill it out the best you can. :+1: I've also included some helpful tips below the template. Feel free to let me know if you have any questions!

Thank you again for your report, we look forward to resolving it!

Template

## 1. Environment

### 1a. Operating system and version

paste here


1b. Caddy version (run caddy version or paste commit SHA)

paste here


1c. Go version (if building Caddy from source; run go version)

paste here


2. Description

2a. What happens (briefly explain what is wrong)

2b. Why it's a bug (if it's not obvious)

2c. Log output

paste terminal output or logs here


2d. Workaround(s)

2e. Relevant links

3. Tutorial (minimal steps to reproduce the bug)

Instructions -- please heed otherwise we cannot help you (help us help you!)

1. Environment: Please fill out your OS and Caddy versions, even if you don't think they are relevant. (They are _always_ relevant.) If you built Caddy from source, provide the commit SHA and specify your exact Go version.

2. Description: Describe at a high level what the bug is. What happens? Why is it a bug? Not all bugs are obvious, so convince readers that it's actually a bug.

   • 2c) Log output: Paste terminal output and/or complete logs in a code block. DO NOT REDACT INFORMATION except for credentials.
   • 2d) Workaround: What are you doing to work around the problem in the meantime? This can help others who encounter the same problem, until we implement a fix.
   • 2e) Relevant links: Please link to any related issues, pull requests, docs, and/or discussion. This can add crucial context to your report.

3. Tutorial: What are the _minimum required specific steps_ someone needs to take in order to experience the same bug? Your goal here is to make sure that anyone else can have the same experience with the bug as you do. You are writing a tutorial, so make sure to carry it out yourself before posting it. Please:

   • Start with an empty config. Add _only_ the lines/parameters that are _absolutely required_ to reproduce the bug.
   • Do not run Caddy inside containers.
   • Run Caddy manually in your terminal; do not use systemd or other init systems.
   • If making HTTP requests, avoid web browsers. Use a simpler HTTP client instead, like curl.
   • Do not redact any information from your config (except credentials). Domain names are public knowledge and often necessary for quick resolution of an issue!
   • Note that ignoring this advice may result in delays, or even in your issue being closed. 😞 Only actionable issues are kept open, and if there is not enough information or clarity to reproduce the bug, then the report is not actionable.

Example of a tutorial:

Create a config file:

{ ... }

Open terminal and run Caddy:

$ caddy ...

Make an HTTP request:

$ curl ...

Notice that the result is ___ but it should be ___.

[CHTJonas]

Thanks @mholt! Sorry if there was a template I should've followed from the start -- my mistake.

1. Environment

1a. OS version

$ uname -a
Darwin Charlie-MBP-2013.local 19.6.0 Darwin Kernel Version 19.6.0: Thu Oct 29 22:56:45 PDT 2020; root:xnu-6153.141.2.2~1/RELEASE_X86_64 x86_64 i386 MacBookPro11,3 Darwin

1b. Caddy version

$ wget https://github.com/caddyserver/caddy/releases/download/v2.2.1/caddy_2.2.1_mac_amd64.tar.gz
$ tar -xzvf caddy_2.2.1_mac_amd64.tar.gz
$ ./caddy version
v2.2.1 h1:Q62GWHMtztnvyRU+KPOpw6fNfeCD3SkwH7SfT1Tgt2c=

1c. Go version

N/A

2. Description

2a. What happens

• I was looking at implementing a 'virtual' link (that is to say, added by caddy and not present in the original filesystem structure) from directories served by the fileserver module to their parent similar to Apache (e.g. here).
• I took a look at lines 336 to 348 of the source code at caddy/modules/caddyhttp/fileserver/browsetpl.go and saw what looks like the feature that I'm after already implemented!
• Except that from what I can tell it doesn't seem to work. Unless the code I'm seeing is actually for something else and I'm just being an idiot!

2b. Why it's a bug (if it's not obvious)

Given the current code (see below) I would expect to see a <a href=".."><span class="goup">Go up</span></a> link in Caddy's directory listing if it's possible for the user to navigate 'up' to another folder.

https://github.com/caddyserver/caddy/blob/2b90cdba52e2a4f160cdef829425bc01fbaa0d04/modules/caddyhttp/fileserver/browsetpl.go#L336-L348

https://github.com/caddyserver/caddy/blob/7d7434c9ce9778adf7b7ff6c3a6575ea1c11ed01/modules/caddyhttp/fileserver/browse.go#L96-L107

2c. Log output

2020/12/30 10:16:22.477 WARN    admin   admin endpoint disabled
2020/12/30 10:16:22.478 INFO    tls.cache.maintenance   started background certificate maintenance  {"cache": "0xc0003d5180"}
2020/12/30 10:16:22.478 INFO    http    server is listening only on the HTTP port, so no automatic HTTPS will be applied to this server {"server_name": "static", "http_port": 80}
2020/12/30 10:16:22.481 INFO    tls cleaned up storage units
2020/12/30 10:16:22.481 INFO    autosaved config    {"file": "/Users/charlie/Library/Application Support/Caddy/autosave.json"}
2020/12/30 10:16:22 Caddy 2 serving static files on :80

2d. Workaround(s)

A bodge is to use a custom template that omits the {{- if .CanGoUp}} and {{- end}} lines only, although that shows the 'Go up' link even at the root (which is incorrect as there's nowhere to go up to).

2e. Relevant links

An idea of what I'd expect can be seen by browsing around the directories here though do bare in mind I've changed the default template slightly (reworded 'Go up' to 'Parent Directory' and added a #folder-shortcut icon) and that this is still subject to the workaround downside above -- the site's root has no parent directory so the link should disappear on that page (only?).

3. Tutorial

$ cd /tmp
$ mkdir test{1..5}
$ caddy file-server --browse
$ curl -sS http://localhost/test{1..5}/ | grep '<span class="goup">Go up</span>'

I would expect the last command to return some matches from grep since each of those test directories is a child of a parent directory which is also navigable by the user.

[mholt]

That is an excellent report. Thank you! The tutorial is perfect. (And don't worry, you didn't miss the template; we only ask for it when we think it'll be helpful.)

Found the bug pretty quickly thanks to that information. Pushing a fix now.

[francislavoie]

You can try it out by downloading the appropriate build artifact at the bottom of this page: https://github.com/caddyserver/caddy/actions/runs/452872923

[CHTJonas]

Fantastic - thanks for the quick fix! I can confirm this now works as expected for me too. 🚀