Follow-up from "Support for statically compressed gzip content-encoding"

The following discussion from !25 (merged) should be addressed:

• @nick.thomas started a discussion: (+2 comments)

  The symlink edge case is interesting. Starting with the following structure:

  a/
    foo
    bar -> ../b/bar
  b/
    bar

  The symlink-unaware user would run gzip against every apparent file, leading to:

  a/
    foo
    foo.gz
    bar -> ../b/bar
    bar.gz
  b/
    bar
    bar.gz

  so we end up with a tree that will support either scheme. It only becomes an issue when a user subsequently modifies a/bar.gz and those changes are not reflected in the HTTP response as it serves b/bar.gz when asked for a/bar.

  I think serving a/bar.gz would be marginally better, but it's not a strong preference. Wdyt?