I do believe that from a run-time point of view (such as speed and cpu
load) there is not much of a difference between using squid acls for
headers and hard-coding a decision.
However I do think that squid users\consumers can vary between
ISPs\enterprises\homes\smbs\others and any default settings would put
one of the consumers into a very strange situation if the acls for
headers will be hard-coded.
The response to alex question why would anybody want to drop
"cteonnt-length:" header:
Some places do not allow cookies or POST for external services and it's
sometimes can looks weird but I still understand why would it be
considered a security hole by some minds.
For most default setup the main concern is caching and not ACLs and
security policy for data smuglling throw the proxy.
We can try to release a recommended list of acls for a more secure
environments and less strict for common used headers acls.
Eliezer
On 07/19/2014 09:06 PM, Alex Rousskov wrote:
>or reject requests with cteonnt-length: header in self defense.
Rejecting requests goes even further from the original RFC, but I
believe we have configuration options to do that as well.
Going forward, I suggest the following discussion format:
For each header (or an algorithmically defined group of headers):
a) Why does anybody may want to drop this header?
b) How do we want to tell Squid that the header should be dropped?
Hard-coded decision, existing squid.conf directives, other?
c) What should be the default behavior? Drop or leave "as is"?
d) Any side actions if the header is dropped? For example, should we
also drop the headers the dropped header lists?
HTH,
Alex.
