Needs E-TAG header. May serve incorrect content on server restart

[coolaj86]

Just manual testing updating the config with SIGUSR1 and it looked like it was even working. However, I found that it's actually sending 304 Not Modified for content that has been modified.

The issue is that it sends last-modified headers with the date of the file, but if the file is swapped out with an earlier file, it sees the if-modified-since header and can't tell that the file has been modified.

Instead it should send an etag which could be as simple as a sha1sum of the file attributes (created at, modified at, size, inode, permissions) or actually performing a sha1 on the file.

To reduce overhead, the sha1 could be stored in memory or a temporary file - if you want to check full contents rather than just attributes that is.

[mholt]

#191 is about ETag. We definitely do want to add this. (What does this have to do with server restart though?)

[coolaj86]

Ooops, shoulda done my homework.

It has to do with restart / SIGUSR1 because if you change the config file such that it points to a different directory, you can't tell that the config file successfully reloaded. It looks like it's reading the old config... until you examine the headers.

[mholt]

if you change the config file such that it points to a different directory, you can't tell that the config file successfully reloaded

Can you elaborate on this?

It looks like it's reading the old config... until you examine the headers.

Config != web page. I'm still confused.

[coolaj86]

The device starts up in a locked state, so any request to any "app" on the device is pointing to the same directory (which is the "lock screen" app).

https://coolaj86.com {
    root /srv/walnut/init.public
    proxy /api http://localhost:4080
    # ... more stuff
}

https://brysonchill.com {
    root /srv/walnut/init.public
    proxy /api http://localhost:4080
    # ... more stuff
}

Once the API gets the master passphrase from the device owner the device unlocks and the config is changed (and caddy gets SIGUSR1 (v0.8) or SIGTERM and then restarted (v0.7))

https://coolaj86.com {
    root /srv/walnut/sites-enabled/coolaj86.com
    proxy /api http://localhost:4080
    # ... more stuff
}

https://brysonchill.com {
    root /srv/walnut/sites-enabled/brysonchill.com
    proxy /api http://localhost:4080
    # ... more stuff
}

The lock screen then issues a refresh of the page (after the api call to unlock the device).... and it's still at the lock screen... WHAT!?

Oh, it's because the html files for the lock screen I just updated (because that's the app I'm working on) and the coolaj86.com app is "older".

So I restart the server with a new config file, and the web page I'm looking at is a completely different web page than what is on disk due to the 304 cache.