On 2014-02-28 04:58, Alex Rousskov wrote:
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.
"Range requests are an OPTIONAL
feature of HTTP, designed so that recipients not implementing this
feature (or not supporting it for the target resource) can respond as
if it is a normal GET request without impacting interoperability."
OPTIONAL says that squid is not obliged to pass on the client request
headers for this feature.
There are also later supporting statements with explicit MAY for server
ignoring the headers, and proxies dropping headers with unknown units.
All of which implies strongly the intent of this.
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.
Mine too thus the RFC. However my Google-fu hs not been able to bring up
any results indicating its actually alive anywhere these days. The
fallout from that Flash CVE seems to be that it was widely blocked from
frameworks and servers several years back.
Also, if the interoperability choice is to respond with 200 full-text
reply. All clients are already expected to handle that properly or we
would definitely have a lot more complaints.
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".
Ignoring conflicting Range and Content-Range may be hard. In the case
where Squid sends on Range: and an ignored Request-Range: that do not
overlap (or only partially) we will end up receiving Content-Range which
cannot provide any data for the client or not enough and forces t to
re-request. Repeating the request by Squid with the same headers will
not help. While fetching the entire object instead is worse than
dropping the Request-Range.
How about a mid-way solution (C). Moving the Request-Range logics into
an undefined "#if USE_OBSOLETE_REQUEST_RANGE" wrapper and waiting for
complaints?
Amos
