Re: Time for 1.3.32 ?
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 TR 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 :) Could you save us some hunting and post it then? -Rasmus
Re: Time for 1.3.32 ?
* 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 TR 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 :) Could you save us some hunting and post it then? 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 position. PR 31036. (2.0 + 1.3) http://www.apache.org/~nd/dbmmap_1.3.patch http://www.apache.org/~nd/dbmmap_2.0.patch *) mod_rewrite:Fix query string handling for proxied URLs. PR 14518. (2.0 + 1.3) modules/mappers/mod_rewrite.c: r1.259 nd
Re: Time for 1.3.32 ?
=?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 position. PR 31036. (2.0 + 1.3) http://www.apache.org/~nd/dbmmap_1.3.patch http://www.apache.org/~nd/dbmmap_2.0.patch *) mod_rewrite:Fix query string handling for proxied URLs. PR 14518. (2.0 + 1.3) modules/mappers/mod_rewrite.c: r1.259 In general, people don't look for 1.3 patches in the 2.0 STATUS file and vice-versa :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Time for 1.3.32 ?
* 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 ;-) nd
Re: Time for 1.3.32 ?
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 possible 1.3 changes, but not vice versa ;-) I think that is part of the confusion, at least for me - while I understand the 2.1/2.0 process, I feel always at a loss as to how to proceed with 1.3. for example, I just posted a backport to from 2.0 to 1.3 that at least one other committer (rasmus) thought was a good idea. where does it go for votes? --Geoff
Re: Time for 1.3.32 ?
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 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 ;-) I think that is part of the confusion, at least for me - while I understand the 2.1/2.0 process, I feel always at a loss as to how to proceed with 1.3. for example, I just posted a backport to from 2.0 to 1.3 that at least one other committer (rasmus) thought was a good idea. where does it go for votes? --Geoff -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Time for 1.3.32 ?
=?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 into 2.0 for possible 1.3 changes, but not vice versa ;-) That's true... now that we're opening 1.3 back up for some development/enhancements, looking into stuff that was added in 2.x and whether they make sense (or are feasible) for 1.3 is a good idea. However, not everyone who works on 1.3 also follows 2.0 or even bothers with the 2.x CVS, so they will not be following 1.3 specific stuff in the 2.x STATUS file. 1.3 has its own STATUS file which should be used. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Time for 1.3.32 ?
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 me to look into 2.0 for possible 1.3 changes, but not vice versa ;-) nd
Re: Time for 1.3.32 ?
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 finish chewing on the ASF CLA stuff I have no CVS access, so I can't actually look at this stuff. And no, I don't agree that the flow is 2.1-2.0-1.3. The trees are way too different for that to make any sense. -Rasmus
Re: Time for 1.3.32 ?
* 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 still suggest posting them here. In case you've overseen it, my reply contained the stuff, including references to the patches... But posting all backport proposals here doesn't sound like a good idea to me, the STATUS file(s) is (are) for that purpose. Until the lawyers here finish chewing on the ASF CLA stuff I have no CVS access, so I can't actually look at this stuff. http://cvs.apache.org/viewcvs/ *shrug*, nd -- Winnetous Erbe: http://pub.perlig.de/books.html#apache2
Re: Time for 1.3.32 ?
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, I don't agree that the flow is 2.1-2.0-1.3. The trees are way too different for that to make any sense. In the case of bug fixes, I absolutely agree. 1.3 is (and should be) a distinct track for solving its bugs. When all is said and done, the patches to 1.3 and 2.0 for bugs 'common' to both versions rarely look or act quite alike. In the case of 'features', I tend to agree they should prove themselves in 2.1-dev first. Consider how we 'broke' CanonicalName handling (for transparent load balancing across ports.) Obviously great features have a way of introducing insidious side effects. Bill
Re: Time for 1.3.32 ?
* Jim Jagielski [EMAIL PROTECTED] wrote: I'd like to propose a 1.3.32 release with a TR 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 -- aus einer Rezension http://pub.perlig.de/books.html#apache2
Re: Time for 1.3.32 ?
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.
Re: Time for 1.3.32 ?
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_http_header and ap_send_error_response since these could be called after ap_die and we don't want to increment the keepalives counter twice on this request. Index: http_protocol.c === diff -u -r1.76 http_protocol.c --- http_protocol.c 21 May 2004 11:43:31 - 1.76 +++ http_protocol.c 8 Jul 2004 16:49:03 - @@ -2074,7 +2074,7 @@ PUSH_EBCDIC_OUTPUTCONVERSION_STATE_r(r, 1); #endif /*CHARSET_EBCDIC*/ -ap_set_keepalive(r); +if(r-connection-keepalive != 1) ap_set_keepalive(r); #ifdef YAHOO #ifdef GZIP @@ -3063,7 +3063,7 @@ ap_hard_timeout(send 304, r); ap_basic_http_header(r); -ap_set_keepalive(r); +if(r-connection-keepalive != 1) ap_set_keepalive(r); ap_table_do((int (*)(void *, const char *, const char *)) ap_send_header_field, (void *) r, r-headers_out, Index: http_request.c === diff -u -r1.29 http_request.c --- http_request.c 21 May 2004 11:43:31 - 1.29 +++ http_request.c 8 Jul 2004 16:49:03 - @@ -1116,6 +1116,12 @@ } /* + * We need r-connection-keepalive set correctly in order to determine if + * we can discard the request body in the next condition + */ +ap_set_keepalive(r); + +/* * If we want to keep the connection, be sure that the request body * (if any) has been read. */ On Tue, 6 Jul 2004, Jim Jagielski wrote: 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 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: 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] restore failing errno for Win32 spawn errors on this list) +1 from me for that errno patch ;) nd -- Umfassendes Werk (auch fuer Umsteiger vom Apache 1.3) -- aus einer Rezension http://pub.perlig.de/books.html#apache2 -- == = Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Time for 1.3.32 ?
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 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: 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] restore failing errno for Win32 spawn errors on this list) +1 from me for that errno patch ;) nd -- Umfassendes Werk (auch fuer Umsteiger vom Apache 1.3) -- aus einer Rezension http://pub.perlig.de/books.html#apache2 -- == = Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Time for 1.3.32 ?
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: 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] restore failing errno for Win32 spawn errors on this list) +1 from me for that errno patch ;) nd -- Umfassendes Werk (auch fuer Umsteiger vom Apache 1.3) -- aus einer Rezension http://pub.perlig.de/books.html#apache2 -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Time for 1.3.32 ?
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 happy :) To get *really* happy, the patch *) mod_rewrite: Fix confused map cache (with maps in different VHs using the same name). PR 26462. (2.0 + 1.3) A patch for 1.3 is here (2.0 goes similar): http://www.apache.org/~nd/mod_rewrite-confusion-1.3.patch modules/mappers/mod_rewrite.c: r1.256 +1: nd, trawick should also in ;-) 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)
Re: Time for 1.3.32 ?
* 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 that errno patch ;) nd -- Umfassendes Werk (auch fuer Umsteiger vom Apache 1.3) -- aus einer Rezension http://pub.perlig.de/books.html#apache2
Re: Time for 1.3.32 ?
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] restore failing errno for Win32 spawn errors on this list) +1 from me for that errno patch ;) nd -- Umfassendes Werk (auch fuer Umsteiger vom Apache 1.3) -- aus einer Rezension http://pub.perlig.de/books.html#apache2 -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: Time for 1.3.32 ?
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
Re: Time for 1.3.32 ?
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.
Re: Time for 1.3.32 ?
* 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 happy :)
To get *really* happy, the patch
*) mod_rewrite: Fix confused map cache (with maps in different VHs using
the same name). PR 26462. (2.0 + 1.3)
A patch for 1.3 is here (2.0 goes similar):
http://www.apache.org/~nd/mod_rewrite-confusion-1.3.patch
modules/mappers/mod_rewrite.c: r1.256
+1: nd, trawick
should also in ;-)
nd
--
$_=q?tvc!uif)%*|#Bopuifs!A`#~tvc!Xibu)%*|qsjou#Kvtu!A`#~tvc!KBQI!)*|~
tvc!ifmm)%*|#Qfsm!A`#~tvc!jt)%*|(Ibdlfs(~ # What the hell is JAPH? ;
@_=split/\s\s+#/;$_=(join''=map{chr(ord( # André Malo ;
$_)-1)}split//=$_[0]).$_[1];s s.*s$_see; # http://www.perlig.de/ ;
