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.
