Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #28483 > unrolled thread

invalidating caches

Back to article view | Back to comp.lang.java.programmer

Contents

  invalidating caches Roedy Green <see_website@mindprod.com.invalid> - 2014-05-15 02:26 -0700
    Re: invalidating caches leif.roar@invalid.com (Leif Roar Moldskred) - 2014-05-15 04:56 -0500
    Re: invalidating caches Jeff Higgins <jeff@invalid.invalid> - 2014-05-15 16:36 -0400
      Re: invalidating caches Roedy Green <see_website@mindprod.com.invalid> - 2014-05-16 01:58 -0700
        Re: invalidating caches Sarah Connor <s.connor@gmail.invalid> - 2014-05-16 10:31 +0000
          Re: invalidating caches "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-05-17 11:06 +0100

#28483 — invalidating caches

This is more a question about Internet protocols than Java.

I am first off the blocks to download new versions of software.  I
often find when I get there, only the old version is still posted.

I understand sometimes the new version has not had time to propagate
to all the mirrors, but I also suspect the old version might be stuck
in an intermediate cache somewhere. Sometimes the site will toggle
between two versions.

I read about this some time ago, and I understood that items in a
cache had a time to live.

What I wondered is, does the server have a way of broadcasting a cache
invalidate to ensure the new version is seen immediately?

If so, can you do it from Java?

The server in theory would know all the end-user IPS who had requested
the page recently, but I don't think caches let the server know what
they are up to.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Young man, in mathematics you don’t understand things.
You just get used to them. 
~ John von Neumann (born: 1903-12-28 died: 1957-02-08 at age: 53)

[toc] | [next] | [standalone]

#28485

Roedy Green <see_website@mindprod.com.invalid> wrote:
> 
> What I wondered is, does the server have a way of broadcasting a cache
> invalidate to ensure the new version is seen immediately?
> 
> If so, can you do it from Java?
>

Broadcasting? No. 

As with anything else in the HTTP protocol, there is no way for the
server to initiate communication with the client.

You can, however, have the _client_ request that intermediate caches
revalidate the freshness of the requested resource with the server, by
setting appropriate Cache-Control headers in the HTTP request.

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#28490

On 05/15/2014 05:26 AM, Roedy Green wrote:

> The server in theory would know all the end-user IPS who had requested
> the page recently, but I don't think caches let the server know what
> they are up to.
>
Caching Tutorial for Web Authors and Webmasters
<https://www.mnot.net/cache_docs/>

[toc] | [prev] | [next] | [standalone]

#28492

On Thu, 15 May 2014 16:36:55 -0400, Jeff Higgins
<jeff@invalid.invalid> wrote, quoted or indirectly quoted someone who
said :

>>
>Caching Tutorial for Web Authors and Webmasters
><https://www.mnot.net/cache_docs/>

One useful tip I learned from that tutorial is a server can
effectively invalidate caches by renaming a document or image.  The
client will have to fetch afresh even if the original had a long time
to live.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Young man, in mathematics you don’t understand things.
You just get used to them. 
~ John von Neumann (born: 1903-12-28 died: 1957-02-08 at age: 53)

[toc] | [prev] | [next] | [standalone]

#28493

On Fri, 16 May 2014 01:58:32 -0700, Roedy Green wrote:

> One useful tip I learned from that tutorial is a server can effectively
> invalidate caches by renaming a document or image.  The client will have
> to fetch afresh even if the original had a long time to live.

That has the nasty side effect of breaking existing bookmarks and links 
though.

[toc] | [prev] | [next] | [standalone]

#28514

Sarah Connor wrote:

> > One useful tip I learned from that tutorial is a server can effectively
> > invalidate caches by renaming a document or image.  The client will have
> > to fetch afresh even if the original had a long time to live.
>
> That has the nasty side effect of breaking existing bookmarks and links
> though.

But, on the other hand, the link to the old version remains separate from the 
link to the "latest" version which can be a good thing.

Nothing to stop a server having several links.  One which always redirects to 
the latest, and others which point to specific versions.  Note that provided 
the redirect is done at HTTP level (or equivalent) then the client and 
intermediates can still cache correctly.

Or poor man's cache control: have a query parameter in the URL which the server 
always ignores, but which code on the client (presumably JavaScript in the 
typical case) sets to a fresh value on each fetch.

    -- chris 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web