- From: Martynas Jusevičius <martynas@atomgraph.com>
- Date: Sun, 29 Oct 2017 13:14:40 +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: <CAE35Vmw=a1=3f-A+4CB4BbQkQO3ydkocB=etbjJQah0emy3OVg@mail.gmail.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