[squid-dev] [PATCH] Reject responses with conflicting Content-Length

[Alex Rousskov]

On 08/11/2015 11:49 PM, Amos Jeffries wrote:

> Which one of these malformations is not malign ?
> 
>  * non-numeric Content-Length
>  * negative value Content-Length
>  * Content-Length with also Transfer-Encoding header
>  * multiple different-value Content-Length
>  * Content-Length on 204 response

All of them may be benign in _some_ cases. Again, just because something
is malformed, does not mean it was created with an evil purpose and
cannot be proxied as intended, without harm, in some specific environments.

It is pointless to argue about this. You are simply using a different
definition of "benign". My definition, in this context, is "broken but
not intended to maim".

Please note that I am _not_ arguing that all benign traffic has to be
proxied and cannot be blocked.


> Each time we go against spec we retreat from the situation of current
> best interoperability.

An RFC helps with general interoperability. In a specific environment,
it is sometimes possible to achieve better interoperability by violating
a MUST than by following it. This assertion is not only logical, but
proven by numerous examples, configuration options, and code. I hope we
do not need to argue about this.

We decide when those specific environments are worth accommodating, and
to what extent. Many factors go into that decision, including past Squid
behavior. We need to be careful when changing Squid to block something.
And careful action usually requires significant effort and discussion.
And that is part of the reason why I left other malformed cases outside
the scope of this thread.


> A lot of the issues you have been pointing out here and elsewhere is a
> result of people experimenting with their newly approved abilities.
> Sometimes getting it wrong, sometimes hitting remaining Squid flaws. But
> that is cause for reporting failures to the experimenters so they can
> fix inline with the spec (and/or us if we are the violator like this C-L
> case), not for bending over backwards to silently allow a whole new
> generation of brokenness to creep in.

I agree that reporting problems and blocking malformed traffic is often
the best choice.

However, the world is not black and white. Usually, the best action is
to block malformed traffic. Sometimes, the best action is to
accommodate. Usually, the best behavior can be hard-coded. Sometimes, we
need a configuration option to let the admin pick the best action for
her environment.

Alex.