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 da
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
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?
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
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 Last-Mod
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 the "user" tab
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: /u
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 the future by o
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).
Would
> 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 If-Modifie
10 matches
Mail list logo