squid-1410

Version:

2.6 (2.5.STABLE11 also)

Bug link:

http://bugs.squid-cache.org/show_bug.cgi?id=1410

How it is diagnosed (reproduced or source analysis)?

We did not reproduce the failure, but only analyzed the source and discussions.

Symptom:

The failure occurs when users configured an array of squid servers to form a big cache. Instead of asking other squid to serve the a cache miss, the squid directly forwarded the request to the backend server.

Root cause:

The root cause is that ‘httpd_accel_port’ differs from ‘http_port’, but the action of asking other servers for object depends on the condition ‘httpd_accel_port == http_port”. The fix is to relax this condition.

More detail:

diff -u -p -r1.561.2.86 client_side.c

--- src/client_side.c                

+++ src/client_side.c        

@@ -3145,8 +3145,8 @@ clientReadRequest(int fd, void *data)

            request->flags.accelerated = http->flags.accel;

            if (!http->flags.internal) {

                if (internalCheck(strBuf(request->urlpath))) {

-                    if (internalHostnameIs(request->host) &&

-                        request->port == ntohs(Config.Sockaddr.http->s.sin_port)) {

/* So in fact, the ‘request->port’ shouldn’t be checked (enforced) when setting ‘http->flags.internal’ to ‘1’. The actual request port is not the same as ‘Config.Sockaddr.http->s.sin_port’ in the buggy case. */

+                    if (internalHostnameIs(request->host)) {

+                        request->port = ntohs(Config.Sockaddr.http->s.sin_port);

                        http->flags.internal = 1;

                    } else if (Config.onoff.global_internal_static && internalStaticCheck(strBuf(request->urlpath))) {

                        xstrncpy(request->host, internalHostname(), SQUIDHOSTNAMELEN);

Call path:

clientReadRequest->clientAccessCheck->clientAccessCheckDone->clientRedirectStart->clientRedirectDone->clientCheckNoCache-> clientCheckNoCacheDone->  clientProcessRequest

// Later in function ‘clientProcessRequest2’: r->flag.internal is used to determine whether to ask other squid servers for the object.

   if (r->flags.cachable || r->flags.internal)

        e = http->entry = storeGetPublicByRequest(r);

So essentially the patch loosen the condition check to set ‘http->flags.internal = 1’, which will determine the late behavior.

Is there Error Message?

No.

Can Errlog/developers anticipate error?

No. The error manifestation condition is not clear and domain specific. If developers can anticipate this, it means that they can avoid the bug as well!