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



> On 29 Oct 2017, at 13:14, Martynas Jusevičius <martynas@atomgraph.com> wrote:
> 
> Requesting WebID with each request is not feasible, as it might generate multiple sub-requests which in turn would also need to do the same, and they all add up.


Not if the public key is public. I think we did make that a requirement to avoid loops.

In any case there are time to live values on internet connections, so even if there
were loops one or another service would end up breaking the connection.

> So I will need to come up with some heuristic here.
> 
> Maybe this is worth mentioning in the spec?

Well let us know what heuristic you came up with, and how well it worked for you.

> 
> On Sun, Oct 29, 2017 at 12:32 PM, Story H.J. <H.J.Story@soton.ac.uk> wrote:
> 
> 
> > 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 12:57:38 UTC