Re: What is an "up to date" version?



> On 29 Oct 2017, at 10:20, Martynas Jusevičius <martynas@atomgraph.com> wrote:
> 
> ETag would still need a request to check If-Modified-Since every time, which is slow.
> 
> OK, I could use Cache-Control: max-age and Expires as clues. But what about servers that do not send them?

Say you are doing an important transaction, then the server can and probably should
make an extra check for safety's sake. 

Otherwise the answer should be that this works very much like other HTTP
transactions without Expiry or other such fields

https://stackoverflow.com/questions/5860216/no-expires-header-sent-content-cached-how-long-until-browser-makes-conditional


A conformant browser (server in this case, since the server is acting as a client) 
should probably be fetching the page every time, which of course will make the 
response very slow for the end user. This type of thing also happened in 
dynamically built form based sites. This ended up teaching people to set 
the right headers. 

Now I think a server is entitled to keep a copy of the data for as long 
as it wants, as this will be useful to understand if something odd is going
on. There is no requirement for amnesia on the web. 

At this time I'd probably be lenient with WebID-TLS authentications that
don't have expiry dates. But over the longer term if it gets to be successful
the existing conventional behavior will probably take over.

Henry


> On Sun, 29 Oct 2017 at 08.41, Story H.J. <H.J.Story@soton.ac.uk> wrote:
> 
> 
> > On 29 Oct 2017, at 08:19, Story H.J. <H.J.Story@soton.ac.uk> wrote:
> >
> >> On 29 Oct 2017, at 03:11, Ed - 0x1b, Inc. <w3c@0x1b.com<mailto:w3c@0x1b.com>> wrote:
> >>
> >> I would guess an up to date etag is typical for cache freshness.
> >> https://en.wikipedia.org/wiki/HTTP_ETag

> >
> > close. The Etag won't tell the local cache if it needs to update the version, it will
> > just be useful when making a request to ask for one where intermediary caches
> > can say, nothing has changed since you last looked.
> > Look at
> > https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.6

> > and
> > https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9

> >
> 
> Even better there is the Expires header:
> https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.21

> 
> And all the text around it in section 14
> 
> 
> 
> > Henry
> >
> >
> > On Sat, Oct 28, 2017 at 2:10 PM, Martynas Jusevičius
> > <martynas@atomgraph.com<mailto:martynas@atomgraph.com>> wrote:
> > Hi,
> >
> > I'm implementing a cache for WebID graphs to improve performance. I was
> > looking at WebID-TLS 4.1 Authentication sequence, which says:
> > "If the WebID Verifier has an up to date version of the graph in its graph
> > cache then it can return it."
> > https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/tls-respec.html#authentication-sequence

> >
> > The phrase "up to date" is repeated multiple times later on, but not defined
> > anywhere.
> >
> > So what is it and who decides that -- the implementor? For how long am I
> > supposed to safely cache the graphs?
> >
> >
> > Martynas
> > atomgraph.com
> >
> >
>

Received on Sunday, 29 October 2017 11:34:05 UTC