net/http: ServeFile should recognise unix epoch as "zero time" ?

[adob]

The check for timestamp validity in http.ServeFile() is not sufficient to detect invalid timestamps on unix systems. On App Engine, all files have the modified date set to 1 Jan 1970 (the unix epoch). In this environment, http.ServeFile() serves files with the header

  Last-Modified: Thu, 01 Jan 1970 00:00:00 GMT

regardless of the actual last modified date of the file. This is a problem because it means files may be cached on client browsers forever. This happens because the client may request the file with

 GET /file.html HTTP/1.1
 If-Modified-Since: Thu, 01 Jan 1970 00:00:00 GMT

Then App Engine will replies with

  304 Not Modified.

In the file src/net/http/fs.go, there is an attempt to check if the modified timestamp is valid by calling Time.IsZero() but this checks if the date is Jan 1, 1 AD, which is always false for all unix timestamps. It probably makes sense to add an explicit check for unix timestamp == 0 to serve ServeFile and convert this to Time.Zero.

[bradfitz]

/cc @dsymonds for thoughts. There might be multiple fixes here.

[adg]

On 11 February 2015 at 20:35, Aleksandr Dobkin notifications@github.com
wrote:

On App Engine, all files have the modified date set to 1 Jan 1970 (the
unix epoch)

Seems to me that this is the problem.
The modified date should be the date of deployment.

[dsymonds]

If http.ServeFile is looking at the local disk state (which isn't a real filesystem), there's going to be failure. App files don't have mtime (or any other *time) recorded. I'm not surprised to see them appear with mtime at the Unix epoch.

[dsymonds]

It seems like fs.go should be checking Unix epoch (and maybe the Mac epoch too?), not just Time.IsZero.

[adg]

Isn't it a failure of the FS layer to provide shoddy mtimes?

What if a file really was created at unix epoch? What does fs.go do then?

On 12 February 2015 at 02:13, David Symonds notifications@github.com
wrote:

It seems like fs.go should be checking Unix epoch (and maybe the Mac
epoch too?), not just Time.IsZero.

—
Reply to this email directly or view it on GitHub
#9842 (comment).

[dsymonds]

On 12 February 2015 at 13:41, Andrew Gerrand notifications@github.com wrote:

Isn't it a failure of the FS layer to provide shoddy mtimes?

Maybe. App Engine doesn't give you a real filesystem, and you don't
have other things like symlinks or executable bits, nor does it
preserve other metadata like user/group.

What if a file really was created at unix epoch? What does fs.go do then?

Dunno, but the safe option would be to pretend that the mtime is
effectively unknown, which is what it appears to be trying to do by
using Time.IsZero, right? It seems like a mostly academic concern
for actual files with a real mtime set to Unix epoch.

[adg]

I guess the test at the top of checkLastModified could be modified to check if modtime.UnixNano == 0 too.

[bradfitz]

Sent https://go-review.googlesource.com/7915