On 10/17/2013 01:43 PM, zipped wrote:
> Thanks for the response, this sounds encouraging. The re-forwarding section
> of the faq details examples of when re-forwarding would fail, however I'm
> unclear on when it would actually work.
Documentation bugs notwithstanding, "it would actually work" in all
other cases. It is easy to test your specific case though, and I
recommend that you do that regardless of what the documentation says.
> Would a header of something like 404 be re-forwarded to the next hop?
No. 404 matches the last bullet on that wiki page because 404 is, I
quote, "not one of the following codes: 403 (Forbidden), 500 (Internal
Server Error), 501 (Not Implemented), 502 (Bad Gateway), 503 (Service
not available), and 504 (Gateway Timeout)."
http://wiki.squid-cache.org/SquidFaq/InnerWorkings?#When_does_Squid_re-forward_a_client_request.3F
> Also, I could not find anything on how to setup squid to do re-forwarding.
> Would re-forwarding be a default behavior of squid in a multiple server
> reverse proxy setup? Any information at all would be appreciated. I'm
> pretty new to squid.
It is difficult to say what the default is because, as you now know,
there are dozens of different scenarios where Squid has to make a
forwarding decision. Squid.conf options like retry_on_error have
defaults, but there are many other factors.
If you have control over the server behavior, I recommend that you
(a) Use one of the response status codes explicitly mentioned on the
wiki page;
and
(b) make sure that the last three bullets on the wiki page do not apply.
For example, use a 504 response status code OR turn reply_on_error while
using 403, 500, 501, or 503 code.
If you do not have control over the server behavior, you can adapt the
server response using eCAP or ICAP. For example, you can convert a 404
response into a 500 response. Alternatively, you can adjust Squid code
to re-forward 404 responses (e.g., by adding ACL support to
retry_on_error and then configuring Squid to re-forward 404 responses).
HTH,
Alex.
Received on Thu Oct 17 2013 - 20:34:20 MDT
This archive was generated by hypermail 2.2.0 : Fri Oct 18 2013 - 12:00:07 MDT