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 17:55:16 +0100
Message-ID: <CAE35VmyB3FSatnE4WUjVCymkthEvN9etKn50_6gR71GqvGOA_A@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>
Henry,

I meant that server generates multiple Linked Data sub-requests to assemble
content from multiple resources, which all happen to be WebID-protected.
WebID profiles are public so loops are not an issue, but performance
overhead is.

On Sun, Oct 29, 2017 at 1:56 PM, Story H.J. <H.J.Story@soton.ac.uk> wrote:

>
>
> > 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 16:55:40 UTC

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