> > I'm more inclined to believe that this isn't due to the redirect so much > as the size of the response headers. Pulling any random package off the > arch website (which has a 302 redirect) doesn't show this behavior:
You're right, my headers are bigger, mirrorbrain include many things: [faidoc@Delorean ~]$ curl -sD- -o/dev/null > http://mirrors.cinnarch.com/cinnarch-core/x86_64/cinnarch-keyring-20120717-3-any.pkg.tar.xz > HTTP/1.1 302 Found > Date: Thu, 10 Jan 2013 18:49:17 GMT > Server: Apache/2.2.16 (Debian) > X-MirrorBrain-Mirror: softlibre.unizar.es > X-MirrorBrain-Realm: country > Link: < > http://mirrors.cinnarch.com/cinnarch-core/x86_64/cinnarch-keyring-20120717-3-any.pkg.tar.xz.meta4>; > rel=describedby; type="application/metalink4+xml" > Link: < > http://softlibre.unizar.es/cinnarch/cinnarch-core/x86_64/cinnarch-keyring-20120717-3-any.pkg.tar.xz>; > rel=duplicate; pri=1; geo=es > Link: < > http://www.mirrorservice.org/sites/repo.cinnarch.com/cinnarch-core/x86_64/cinnarch-keyring-20120717-3-any.pkg.tar.xz>; > rel=duplicate; pri=2; geo=gb > Link: < > http://cinnarch.limun.org/cinnarch-core/x86_64/cinnarch-keyring-20120717-3-any.pkg.tar.xz>; > rel=duplicate; pri=3; geo=de > Digest: MD5=rmURnbMAoRYoNhtja1VQgA== > Digest: SHA=Hu0X2ym8sBEUQGaXjvFQHdIctgw= > Digest: SHA-256=nfFkPNZd8vq05MUCxOVqlwE3YMrAJzT9R0xga6P0DNY= > Location: > http://softlibre.unizar.es/cinnarch/cinnarch-core/x86_64/cinnarch-keyring-20120717-3-any.pkg.tar.xz > Vary: Accept-Encoding > Content-Length: 369 > Content-Type: text/html; charset=iso-8859-1 2013/1/8 Dave Reisner <d...@falconindy.com> > On Tue, Jan 08, 2013 at 12:39:22AM +0100, Alexandre Filgueira wrote: > > Hi > > > > I have a repo using redirections to let the server get the closest mirror > > for the client using Mirrorbrain software. When configuring pacman to > that > > mirror, he follows the redirection as expected by using FOLLOWLOCATION in > > curl opts, but he shows 2 download progress, I guess that one is for the > > redirection and the last one for the file itself. So my question is... > > should be look like that? or would be correct to detect redirections and > > show just one download progress? > > I'm more inclined to believe that this isn't due to the redirect so much > as the size of the response headers. Pulling any random package off the > arch website (which has a 302 redirect) doesn't show this behavior: > > $ sudo pacman -U > https://www.archlinux.org/packages/extra/x86_64/aalib/download/ > alpmtmp.q1pXbL 144.7 KiB 591K/s 00:00 > [----------------------] 100% > loading packages... > resolving dependencies... > looking for inter-conflicts... > > Packages (1): > > Name New Version Net Change > > aalib 1.4rc5-9 0.75 MiB > > Total Installed Size: 0.75 MiB > > Proceed with installation? [Y/n] > > The header size is a full 100 bytes smaller than your example: > > $ curl -sD- -o/dev/null > https://www.archlinux.org/packages/extra/i686/aalib/download/ | wc -c > 287 > > > > > This is an example of what is writting pacman: > > > > Proceed with installation? [Y/n] y > > > :: Retrieving packages from cinnarch-repo... > > > faenza-icon-theme-1... 382.0 B 6.51M/s 00:00 > > > [######################] 100% > > > faenza-icon-theme-1... 10.8 MiB 333K/s 00:16 > > > [##############--------] 66% > > > > Uggh. IMO, curl really shouldn't be doing this and should only be > triggering the progress callback for the response body. > > d > >
