W3C home > Mailing lists > Public > public-webid@w3.org > October 2017

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

From: Martynas Jusevičius <martynas@atomgraph.com>
Date: Sun, 29 Oct 2017 13:14:40 +0100
Message-ID: <CAE35Vmw=a1=3f-A+4CB4BbQkQO3ydkocB=etbjJQah0emy3OVg@mail.gmail.com>
To: "Story H.J." <H.J.Story@soton.ac.uk>
Cc: public-webid <public-webid@w3.org>, "Ed - 0x1b, Inc." <w3c@0x1b.com>
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.

So I will need to come up with some heuristic here.

Maybe this is worth mentioning in the spec?

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:15:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:06:03 UTC