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

From: Andrew Brown <anbrown_at_rim.com>
Date: Thu, 10 May 2012 23:58:29 +0000

On 5/10/12 4:33 PM, "Eliezer Croitoru" <eliezer_at_ngtech.co.il> 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.

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
- should I simply submit that patch to squid-dev?

Cheers,
Andrew

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Received on Thu May 10 2012 - 23:58:39 MDT

This archive was generated by hypermail 2.2.0 : Fri May 11 2012 - 12:00:03 MDT