Re: [fossil-users] fossil delete user

2018-05-17 Thread bytevolcano
I think Peter is referring to deleting users from the "user" table. Fossil keeps the commit history forever, and each manifest has the name of the user that made the commit. In the database, this is recorded in the user column of the "event" table as the name of the user that made the commit.

[fossil-users] HTTP caching, again

2018-05-17 Thread Florian Balmer
Sorry for my perseveration on the topic. I'm using a /uv index page for my repositories. After login, the index page is not expired, and I can only see the Admin entry from the top navigation bar until after a "hard" reload with Ctrl+F5. So I tried to to generate a "login-time-sensitive" ETag.

Re: [fossil-users] HTTP caching, again

2018-05-17 Thread Richard Hipp
On 5/17/18, Joerg Sonnenberger wrote: > On Thu, May 17, 2018 at 07:02:17PM +0200, Florian Balmer wrote: >> So I tried to to generate a "login-time-sensitive" ETag. This worked well >> with the "cexpire" field from the "user" table (which is actually the >> login >> time, shifted to

Re: [fossil-users] HTTP caching, again

2018-05-17 Thread Florian Balmer
> One possible solution may be to include the "cexpire" field in > ETag calculation, drop the If-Modified-Since handler, but still > return a Last-Modified date. Well, it may be possible to support both caching mechanisms. But then an ETag mismatch should result in a cache miss, and the

Re: [fossil-users] HTTP caching, again

2018-05-17 Thread Florian Balmer
D. Richard Hipp: > The ETag values already reset based on changes to the display > cookie. I suppose they could change again based on the login > cookie. The question is, would this solve Florent's problem? Yes, adding "user.cexpire" to the ETag ingredients [0] would solve part of the problem:

Re: [fossil-users] HTTP caching, again

2018-05-17 Thread Joerg Sonnenberger
On Thu, May 17, 2018 at 07:02:17PM +0200, Florian Balmer wrote: > So I tried to to generate a "login-time-sensitive" ETag. This worked well > with the "cexpire" field from the "user" table (which is actually the login > time, shifted to the future by one unit of the "cookie-expire" setting).

Re: [fossil-users] HTTP caching, again

2018-05-17 Thread Joerg Sonnenberger
On Thu, May 17, 2018 at 04:08:18PM -0400, Richard Hipp wrote: > On 5/17/18, Joerg Sonnenberger wrote: > > On Thu, May 17, 2018 at 07:02:17PM +0200, Florian Balmer wrote: > >> So I tried to to generate a "login-time-sensitive" ETag. This worked well > >> with the "cexpire" field from