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


_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx