Re: [squid-users] Modifying error Responses.

From: Chris Robertson <crobertson@dont-contact.us>
Date: Mon, 04 Feb 2008 12:18:34 -0900

Krist van Besien wrote:
> Hello all,
>
> I need a way to modify the body of a response when a server responds
> with an error code. I have a suspicion that this may be possible with
> squid, but I'm getting a bit confused by the terse documentation.
>
> First a bit of background to better understand the problem.
>
> We run a website that serves content for mobile phones. This content
> resides on several backend servers, most of them live with partners
> who provide our content. We have an "aggregator" that accepts requests
> from mobile phones, and then in turn requests the content form one or
> more backend servers. The content these backends deliver is xml, and
> this xml gets transformed by our aggregator in to something a mobile
> phone can display. We access these backends through a squid proxy to
> have some caching.
>
> Our problem is that sometimes the backend sends an error (404, 500
> etc..) without a properly formed xml body. This causes a thread on our
> aggregator to block until a timeout is reached. As a result a problem
> on a backend can lead to resource depletion on our aggregator.
>
> On possible solution would be to modify error responses. We want to
> tack our own xml response body in to any errror response we get from
> a backend.
>

Look at the error_map directive
(http://www.squid-cache.org/Versions/v2/2.6/cfgman/error_map.html).
While it states it is designed for accelerators, I imagine it should
work in a forward proxy.

> I've done some reading, and came across ICAP, eCam and clientstreams.
> From the little documentation that is available i'm not sure how to
> attack this problem.
> - I only want to modify http responses when the backend server sends
> an error code (4xx, 5xx).
> - I only want a simple modification. Basically swap out whatever body
> in the response with our own.
> - We currently use squid 2.6. We could move to 3.0 if needed.
>
> Any suggestions as to what the best way to solve our problem would be
> are welcome.
>
> Krist van Besien
>
>

Chris
Received on Mon Feb 04 2008 - 14:18:56 MST

This archive was generated by hypermail pre-2.1.9 : Sat Mar 01 2008 - 12:00:04 MST