The GWT UI static servlets (e.g. WarGwtUiServlet) were already using
class load time as the "mtime" of a file, to account for the fact that
the build system always sets the mtime of zipfile entries to the Unix
epoch. (This is intentional, to keep bazel builds reproducible.)
PolyGerrit has the same problem served from a WAR file, but was not
applying this hack. Complicating the situation is that the same class
(PolyGerritUiServlet) is used for the dev server, where we can trust
the mtime. Hackily check whether the path in question is on-disk in the
implementation of getLastModifiedTime.
There was also a bug in ResourceServlet#maybeStream that was bypassing
getLastModifiedTime when checking If-Modified-Since; fix that as well.
While we're in here, fix the other broken class in this hierarchy,
WarDocServlet.
In retrospect, it may have been a mistake to make ResourceServlet try to
handle all possible caching behaviors, since it makes bugs like this all
too easy to introduce. Long term, may want to disentangle the on-disk
implementation, which may depend on mtime to determine staleness, from
the zipfile implementation, which shouldn't.
Bug: Issue 6885
Change-Id: Iea041774c1005cb9918c462d01aef05cff61da23
65c8345a96