in reply to Re: [OT] HTTP downloads and caching
in thread [OT] HTTP downloads and caching

Yeah, my initial thoughts were along the lines that the hosting company had somehow stuffed up a server upgrade.
If I can find a case where someone other than me can hit the same issue then I'll consider entertaining the same thought again.
But, as it currently stands, it apparently affects only me and it happens to me *every* time I download that file over http.
OTOH, if it is affecting only me, then that doesn't really matter - that would be good news.

There are some other oddities that I didn't mention.
When I updated www.sisyphusion.tk/ppm/Math-Float128.ppd, I also updated www.sisyphusion.tk/ppm/package.xml - but there's no problem grabbing the updated version of package.xml.
It's only the updated version of Math-Float128.ppd that I can't grab.
Now that's really odd, isn't it. Two files in the same directory - no problem getting the current version of one of them, but I can only get the *previous* version of the other !

Actually, there's at least one other file (in a different directory) that was also updated, and is affected in the same way.

Anyway, thanks for checking - it helps to know that it's not *just* the hosting company that can wget the current version of the file.
And thanks for going to the additional trouble of thinking about it, and of articulating those thoughts.

I would strongly suspect that my problem was indicative of some caching on my local machine if not for the fact that it's happening on all three of my local machines - two (ie the two Linux ones) of which don't get fired up all that often.
That all three machines are affected in the same way leads me to think that it's my ISP that's throwing the spanner into the works. (My next step will probably be to see what my ISP thinks of that hypothesis :-)

Cheers,
Rob

Replies are listed 'Best First'.
Re^3: [OT] HTTP downloads and caching
by hippo (Archbishop) on Oct 07, 2015 at 12:54 UTC
    That all three machines are affected in the same way leads me to think that it's my ISP that's throwing the spanner into the works. (My next step will probably be to see what my ISP thinks of that hypothesis :-)

    That sounds like the obvious conclusion to me, too. You could always check whether it is a caching issue (either at the ISP or elsewhere) by appending a query string to the URL. Or indeed by using an https URL if one is available for that resource.

    Good luck with your investigations.

[reply]
      You could always check whether it is a caching issue (either at the ISP or elsewhere) by appending a query string to the URL

      I don't think I would *ever* have thought of that. What good thinking !!

      So ... when I append a (random) query string to the URL I get the "new" file, but when I omit the query string I get the "old" file.
      This surely demonstrates that it's a caching issue, but is there a way for me to pinpoint the location of this cache ?

      Afterthought: If wget is accessing a cache on the local linux machine, where would that cache be located ?

      Cheers,
      Rob
[reply]

        Caching is a good possibility worth investigating but the query string may or may not affect a serverside or middleware/service cache; their heuristics for what constitutes a new or different request are up to them.

[reply]
        is there a way for me to pinpoint the location of this cache ?

        Not if it's outside your control. If you run your favourite packet sniffer at the border of your network (ie. as far up the chain as you have access) that should show whether the cache is outside or not.

        If wget is accessing a cache on the local linux machine, where would that cache be located ?

        I'm not familiar enough with wget to comment, but I think that's highly unlikely anyway given you've been trying with different user agents on different client machines. A quick google shows that wget has a --cache option which can be set to "off" to bypass upstream proxies.

[reply]

In Section Seekers of Perl Wisdom