Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4E57C5CB.7010403@rowe-clan.net>
Date: Fri, 26 Aug 2011 11:11:55 -0500
From: "William A. Rowe Jr." <wrowe@rowe-clan.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: svn commit: r1161681 -
 /httpd/httpd/trunk/modules/http/byterange_filter.c
References: <20110825183326.A09F323888E7@eris.apache.org>
 <4E57455B.5040300@apache.org>
 <472DDD24-BEF9-4B56-AF32-A6865D8137E1@jaguNET.com>
In-Reply-To: <472DDD24-BEF9-4B56-AF32-A6865D8137E1@jaguNET.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 8/26/2011 6:42 AM, Jim Jagielski wrote:
> IMO, the function of ap_set_byterange() is to create the
> official working copy of r->range that will be used, and in doing
> so, provide first level verification of what is valid
> (as well as determining if we want to accept the byte-range
> as provided by the client or simply bail out with a 416
> or 200).

Certainly, but we can do so through an array, and can much more quickly
reassemble the canonical r->range from that array.  Only two string ops
(decode, and then format).  Once we have an untainted r->range, this is
what we aught to pass on to any back end proxy client.

> If we are going to fix it, imo, we should do it here, but
> I'm +-0 on whether to ignore or break when we hit a wrong
> order…

Not break; the spec is blindingly clear that a 200 is always a right
answer, so if we inhibit rewinding, we should fall back on 200 if
any range could be satisfied.  (If the content is shorter than any
of the given ranges, we can 416).  No?