[PATCH] Re: [RFC] drop Request-Range header support

On 28/02/2014 11:33 a.m., Alex Rousskov wrote:
> 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.

Please look at what decideIfWeDoRanges() already does to the server traffic.
Under your proposal to ignore Request-Range and treat Range normally
Squid will newely become a client emitting only Request-Range whenever
range_offset_limit exceeded or connection-auth is used.

Under my proposal it would never emit Request-Range and treat Range like
it does now normally. Except not being overridden if Request-Range
follows it. The result is that the Range feature behaviour should happen
as per the spec, without unexpected range responses appearing from
servers (and from older Squid installs) taking the Request-Range values
as their basis.

(PS. I am also confused as to why connection-auth is relevant to Ranges.
But that is another discussion.)

> Range is an end-to-end
> header. No OPTIONAL feature would work if proxies start dropping the
> headers related to it!

Agreed on that last sentence. Which is why the _original_ proposal was
only to discard the conflicting non-standard and apparently *rare*
legacy header (Request-Range). Or to drop the lot when there is a conflict.

This is what Squid is currently doing (from the HTTPbis part 1 spec):
"
   All HTTP requirements applicable to an origin server also apply to
   the outbound communication of a gateway. A gateway communicates with
   inbound servers using any protocol that it desires, including private
   extensions to HTTP that are outside the scope of this specification.
"

At present mapping a non-standard legacy Request-Range header into an
server Range request as if it were just "Range:". Overriding any actual
Range header which preceeded it (and being overridden if its preceeding
a Range).

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

This bit seems quite explicit about proxy being allowed to drop/discard
Range when appropriate:

" A proxy MAY discard a Range
   header field that contains a range unit it does not understand.
"

The header list unfolding is supposed to happen forst before
interpretation. So two Range headers are *supposed* by the message
syntax to concatenate with a ','. But that results in an invalid string
for the Range field-value.

... I am reading the OPTIONAL as implying we can pretend not to support
"bytes" unit on these broken requests and discard the invalid field-value.

The feature is entirely dependent on this first header being delivered.
Breakage risk only starts occuring if the response headers are fiddled
with. If this request header is never delivered at all the feature is
simply not used. HTTP continues working fine.

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

By the time Content-Range is received and conflicts we have already
*not* ignored Range in its entirety. One Range header is being managed,
the others have been ignored and we have no idea if the ignored one(s)
is what the server response is about.

Anyhow. This is way off track from the proposal. Which is primarily
about legacy Request-Range header.

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

Good point. Patches attached for what I understand each of our proposals
are. Now lets see what goes wrong :-P

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

But you are objecting to ignoring Request-Range?

Amos