fileserver: Allow Etag override

[charles-dyfis-net]

Fixes #5546

Tested with a Caddyfile with a form roughly resembling:

route {
  header {
    ETag "\"${content-hash-here}\""
    -Last-Modified
  }
  root * /content/by-hash/${content-hash-here}
  file_server
}

(with ${content-hash-here} replaced with an actual hash rendered to base-16).

[CLAassistant]

All committers have signed the CLA.

[mholt]

I'd say this LGTM. Thank you!

[francislavoie]

FYI regarding your example, you can use backticks instead of double quotes to avoid needing to escape them. See the docs https://caddyserver.com/docs/caddyfile/concepts#tokens-and-quotes

[emilylange]

@charles-dyfis-net FYI there is also a slightly different approach in NixOS/nixpkgs#222354

[charles-dyfis-net]

@charles-dyfis-net FYI there is also a slightly different approach in NixOS/nixpkgs#222354

This change strikes me as complimentary: if fileserver honors existing ETag values, a plugin can be used to set them so there's a cleaner way to use out-of-tree code to extract an ETag from the filesystem path.

[charles-dyfis-net]

Hmm. There's something I don't understand here.

Going back over the configuration I successfully tested it with, a closer approximation would be:

route {
  root * /content/by-hash/${content-hash-here}
  header ETag `"${content-hash-here}"`
  file_server
  header -Last-Modified
}

Note, two separate header blocks. If I combine them into a single header block as shown above, Etag is no longer set before file_server is invoked.

[mholt]

Correct. If you remove a header it defers the operation until the response is written. The two header lines is the correct way to do it in your case where you need one set before the write.

[charles-dyfis-net]

Ah! I didn't pay enough attention to where exactly the deferred tag was in the adapt output. Makes perfect sense, then.

[francislavoie]

Yeah if you use - to delete in the same header block it enables defer mode which makes header operations happen on the way back up the middleware pipeline instead of on the way down, so it runs after the file server.

[mholt]

I didn't even notice that in the original config. 😅 (I wonder if we should print a warning in the logs.)

I like to think of it as: add first, delete later.

[charles-dyfis-net]

Yup. I saw it in the docs, but read them to be saying that that individual operation would be deferred, as opposed to the whole batch.

[mholt]

Gotcha. I'll try to clarify that. That might be a bug though. 🤔 I think I know why it is that way but I'm not sure if that's ideal/intentional. (Anyway, off-topic.)

Is this good to merge then?

[charles-dyfis-net]

I'm not aware of anything that should block merge.