Bash – Creating a RFC 1123 compliant date for HTTP header creation on the CLI

First of all, you should know that you are running an obsolete version of ModSecurity (branch 1.x). If you are running Apache 2.0.x you should upgrade to ModSecurity 2.x. If you are still running Apache 1.3.x then I am afraid that you don't have a choice since ModSecurity 2.x won't work with it. ModSecurity 1.x itself is not known to be vulnerable, but its rule engine is too inflexible for today's demands.

If I recall correctly, ModSecurity 1.x required POST requests to specify content length purely because it didn't support chunked request bodies (the alternative way of submitting request bodies, in which the total length is not known until the end). Chunked request bodies were incredibly rare then (we're talking years 2003, 2004) and are still rare (although some mobile devices are using them).

There are no such restrictions in ModSecurity 2.x.

If you remove that rule you will create a big hole through which someone could sneak in an attack undetected. On the other hand, I can argue that, with you running ModSecurity 1.x, there are other ways to do the same. Alternatively, tweak the rule to refuse requests that have the Transfer-Encoding request header set. You should be safe with that.

Disclosure: I wrote ModSecurity.

I think I understand your confusion. It works, but not as you were expecting.

SQUID does not actually redirect with the redirect_program directive, it rewrites. For example:

www.domain.com points to an IP that SQUID is available on

SQUID pipes the request through redirect_program

SQUID rewrites www.domain.com/dir1/ to server1 and www.domain.com/dir2/ to server2.

The client sees the same thing the whole time, as SQUID doesn't redirect.

Hopefully this is clear. If redirection is the functionality you desire, you might consider using Apache's mod_rewrite. It is more suitable for redirect functionality.