At 12:01 PM 9/8/2004, Rasmus Lerdorf wrote:
>On Wed, 8 Sep 2004, [ISO-8859-15] André Malo wrote:
>> Actually I'm talking about the two proposals on the top. If you are
>> interested in backport voting, you need to touch the STATUS file anyway and
>> should follow the commits there.
>
>[...] And no
* Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
> On Wed, 8 Sep 2004, [ISO-8859-15] André Malo wrote:
> > Actually I'm talking about the two proposals on the top. If you are
> > interested in backport voting, you need to touch the STATUS file anyway
> > and should follow the commits there.
>
> I'd st
On Wed, 8 Sep 2004, [ISO-8859-15] André Malo wrote:
> Actually I'm talking about the two proposals on the top. If you are
> interested in backport voting, you need to touch the STATUS file anyway and
> should follow the commits there.
I'd still suggest posting them here. Until the lawyers here fi
On Wed, 8 Sep 2004, [ISO-8859-15] André Malo wrote:
> * Jim Jagielski <[EMAIL PROTECTED]> wrote:
>
> > In general, people don't look for 1.3 patches in the 2.0 STATUS file
> > and vice-versa :)
>
> As far as I can see, the current way to make changes is 2.1 -> 2.0 -> 1.3.
> So it makes sense for m
=?ISO-8859-15?Q?Andr=E9?= Malo wrote:
>
> * Jim Jagielski <[EMAIL PROTECTED]> wrote:
>
> > In general, people don't look for 1.3 patches in the 2.0 STATUS file
> > and vice-versa :)
>
> As far as I can see, the current way to make changes is 2.1 -> 2.0 -> 1.3.
> So it makes sense for me to look
There is a STATUS file in the 1.3 tree.
Geoffrey Young wrote:
>
> André Malo wrote:
> > * Jim Jagielski <[EMAIL PROTECTED]> wrote:
> >
> >
> >>In general, people don't look for 1.3 patches in the 2.0 STATUS file
> >>and vice-versa :)
> >
> >
> > As far as I can see, the current way to make ch
André Malo wrote:
> * Jim Jagielski <[EMAIL PROTECTED]> wrote:
>
>
>>In general, people don't look for 1.3 patches in the 2.0 STATUS file
>>and vice-versa :)
>
>
> As far as I can see, the current way to make changes is 2.1 -> 2.0 -> 1.3.
> So it makes sense for me to look into 2.0 for possib
* Jim Jagielski <[EMAIL PROTECTED]> wrote:
> In general, people don't look for 1.3 patches in the 2.0 STATUS file
> and vice-versa :)
As far as I can see, the current way to make changes is 2.1 -> 2.0 -> 1.3.
So it makes sense for me to look into 2.0 for possible 1.3 changes, but not
vice versa ;
=?ISO-8859-15?Q?Andr=E9?= Malo wrote:
>
> Actually I'm talking about the two proposals on the top. If you are
> interested in backport voting, you need to touch the STATUS file anyway and
> should follow the commits there.
>
> However.
>
> *) mod_rewrite: Fix 0 bytes write into random memory
* Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
> On Tue, 7 Sep 2004, [ISO-8859-15] André Malo wrote:
> > * Jim Jagielski <[EMAIL PROTECTED]> wrote:
> >
> > > I'd like to propose a 1.3.32 release with a T&R either late this
> > > week or early next.
> >
> > Sounds good.
> > Though I'd like to point to
On Tue, 7 Sep 2004, [ISO-8859-15] André Malo wrote:
> * Jim Jagielski <[EMAIL PROTECTED]> wrote:
>
> > I'd like to propose a 1.3.32 release with a T&R either late this
> > week or early next.
>
> Sounds good.
> Though I'd like to point to the 2.0 status file, where a bugfix (to 2.0
> and 1.3) is wa
* Jim Jagielski <[EMAIL PROTECTED]> wrote:
> I'd like to propose a 1.3.32 release with a T&R either late this
> week or early next.
Sounds good.
Though I'd like to point to the 2.0 status file, where a bugfix (to 2.0
and 1.3) is waiting for approval :)
nd
--
"Solides und umfangreiches Buch"
I'd like to propose a 1.3.32 release with a T&R either late this
week or early next.
There's enough changes to warrant it I think. In the meantime,
if people could test HEAD, that would be great! Especially
those hit by the mod_dav/mod_frontpage problems that
surfaced with 1.3.31.
Rasmus Lerdorf wrote:
>
> On Fri, 20 Aug 2004, Jim Jagielski wrote:
> > I'm reviewing this... I'm mostly investigating whether
> > the check for keepalive!=1 before calling ap_set_keepalive
> > in ap_send_http_header and ap_send_error_response is
> > too ap_die() specific. It seems to me that
> >
On Fri, 20 Aug 2004, Jim Jagielski wrote:
> I'm reviewing this... I'm mostly investigating whether
> the check for keepalive!=1 before calling ap_set_keepalive
> in ap_send_http_header and ap_send_error_response is
> too ap_die() specific. It seems to me that
> ap_set_keepalive should be smarter in
I'm reviewing this... I'm mostly investigating whether
the check for keepalive!=1 before calling ap_set_keepalive
in ap_send_http_header and ap_send_error_response is
too ap_die() specific. It seems to me that
ap_set_keepalive should be smarter internally about
"double or more calls" per request.
Ok, how about this.
Add a call to ap_set_keepalive(r) in ap_die() before the check to see
if we should be discarding the request body. Then, since ap_set_keepalive
increments the keepalives counter on the connection if keepalive is
determined to be enabled, add a check to the calls in ap_send_htt
Yes, we do, and we're still waiting for a patch. However,
I can't see us delaying 1.3.32 for an "unreasonable"
amount of time.
On Jul 5, 2004, at 10:54 AM, Rasmus Lerdorf wrote:
We still have that outstanding issue of conn->keepalive being bogus in
ap_die() because it hasn't been set yet and thus w
We still have that outstanding issue of conn->keepalive being bogus in
ap_die() because it hasn't been set yet and thus we can't discard the
request body in situations where we really need to. See my previous long
explanation of that problem.
-Rasmus
On Sat, 3 Jul 2004, Jim Jagielski wrote:
> L
Let's use STATUS :)
=?ISO-8859-15?Q?Andr=E9?= Malo wrote:
>
> * Jeff Trawick <[EMAIL PROTECTED]> wrote:
>
> > well, if you're going to be that way then consider my simple Win32 patch to
> > fix reporting of proper error by spawnl(), which needs another +1 :)
> >
> > (see thread "[1.3 PATCH] res
* Jeff Trawick <[EMAIL PROTECTED]> wrote:
> well, if you're going to be that way then consider my simple Win32 patch to
> fix reporting of proper error by spawnl(), which needs another +1 :)
>
> (see thread "[1.3 PATCH] restore failing errno for Win32 spawn errors" on
> this list)
+1 from me for
André Malo wrote:
* "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote:
At 01:14 PM 7/2/2004, you wrote:
I'm floating the idea of releasing 1.3.32 shortly...
Comments or thoughts?
Let me get the mutex protection into mod_rewrite after this holiday
weekend - win32 1.3 mod_rewrite users can finally be
* "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote:
> At 01:14 PM 7/2/2004, you wrote:
> >I'm floating the idea of releasing 1.3.32 shortly...
> >Comments or thoughts?
>
> Let me get the mutex protection into mod_rewrite after this holiday
> weekend - win32 1.3 mod_rewrite users can finally be ha
Jim Jagielski wrote:
I'm floating the idea of releasing 1.3.32 shortly...
Comments or thoughts?
I'll be happy to help re-review diffs with 1.3.31 and test release candidates
(or tags or HEAD or whatever) and so forth. No strong feelings either way though.
At 01:14 PM 7/2/2004, you wrote:
>I'm floating the idea of releasing 1.3.32 shortly...
>Comments or thoughts?
Let me get the mutex protection into mod_rewrite after this holiday
weekend - win32 1.3 mod_rewrite users can finally be happy :)
Bill
I'm floating the idea of releasing 1.3.32 shortly...
Comments or thoughts?
26 matches
Mail list logo