in reply to Page Expiration

I can confirm seeing this on drinkd's browser. I'm the other PerlMonk in question. The first time he accesses the site each day, he sees a cached version of the site as seen from within my account.

We did experiment enough to verify that he couldn't actually use my account to post or vote, but it's still a little disturbing that he could see, for example, my personal messages.

One point I will note is that he's not clicking the "Remember me" checkbox when he logs in (he prefers to log in each day). This could be relevant. It also means that theoretically any Anonymous Monk in my company could be viewing my account on a daily basis!

I assume that our company's proxy server is caching things over-aggresively. Isn't there some way to circumvent this?

Update: I should be more explicit about something that drinkd alluded to. We work at a large corporation with a corporate IT group that is never ever going to bother reconfiguring the gateway solely for our PerlMonks viewing pleasure. This leads us to hope that the answer lies elsewhere. What we're wondering is: Should PerlMonks be using something like an Expires: header? Is it already doing this?

buckaduck

Replies are listed 'Best First'.
Re: Re: Page Expiration
by maverick (Curate) on Nov 09, 2001 at 20:39 UTC
    I run the squid proxy server at home and it has a configuration option to specify, based upon a url regexp, what things to cache or not to cache. I would suspect that most decent proxy programs have a way to do this. I'd suggest having your sysadmin look into this, because odds are, PM isn't the only site that your proxy will over aggressively cache.

    /\/\averick
    perl -l -e "eval pack('h*','072796e6470272f2c5f2c5166756279636b672');"

[reply]

      Perl Monks isn't the only site that doesn't deal with Web caches properly, but that's no reason for it to violate HTTP standards.

      If an HTTP response makes no statement as to what a cache should do with it (no Last-Modified, Expires or Cache-Control), the document is considered cacheable.

      I disagree that cache administrators should be held responsible for creating workarounds for non-compliant sites. Web site/application developers should be responsible for ensuring their code works properly.

[reply]
        I agree that PM should send the proper headers. That will fix the problem they have with PM. Now, what about the other >50% of the sites on the net that don't? Should their sysadmin (or the end user) be burdened with the task of contacting the admins of every site and asking them to fix/add the correct cache headers?

        In a perfect world everyone's headers would be correct, then again in a perfect world nobody would use MS Word to generate HTML. :) Yes, the correct solution is that every site on the net should send the correct headers, HOWEVER the practical/realistic solution is to configure your cache. I would wager that it is possible to tell >90% of the time whether or not a URL is dynamic or not based upon it's construction and for that matter squid comes out of the box with a set of rules that have never needed to be tweaked.

        /\/\averick
        perl -l -e "eval pack('h*','072796e6470272f2c5f2c5166756279636b672');"

[reply]
Re: Re: Page Expiration
by blakem (Monsignor) on Nov 10, 2001 at 01:51 UTC
    A silly client side hack would be to access perlmonks through some of its lesser known aliases: http://yoda.blockstackers.com comes to mind....

    Or, you could muck with your own DNS, (with /etc/hosts, its Windows equivalent, or a local DNS caching server) to point some other odd domain (ThisReallyIsForWorkIPromise.com perhaps??) at perlmonks IP.

    If your cache is based on domain names (which I imagine it would be) this would prevent the casual anonymonk from tripping over your private messages.

    -Blake

[reply]

In Section Perl Monks Discussion