- From: Martynas Jusevičius <martynas@atomgraph.com>
- Date: Sun, 29 Oct 2017 17:55:16 +0100
- To: "Story H.J." <H.J.Story@soton.ac.uk>
- Cc: public-webid <public-webid@w3.org>, "Ed - 0x1b, Inc." <w3c@0x1b.com>
- Message-ID: <CAE35VmyB3FSatnE4WUjVCymkthEvN9etKn50_6gR71GqvGOA_A@mail.gmail.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