Re: Current trunk does not build on Win

[William A Rowe Jr]

On Mon, Apr 16, 2018 at 8:37 AM, Steffen  wrote:
>
> I like to continue building/testing trunk.
>
> Is there a fix coming ?

I guess not from the author. Try r1829381 now committed to trunk. If
that doesn't work, we'll revert and start again, no cycles to check
the fix myself.

Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

[William A Rowe Jr]

On Tue, Apr 17, 2018 at 11:28 AM, Graham Leggett  wrote:
>
> The distributions have been doing this nigh on two decades - the stability of 
> a given software baseline which will not suddenly break at 3am some arbitrary 
> Sunday in the middle of the holidays is the very product they’re selling. 
> This works because they ship a baseline, plus carefully curated fixes as 
> required by their communities, trading off the needs of their communities and 
> stability.

So with respect to *our* communities...

On Tue, Apr 17, 2018 at 11:17 AM, Graham Leggett  wrote:
> On 17 Apr 2018, at 6:08 PM, William A Rowe Jr  wrote:
>
>> No enhancement since 2011-12-19 has been presented for the collective
>> community's scrutiny.
>
> Again, I’m not following.
>
> The architecture of v2.4 has been very stable, the need for breaking changes 
> has been largely non existent, and the focus since 2011 has been to get 
> changes backported to v2.4 instead.
>
> To distill this down to raw numbers, there have been 1546 discrete backports 
> (my simple grep of CHANGES) since 2011 - which has provided an enormous 
> amount of enhancement for the collective community’s scrutiny.

And the corresponding number of regressions and behavior changes. None
of these have enjoyed an "RC" or "beta", whatever one calls it, to
validate before adoption - other than our claim of "best httpd yet".
It has been an entirely new kitchen sink on every subversion release.

> You seem to be making a mountain out of a molehill, I just don’t see the 
> problem you’re trying to solve.

You are welcome to attribute this concern any way you like, and be
satisfied with whatever yardstick you wish to measure it by. If you
interpret our users as desiring enhancement and not stability, then
those are the interests you should advocate. I'll leave this thread
alone for another week again to give them the opportunity to chime in.

Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

[Alain Toussaint]

> No
> distribution (that I am aware of) ships something called Apache httpd v2.4.29.

At LFS (linux from scratch), we're the exception confirming the rule of 
shipping v2.4.29 with the
single patch of defining a preferred layout (the BLFS layout patch) in LFS/BLFS 
v8.2.

B/LFS-svn is shipping with v2.4.33 currently.

Alain (bug chaser for B/LFS and ALFS working toward editorship).

Re: [Bug 62308] New: Apache crashes after graceful restart with AH02599: slotmem (failed size check)

[Exonetric]

FWIW, I am seeing this too, but examining the code I could not see how. It 
looks like it just does a shm destroy and then moves on to recreating the SHM 
segment.

> On 17 Apr 2018, at 14:03, Jim Jagielski  wrote:
> 
> This should not be a fatal error... I don't think it was before.
> 
>> Begin forwarded message:
>> 
>> From: bugzi...@apache.org
>> Subject: [Bug 62308] New: Apache crashes after graceful restart with 
>> AH02599: slotmem (failed size check)
>> Date: April 17, 2018 at 6:21:09 AM EDT
>> To: b...@httpd.apache.org
>> Reply-To: "Apache HTTPD Bugs Notification List" 
>> 
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=62308
>> 
>>Bug ID: 62308
>>   Summary: Apache crashes after graceful restart with AH02599:
>>slotmem (failed size check)
>>   Product: Apache httpd-2
>>   Version: 2.4.33
>>  Hardware: PC
>>Status: NEW
>>  Severity: regression
>>  Priority: P2
>> Component: mod_proxy_balancer
>>  Assignee: b...@httpd.apache.org
>>  Reporter: d...@d-velop.de
>>  Target Milestone: ---
>> 
>> Created attachment 35878
>>  --> https://bz.apache.org/bugzilla/attachment.cgi?id=35878=edit
>> logfile with configuration change example
>> 
>> After updating from 2.4.27 to 2.4.33, we get a crash when doing a graceful
>> restart after modifying the mod_proxy/mod_proxy_balancer configuration in the
>> filesystem. 
>> We are modifying the configuration files dynamicaly when our infrastructure
>> changes. After this, we do a graceful restart using the following Windows
>> command: httpd.exe -k restart
>> This worked fine with 2.4.27 and below. 
>> With 2.4.33 we get the following message:
>> AH02599: existing shared memory for 
>> C:/Apache24/temp/slotmem-shm-p17ffdef3.shm
>> could not be used (failed size check)
>> 
>> I've added a Apache logfile with an example of configuration change that 
>> causes
>> this issue
>> 
>> -- 
>> You are receiving this mail because:
>> You are the assignee for the bug.
>> -
>> To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
>> For additional commands, e-mail: bugs-h...@httpd.apache.org
>> 
> 

Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

