On 10/31/2017 02:53 AM, Amos Jeffries wrote: > On 31/10/17 21:29, Troiano Alessio wrote: >> Can't be an idea to "forward" the rst to the client? In this way the >> proxy will be totally transparent and the reload is demanded to the >> client (browser). > That one is already on the wishlist and even has a old patch ... but the patch claims to have no affect on cases where Squid responds with an error page. That choice made it possible for that implementation to be configuration-free. If Squid starts forwarding *all* connection resets to clients, then some admins will rightfully complain that their users deserve a nice proxy-generated error page with a support ticket submission interface (instead of a silent connection reset with a confusing browser error page). In summary, no single behavior will satisfy everybody. We need a new configuration option flexible enough to cover known use cases, including Alessio's. For example, on_server_error with "retry", "respond", and "terminate" actions (ideally with an ACL to detect cases where there are no unused peer addresses left to try and an ACL to count the number of retries for the current peer address). Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
