On 02/27/2014 12:58 AM, Amos Jeffries wrote: >>> FWIW: the specification says any proxy MAY drop Range at its choice.
Where does it say that? I do not see such language in Section 3.1 of draft-ietf-httpbis-p5-range-26. There is a "MAY reject" clause, but rejection implies a 416 error response rather than a silent removal AFAICT. The proxy MAY ignore the Range header, of course, but that is again different from removing it. >> Do you propose to hard-code actions (a) and (b)? Will some existing or >> new option control this behavior? > > > (A) can be hard-coded in the form of either: ... > (B) the putRange() can detect multiples and set the range to a special > (empty header?) value that gets stripped at the end of parsing. ... My concern is that we will break interoperability with some clients if we start removing all Request-Range headers and/or all duplicate Range headers. I am sure we can implement this one way or another, but I am not sure such policing will not result in breakages. This is a common problem with "garbage in, compliance out" arguments: On one hand, it is nice to help your neighbor by sanitizing traffic. On the other hand, each sanitation act increases the chances of introducing real-world incompatibility that we will have to deal with later. My preference here is to sanitize nothing but ignore contradicting Content-Range and Range specs. I will not object to other approaches, especially if their proponents promise to adjust their code if/when admins complain about clients that modified Squid started to "break". Thank you, Alex.