[Graham Leggett]

On 17 Apr 2018, at 5:40 PM, William A Rowe Jr  wrote:

>> I’m not following the “all in vain”.
>> 
>> This patch in v2.4.33 was dine specifically to fix an issue in Xenial, and 
>> Ubuntu is on the case:
>> 
>> https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1750356
> 
> Then Ubuntu is distributing neither httpd 2.4.33 nor 2.4.29, as
> published by the Apache HTTP Project. This is another example of
> cherry picking a miscellany of fixes.

Yes. This is the very definition of the Ubuntu “Long Term Support” releases. It 
is also the very definition of “Redhat Enterprise Linux”.

> If a distributor shipped a source package of something called Apache
> httpd 2.4.29, which is obviously not .29 but .29+{stuff}, what would
> be our reaction?

No reaction.

There is no source of confusion. The distros all use (for example) v2.4.29 as 
their baseline version, and then a sub-version-number that to indicate their 
patch level on top of ours. No distribution (that I am aware of) ships 
something called Apache httpd v2.4.29.

The distributions have been doing this nigh on two decades - the stability of a 
given software baseline which will not suddenly break at 3am some arbitrary 
Sunday in the middle of the holidays is the very product they’re selling. This 
works because they ship a baseline, plus carefully curated fixes as required by 
their communities, trading off the needs of their communities and stability.

None of this is new.

It turns out that we, the httpd project (and apr), have had the exact same 
approach to stability that the distros have had for the last two decades. As a 
result, you can take an ASF supplied httpd RPM and drop it into Redhat 
Enterprise Linux and this “just works”, because our ABI guarantees align 
exactly with the ABI guarantees of the stable distros.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

[Graham Leggett]

On 17 Apr 2018, at 6:08 PM, William A Rowe Jr  wrote:

> No enhancement since 2011-12-19 has been presented for the collective
> community's scrutiny.

Again, I’m not following.

The architecture of v2.4 has been very stable, the need for breaking changes 
has been largely non existent, and the focus since 2011 has been to get changes 
backported to v2.4 instead.

To distill this down to raw numbers, there have been 1546 discrete backports 
(my simple grep of CHANGES) since 2011 - which has provided an enormous amount 
of enhancement for the collective community’s scrutiny.

You seem to be making a mountain out of a molehill, I just don’t see the 
problem you’re trying to solve.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

[William A Rowe Jr]

On Tue, Apr 17, 2018 at 10:50 AM, William A Rowe Jr  wrote:
>
> No enhancement since 2011-12-19 has been subjected to any community
> scrutiny. This was the date 2.3.16-beta for 2.4 was announced.

Sorry that statement is somewhat unfair...

* Anyone is welcome to "be a developer" and check out trunk, same for
2.4 branch. It simply isn't "published" till it is released.
* Anyone participating at dev@ can join in for three days of voting.
* PR watchers frequently test proposed fixes, some with new features.
* Steffen and others offer up binaries of proposed backports or
modules, e.g. the h2 and mod_md efforts.

The word "any" is way off-base. Trying this instead;

No enhancement since 2011-12-19 has been presented for the collective
community's scrutiny.

Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

[William A Rowe Jr]

On Tue, Apr 17, 2018 at 9:47 AM, Graham Leggett  wrote:
> On 17 Apr 2018, at 4:41 PM, William A Rowe Jr  wrote:
>
>> We observe the "code freeze" effect (defined by three different
>> distributors) coupled with distributors deep distrust of our releases,
>> so by continuously polluting our version major.minor release with more
>> and more cruft, those users are denied not only the new cruft, but all
>> the bug fixes to the old cruft as well... there's really no other
>> explanation for the users of one of our most common distributions to
>> be locked out of several subversions worth of bugfix corrections.
>
> I’m lost - what problem are you trying to solve?

There is a second problem implied above, which I overlooked, sorry.

No enhancement since 2011-12-19 has been subjected to any community
scrutiny. This was the date 2.3.16-beta for 2.4 was announced.

