portsnap oddities

[Colin Percival]

Gary Newcombe wrote:
> Yes, nail on the head methinks. This server is behind a proxy and portsnap
> works fine with it disabled. With combination of advproxy, havp and privoxy:
> 
> [mesh:/var/db/portsnap]# l *[3d].gz
> -rw-r--r--  1 root  wheel    64B  5 Aug 12:51
> ad06d1f7b82db9ebcb496e7d48a754932622f1c8d6166564e61666d059f1b8fd.gz
> -rw-r--r--  1 root  wheel    64B  5 Aug 12:51
> ad3d51001a264245eab5894cece6c902d073841143e9ffc7ee8379948a44aae3.gz
> 
> Without:
> [...]
> Fetching 2 patches...
> [...]
>  done.
> Applying patches... done.
> Fetching 0 new ports or files...
> done.
> [mesh:/var/db/portsnap]# l *[3d].gz
> -rw-r--r--  1 root  wheel    64B  5 Aug 13:32
> ad06d1f7b82db9ebcb496e7d48a754932622f1c8d6166564e61666d059f1b8fd.gz
> -rw-r--r--  1 root  wheel    64B  5 Aug 13:32
> ad3d51001a264245eab5894cece6c902d073841143e9ffc7ee8379948a44aae3.gz
> 
> So the files did seem to be intact initially anyway?

Everything seems to be working fine now.  You can delete those two files; they
were left behind because I forgot to handle the case of 'file download failed,
portsnap gets run again, and then patch download succeeds'.  The correct
versions of the files are stored in the /var/db/portsnap/files/ directory.

> Just clearing the cache
> for the proxy didn't seem to solve the problem btw.

It's possible that your cache gets confused by pipelined HTTP.  It wouldn't be
the first time that has happened...

Colin Percival