Re: [RFC] drop Request-Range header support

On 02/27/2014 02:57 PM, Amos Jeffries wrote:
> 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."

Sure.

> OPTIONAL says that squid is not obliged to pass on the client request
> headers for this feature.

Sorry, but I believe your interpretation of OPTIONAL is just wrong. The
proxy is required to forward end-to-end headers. Range is an end-to-end
header. No OPTIONAL feature would work if proxies start dropping the
headers related to it!

> 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.

I saw those statements. I do not think they imply that proxies can
remove Range. If the intent was to say that proxies can drop Ranges (not
ignore, but remove them!), the specs are buggy and should be adjusted to
say that explicitly.

> Ignoring conflicting Range and Content-Range may be hard.

Ignoring them is not hard. Just keep HttpRequest::range pointer NULL and
Squid will ignore them. Please note that I am advocating ignoring all
*Range headers if at least two of them conflict. I am not advocating
ignoring just some of the *Range headers in the request. If one of them
is broken or any two are inconsistent, we should ignore all of them.

> 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.

If my approach is implemented, the client talking through Squid will get
exactly what the same client will get without Squid. If a broken client
is happy, so are we. If a broken client is not happy, they would not be
able to rightfully blame Squid for "breaking" something.

> 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?

Your call. As I said, I do not object to removal of that code, whether
that means #ifdefing it, commenting it out, or removing it completely.

Cheers,

Alex.
Received on Thu Feb 27 2014 - 22:33:52 MST