Why do I get a 503 Service Unavailable on an ESI Fragment using Varnish?

Question

I have set up locally Varnish and have implemented an ESI fragment on a specific area of the page; but as soon as I turn on ESI on the default.vcl, varnish stops caching and even more, that specific section of the page where the fragment is added, renders a 503 service unavailable notice instead.

The line that seems to make varnish stop caching is the else statement here:

if (req.url ~ "\.(png|gif|jpg|swf|css|js)$") {
    unset beresp.http.set-cookie;
    set beresp.ttl = 20m;
}
else {
    set beresp.do_esi = true;
}

Here is my default.vcl: http://pastebin.com/MEQF4Gbk

Now, in the RxHeaders I get a lot of "ESI_xmlerror c No ESI processing, first char not '<'"

Here a sample of one of the RxHeaders (for a JS file) http://pastebin.com/tX7zpBN1

I guess, I'm not understanding how am suppose to tell varnish to cache only when it has esi fragment? Can someone explain what I'm doing wrong?

I have since updated the default.vcl to this http://pastebin.com/yaW0hZeL then, the esi_blocks.vcl is this: http://pastebin.com/1CMr6q4E and the drupal.vcl to this http://pastebin.com/cz7zNDqQ but still getting a 503 error baked on that esi fragment part of the page. — Sam3k, Nov 20 '12 at 20:00

score 0 · Answer 1 · answered Jul 17 '13 at 19:44

Your vcl is set to do esi processing of not only the page containing the esi, but the esi fragments themselves, and the latter are failing resulting in 503s instead of the snippet you want. If you do not want to recursively process fragments as esi containers themselves you can change your VCL to:

if (req.url ~ "\.(png|gif|jpg|swf|css|js)$") {
    unset beresp.http.set-cookie;
    set beresp.ttl = 20m;
}
else if (req.esi_level == 0 ) {
    set beresp.do_esi = true;
}

If you do want to process those includes as esi containers themselves, make sure they start with an angle bracket < (varnish 2 defaults to only performing esi for html/xml). If that's not possible, you can configure varnish not to care by setting this param when starting varnishd:

esi_syntax=0×1

If I were you I would enable esi specifically for the resources that can contain esi:includes rather than disabling it for select content types like you are doing. This way you don't need to maintain a list in your VCL that might change, and resources that do not contain esi includes won't waste varnish's time scanning for them. You can do this based on a response header from the backend like X-Varnish-Do-Esi, and only send that response header for resources that contain includes.

Why do I get a 503 Service Unavailable on an ESI Fragment using Varnish?

1 Answers1