nginx as reverse caching proxy for CentOS repositories

Wouter Schoot wouter at schoot.org
Mon Mar 15 00:01:22 MSK 2010


Hi Maxim,

Thanks for your reply!

I do however have replies which state there is a cache-hit, so there's 
no need to refetch the file:

***14/Mar/2010:21:31:32 +0100 HIT Cache-Control: - Expires: - "GET 
/centos/5.4/os/i386/CentOS/chkconfig-1.3.30.1-2.i386.rpm HTTP/1.1" (200) 
"urlgrabber/3.1.0 yum/3.2.22"
***14/Mar/2010:21:31:32 +0100 HIT Cache-Control: - Expires: - "GET 
/centos/5.4/os/i386/CentOS/chkconfig-1.3.30.1-2.i386.rpm HTTP/1.1" (200) 
"urlgrabber/3.1.0 yum/3.2.22"

(using the following log-line:     log_format cache '***$time_local '
                      '$upstream_cache_status - $upstream_status - '
                      'Cache-Control: $upstream_http_cache_control '
                      'Expires: $upstream_http_expires ')

> Most likely your client (incorrectly) assumes that range request
> must by satisfied, and bails out due to getting full reply (which
> happens when url in question isn't yet cached).
>
> Looking into client code may shed some light on the problem.

So it probably lies somewhere in the Range header. Is there some setting 
I can use in nginx to override or obey whatever the CentOS installer 
wants? A client-hack in nginx' config, so to say?

But, now that I think of it.. When nginx has the file cached (HIT 
cachestatus), how does nginx' reply to the client differ from the 
original one... When I directly fetch the rpm from the backend mirror 
(during install), there's no problem at all. Only when I put nginx in 
between, with or without the rpm in cache, it fails on me.

Wouter




More information about the nginx mailing list