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

[Alex Rousskov]

On 08/10/2015 11:30 PM, Amos Jeffries wrote:

> There is exactly 2 cases of benign malformation:
...
> All other malformations are *malign*.


This is your opinion, not a fact.

IMO, being "benign" cannot be defined by an RFC because that
classification depends on real-world circumstances, not just syntax
rules. An RFC can require action X when a header is malformed, of
course. We ought to follow that recommendation except if doing X breaks
too many benign real-world cases. If the latter happens, we may want to
give admin a choice.

All of that complexity and decision making is outside this thread scope.


>> For the record, here is a Bing server response that prompted this change:
>>
>>> HTTP/1.1 206 Partial Content
>>> Cache-Control: public, max-age=15552000
>>> Content-Length: 14543
>>> Content-Type: application/x-javascript; charset=utf-8
>>> Last-Modified: Tue, 14 Jul 2015 01:35:04 GMT
>>> Vary: Accept-Encoding
>>> Server: Microsoft-IIS/8.5
>>> Date: Wed, 05 Aug 2015 15:42:26 GMT
>>> Content-Length: 300
>>> Content-Range: bytes 14243-14542/14543
>>> Accept-Ranges: bytes
>>
>> As you can see, the addition of an extra Content-Length field was
>> probably triggered by the partial response to the Range request.


> Is that an IIS? Bing? or ICAP server bug?

AFAIK, the quoted header did not come from the ICAP server under Squid
control. I believe it came from some Bing server, but I do not know the
details. The reasons I mentioned that header here is to document that
the problem is happening right now, possibly on a relatively popular
site, and may involve a relatively complex combination of headers.


HTH,

Alex.