gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] tla seeing stale .listing files through caching web


From: Richard Curnow
Subject: Re: [Gnu-arch-users] tla seeing stale .listing files through caching web proxy
Date: Mon, 24 May 2004 16:23:15 +0100
User-agent: Mutt/1.5.6i

* Adrian Irving-Beer <address@hidden> [2004-05-21]:
> On Fri, May 21, 2004 at 04:21:12PM +0100, Richard Curnow wrote:
> 
> TLA:
> > GET http://stampede.org/~lethal/%7barchive%7d/linux/ [. . .]
> 
> wget:
> > GET http://stampede.org/%7Elethal/%7Barchive%7D/linux/ [. . .]
> 
> I don't know the root of your problem, but I do know that according to
> my Squid proxy, these are two different URLs, even if they're both just
> the differently-escaped versions of the same URL.

Yes, I noticed that after I wrote the first message and wondered if it
was the explanation for what I'd seen.

> I would explore more, but unfortunately, I can't test locally... I think
> our proxy finds server access too fast and doesn't bother caching it or
> something. :)  Or it could be that I have to use internal (192.168...)
> addresses.
> 
> Possible solutions:
>       * use Apache mod_expires directives server-side,

I don't run the remote server

>       * use ACLs that exclude anything arch-like from being cached,

I don't run the proxy

>       * hack tla to use 'no-cache' directives.

I'll probably have to look at this option.

> I had to abandon use of tla over a proxy altogether, myself.  We use
> tight header filtering (inclusive, not exclusive) and there are just too
> many WebDAV headers to recompile Squid every time I find a new one.
> Particular the ones that turn out to be critical to a commit, and that
> cause tla to leave the repo in a manual-intervention-required state. :)

Write access isn't a problem fortunately, the repo I'm accessing through
http is read-only for me.

Thanks for your insights
Richard

-- 
Richard \\\ SH-4/SH-5 Core & Debug Architect
Curnow  \\\         SuperH (UK) Ltd, Bristol




reply via email to

[Prev in Thread] Current Thread [Next in Thread]