2.6 (2.5.STABLE11 also)

Bug link:


How it is diagnosed (reproduced or source analysis)?

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


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?


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!