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