Re: [fossil-users] HTTP caching, again

Though I'm aware that this is not something you may consider useful for Fossil, I'm posting a minor update, for the sake of correctness: (0) Wrong Statement Me: > I think that "Vary: Cookie" is intended to work with unconditional > HTTP requests: the browser is directed to stick to the expiry

Re: [fossil-users] HTTP caching, again

Now I see why the clever and elegant solution to use "Vary: Cookie", as suggested by Joerg, does not fix /uv page expiration after login and logout, and I can also explain the strange differences between the local Fossil built-in web server, and my remote web server. The local Fossil built-in web

Re: [fossil-users] HTTP caching, again

Joerg: > Such a proxy would be pretty broken. ... Again, such a client is > pretty much broken already under the caching model. ... I agree. Writing an HTTP server in a perfect world may be easy. But I feel like a lot of programming work are efforts to make broken clients (or "components") work?

Re: [fossil-users] HTTP caching, again

On Fri, May 18, 2018 at 08:39:15AM +0200, Florian Balmer wrote: > Also, with "Vary: Cookie", there may be issues with caching proxies, > depending on whether they receive and evaluate all the cookies, but this > may not be a problem for Fossil. Such a proxy would be pretty broken. It has to parse

Re: [fossil-users] HTTP caching, again

Joerg: > I don't think you need to reset it, just sending the vary header > should be enough? I was able to try this, and it works fine! Adding the following line: fprintf(g.httpOut, "Vary: Cookie\r\n"); right after printing the ETag header in src/cgi.c (and also after printing the

Re: [fossil-users] HTTP caching, again

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

Re: [fossil-users] HTTP caching, again

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

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

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

> 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

[fossil-users] HTTP caching, again

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.