Re: [VOTE] Release Apache httpd 2.4.15 as GA
* William A Rowe Jr wrote: On Mon, Jun 22, 2015 at 2:01 PM, André Malo n...@perlig.de wrote: * Yann Ylavic wrote: It seems that RedirectMatch isn't documented without the third (URL) argument, unless in Location. Huh? Actually it is (or maybe I'm not getting something here). I checked at least back until 2.0. http://httpd.apache.org/docs/2.4/mod/mod_alias.html#redirect clearly documents this. That's helpful, except that #redirectmatch does not point back to #redirect as authoritative over arguments. *shrug* apparently I interpret equivalent differently (the part you left out of the quote), but whatever. We all now agree that the 2.4.12 and prior behavior should be preserved, but that doesn't remedy the documentation. Well, we could copy it, if that makes you happy ;-) nd -- Das, was ich nicht kenne, spielt stückzahlmäßig *keine* Rolle. -- Helmut Schellong in dclc
Issue with bugzilla for BZ #57992 and #57993
Hi, I wanted to CLOSE bug #57992 and #57993 as INVALID. Strangely, they apparently have never been sent to b...@httpd.apache.org (at least according to the mail archive I use) Moreover, when I try to CLOSE them, I get an error, even if the state is correctly changed. I don't really know who to send this report to... so here it is. Best regards, CJ ASF Bugzilla has encountered an internal error. You may have found a bug in ASF Bugzilla! Or, you may have followed a deep link that contains information Bugzilla doesn't understand. Remember: *Garbage In, Garbage Out!* If you are sure that you didn't cause this error, please save this page and send it to bugzilla-ad...@apache.org with details of what you were doing at the time this message appeared. We *especially* want to know the URL of the page you were on before you got this message. *Attention Tomcat 5 Users:* The default home page of Tomcat 5 contains a link that is supposed to give you a list of open bugs. Instead, you get this message, which is not what you came here for. This issue has been reported as Tomcat 5 Bug 33117 http://issues.apache.org/bugzilla/show_bug.cgi?id=33117 and has been fixed for the next release. URL: https://bz.apache.org/bugzilla/process_bug.cgi undef error - This shouldn't happen at /usr/share/perl/5.18/Text/Wrap.pm line 84.
Re: svn commit: r1688331 - /httpd/httpd/trunk/modules/filters/mod_substitute.c
On Tue, Jun 30, 2015 at 3:35 AM, William A Rowe Jr wr...@rowe-clan.net wrote:
On Mon, Jun 29, 2015 at 8:06 PM, Yann Ylavic ylavic@gmail.com wrote:
Maybe defining (naming) inherit_before tristate values would help:
Not really...
+a-inherit_before = (over-inherit_before == INHERIT_ON
+ || (over-inherit_before == INHERIT_UNSET
+ base-inherit_before == INHERIT_ON));
if (a-inherit_before) {
This logic was convoluted
Agreed.
and therefore resulted in in the old default
behavior if the option wasn't explicitly set.
I can't see this though, over-inherit_before == over-inherit_before
== INHERIT_UNSET resulted in a-inherit_before = FALSE in trunk and
TRUE in 2.[24].x.
See the most recent trunk
commits for a more legible solution that follows the design pattern used
throughout other core modules.
That's simpler indeed.
I previously overlooked that the merge were already against the merged
parents, so base-inherit_before will be unset iff it is unused so
far, hence I was wrong about the third level issue...
( I had to play with gdb to figure out though :)
Your logic above fails to preserve the unset state, and fails to when
consider base-inherit_before is explicitly off.
I can't see this either...
I still think my logic was working too, just like the change you did
regarding max_line_length_set in r1688341 (you don't preserve the
unset state there either).
This is why it is
preferred not to invent new wheels when good wheels exist, particularly if
there will be a square side on the new wheel.
That I can agree with ;)
Btw, I added your proposed changes to the 2.4.x/2.2.x proposals.
Regards,
Yann.
Re: svn commit: r1688331 - /httpd/httpd/trunk/modules/filters/mod_substitute.c
This is the case, a single SubstituteInheritBefore directive, defaulting to Off in trunk and On in 2.4 / 2.2 (proposed patches). On Tue, Jun 30, 2015 at 12:39 PM, Plüm, Rüdiger, Vodafone Group ruediger.pl...@vodafone.com wrote: +1. They can even make their configuration future proof today by setting the 2.4 default behaviour explicitly. Regards Rüdiger -Original Message- From: Jim Jagielski [mailto:j...@jagunet.com] Sent: Dienstag, 30. Juni 2015 12:25 To: dev@httpd.apache.org Cc: c...@httpd.apache.org Subject: Re: svn commit: r1688331 - /httpd/httpd/trunk/modules/filters/mod_substitute.c My pref is that we create one single directive which controls this. With 2.4 the default is the old (incorrect) merge and with trunk it is the new (correct) merge. That way those upgrading from 2.4 - 2.6/3.0 will only need to worry about a directive default change.
[NOTICE] Intent to TR 2.4.16 next week
My goal is that all outstanding bugs and backports and/or showstoppers have sufficient +1 and sufficient testing to warrant a TR next week (ie: the week of July 7th)
Re: svn commit: r1688331 - /httpd/httpd/trunk/modules/filters/mod_substitute.c
My pref is that we create one single directive which controls this. With 2.4 the default is the old (incorrect) merge and with trunk it is the new (correct) merge. That way those upgrading from 2.4 - 2.6/3.0 will only need to worry about a directive default change.
RE: svn commit: r1688331 - /httpd/httpd/trunk/modules/filters/mod_substitute.c
+1. They can even make their configuration future proof today by setting the 2.4 default behaviour explicitly. Regards Rüdiger -Original Message- From: Jim Jagielski [mailto:j...@jagunet.com] Sent: Dienstag, 30. Juni 2015 12:25 To: dev@httpd.apache.org Cc: c...@httpd.apache.org Subject: Re: svn commit: r1688331 - /httpd/httpd/trunk/modules/filters/mod_substitute.c My pref is that we create one single directive which controls this. With 2.4 the default is the old (incorrect) merge and with trunk it is the new (correct) merge. That way those upgrading from 2.4 - 2.6/3.0 will only need to worry about a directive default change.
Re: Issue with bugzilla for BZ #57992 and #57993
Should have read the whole message... Sent to bugzilla-ad...@apache.org CJ Le 01/07/2015 07:08, Christophe JAILLET a écrit : Hi, I wanted to CLOSE bug #57992 and #57993 as INVALID. Strangely, they apparently have never been sent to b...@httpd.apache.org (at least according to the mail archive I use) Moreover, when I try to CLOSE them, I get an error, even if the state is correctly changed. I don't really know who to send this report to... so here it is. Best regards, CJ ASF Bugzilla has encountered an internal error. You may have found a bug in ASF Bugzilla! Or, you may have followed a deep link that contains information Bugzilla doesn't understand. Remember: *Garbage In, Garbage Out!* If you are sure that you didn't cause this error, please save this page and send it to bugzilla-ad...@apache.org with details of what you were doing at the time this message appeared. We *especially* want to know the URL of the page you were on before you got this message. *Attention Tomcat 5 Users:* The default home page of Tomcat 5 contains a link that is supposed to give you a list of open bugs. Instead, you get this message, which is not what you came here for. This issue has been reported as Tomcat 5 Bug 33117 http://issues.apache.org/bugzilla/show_bug.cgi?id=33117 and has been fixed for the next release. URL: https://bz.apache.org/bugzilla/process_bug.cgi undef error - This shouldn't happen at /usr/share/perl/5.18/Text/Wrap.pm line 84.
Re: option to block async write completion?
On Fri, Jun 19, 2015 at 10:03 AM, Eric Covener cove...@gmail.com wrote: Maybe make MAX_REQUESTS_IN_PIPELINE configurable and use 1 in your case? that's interesting, will check it out. This turned into a bot of a pain when I realized just using a flush bucket accomplishes the same thing (everything up to the flush bucket is blocking)
AW: option to block async write completion?
-Ursprüngliche Nachricht- Von: Eric Covener [mailto:cove...@gmail.com] Gesendet: Dienstag, 30. Juni 2015 20:09 An: Apache HTTP Server Development List Betreff: Re: option to block async write completion? On Fri, Jun 19, 2015 at 10:03 AM, Eric Covener cove...@gmail.com wrote: Maybe make MAX_REQUESTS_IN_PIPELINE configurable and use 1 in your case? that's interesting, will check it out. This turned into a bot of a pain when I realized just using a flush bucket accomplishes the same thing (everything up to the flush bucket is blocking) Are you sure that works with every filter in between? As far as I remember some filters (mod_deflate?) just drop everything once they have seen EOS / EOR. Regards Rüdiger
Re: option to block async write completion?
On Tue, Jun 30, 2015 at 8:53 PM, Plüm, Rüdiger, Vodafone Group ruediger.pl...@vodafone.com wrote: -Ursprüngliche Nachricht- Von: Eric Covener [mailto:cove...@gmail.com] Gesendet: Dienstag, 30. Juni 2015 20:09 An: Apache HTTP Server Development List Betreff: Re: option to block async write completion? On Fri, Jun 19, 2015 at 10:03 AM, Eric Covener cove...@gmail.com wrote: Maybe make MAX_REQUESTS_IN_PIPELINE configurable and use 1 in your case? that's interesting, will check it out. This turned into a bot of a pain when I realized just using a flush bucket accomplishes the same thing (everything up to the flush bucket is blocking) Are you sure that works with every filter in between? As far as I remember some filters (mod_deflate?) just drop everything once they have seen EOS / EOR. At least ap_http_filter() does...
Re: LimitRequestBody is broken in 2.4.13-2.4.15
Thanks for reporting this before the testing/release. Fixed in r1688274 (will now propose a backport), and since this is a showstopper, it will be merged (once reviewed) before 2.4.16/2.2.30. Proposed patch (for backport) is http://people.apache.org/~ylavic/httpd-2.4.x-fix_LimitRequestBody.patch Thanks (again) for testing if that's possible. I have tested the patch, it works :-) Thank you very much! Regards, Michael
Re: option to block async write completion?
On Tue, Jun 30, 2015 at 5:29 PM, Graham Leggett minf...@sharp.fm wrote: To be 100% safe, send the flush bucket down the stack on it’s own, not tacked onto the end of the brigade with the EOS. Thanks all -- I lucked into having that relationship already between the heap buckets and EOS, and the flushes are just tacked on when the heap buckets are passed.
Re: option to block async write completion?
On 30 Jun 2015, at 8:53 PM, Plüm, Rüdiger, Vodafone Group ruediger.pl...@vodafone.com wrote: This turned into a bot of a pain when I realized just using a flush bucket accomplishes the same thing (everything up to the flush bucket is blocking) Are you sure that works with every filter in between? As far as I remember some filters (mod_deflate?) just drop everything once they have seen EOS / EOR. mod_deflate is a per-request filter, the request ceases to exist after EOS/EOR, so in theory this wouldn’t affect the flush bucket. To be 100% safe, send the flush bucket down the stack on it’s own, not tacked onto the end of the brigade with the EOS. Regards, Graham —