Yes, patches go through test frameworks and peer review. But every
enhancement has been foisted on the user community without any
pre-adoption scrutiny.

This is made plain by the frequent number of rejected release
candidates, and by the equally frequent number of post-release
regression reports.

No enhancement I'm aware of has been rejected by the dev@ community;
eventually objections will be withdrawn, with enough committers will
rubber stamp whatever is in STATUS.

The project has been responsive to these regressions by releasing
fixes, which themselves are overloaded with new features and behavior
changes.

Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

[Eric Covener]

> If a distributor shipped a source package of something called Apache
> httpd 2.4.29, which is obviously not .29 but .29+{stuff}, what would
> be our reaction?

The package name/filename/etc or the compiled-in server version?
For the former, it's already differentiated on most distros I've seen.
For the latter, I don't have any real concern as most people
understand if it's complex & packaged, it's patched.

-- 
Eric Covener
cove...@gmail.com

Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

[William A Rowe Jr]

On Tue, Apr 17, 2018 at 9:47 AM, Graham Leggett  wrote:
> On 17 Apr 2018, at 4:41 PM, William A Rowe Jr  wrote:
>
>> And everything contributed to 2.4.33 release? All in vain. None of
>> that in this OS distribution, because, code freeze.
>
> I’m not following the “all in vain”.
>
> This patch in v2.4.33 was dine specifically to fix an issue in Xenial, and 
> Ubuntu is on the case:
>
> https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1750356

Then Ubuntu is distributing neither httpd 2.4.33 nor 2.4.29, as
published by the Apache HTTP Project. This is another example of
cherry picking a miscellany of fixes.

>> We observe the "code freeze" effect (defined by three different
>> distributors) coupled with distributors deep distrust of our releases,
>> so by continuously polluting our version major.minor release with more
>> and more cruft, those users are denied not only the new cruft, but all
>> the bug fixes to the old cruft as well... there's really no other
>> explanation for the users of one of our most common distributions to
>> be locked out of several subversions worth of bugfix corrections.
>
> I’m lost - what problem are you trying to solve?

The problem identified above, distributors falling into the role of
individually, project-by-project, release-by-release managing
versioning of what other modern software projects arbitrage in their
own subversion branches.

The use of the Apache HTTP Server mark itself is predicated on the
software shipped by Apache HTTP Project. So this forking leads to
interesting questions (probably permissible for combinations of code
released at different points by the project).

If a distributor shipped a source package of something called Apache
httpd 2.4.29, which is obviously not .29 but .29+{stuff}, what would
be our reaction?

Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

[Graham Leggett]

On 15 Apr 2018, at 3:25 AM, Yehuda Katz  wrote:

> That also assumes the OS distributions pick up the point releases. RedHat 
> certainly doesn't pick up the new features, only bug fixes.

By design - that is what “Redhat Enterprise Linux” is.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

[Graham Leggett]

On 17 Apr 2018, at 4:41 PM, William A Rowe Jr  wrote:

> And everything contributed to 2.4.33 release? All in vain. None of
> that in this OS distribution, because, code freeze.

I’m not following the “all in vain”.

This patch in v2.4.33 was dine specifically to fix an issue in Xenial, and 
Ubuntu is on the case:

https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1750356

> We observe the "code freeze" effect (defined by three different
> distributors) coupled with distributors deep distrust of our releases,
> so by continuously polluting our version major.minor release with more
> and more cruft, those users are denied not only the new cruft, but all
> the bug fixes to the old cruft as well... there's really no other
> explanation for the users of one of our most common distributions to
> be locked out of several subversions worth of bugfix corrections.

I’m lost - what problem are you trying to solve?

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

Re: [Bug 61860] Headers duplication when 416 status code occurs

[Luca Toscano]

2018-04-09 22:38 GMT+02:00 Luca Toscano :

