0

I just setup a stock varnish install on debian and I am testing it out. It seems to work fine, except its not loading anything in the "/images" folder.

Works over Lighttpd:

example.com/images/rss_icons.gif

Does not work via Varnish

example.com:6081/images/rss_icons.gif

Logs (IP's hidden)

15 SessionOpen  c 0.0.0.0 62452
15 ReqStart     c 0.0.0.0 62452 784321607
15 RxRequest    c GET
15 RxURL        c /images/rss_icons.gif
15 RxProtocol   c HTTP/1.1
15 RxHeader     c Host: 0.0.0.0:6080
15 RxHeader     c User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0
15 RxHeader     c Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
15 RxHeader     c Accept-Language: en-US,en;q=0.5
15 RxHeader     c Accept-Encoding: gzip, deflate
15 RxHeader     c Connection: keep-alive
15 VCL_call     c recv
15 VCL_return   c lookup
15 VCL_call     c hash
15 VCL_return   c hash
15 Hit          c 784321606
15 VCL_call     c hit
15 VCL_return   c deliver
15 Length       c 345
15 VCL_call     c deliver
15 VCL_return   c deliver
15 TxProtocol   c HTTP/1.1
15 TxStatus     c 404
15 TxResponse   c Not Found
15 TxHeader     c Content-Type: text/html
15 TxHeader     c Server: lighttpd/1.4.19
15 TxHeader     c Content-Length: 345
15 TxHeader     c Date: Sun, 13 Jan 2013 16:23:33 GMT
15 TxHeader     c X-Varnish: 784321607 784321606
15 TxHeader     c Age: 7
15 TxHeader     c Via: 1.1 varnish
15 TxHeader     c Connection: keep-alive
15 ReqEnd       c 784321607 1358094213.560343742 1358094213.560402632 0.180203199 0.000025749 0.000033140

Any ideas or suggestions?

4
  • Can you please post your default.vcl file here. That will help us to understand the problem
    – Napster_X
    Jan 13, 2013 at 18:38
  • Please provide the log of the request that made a backend request (seven seconds before this one) - this is just showing a cached 404 response. Jan 13, 2013 at 18:58
  • I created a symlink to the images folder called img, and updated the HTML and the picture did load correctly. I'm not seeing anywhere in the configs where the "images" folder would be set to do something different.
    – Aaron A
    Jan 13, 2013 at 20:39
  • @GeekRide /etc/default/varnish - pastebin.com/nuwRw8Gj /etc/varnish/default/acl - pastebin.com/BsL4q6Cn
    – Aaron A
    Jan 13, 2013 at 20:45

2 Answers 2

0

Probably you have accessed /images/rss_icons.gif before the directory existed so it entered varnish cache as a 404 and is now served as such from the cache.

You can purge the entries related to /images from the cache with a purge operation. See this related question.

5
  • That's not it - just installed varnish today, and the site content has not changed for weeks. Regardless, I tried anyway - no difference.
    – Aaron A
    Jan 14, 2013 at 2:35
  • But now you should have a trace in lighttpd error log of the 404 following your attempt after the purge of related varnish objects. Jan 14, 2013 at 10:58
  • I did see that trace before, which makes no sense (the 200 request from lighttpd direct, and the 404 through varnish): acccess log
    – Aaron A
    Jan 14, 2013 at 12:30
  • According to access_log, in the 200 case there's one hostname in the HTTP Host field, and in the 404 case a different one (shown as 1.2.3.4). That looks wrong, it should be the same in both varnish and non-varnish case. Assuming you hit varnish with http://1.2.3.4:port/path, then better use the real hostname instead of the IP address so that lighttpd has the same information to process independently of varnish. Jan 14, 2013 at 12:59
  • I tried loading them both view IP or both via hostname - the results are consistent and the 404 always displays on anything in the images folder when accessed via varnish
    – Aaron A
    Jan 15, 2013 at 3:44
0

The problem was a default line in one of the lighttpd configuration files:

$HTTP["remoteip"] =~ "127.0.0.1" {
    alias.url += (
            "/doc/" => "/usr/share/doc/",
            "/images/" => "/usr/share/images/"
    )
    $HTTP["url"] =~ "^/doc/|^/images/" {
            dir-listing.activate = "enable"
    }
}

After removing that, everything is good to go!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .