On 11/05/2012 11:58 a.m., Andrew Brown wrote:
On 5/10/12 4:33 PM, "Eliezer Croitoru" wrote:
On 10/05/2012 23:47, Andrew Brown wrote:
Hello,
I'm comparing Squid 2.7 to Squid 3.1, and I've found the error code
returned between the two versions differs when attempting to fetch a
site
where the domain name does not exist. In Squid 2.7, it returns an HTTP
504 (Gateway Timeout), while Squid 3.1 returns an HTTP 503 (Service
Unavailable)
I've narrowed this down to FwdState::makeConnectingError(err_type), but
I'm not sure if this is by design.
It seems to be related to whether the request requires validation, but I
can't see an obvious way to force this via configuration.
In lieu of finding a way to force Squid 3.1 to always return an HTTP 504
error code, I've prepared a patch which seems to work, but I'd still
like
some community feedback prior to submitting it. Is there a particular
reason why Squid 3.1 will return either HTTP 503 or 504, depending on
whether the request requires validation?
Thanks,
Andrew
well there is not a really one way to implement it.
the real issue is not a 504 case because the gateway is available and
running OK.
so it's not a gateway issue.
but it's also not a 503 code because this is dns resolution case and can
be because of couple of reasons.
i think that it's better left as a 503 because instead of checking
routing issue on the proxy you will check another level.
Eliezer
Yes, I understood that; there is no real HTTP error response code for
NXDOMAIN.
Unfortunately, we have sort a split-horizon, where our clients use ProxyA
as a default unless they receive an HTTP 504 response. When those clients
receive that HTTP 504 response code, they fail back to ProxyB which
hopefully can resolve that name, and if not, returns the same error code.
Hence, Squid 3.1 in its vanilla form causes issues for these clients,
since it returns HTTP 503 now.z
So there are no concerns about it either way? Our patch effectively
returns Squid 3.1 back to Squid 2.7 behaviour via configuration parameter
There is no "back" involved here. 2.7 and 3.1 are alternative forks of
the 2.5 release, one in C and one in C++.
They are being re-combined in 3.2 release series, which deprecates both
series.
- should I simply submit that patch to squid-dev?
This is bug http://bugs.squid-cache.org/show_bug.cgi?id=1274 whose
discussion covers the multiple details that have to be taken into
account first.
A patch is welcome, but it needs to meet several requriements:
* to resolve things within the HTTP semantic use-cases discussed in
the bug report.
* a new configuration parameter is not necessary, the traffic mode and
DNS codes should be sufficient to differentiate the cases.
* needs to be on 3.2 series. Older series the DNS details are isolated
within the DNS component and unavailable at the point 5xx is decided.
Amos