> Hi everybody,
>
> 2018-04-05 7:59 GMT+02:00 :
>
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=61860
>>
>> --- Comment #4 from Luca Toscano  ---
>> Ok now I think I know what's happening (and I got what Eric was trying to
>> suggest). One of the things that ap_send_error_response does is running
>> ap_run_insert_error_filter, that allows modules to insert their filters
>> (that
>> will be executed). mod_headers does it, specifically it adds this bit:
>>
>> /*
>>  * Make sure we propagate any "Header always" settings on the error
>>  * path through http_protocol.c.
>>  */
>> static apr_status_t ap_headers_error_filter(ap_filter_t *f,
>> apr_bucket_brigade *in)
>>
>> It makes sure that the Headers set via 'always' are in err_headers_out, to
>> allow them to be added in the response. The issue in my opinion is that in
>> ap_send_error_respose we swap r->headers_out with r->err_headers_out, and
>> clear
>> r->err_headers_out (that will be re-populated afterwards). Should we
>> simply do:
>>
>> Index: modules/http/http_protocol.c
>> ===
>> --- modules/http/http_protocol.c(revision 1828234)
>> +++ modules/http/http_protocol.c(working copy)
>> @@ -1262,7 +1262,6 @@
>>  }
>>
>>  if (!r->assbackwards) {
>> -apr_table_t *tmp = r->headers_out;
>>
>>  /* For all HTTP/1.x responses for which we generate the message,
>>   * we need to avoid inheriting the "normal status" header fields
>> @@ -1269,9 +1268,7 @@
>>   * that may have been set by the request handler before the
>>   * error or redirect, except for Location on external redirects.
>>   */
>> -r->headers_out = r->err_headers_out;
>> -r->err_headers_out = tmp;
>> -apr_table_clear(r->err_headers_out);
>> +apr_table_clear(r->headers_out);
>>
>>  if (ap_is_HTTP_REDIRECT(status) || (status == HTTP_CREATED)) {
>>  if ((location != NULL) && *location) {
>>
>>
> I am testing the above patch as possible solution for
> https://bz.apache.org/bugzilla/show_bug.cgi?id=61860, in which a user
> reports that a range error request gets headers duplicated (more
> specifically, all the ones set via Header always). Is there anything big
> that I am missing? I think that it these situations httpd should just use
> r->err_headers_out..
>

Still working on this, for the moment I haven't found any clear regression
when applying the following:

 Index: modules/http/http_protocol.c
===
--- modules/http/http_protocol.c(revision 1828234)
+++ modules/http/http_protocol.c(working copy)
@@ -1262,7 +1262,6 @@
 }

 if (!r->assbackwards) {
-apr_table_t *tmp = r->headers_out;

 /* For all HTTP/1.x responses for which we generate the message,
  * we need to avoid inheriting the "normal status" header fields
@@ -1269,9 +1268,7 @@
  * that may have been set by the request handler before the
  * error or redirect, except for Location on external redirects.
  */
-r->headers_out = r->err_headers_out;
-r->err_headers_out = tmp;
-apr_table_clear(r->err_headers_out);
+apr_table_clear(r->headers_out);

 if (ap_is_HTTP_REDIRECT(status) || (status == HTTP_CREATED)) {
 if ((location != NULL) && *location) {

The above bit seems to solve the issue reported by the user in PR 61860.
This code has been working for a long time so I am wondering if I am
missing any use cases, but IIUC swapping headers_out with err_headers_out
seems to deviate from what's written in httpd.h:

 * The difference between headers_out and err_headers_out is that the
 * latter are printed even on error, and persist across internal
redirects
 * (so the headers printed for ErrorDocument handlers will have them).

Any suggestion is really appreciated :)

Thanks!

Luca

Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)

[William A Rowe Jr]

On Sat, Apr 14, 2018 at 8:48 AM, Jim Jagielski  wrote:
> IMO, the below ignores the impacts on OS distributors who
> provide httpd. We have seen how long it takes for them
> to go from 2.2 to 2.4...

They went to 2.4 once 2.4 was no longer beta. There is this concept
called "code freeze". At that point in the most modern OS distribution
(for the few weeks that lasts), Ubuntu 18.04 ships with...

Apache httpd 2.4.29
Apache apr 1.6.3
Apache apr-util 1.6.1
libcurl 7.58
OpenSSL 1.1.0g
nghttp2 1.30.0
brotli 1.0.3
Expat 2.2.5
jansson 2.11
libxml2 2.9.4
lua 5.3.3
PCRE 8.39 + 10.31
ZLib 1.2.11

How long will it take Ubuntu to pick up 2.4.next + OpenSSL 1.1.1 to
support TLSv1.3? Answer: next release, the 18.04 ship sailed.

And everything contributed to 2.4.33 release? All in vain. None of
that in this OS distribution, because, code freeze.

Nobody installing Ubuntu 18.04 finds TLSv1.3 from OpenSSL and their
consuming programs out of the box. This means 18.10, or 20.04, 2 years
from now - for those "stable" users.

The only thing this imaginary numbering question provokes is fear of
moving the project forwards. In the time its taken this project to
make minor tweaks around the edges in httpd, and jump forward by only
a handful of large leaps over 20 years, how many versions did our
primary open-source consumers release? Ubuntu 18.04 again - the only
thing almost as slow as httpd evolution has been lynx;

chromium 65  firefox 59  konqueror 17 lynx 2.8.9

Thanks David, and Nick, for trying to dispel this paranoia that
version numbers will cause users and distributors to flee the project.

Here's my concern, if .subversion meant bug fix (and bug fix, only)
then httpd distributed across Debian, Ubuntu, Redhat, Fedora,
Free/Open/NetBSD etc etc could correspond to something the httpd
project released. Because they all cherry pick only "necessary" bug
fixes (and each define those differently), not one of them distributes
*Apache Software Foundation Apache Web Server httpd*. By mashing all
the fun new stuff into the same numbers because adoption yadda yadda,
none of them can turn to httpd for the necessary fixes for their
distribution, and they certainly can't simply review and rubber stamp
our subversion release for the "right" set of bug fixes.

The irony in all this is that I was taught "version numbers are cheap"
fairly early, by this very project. No truth-in-advertising, that
"subversion numbers are cheap, major version numbers are a heavy lift
of 20 years of baggage."

You also claimed some delay in 2.4 adoption, when there was none in
fact. In 2014;

January; OpenSUSE 13 ships httpd 2.4.10
March; Ubuntu 14.04 ships httpd 2.4.7
April; RedHat 7 ships httpd 2.4.6

We observe the "code freeze" effect (defined by three different
distributors) coupled with distributors deep distrust of our releases,
so by continuously polluting our version major.minor release with more
and more cruft, those users are denied not only the new cruft, but all
the bug fixes to the old cruft as well... there's really no other
explanation for the users of one of our most common distributions to
be locked out of several subversions worth of bugfix corrections.

Fwd: [Bug 62308] New: Apache crashes after graceful restart with AH02599: slotmem (failed size check)

[Jim Jagielski]

This should not be a fatal error... I don't think it was before.

> Begin forwarded message:
> 
> From: bugzi...@apache.org
> Subject: [Bug 62308] New: Apache crashes after graceful restart with AH02599: 
> slotmem (failed size check)
> Date: April 17, 2018 at 6:21:09 AM EDT
> To: b...@httpd.apache.org
> Reply-To: "Apache HTTPD Bugs Notification List" 
> 
> https://bz.apache.org/bugzilla/show_bug.cgi?id=62308
> 
>Bug ID: 62308
>   Summary: Apache crashes after graceful restart with AH02599:
>slotmem (failed size check)
>   Product: Apache httpd-2
>   Version: 2.4.33
>  Hardware: PC
>Status: NEW
>  Severity: regression
>  Priority: P2
> Component: mod_proxy_balancer
>  Assignee: b...@httpd.apache.org
>  Reporter: d...@d-velop.de
>  Target Milestone: ---
> 
> Created attachment 35878
>  --> https://bz.apache.org/bugzilla/attachment.cgi?id=35878=edit
> logfile with configuration change example
> 
> After updating from 2.4.27 to 2.4.33, we get a crash when doing a graceful
> restart after modifying the mod_proxy/mod_proxy_balancer configuration in the
> filesystem. 
> We are modifying the configuration files dynamicaly when our infrastructure
> changes. After this, we do a graceful restart using the following Windows
> command: httpd.exe -k restart
> This worked fine with 2.4.27 and below. 
> With 2.4.33 we get the following message:
> AH02599: existing shared memory for C:/Apache24/temp/slotmem-shm-p17ffdef3.shm
> could not be used (failed size check)
> 
> I've added a Apache logfile with an example of configuration change that 
> causes
> this issue
> 
> -- 
> You are receiving this mail because:
> You are the assignee for the bug.
> -
> To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
> For additional commands, e-mail: bugs-h...@httpd.apache.org
> 

DAV lock database management tool

[Emmanuel Dreyfus]

Hello

mod_dav_fs is a nice solution to provide file sharing, but I have found 
the management of stale mod_dav_fs locks a pain to handle. If an 
application crashes holding a lock, one have to await for lock timeout
before touchign the file again.

Perhaps there is a smart solution to this, but since I did not find
it, I made this tool to manage the lock database:
https://ftp.espci.fr/pub/htdavlock/htdavlock-0.2.tar.gzc

It is able to dump the mod_dav_fs lock database content, and
with appropriate Apache configuration (see README), it can remove locks.

I provide it for whoever is interested. Feedback are welcome.

-- 
Emmanuel Dreyfus
m...@netbsd.org