Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Date: Mon, 29 Aug 2011 17:42:54 +0200 (CEST)
From: Stefan Fritsch <sf@sfritsch.de>
To: dev@httpd.apache.org
Subject: RE: 2.2 approach for byterange?
In-Reply-To: 
 <E563FB5AB3F02844AC749BA39E494AB4053BBD61@VF-MBX11.internal.vodafone.com>
Message-ID: <alpine.DEB.2.00.1108291741040.15665@eru.sfritsch.de>
References: 
 <CALK=YjMnLtm2o4KxzYrppNJ0BpC7hYLGpdzg70o4Bfe5JnrQXA@mail.gmail.com><201108281112.08119.sf@sfritsch.de><4E5A81AE.1080805@apache.org><201108282222.27230.sf@sfritsch.de>
 <CAHSOX_BdNVFGNWNSPYR3zOAX-mmTZ68-FNqO6qos-7prYbiUKQ@mail.gmail.com>
 <E563FB5AB3F02844AC749BA39E494AB4053BBD61@VF-MBX11.internal.vodafone.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED;
 BOUNDARY="683461219-1463984557-1314632574=:15665"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--683461219-1463984557-1314632574=:15665
Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Mon, 29 Aug 2011, "Pl=FCm, R=FCdiger, VF-Group" wrote:

> =09Sent: Montag, 29. August 2011 17:32
> =09To: dev@httpd.apache.org
> =09Subject: Re: 2.2 approach for byterange?
>
>
> =09On Sun, Aug 28, 2011 at 4:22 PM, Stefan Fritsch <sf@sfritsch.de> wrote=
:
>
>
> =09looks good overall.
>
> =09+                    while (start64 - off_first > (apr_uint64_t)copy->=
length) {
> =09+                        apr_bucket *tmp;
> =09+                        int i =3D 0;
> =09+                        if (i++ >=3D 99999)
> =09+                            return APR_EINVAL;
> =09I assume you meant to initialize i before the while() loop.
>
> =09Greg
>
>
> =09I guess yes. The question is if we should keep that in the backport at=
 all, as we only do it in the first location
> =09and not in the second location and 99999 looks like a rather high numb=
er without any comment and documention.
> =09IMHO even arbitrary numbers deserve that.
>


Looks like an accidental commit or merge error in r1162131. I think we=20
should remove that block both from trunk and from the backport.

--683461219-1463984557-1314632574=:15665--