Re: [squid-users] Squid error code response to NXDOMAIN

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
Received on Fri May 11 2012 - 03:04:26 MDT