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.
Received on Thu Feb 27 2014 - 15:58:32 MST
This archive was generated by hypermail 2.2.0 : Fri Feb 28 2014 - 12:00:15 MST