RE: [squid-users] squid 3.2 and error_map equivalent

OK, this seems a reasonable enough approach (but not ideal with the redirect) - I will give it a try.

The primary use is that we want to catch the icap errors (in case the icap-server is down) or "502 - Bad gateway"...

An additional question: how can I detect if the 502/... have been generated by squid and not by the upstream servers? (so that the error page redirect only happens in those cases)

Martin

-----Original Message-----
From: Amos Jeffries [mailto:squid3_at_treenet.co.nz]
Sent: Samstag, 23. M�rz 2013 02:15
To: squid-users_at_squid-cache.org
Subject: Re: [squid-users] squid 3.2 and error_map equivalent

On 23/03/2013 4:57 a.m., Martin Sperl wrote:
> Hi!
>
> Is there an equivalent for the squid 2.X error_map functionality?
>
> Depending on context we would need to provide different error messages and text customizations.
>
> The error_map config would have been an ideal match for my requirements - a small apache with mod_rewrite could easily get "abused" for that (including a policy framework which pages to deliver for which portion of the reverse-proxy URL, which virtual host does get accessed,...)
>
> Is there any different means to do that in an elegant manner that does not require icap or similar?

Not exactly. You are the first person to ask for it in that last 3
years, so no emphasis was made on porting the feature across.

error_map simpy replaces *all* upstream responses with the mapped status
code, using the same custom template. So it would not seem to meet your
"depending on context" requirement anyway.

Try this:
   acl 404 http_status 404
   deny_info YOUR_404_PAGE 404
   http_reply_access deny 404

... etc. Which should replace the server-provided content with
YOUR_404_PAGE *and* allows other ACLs n the reply rule set to determine
whether or not your page is to be mapped in.

Amos

This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp
Received on Mon Mar 25 2013 - 09:55:47 MDT