[PlanetCCRMA] Re: Size Mismatch Problem

Axel Thimm planetccrma@ccrma.Stanford.EDU
Tue Jul 20 18:06:01 2004


--+QahgC5+KEYLbs62
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 20, 2004 at 05:42:35PM -0700, Fernando Pablo Lopez-Lezcano wrot=
e:
> On Mon, 2004-07-19 at 04:10, Axel Thimm wrote:
> > On Mon, Jul 19, 2004 at 12:17:12PM +0200, David Fraser wrote:
> > > Axel Thimm wrote:
> > > >On Mon, Jul 19, 2004 at 05:09:48PM +0800, Andrew Wilson wrote:
> > > >>pkglist.updates
> > > >>pkglist.planetccrma
> > > >>srclist.planetccrma
> > > >>
> > > >>fail to download with a "Size Mismatch" error.  I left it for a
> > > >>while to see if it was a temporary error due to a repository
> > > >>update etc.  However I have been getting the error for a couple of
> > > >>weeks now.
> >=20
> > > >I don't have any issues. This is commonly seen on cached lines. Do y=
ou
> > > >have a transparent squid or otherwise, you can turn off? Or is your
> > > >ISP doing the caching for you?
> >=20
> > > I've often had problems like this. It would be great if there was a m=
ore=20
> > > intelligent way to try debug them ...
> > > I'm sure that they're not just caching problems as I've checked MD5 s=
ums=20
> > > from other hosts in other countries and still had the problems...
> >=20
> > On Mon, Jul 19, 2004 at 06:34:56PM +0800, Andrew Wilson wrote:
> > > I am not running any local proxy or caching.  My ISP does run a
> > > proxy so I need to confirm that this is not the problem. =20
> > >=20
> > > However the problem has been extending over a couple of weeks which
> > > is a long time to hold something in cache.  Also the update process
> > > was working fine on Fedora Core 1 (plus RH9 and RH8).  It was also
> > > possible to retrieve using wget (also http).
> > >=20
> > > My guess is still with something I have broken, but I am game to
> > > check anything.
> >=20
> > The mirror at planetccrma.atrpms.net has a server side expiry
> > mechanism to overcome intermediate proxys caching the metadata.
> >=20
> > Could you try this (It is updated once a day at 19:00 CEST)? If it
> > works it is a caching issue, if not, it is something else.
>=20
> It would be nice to know what happened if you try the atrpms mirror. If
> there is something I can do at the server side I would do it (Axel: how
> do you set that expiry mechanism?)

I use

ExpiresActive on
ExpiresDefault "now"
ExpiresByType application/x-rpm "access plus 30 days"
AddType application/x-rpm .rpm

E.g. all meta-data expire immediately, or all, but *.rpm
--=20
Axel.Thimm at ATrpms.net

--+QahgC5+KEYLbs62
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA/cEHQBVS1GOamfERAn4QAJ9FPpJf9qbun9Zj9Q3RHnkIv3tNHQCcDZt/
LRN8pnpSq+YiQvq0o57bnm8=
=/oXb
-----END PGP SIGNATURE-----

--+QahgC5+KEYLbs62--