Re: So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

[Stefan Eissing]

Daniel,

would you find it feasible to make a 2.4 release every first Tuesday of the 
month? Other projects have excellent experiences with such release timings. 

I‘d expect this would let us focus on the changes („one more week until 
release“), take off pressure („we can do it in the next release“), avoid meta 
discussions („is this a good time?“) and let us streamline the test/release 
work with changes in process/automation with a higher motivation.

Again, this would be your burden and call until we have so much 
routine/automation that everyone can do it. So it needs to be your decision.

Cheers, Stefan

> Am 19.04.2018 um 00:43 schrieb Daniel Ruggeri :
> 
> On 4/18/2018 10:58 AM, William A Rowe Jr wrote:
>>> The release cycle is hours, to the benefit of all interested. Be it a 
>>> blocking bug fixed or a nice feature implemented. These are mostly people 
>>> who do it for fun. Some even run large server clusters, so a „hobbyist“ 
>>> label does not apply.
>> Hours, yes, but we've had a willing RM, who has automated even
>> more of this than Jim or I had, and has a very hard time finding
>> any target to point to. E.g. "ok, that looks like the right resolution
>> to the last of the regressions... let's..." ... "...oh there are all these
>> other shiny objects in STATUS... rock-n-roll!!!" 
>> ...
> 
> What's particularly interesting to me, as I follow the conversation in
> my usual lurker-mode, is that Bill hit the nail on the head with this
> observation. I was waiting for the dust to settle to run through the
> scripts again for another T and release vote... but am not totally
> sure if we're ready. (mea culpa: my brain melted as I tried to follow
> the merging discussion so instead started parsing for "Yep. We're good
> now.")
> 
> My current read on the conversation is that we're happy (or maybe just
> content) with the SSL merging fixes and we should prep to ship 2.4.34 as
> a fix. Does anyone disagree?
> 
> -- 
> Daniel Ruggeri
> 

Re: Expanding httpd adoption internationally - POC

[Marion et Christophe JAILLET]

Le 18/04/2018 à 22:12, William A Rowe Jr a écrit :

On Wed, Apr 18, 2018 at 2:31 PM, Nick Kew  wrote:

I suspect the straightforward way to do this, in 2.6/3.0, will be to add an
i18n table of the error log strings extracted from and indexed by those
APLOGNO() entries. No match? Default English message.

Please, not without an overhaul of APLOGNO to automate it a lot better!
The time to devise your error message is when coding an original
ap_log_*error, not retrospectively once a number has been generated!

++1

This could be achieved easily by just adding in 'log_error_core()':
(+ a few lines to initialize gettext in main() + a few lines to get a 
pool in 'log_error_core()' (i.e. p below))


    /* Check if we have a leading AHn: header */
    if (p &&
    fmt[0] == 'A' &&
    fmt[1] == 'H' &&
    apr_isdigit(fmt[2]) &&
    apr_isdigit(fmt[3]) &&
    apr_isdigit(fmt[4]) &&
    apr_isdigit(fmt[5]) &&
    apr_isdigit(fmt[6]) &&
    fmt[7] == ':' &&
    fmt[8] == ' ') {
    const char *tmp;

    /* Get the translation of the message itself */
    tmp = gettext([9]);

    /* Rewrite the format string with the translated message */
    fmt = apr_pstrcat(p, apr_pstrmemdup(p, fmt, 9), tmp, NULL);
    printf("tmp: %s\n", fmt);
    }

That's all.
If interested by this approach, I can give a full working patch.

the po file can then be generated with things like:
   xgettext server/core.c -kap_log_error:5

This could be a good starting point which does not need to refactor 
everything, at the cost of some cycles and some additional memory.



In fact, it would call for a refactoring of the entire ap_log framework
away from printf-style format strings and vars, that’ll inevitably give rise
to a whole new level of awkwardness.  Which seems like a very bad
effort-to-gain ratio.  -1 to embarking on this, unless you want to
create a new experimental branch to play in.

I agree this is not a trivial change. There are specific risks of corrupting
one language's %tokens in a way that segfaults the runtime (switch any
%d for a %s and boom.) The resulting table is absolutely a root admin's
directive, must not be manipulated by any other than root.


If using gettext, there are some tools to check for that.

CJ

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

[William A Rowe Jr]

Does the root of this issue go back to this backport?

Author: minfrin
Date: Tue Feb 13 22:11:47 2018
New Revision: 1824180

URL: http://svn.apache.org/viewvc?rev=1824180=rev
Log:
mod_proxy_balancer,mod_slotmem_shm: Rework SHM reuse/deletion to not
depend on the number of restarts (non-Unix systems) and preserve shared
names as much as possible on configuration changes for SHMs and persisted
files.  PR 62044.
trunk patch: http://svn.apache.org/r1822509
 http://svn.apache.org/r1822511
 http://svn.apache.org/r1823412
 http://svn.apache.org/r1823415
 http://svn.apache.org/r1823416
 http://svn.apache.org/r1823564
 http://svn.apache.org/r1823572
 http://svn.apache.org/r1823575
2.4.x patch: trunk works (modulo CHANGES)
 (or
http://home.apache.org/~ylavic/patches/httpd-2.4.x-PR62044-slotmems_reuse.patch)
+1: ylavic, jim, minfrin


If that's true, certain protestations over the horrors of refactoring are
obvious crocodile tears, perhaps owing to a lack of actual evalution
of the code one votes up +1 with insufficient (no?) attention to detail?

Each reviewer voting up a backport shares the full ownership of any
such change on behalf of HTTP Server project, and the shares in the
collective mea culpa. If that reviewer were to try to lay all blame on the
original author of such a patch... wow... shameful.


On Wed, Apr 18, 2018 at 9:01 AM, Yann Ylavic  wrote:
> This isn't fair Jim, the previous code didn't work as expected either, IMHO.
>
> Regarding PR 62277 for instance, it worked because it attach()ed SHMs
> of unrelated balancers instead of creating new ones (this was the
> paper over SysV vs Posix, not the actual code which I think shows the
> real/potential issue on some systems).
>
> For this PR 62308, let's see if this is a crash or the annoying AH02599 
> "only".
> In both cases "mea culpa maxima" (flogging myself and so on) but yes
> changes can be buggy and I don't see why you seem to imply that all
> this was gratuitous and for the sake of changing/breaking code. It was
> intended to be bug fixes only, any bug revealed by the previous being
> fixed itself fixed, when should we give up? I don't...
>
> Please let's be constructive and not impugn motives on why a code is
> changed, it's sometimes simply needed, and in any case open to
> review/feedback/veto/tests at any time, including when it's proposed
> for backport.
>
>
> On Wed, Apr 18, 2018 at 1:56 PM, Jim Jagielski  wrote:
>> Most likely it is due to some assumptions in slotmem based on the underlying
>> shm implementation, ie: SysV or Posix.
>>
>> I would be remiss is pointing out that here is yet another case where
>> instead of a simple fix for a bug, we instead refactored a sh*t-ton of code
>> and in the process, broke stuff.
>>
>> Can we PLEASE avoid using bug reports as opportunities to
>> show everyone how smart we are and rewrite whole swaths of
>> code... please!
>>
>>
>> On Apr 17, 2018, at 12:37 PM, Exonetric  wrote:
>>
>> 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)
>>

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

[Daniel Ruggeri]

On 4/18/2018 1:34 PM, Alain Toussaint wrote:
>> As an aside - httpd has a —enable-layout option in configure that defines 
>> where things should go.
>> If you patch the following file how you want it and submit it to us, we can 
>> formally support LFS
>> out the box and you can remove the need for your patch:
>>
>> https://svn.apache.org/repos/asf/httpd/sandbox/replacelimit/config.layout
>>
>> Regards,
>> Graham
>> —
>>
> Great idea which I'll submit to the power that be.
>
> Alain

Minor correction to the URL for latest and greatest:
https://svn.apache.org/repos/asf/httpd/httpd/trunk/config.layout

As we love to say, "patches welcome!"

Feel free to just submit your diff here (since dev@ IS the power that be)

-- 
Daniel Ruggeri

Re: "Most Popular Web Server?"

[Daniel Ruggeri]

On 4/18/2018 11:46 AM, Jim Jagielski wrote:
> IMO, this boils down to 2 things:
>
>   1. nginx, particularly, does a LOT of promoting, marketing, PR, etc...
>  We don't. They get to promote their FUD all the time and remain
>  pretty much unchallenged.

Speaking from experience at $dayjob, I can confirm that the marketing
and sales folks are out in full force. I and a colleague have both been
contacted at our work addresses with messages tailored to our cloud and
cloud native jobs. Editorially, my work email address is not published
publicly - so this requires at least some minimal thinking to figure out
what the address is and to send the right targeted message.

At the same time, we should acknowledge that there are some things these
other products do well. TCP proxy/loadbalancing seems to be present in
many proxies but not httpd. Most products do not expose users to
underlying implementation details and instead allow the administrator to
express what they want done (the example that comes to mind is
slotmem/proxy modules needing to be loaded or a semi-confusing error
will come up). Some have really great 'how to' pages on their main docs
site to keep people from needing to dig.

>   2. They don't seem to have issues in understanding that new features,
>  enhancements and improvements to the server is what keeps users
>  and grows community. Instead, we either spend our time naval
>  gazing and pondering such inane issues as revisiting versioning,
>  or else treat the codebase like a school exercise where the
>  winner is the one who changes the most number of lines. Each time
>  a new feature is proposed, we have to deal with the incessant
>  blather around 2.6, 3.0, EOLing 2.4, blah blah blah. We've had
>  some features in httpd long before similar functionality existed
>  in nginx, for example, but they got to release 1st because we
>  were too busy standing on soapboxes or bike-shedding.

I think it's fair to point out that we have shipped regressions in some
form or another for several of our recent releases... plus a few that
didn't get shipped thanks to the n00b RM :-). I can't speak for every
contributor to the code base, but I view breaking or significantly
altering a configuration that is working today to be criminal.

Given that we have made mistakes, the conversations that are being held
are both an acknowledgement of the errors and brainstorming about how we
can proceed without harming our users. We want to release new features
AND remain stable AND improve the code base. There is a balancing act
among those three goals we need to agree on as a community.



I'll use this blank line as a quote for what I think could possibly be a
third point for consideration. We are lacking in two areas that I think
are key for survivability: enterprise usability and machine-based management
On the enterprise front: one of the things that Microsoft gets right is
that with enough clicking around in a UI, an administrator can
accidentally implement a perfectly functional server. The massive
amounts of study put toward usability and consistency pays off since an
admin who understands how to generally set up a windows server could
just kinda figure out how to start and manage the web subsystem. Talking
about nginx in the enterprise, you don't get that same level of
"clickability"... but you DO get a phone number you can call and
complain to when your config isn't working right as well as some
pre-sales/post-sales engineers that will help you through the
configuration syntax.

On the exact opposite front: IIS and nginx suffer just as badly as we do
when it comes to machine-driven management. There are pretty clear
trends happening in the world around aggregating several OSS projects
into a larger amalgamation (Kubernetes being a rather fine example).
These amalgamations tend to prefer services which can be configured by a
machine both pre and post start. In the proxy space, envoy is a big
up-and-comer where config can be read from file but completely altered
via API after the server has started. Having a machine-friendly
configuration syntax (YML or JSON, for example) would be a great gateway
to constructing a generic API handler that can modify nearly any part of
the running server.

To be fair... I think these are cool things to do, but FAR beyond my
skill set and time budget.



> Personally, I'd like to see the the PMC take a more active and
> direct role in addressing #1, maybe w/ monthly blog posts
> coordinated w/ Sally. It would also be cool to reboot Apache Week
> (I know it was an external, 3rd party effort) in in conjunction
> w/ the blog posts or instead of it.

This is interesting. Can you provide some examples for the types of blog
posts that you think would be good to make? Stealing from other parts of
the thread (thanks, Luca!), I could see value in providing bite-sized
tidbits of how requests/responses are run, what this whole "hook" and
"pool" 

Re: "Most Popular Web Server?"

[Greg Stein]

Just. Stop.

On Wed, Apr 18, 2018 at 5:29 PM, Jim Jagielski  wrote:

>
>
> > On Apr 18, 2018, at 2:32 PM, William A Rowe Jr 
> wrote:
> >
> > On Wed, Apr 18, 2018 at 1:07 PM, Jim Jagielski  wrote:
> >>
> >>> On Apr 18, 2018, at 1:21 PM, William A Rowe Jr 
> wrote:
> >>>
> >>> There we go again. Why do you and Graham have to make this about
> >>> Bill vs. yourselves?
> >>
> >> I didn't.
> >
> > It's a challenge to read this otherwise;
> >
>
> I used the term "we" consistently. If, for some reason, you see
> things in what I say that you think may align w/ behaviors that
> you attribute to yourself, that is you putting that on, not me.
>
>

So... when should we do 2.4.34? [WAS: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost configs)]

[Daniel Ruggeri]

On 4/18/2018 10:58 AM, William A Rowe Jr wrote:
>> The release cycle is hours, to the benefit of all interested. Be it a 
>> blocking bug fixed or a nice feature implemented. These are mostly people 
>> who do it for fun. Some even run large server clusters, so a „hobbyist“ 
>> label does not apply.
> Hours, yes, but we've had a willing RM, who has automated even
> more of this than Jim or I had, and has a very hard time finding
> any target to point to. E.g. "ok, that looks like the right resolution
> to the last of the regressions... let's..." ... "...oh there are all these
> other shiny objects in STATUS... rock-n-roll!!!" 
> ...

What's particularly interesting to me, as I follow the conversation in
my usual lurker-mode, is that Bill hit the nail on the head with this
observation. I was waiting for the dust to settle to run through the
scripts again for another T and release vote... but am not totally
sure if we're ready. (mea culpa: my brain melted as I tried to follow
the merging discussion so instead started parsing for "Yep. We're good
now.")

My current read on the conversation is that we're happy (or maybe just
content) with the SSL merging fixes and we should prep to ship 2.4.34 as
a fix. Does anyone disagree?

-- 
Daniel Ruggeri

Re: "Most Popular Web Server?"

[Jim Jagielski]

> On Apr 18, 2018, at 2:32 PM, William A Rowe Jr  wrote:
> 
> On Wed, Apr 18, 2018 at 1:07 PM, Jim Jagielski  wrote:
>> 
>>> On Apr 18, 2018, at 1:21 PM, William A Rowe Jr  wrote:
>>> 
>>> There we go again. Why do you and Graham have to make this about
>>> Bill vs. yourselves?
>> 
>> I didn't.
> 
> It's a challenge to read this otherwise;
> 

I used the term "we" consistently. If, for some reason, you see
things in what I say that you think may align w/ behaviors that
you attribute to yourself, that is you putting that on, not me.

Re: "Most Popular Web Server?"

[Marion et Christophe JAILLET]

Le 18/04/2018 à 21:00, Luca Toscano a écrit :


Before joining the httpd project as contributor I struggled to find 
good technical sources about how the httpd internals work, especially 
when it comes to important bits like mpm-event and how its 
architecture can be compared with other products. One of my first 
tasks was to improve the mpm-event's documentation page, and it took 
me a ton of time to understand a very high level overview of it (plus 
a lot of people patiently tried to explain to me how things were 
working). Without good "authoritative" references a lot of people can 
write whatever they want on httpd, because there are too few people 
that can scan the web and discuss inaccuracies (https://xkcd.com/386).


I keep struggling with internals in these days, even if I check 
httpd's code daily, so I can't imagine somebody not involved in the 
project that tries to make a comparison between httpd and product X, 
when the latter has a ton of good explanation about how it works in 
detail (most of the times with a lot of really explicative graphics 
attached).


My point is: blogging is fine, but before even starting that I'd focus 
on dumping everybody's knowledge in sections of the docs like 
http://httpd.apache.org/docs/trunk/developer 
. It is boring and less 
fun than writing C code for sure, but I bet that a ton of people would 
enjoy details about how things work. It will be easier for people to 
spot "liars" in the web that focus their marketing strategy only on 
how httpd is "old" and not performant too..



+1

There are some books around about these internals. Some can be 
downloaded in pdf.
I also from time to time give a look at 
http://www.fmc-modeling.org/category/projects/apache/amp/Apache_Modeling_Project.html 
which gives a nice overview, which I hope, is still correct.


CJ

Re: "Most Popular Web Server?"

[Mark Blackman]

> On 18 Apr 2018, at 17:29, William A Rowe Jr  wrote:
> 
> 
> Many will always carry a deep fondness or appreciation for Apache
> httpd; how much traffic it actually carries in future years is another
> question entirely, and has everything to do with the questions we
> should have solved some time ago, and aught to solve now. Better late
> than never.

Is most popular the right thing to aim for? I would advise continuing to trade 
on Apache’s current strengths (versatility and documentation for me and 
relative stability) and let the chips fall where they may. It’s an open source 
project with a massive first-mover advantage and no investors to please. Just 
do the right thing, stay visible and the rest will sort itself out.

Corporates are pretty wedded to Apache due to 3rd party module support.

- Mark

Re: Expanding httpd adoption internationally

[William A Rowe Jr]

On Wed, Apr 18, 2018 at 2:31 PM, Nick Kew  wrote:
>
>> I suspect the straightforward way to do this, in 2.6/3.0, will be to add an
>> i18n table of the error log strings extracted from and indexed by those
>> APLOGNO() entries. No match? Default English message.
>
> Please, not without an overhaul of APLOGNO to automate it a lot better!
> The time to devise your error message is when coding an original
> ap_log_*error, not retrospectively once a number has been generated!

++1

> In fact, it would call for a refactoring of the entire ap_log framework
> away from printf-style format strings and vars, that’ll inevitably give rise
> to a whole new level of awkwardness.  Which seems like a very bad
> effort-to-gain ratio.  -1 to embarking on this, unless you want to
> create a new experimental branch to play in.

I agree this is not a trivial change. There are specific risks of corrupting
one language's %tokens in a way that segfaults the runtime (switch any
%d for a %s and boom.) The resulting table is absolutely a root admin's
directive, must not be manipulated by any other than root.

> BTW, my previous reply in this thread was predicated on your reference
> to “specific nginx FUD”.  I misread your post as describing some FUD.

No worries.

> Come to think of it, from memory of developing nginx modules, their
> error message framework looks a lot like ours.  It's in english too.
> Though I never delved into its internals.

Anyone with more info feel free to share. I can state for a fact your
IIS error messages are localized.

Re: Expanding httpd adoption internationally

[Nick Kew]

> I suspect the straightforward way to do this, in 2.6/3.0, will be to add an
> i18n table of the error log strings extracted from and indexed by those
> APLOGNO() entries. No match? Default English message.

Please, not without an overhaul of APLOGNO to automate it a lot better!
The time to devise your error message is when coding an original
ap_log_*error, not retrospectively once a number has been generated!

In fact, it would call for a refactoring of the entire ap_log framework
away from printf-style format strings and vars, that’ll inevitably give rise
to a whole new level of awkwardness.  Which seems like a very bad
effort-to-gain ratio.  -1 to embarking on this, unless you want to
create a new experimental branch to play in.

BTW, my previous reply in this thread was predicated on your reference
to “specific nginx FUD”.  I misread your post as describing some FUD.

Come to think of it, from memory of developing nginx modules, their
error message framework looks a lot like ours.  It's in english too.
Though I never delved into its internals.

— 
Nick Kew

Re: Expanding httpd adoption internationally

[William A Rowe Jr]

On Wed, Apr 18, 2018 at 1:53 PM, Marion et Christophe JAILLET
 wrote:
> Le 18/04/2018 à 20:00, William A Rowe Jr a écrit :
>>
>> Localizing our error messages alone would go a long ways to being
>> friendly to non-english speaking administrators. If we don't want to
>> bother, we can expect for our software to be further marginalized.
>
> you mean something like instrumenting our logging functions and use, for
> example, gettext as a translation mechanism?
>
> As an example on 1 file, with one logging function, something like:
>xgettext server/core.c -kap_log_error:5 -o -
> With this example, APLOGNO() are swallowed, because xgettext is not aware of
> the stringizing done in APLOGNO(), but we could try to find a way to deal
> with it.

I suspect the straightforward way to do this, in 2.6/3.0, will be to add an
i18n table of the error log strings extracted from and indexed by those
APLOGNO() entries. No match? Default English message.

Load this all in at startup as a hash based on the error language
requested by-vhost. So the es.example.com vhost might deliver
a host error log populated with Spanish, while the primary www.
host and global error log are in other languages. Index the various
hash string tables by language code to prevent any duplicates from
being loaded.

This makes the individual allocations even more critical, as we have
an entire set of %s %d tokens listed in that table. Adding an extra %d
element would call for a new APLOGNO() allocation.

At that point, the entire table can be programmatically translated
(somewhat goofy results) and then refined with sensible text.

The more challenging aspect are the number of "running" "stopped"
"restarting" sorts of %s text patterns which aught to also be
translated. They fall in the wrong position of some sentences, so
for a handful of these, replacing them with three distinct error log
messages might be the easier way to proceed. Otherwise, we
could have some secondary translation table for those word:word
entities, probably not associated to any specific APLOGNO.

Re: "Most Popular Web Server?"

[Luca Toscano]

My 2c!

2018-04-18 19:21 GMT+02:00 William A Rowe Jr :

> On Wed, Apr 18, 2018 at 11:46 AM, Jim Jagielski  wrote:
> > IMO, this boils down to 2 things:
> >
> >   1. nginx, particularly, does a LOT of promoting, marketing, PR, etc...
> >  We don't. They get to promote their FUD all the time and remain
> >  pretty much unchallenged.
>
> Launched a thread on one aspect we don't have right, and not limited
> to nginx. Another aspect we probably won't solve-for is the tendency
> for new server/proxy solutions to be linux-only, or linux/windows. So
> long as we can abstract it, we don't have any reason to jettison other
> active platform communities which offer enough features.
>
> > Personally, I'd like to see the the PMC take a more active and
> > direct role in addressing #1, maybe w/ monthly blog posts
> > coordinated w/ Sally. It would also be cool to reboot Apache Week
> > (I know it was an external, 3rd party effort) in in conjunction
> > w/ the blog posts or instead of it.
>
> That's a great idea! But the readers are almost exclusively httpd's
> adopters, rarely those who are adopters of other technology.
> Would it help retention of existing admins? Sure, somewhat.
>

Before joining the httpd project as contributor I struggled to find good
technical sources about how the httpd internals work, especially when it
comes to important bits like mpm-event and how its architecture can be
compared with other products. One of my first tasks was to improve the
mpm-event's documentation page, and it took me a ton of time to understand
a very high level overview of it (plus a lot of people patiently tried to
explain to me how things were working). Without good "authoritative"
references a lot of people can write whatever they want on httpd, because
there are too few people that can scan the web and discuss inaccuracies (
https://xkcd.com/386).

I keep struggling with internals in these days, even if I check httpd's
code daily, so I can't imagine somebody not involved in the project that
tries to make a comparison between httpd and product X, when the latter has
a ton of good explanation about how it works in detail (most of the times
with a lot of really explicative graphics attached).

My point is: blogging is fine, but before even starting that I'd focus on
dumping everybody's knowledge in sections of the docs like
http://httpd.apache.org/docs/trunk/developer. It is boring and less fun
than writing C code for sure, but I bet that a ton of people would enjoy
details about how things work. It will be easier for people to spot "liars"
in the web that focus their marketing strategy only on how httpd is "old"
and not performant too..


> Until we shake this notion of "2.6/3.0 considered harmful", the httpd
> project is effectively concluded/no more than a couple tinkerers'
> patch collection.
>

Don't really want to comment on other subjects but only pointing that the
statement, in my opinion, is not true. I saw a lot of people recently
pushing for 2.6, and I believe that everybody's agree that it needs to be
done. We are still trying to find a balance between eagerness of improve
how 2.4 works and its limits, but I am pretty sure we'll find a way soon.

Luca

Re: Expanding httpd adoption internationally

[Marion et Christophe JAILLET]

Le 18/04/2018 à 20:00, William A Rowe Jr a écrit :

I'm speaking of personal i18n experience as a Windows developer, and
assigning support for Cyrillic-based languages in nginx that I've presumed
exist (I've never researched the software but am familiar with the origins.)

[...]

In short, we demand admins read their httpd error log in English, even
where the underlying cause has been rendered in their local language
by the underlying operating system. (OS error messaging falls apart in
mass hosting where readers of different languages are hosted on the
same box, but that's an unusual situation, based on mass-vhoster
marketing alone.)

Localizing our error messages alone would go a long ways to being
friendly to non-english speaking administrators. If we don't want to
bother, we can expect for our software to be further marginalized.
you mean something like instrumenting our logging functions and use, for 
example, gettext as a translation mechanism?


As an example on 1 file, with one logging function, something like:
   xgettext server/core.c -kap_log_error:5 -o -
With this example, APLOGNO() are swallowed, because xgettext is not 
aware of the stringizing done in APLOGNO(), but we could try to find a 
way to deal with it.


CJ

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

[Alain Toussaint]

Le mercredi 18 avril 2018 à 11:41 +0200, Graham Leggett a écrit :
> On 17 Apr 2018, at 7:17 PM, Alain Toussaint  wrote:
> 
> > > 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).
> 
> Looking at http://www.linuxfromscratch.org/blfs/view/svn/server/apache.html 
> it doesn’t appear that
> you’re shipping httpd at all, instead you’re directing people to get httpd 
> from the ASF, and are
> supplying a patch to make it work with LFS. Both of these activities are 
> entirely fine.

We do have mirrors for the cases where upstream changes deviate from the book's 
instruction and the
automated ALFS tool draw primarily from the mirrors before hitting upstream but 
peoples doing thing
by hands while reading the books do take the packages from upstream.

> As an aside - httpd has a —enable-layout option in configure that defines 
> where things should go.
> If you patch the following file how you want it and submit it to us, we can 
> formally support LFS
> out the box and you can remove the need for your patch:
> 
> https://svn.apache.org/repos/asf/httpd/sandbox/replacelimit/config.layout
> 
> Regards,
> Graham
> —
> 

Great idea which I'll submit to the power that be.

Alain

Re: svn commit: r1829430 - /httpd/httpd/patches/2.4.x/core-check_errorlog_dir_syslog.patch

[Luca Toscano]

Thanks a lot Jim! I like your code change and the extra checks, but I'd
prefer to use strncmp if possible, also in log.c.
Feel free to amend the patch, or I'll do it tomorrow (I forgot the entry in
CHANGES too, your name should be on it :).

Luca

2018-04-18 18:36 GMT+02:00 Jim Riggs :

> Fair enough. I'm fine standardizing either way. strn?cmp() is probably
> more "correct". As it stands, though, the check in core is not actually
> checking everything that log.c will handle.
>
>
> > On 18 Apr 2018, at 10:15, William A Rowe Jr  wrote:
> >
> > On Wed, Apr 18, 2018 at 7:17 AM, Jim Riggs  wrote:
> >> I didn't think of this before, but there is one edge case this would
> miss: if someone (for whatever reason) wants a relative ErrorLog *file*
> named `syslog*', for example `ErrorLog "syslog-httpd.log"' or `ErrorLog
> "syslog.log"'. It appears that this is already broken in server/log.c,
> though. Also, log.c is using str(n)casecmp. The following would make things
> consistent and handle this weird edge case. Thoughts?
> >>
> >> Index: server/core.c
> >> ===
> >> --- server/core.c   (revision 1829431)
> >> +++ server/core.c   (working copy)
> >> @@ -4867,7 +4867,8 @@
> >> static int check_errorlog_dir(apr_pool_t *p, server_rec *s)
> >> {
> >> if (!s->error_fname || s->error_fname[0] == '|'
> >> -|| strcmp(s->error_fname, "syslog") == 0) {
> >> +|| strcasecmp(s->error_fname, "syslog") == 0
> >> +|| strncasecmp(s->error_fname, "syslog:", 7) == 0) {
> >> return APR_SUCCESS;
> >> }
> >> else {
> >> @@ -5281,7 +5282,9 @@
> >> apr_file_printf(out, "ServerRoot: \"%s\"\n", ap_server_root);
> >> tmp = ap_server_root_relative(p, sconf->ap_document_root);
> >> apr_file_printf(out, "Main DocumentRoot: \"%s\"\n", tmp);
> >> -if (s->error_fname[0] != '|' && strcmp(s->error_fname, "syslog")
> != 0)
> >> +if (s->error_fname[0] != '|'
> >> +&& strcasecmp(s->error_fname, "syslog") != 0
> >> +&& strncasecmp(s->error_fname, "syslog:", 7) != 0)
> >> tmp = ap_server_root_relative(p, s->error_fname);
> >> else
> >> tmp = s->error_fname;
> >> @@ -5456,4 +5459,3 @@
> >> core_cmds,/* command apr_table_t */
> >> register_hooks/* register hooks */
> >> };
> >> -
> >> Index: server/log.c
> >> ===
> >> --- server/log.c(revision 1829431)
> >> +++ server/log.c(working copy)
> >> @@ -396,7 +396,8 @@
> >> }
> >>
> >> #ifdef HAVE_SYSLOG
> >> -else if (!strncasecmp(s->error_fname, "syslog", 6)) {
> >> +else if (strcasecmp(s->error_fname, "syslog") == 0
> >> + || strncasecmp(s->error_fname, "syslog:", 7) == 0) {
> >> if ((fname = strchr(s->error_fname, ':'))) {
> >> /* s->error_fname could be [level]:[tag] (see #60525) */
> >> const char *tag;
> >
> > Shouldn't we normalize the use of strcmp instead of strcasecmp?
> > In any case it must be entirely normalized to one or the other.
> >
> > Linux is a case-sensitive OS in the first place, and if configured
> > with SYSLOG: today it is broken when you hit core, which ignores
> > that code path. Since the behavior has always been syslog: I'm
> > not seeing a benefit to case insensitivity.
>
>

Re: "Most Popular Web Server?"

[William A Rowe Jr]

On Wed, Apr 18, 2018 at 1:07 PM, Jim Jagielski  wrote:
>
>> On Apr 18, 2018, at 1:21 PM, William A Rowe Jr  wrote:
>>
>> There we go again. Why do you and Graham have to make this about
>> Bill vs. yourselves?
>
> I didn't.

It's a challenge to read this otherwise;

On Wed, Apr 18, 2018 at 11:46 AM, Jim Jagielski  wrote:
>
>   2. [...] Instead, we either spend our time naval
>  gazing and pondering such inane issues as revisiting versioning,

You would be hard pressed to suggest you are calling anyone else's
concerns inane, and demonstrate resentment in your email tone on
every thread I present offering different ways to do things, other than
continuing as-is and on the same glide path of httpd into irrelevancy.


On Tue, Apr 17, 2018 at 11:17 AM, Graham Leggett  wrote:
>
> You seem to be making a mountain out of a molehill [...]


Both statements attack not the technical question, but the questioner.
Please mind your framing.

Re: "Most Popular Web Server?"

[Jim Jagielski]

> On Apr 18, 2018, at 1:21 PM, William A Rowe Jr  wrote:
> 
> 
> There we go again. Why do you and Graham have to make this about
> Bill vs. yourselves?

I didn't.

Re: Expanding httpd adoption internationally

[William A Rowe Jr]

I'm speaking of personal i18n experience as a Windows developer, and
assigning support for Cyrillic-based languages in nginx that I've presumed
exist (I've never researched the software but am familiar with the origins.)

IIS/Windows long offered robust support to the multibyte character development
spheres, along with localized error messages and JP-2022 rendering. Also enjoys
a very long history of R-T-L text support.

This is a very dated report but is still useful in illustrating early nginx
vs IIS vs Apache httpd adoption, which has always mapped well into
my assumptions;

https://w3techs.com/blog/entry/most_popular_web_servers_by_country

In short, we demand admins read their httpd error log in English, even
where the underlying cause has been rendered in their local language
by the underlying operating system. (OS error messaging falls apart in
mass hosting where readers of different languages are hosted on the
same box, but that's an unusual situation, based on mass-vhoster
marketing alone.)

Localizing our error messages alone would go a long ways to being
friendly to non-english speaking administrators. If we don't want to
bother, we can expect for our software to be further marginalized.


On Wed, Apr 18, 2018 at 12:45 PM, Nick Kew  wrote:
>
>> On 18 Apr 2018, at 17:55, William A Rowe Jr  wrote:
>>
>>  So I'll start with this;
>
> Erm, would you like to cite a source for that claim?  I confess it’s not one 
> I’ve seen.
> I don’t follow either nginx marketing nor any fan club they might have.
>
> If what you refer to is the latter, it’s natural for any incumbent 
> market-leader
> to feature in such unflattering comparisons, while challenger communities
> have more tendency to be evangelical.  Though nowadays nginx should be
> up there with us on the wrong side of challenger comparisons!
>
> —
> Nick Kew

Re: Expanding httpd adoption internationally

[Nick Kew]

> On 18 Apr 2018, at 17:55, William A Rowe Jr  wrote:
> 
>  So I'll start with this;

Erm, would you like to cite a source for that claim?  I confess it’s not one 
I’ve seen.
I don’t follow either nginx marketing nor any fan club they might have.

If what you refer to is the latter, it’s natural for any incumbent market-leader
to feature in such unflattering comparisons, while challenger communities
have more tendency to be evangelical.  Though nowadays nginx should be
up there with us on the wrong side of challenger comparisons!

— 
Nick Kew

Re: "Most Popular Web Server?"

[William A Rowe Jr]

On Wed, Apr 18, 2018 at 11:46 AM, Jim Jagielski  wrote:
> IMO, this boils down to 2 things:
>
>   1. nginx, particularly, does a LOT of promoting, marketing, PR, etc...
>  We don't. They get to promote their FUD all the time and remain
>  pretty much unchallenged.

Launched a thread on one aspect we don't have right, and not limited
to nginx. Another aspect we probably won't solve-for is the tendency
for new server/proxy solutions to be linux-only, or linux/windows. So
long as we can abstract it, we don't have any reason to jettison other
active platform communities which offer enough features.

> Personally, I'd like to see the the PMC take a more active and
> direct role in addressing #1, maybe w/ monthly blog posts
> coordinated w/ Sally. It would also be cool to reboot Apache Week
> (I know it was an external, 3rd party effort) in in conjunction
> w/ the blog posts or instead of it.

That's a great idea! But the readers are almost exclusively httpd's
adopters, rarely those who are adopters of other technology.
Would it help retention of existing admins? Sure, somewhat.

>   2. They don't seem to have issues in understanding that new features,
>  enhancements and improvements to the server is what keeps users
>  and grows community. Instead, we either spend our time naval
>  gazing and pondering such inane issues as revisiting versioning,
>  or else treat the codebase like a school exercise where the
>  winner is the one who changes the most number of lines. Each time
>  a new feature is proposed, we have to deal with the incessant
>  blather around 2.6, 3.0, EOLing 2.4, blah blah blah. We've had
>  some features in httpd long before similar functionality existed
>  in nginx, for example, but they got to release 1st because we
>  were too busy standing on soapboxes or bike-shedding.

There we go again. Why do you and Graham have to make this about
Bill vs. yourselves? It isn't. What I've presented is data, and real world
observations, conclusions and assumptions by myself and OH from
other engineers and users. When your argument boils down to "but I
don't see it that way" you've already lost the technical argument. Not
that one or the other conclusion is more correct, but that you reject
considering valid any perspective other than your own.

New features have been bogged down because they keep introducing
breaking changes to 2.4.x behavior. Then there is a big loop-de-loop
of fitting square pegs into the round holes, and finally we have some
"compatible" Frankenstein monster of a work-around. Using the word
compatible very loosely here. How fast would mod_http2 happened
had no crazy glue been required to fit metric bolts into english nuts?
Or the ssl/md refactoring? These are things that open source projects
demand to have clear revisioning.

Because of this intractable position against ever shipping another
version major.minor of httpd, this false narrative that no administrator
or distributor would ever pick up the .next good version, that "every"
contributor's time is a waste if they can't have their enhancement
in the next bug fix release "right now!"; there's no incentive to do any
of the hard work of solving the .last version's structural deficiencies,
or to implement any of the enhancements in a legible and robust
way without legacy headaches and workarounds, leaving httpd on
a glide-path to eventual abandonment.

In other words, your observation 2. above is a total red herring,
no patches were blocked significantly longer than people took
to work out the kinks, discussions of versioning never actually
delayed the introduction of features (there were parallel threads,
but only typical technical objections)... and proves again that you
seek to stall this project, after promises to the contrary.

Until we shake this notion of "2.6/3.0 considered harmful", the httpd
project is effectively concluded/no more than a couple tinkerers'
patch collection.

> And finally, when the vast majority of web servers nowadays live
> *behind* proxy servers, these type of metric surveys are meaningless.
> Of course, I feel that this was nginx and MS' plan all along: they
> knew how things were changing and wanted to win the "proxy server
> market"... all that should be pretty obvious w/ 20/20 hindsight.

The actual heavy lift isn't even httpd proxy_balancer/nginx/IIS...
the real work is being done by the transparent gateway/proxies,
something we don't even speak (and is realistically beyond our charter.)

Expanding httpd adoption internationally

[William A Rowe Jr]

On Wed, Apr 18, 2018 at 11:46 AM, Jim Jagielski  wrote:
>
>   1. nginx, particularly, does a LOT of promoting, marketing, PR, etc...
>  We don't. They get to promote their FUD all the time and remain
>  pretty much unchallenged.

I'd like to break out and break down specific nginx FUD... but much
moreso, our failure to meet a market of administrators who have
their choice and don't choose httpd... and take these apart as specific
httpd dev@ threads. So I'll start with this;

httpd: English-only for administrators

nginx: Internationalized admin, esp non-latin support

IIS: Internationalized admin, esp ISO-2022 language support

Any questions?

/scheme/i sensitivity? (was: svn commit: r1829430 - /httpd/httpd/patches/2.4.x/core-check_errorlog_dir_syslog.patch)

[William A Rowe Jr]

On Wed, Apr 18, 2018 at 11:36 AM, Jim Riggs  wrote:
> Fair enough. I'm fine standardizing either way. strn?cmp() is probably more 
> "correct". As it stands, though, the check in core is not actually checking 
> everything that log.c will handle.

There are a number of places where we have "scheme:resource"-style
resources throughout httpd. Especially mod_ssl.

Do we want to make a group commitment to strn?casecmp() all of
these cases in any 2.next/3.0 release?

Re: "Most Popular Web Server?"

[Jim Jagielski]

IMO, this boils down to 2 things:

  1. nginx, particularly, does a LOT of promoting, marketing, PR, etc...
 We don't. They get to promote their FUD all the time and remain
 pretty much unchallenged.

  2. They don't seem to have issues in understanding that new features,
 enhancements and improvements to the server is what keeps users
 and grows community. Instead, we either spend our time naval
 gazing and pondering such inane issues as revisiting versioning,
 or else treat the codebase like a school exercise where the
 winner is the one who changes the most number of lines. Each time
 a new feature is proposed, we have to deal with the incessant
 blather around 2.6, 3.0, EOLing 2.4, blah blah blah. We've had
 some features in httpd long before similar functionality existed
 in nginx, for example, but they got to release 1st because we
 were too busy standing on soapboxes or bike-shedding.

Personally, I'd like to see the the PMC take a more active and
direct role in addressing #1, maybe w/ monthly blog posts
coordinated w/ Sally. It would also be cool to reboot Apache Week
(I know it was an external, 3rd party effort) in in conjunction
w/ the blog posts or instead of it.

And finally, when the vast majority of web servers nowadays live
*behind* proxy servers, these type of metric surveys are meaningless.
Of course, I feel that this was nginx and MS' plan all along: they
knew how things were changing and wanted to win the "proxy server
market"... all that should be pretty obvious w/ 20/20 hindsight.

> On Apr 18, 2018, at 12:29 PM, William A Rowe Jr  wrote:
> 
> "Established in 1999, the all-volunteer Apache Software Foundation
> oversees more than 350 leading Open Source projects, including Apache
> HTTP Server --the world's most popular Web server software."
> 
> How long will that last claim remain true?
> 
> We can sum up the state of affairs from four well-respected web server
> popularity reports from three sources;
> 
> https://news.netcraft.com/archives/2018/03/27/march-2018-web-server-survey.html
> (Based on 214M hostnames / 7M IP's)
> 
> https://secure1.securityspace.com/s_survey/data/201803/index.html
> (Based on 63M hostnames)
> https://secure1.securityspace.com/s_survey/data/man.201803/httpbyip.html
> (Based on 5M IP's)
> 
> https://w3techs.com/technologies/overview/web_server/all
> (Based on Alexa-ranked top ~10M primary domains)
> 
> Notably, we now hold the minority-majority position across the "web
> server" space, discounting the fact that "unknown/other" would
> probably still land us at 50% using really simple stats, for some few
> more months. Still, there is an unarguable downward trend of adoption
> and relevance of Apache httpd.
> 
> Depending on which survey you examine, either IIS or ngnix has caught
> up rapidly; the disagreement between surveys is often laughable. While
> IP's themselves might make for a better mapping, these are equally
> 'virtual' and don't represent machines either. Mass hosting, by name
> or number, is easily observed in these reports with huge swings from
> month to month. Reports which don't feature as much swing have
> apparently factored out much of the duplicated noise/domain camping.
> 
> As as been restated over and over, http:// is effectively DOA, long
> live https:// (h2, etc). Brings us to the point that we have not been
> the most popular HTTP/TLS server for over two years, and you can
> surmise what this will do over time to the numbers offered above;
> https://secure1.securityspace.com/s_survey/sdata/201803/index.html
> https://secure1.securityspace.com/s_survey/sdata/201803/servers.html
> 
> Many will always carry a deep fondness or appreciation for Apache
> httpd; how much traffic it actually carries in future years is another
> question entirely, and has everything to do with the questions we
> should have solved some time ago, and aught to solve now. Better late
> than never.

Re: svn commit: r1829430 - /httpd/httpd/patches/2.4.x/core-check_errorlog_dir_syslog.patch

[Jim Riggs]

Fair enough. I'm fine standardizing either way. strn?cmp() is probably more 
"correct". As it stands, though, the check in core is not actually checking 
everything that log.c will handle.


> On 18 Apr 2018, at 10:15, William A Rowe Jr  wrote:
> 
> On Wed, Apr 18, 2018 at 7:17 AM, Jim Riggs  wrote:
>> I didn't think of this before, but there is one edge case this would miss: 
>> if someone (for whatever reason) wants a relative ErrorLog *file* named 
>> `syslog*', for example `ErrorLog "syslog-httpd.log"' or `ErrorLog 
>> "syslog.log"'. It appears that this is already broken in server/log.c, 
>> though. Also, log.c is using str(n)casecmp. The following would make things 
>> consistent and handle this weird edge case. Thoughts?
>> 
>> Index: server/core.c
>> ===
>> --- server/core.c   (revision 1829431)
>> +++ server/core.c   (working copy)
>> @@ -4867,7 +4867,8 @@
>> static int check_errorlog_dir(apr_pool_t *p, server_rec *s)
>> {
>> if (!s->error_fname || s->error_fname[0] == '|'
>> -|| strcmp(s->error_fname, "syslog") == 0) {
>> +|| strcasecmp(s->error_fname, "syslog") == 0
>> +|| strncasecmp(s->error_fname, "syslog:", 7) == 0) {
>> return APR_SUCCESS;
>> }
>> else {
>> @@ -5281,7 +5282,9 @@
>> apr_file_printf(out, "ServerRoot: \"%s\"\n", ap_server_root);
>> tmp = ap_server_root_relative(p, sconf->ap_document_root);
>> apr_file_printf(out, "Main DocumentRoot: \"%s\"\n", tmp);
>> -if (s->error_fname[0] != '|' && strcmp(s->error_fname, "syslog") != 0)
>> +if (s->error_fname[0] != '|'
>> +&& strcasecmp(s->error_fname, "syslog") != 0
>> +&& strncasecmp(s->error_fname, "syslog:", 7) != 0)
>> tmp = ap_server_root_relative(p, s->error_fname);
>> else
>> tmp = s->error_fname;
>> @@ -5456,4 +5459,3 @@
>> core_cmds,/* command apr_table_t */
>> register_hooks/* register hooks */
>> };
>> -
>> Index: server/log.c
>> ===
>> --- server/log.c(revision 1829431)
>> +++ server/log.c(working copy)
>> @@ -396,7 +396,8 @@
>> }
>> 
>> #ifdef HAVE_SYSLOG
>> -else if (!strncasecmp(s->error_fname, "syslog", 6)) {
>> +else if (strcasecmp(s->error_fname, "syslog") == 0
>> + || strncasecmp(s->error_fname, "syslog:", 7) == 0) {
>> if ((fname = strchr(s->error_fname, ':'))) {
>> /* s->error_fname could be [level]:[tag] (see #60525) */
>> const char *tag;
> 
> Shouldn't we normalize the use of strcmp instead of strcasecmp?
> In any case it must be entirely normalized to one or the other.
> 
> Linux is a case-sensitive OS in the first place, and if configured
> with SYSLOG: today it is broken when you hit core, which ignores
> that code path. Since the behavior has always been syslog: I'm
> not seeing a benefit to case insensitivity.

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

[Rainer Jung]

Am 18.04.2018 um 18:07 schrieb William A Rowe Jr:

On Wed, Apr 18, 2018 at 10:57 AM, Rainer Jung  wrote:


Since this thread was triggered by the mod_ssl config merging problems: I
think that was a case where a new feature was really nice, but to implement
it the needed changes where not not easy to understand in detail. Combined
with the complex behavior of mod_ssl w.r.t. config merging we ended up with
unexpected config merging problems. So that specific problem belongs to your
class 1 (I think both, the one detected by Mark Blackman and the one
received via Joe).

It is not a total surprise, that regressions - be it due to features, bug
fixing or refactoring - most often happen in mod_proxy or mod_ssl. These are
IMHO by far the most complex modules (together with the event MPM).
Unfortunately the same parts are very attractive for features, so we have
some need to touch them.


Keep in mind Windows has been broken on nearly every release,
recently in the core and mod_ssl build. So although I forked an SSL
regression thread, please don't read into this that they are primary
"culprits"... even core changes broke mod_security.


You are right, windows builds is also a fragile area. Not because the 
builds themselves are fragile, but many of us do not have them in their 
focus.



I am not blaming either proxy+ssl modules, nor their developers.

I'm raising process issues, not contribution or contributor issues.
Looking for a scheme to let contributors shine by putting our code
enhancements and major refactoring through a community review
process, which has been neglected for most of this decade.



All in all I'd prefer an attempt to have a faster moving 2.6 and a stable
backport branch 2.4 real soon.


Question, if 2.6 is moving "fast", and handled as 2.4 was, is there any
net benefit for better releases? What can we agree to in versioning
prior to 2.6.x-GA that will ease the process for contributors, external
module authors, distributors and users?


I would expect people picking up 2.6 to be in a better position doing 
frequent updates and having a bit higher tolerance for an occasional 
break as the downside of getting new features quickly.


So people could choose: stick to the slowly moving 2.4 branch (and get 
it from the enterprise distro vendor) or switch to the faster moving 2.6 
with the downside of a higher risk in regressions and using a different 
source for the binaries (or of course build themselves).


Regards,

Rainer

"Most Popular Web Server?"

[William A Rowe Jr]

"Established in 1999, the all-volunteer Apache Software Foundation
oversees more than 350 leading Open Source projects, including Apache
HTTP Server --the world's most popular Web server software."

How long will that last claim remain true?

We can sum up the state of affairs from four well-respected web server
popularity reports from three sources;

https://news.netcraft.com/archives/2018/03/27/march-2018-web-server-survey.html
(Based on 214M hostnames / 7M IP's)

https://secure1.securityspace.com/s_survey/data/201803/index.html
(Based on 63M hostnames)
https://secure1.securityspace.com/s_survey/data/man.201803/httpbyip.html
(Based on 5M IP's)

https://w3techs.com/technologies/overview/web_server/all
(Based on Alexa-ranked top ~10M primary domains)

Notably, we now hold the minority-majority position across the "web
server" space, discounting the fact that "unknown/other" would
probably still land us at 50% using really simple stats, for some few
more months. Still, there is an unarguable downward trend of adoption
and relevance of Apache httpd.

Depending on which survey you examine, either IIS or ngnix has caught
up rapidly; the disagreement between surveys is often laughable. While
IP's themselves might make for a better mapping, these are equally
'virtual' and don't represent machines either. Mass hosting, by name
or number, is easily observed in these reports with huge swings from
month to month. Reports which don't feature as much swing have
apparently factored out much of the duplicated noise/domain camping.

As as been restated over and over, http:// is effectively DOA, long
live https:// (h2, etc). Brings us to the point that we have not been
the most popular HTTP/TLS server for over two years, and you can
surmise what this will do over time to the numbers offered above;
https://secure1.securityspace.com/s_survey/sdata/201803/index.html
https://secure1.securityspace.com/s_survey/sdata/201803/servers.html

Many will always carry a deep fondness or appreciation for Apache
httpd; how much traffic it actually carries in future years is another
question entirely, and has everything to do with the questions we
should have solved some time ago, and aught to solve now. Better late
than never.

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

[William A Rowe Jr]

On Wed, Apr 18, 2018 at 10:57 AM, Rainer Jung  wrote:
>
> Since this thread was triggered by the mod_ssl config merging problems: I
> think that was a case where a new feature was really nice, but to implement
> it the needed changes where not not easy to understand in detail. Combined
> with the complex behavior of mod_ssl w.r.t. config merging we ended up with
> unexpected config merging problems. So that specific problem belongs to your
> class 1 (I think both, the one detected by Mark Blackman and the one
> received via Joe).
>
> It is not a total surprise, that regressions - be it due to features, bug
> fixing or refactoring - most often happen in mod_proxy or mod_ssl. These are
> IMHO by far the most complex modules (together with the event MPM).
> Unfortunately the same parts are very attractive for features, so we have
> some need to touch them.

Keep in mind Windows has been broken on nearly every release,
recently in the core and mod_ssl build. So although I forked an SSL
regression thread, please don't read into this that they are primary
"culprits"... even core changes broke mod_security.

I am not blaming either proxy+ssl modules, nor their developers.

I'm raising process issues, not contribution or contributor issues.
Looking for a scheme to let contributors shine by putting our code
enhancements and major refactoring through a community review
process, which has been neglected for most of this decade.


> All in all I'd prefer an attempt to have a faster moving 2.6 and a stable
> backport branch 2.4 real soon.

Question, if 2.6 is moving "fast", and handled as 2.4 was, is there any
net benefit for better releases? What can we agree to in versioning
prior to 2.6.x-GA that will ease the process for contributors, external
module authors, distributors and users?

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

[William A Rowe Jr]

On Wed, Apr 18, 2018 at 1:01 AM, Stefan Eissing
 wrote:
>
>> Am 17.04.2018 um 19:18 schrieb William A Rowe Jr :
>>
>>> 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.
>
> All my substantial functional additions had beta releases for months before 
> being voted into the 2.4.x branch. With binary beta packages available for 
> several platforms by several supporters.

Yes; this is an exception. But as you first encountered, the scope of
changes requires extensive rewiring of the hook processing phases
and the architecture of modules themselves.

You are in one instance (h2) spanning two worlds, one of very stable
API's, architecture and predictable release cadences (nghttp2), and "us".
Which makes your life easier, and more enjoyable?

Since we never see a beta of the collective work, we don't pick up the
various build problems (mod_md.h missing from make install on unix?
CMake ignorant of new files and paths?) Your underlying module
sources, built from apxs or similar I'm not worried about. The various
patches required to glue it together is what I worry about.

In most versioning schemes, these fundamental changes to the API,
behavior and existing modules would have been set off with another
version minor, or when redefining the module struct and existing hook
behavior, a version major update. There would have been at least one
beta of the collective work, issues would have been uncovered, then
we return to fixing up the smaller bugs that don't require refactoring.

> William, this painting our world a dark and miserable place is coming back 
> every few months. It is a disservice to the people who contribute changes 
> here.

If stating the plain facts of the state of our current release(s) continues
to be dark and miserable, that mirrors some disservice to the people
who are *trying* to consume our software.

I understand why you would say that from a recent PMC business
private post; I plan to share (and paint dark) that picture with the full
dev community, with some real improvements.

>>> 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.
>
> There are alternative ways to be creative and innovate than going through 
> this PMC into a semi annual release.

Exactly... that's why I started this thread without any prescription.
Let's hear them all, and agree to some. There are some overloaded
deeply-held beliefs here about the scarcity of version majors which
we first need to set aside, starting another thread on the raw data
from that exercise.

> Releasing a module (plus some small patches) on github opens ways for 
> collaboration with people who like Apache and new stuff. Distros like Debian 
> unstable and Fedora pick up stuff from there. PPAs for apt are made 
> available. Steffen offers Windows builts.

Yes; this is true of both subversion releases and major version releases.

Take a radically incompatible example; PCRE 8 seems to have some
perpetual life while PCRE 10 has very slow adoption, because old
stack optimizations no longer play in a world where stack corruption
exploits are trivial, and he deliberately made such things hard to do.
Still, the distributors ship PCRE 10 to be consumed alongside the
older cruftier choice.

> The release cycle is hours, to the benefit of all interested. Be it a 
> blocking bug fixed or a nice feature implemented. These are mostly people who 
> do it for fun. Some even run large server clusters, so a „hobbyist“ label 
> does not apply.

Hours, yes, but we've had a willing RM, who has automated even
more of this than Jim or I had, and has a 

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

[Rainer Jung]

Am 18.04.2018 um 15:07 schrieb Jim Jagielski:

There are, IMO at least, 3 types of "regression" that we should be
concerned about or that some people are concerned about:

   1. New features:
  Undoubtedly, new features will likely have bugs and
  no by adding new features we could be adding bugs
  which could be seen as a regression.

   2. Simple fixes:
  A simple fix causes a regression.

   3. Wholesale refactoring:
  IMO, this is the one which is the most problematic for
  us lately. We have seen several cases where a simple
  bug or a desire to "make this part of the code better"
  has resulted in huge amounts of code churn, major rewrites
  and major refactoring.

My PoV is that:

  o We need to continue to add new features. We must provide better
QA and testing.

  o We need to avoid our natural inclinations to look at "fixing
bugs" as an opportunity for major refactors. If people want
to major refactor, fine. But that stays in trunk. What is
important is that we patch the bug 1st. Premature re-factoring
is as bad as premature optimization.


Since this thread was triggered by the mod_ssl config merging problems: 
I think that was a case where a new feature was really nice, but to 
implement it the needed changes where not not easy to understand in 
detail. Combined with the complex behavior of mod_ssl w.r.t. config 
merging we ended up with unexpected config merging problems. So that 
specific problem belongs to your class 1 (I think both, the one detected 
by Mark Blackman and the one received via Joe).


It is not a total surprise, that regressions - be it due to features, 
bug fixing or refactoring - most often happen in mod_proxy or mod_ssl. 
These are IMHO by far the most complex modules (together with the event 
MPM). Unfortunately the same parts are very attractive for features, so 
we have some need to touch them.


When implementing a feature or fixing a bug it is often hard to decide 
where the border is crossed that makes a change a "major" refactoring or 
whether a changes still mostly helps to understand the code.


We do lack a robust procedure and resources for testing complex 
configurations and also testing on many platforms. I don't have a 
solution for that :(


More release branches would only help, if people would actually pick 
them up. So we would need to keep features in the higher branches at 
least for a noticeable time. Of course the enterprise distros would not 
pick the additional release branches up, but maybe if they have 
attractive features, they might get picked up by faster moving distros, 
inside container images and by 3rd-parties like Apache Lounge. We could 
even provide builds for some platforms as a voluntary service.


All in all I'd prefer an attempt to have a faster moving 2.6 and a 
stable backport branch 2.4 real soon.


Regards,

Rainer

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

[William A Rowe Jr]

A shm destroy cannot remove an open shm (any more than rm
will remove an open file - at least on windows). In a graceful,
you have a lingering child holding on to that resource.

The short term fix would be to rename the offending shm resource
on each attempted graceful restart.

It may be possible to grow an open shm resource when needed.
Only previous openers are likely to be aware it was expanded.



On Tue, Apr 17, 2018 at 11:37 AM, Exonetric  wrote:
> 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: svn commit: r1829430 - /httpd/httpd/patches/2.4.x/core-check_errorlog_dir_syslog.patch

[William A Rowe Jr]

On Wed, Apr 18, 2018 at 7:17 AM, Jim Riggs  wrote:
> I didn't think of this before, but there is one edge case this would miss: if 
> someone (for whatever reason) wants a relative ErrorLog *file* named 
> `syslog*', for example `ErrorLog "syslog-httpd.log"' or `ErrorLog 
> "syslog.log"'. It appears that this is already broken in server/log.c, 
> though. Also, log.c is using str(n)casecmp. The following would make things 
> consistent and handle this weird edge case. Thoughts?
>
> Index: server/core.c
> ===
> --- server/core.c   (revision 1829431)
> +++ server/core.c   (working copy)
> @@ -4867,7 +4867,8 @@
>  static int check_errorlog_dir(apr_pool_t *p, server_rec *s)
>  {
>  if (!s->error_fname || s->error_fname[0] == '|'
> -|| strcmp(s->error_fname, "syslog") == 0) {
> +|| strcasecmp(s->error_fname, "syslog") == 0
> +|| strncasecmp(s->error_fname, "syslog:", 7) == 0) {
>  return APR_SUCCESS;
>  }
>  else {
> @@ -5281,7 +5282,9 @@
>  apr_file_printf(out, "ServerRoot: \"%s\"\n", ap_server_root);
>  tmp = ap_server_root_relative(p, sconf->ap_document_root);
>  apr_file_printf(out, "Main DocumentRoot: \"%s\"\n", tmp);
> -if (s->error_fname[0] != '|' && strcmp(s->error_fname, "syslog") != 0)
> +if (s->error_fname[0] != '|'
> +&& strcasecmp(s->error_fname, "syslog") != 0
> +&& strncasecmp(s->error_fname, "syslog:", 7) != 0)
>  tmp = ap_server_root_relative(p, s->error_fname);
>  else
>  tmp = s->error_fname;
> @@ -5456,4 +5459,3 @@
>  core_cmds,/* command apr_table_t */
>  register_hooks/* register hooks */
>  };
> -
> Index: server/log.c
> ===
> --- server/log.c(revision 1829431)
> +++ server/log.c(working copy)
> @@ -396,7 +396,8 @@
>  }
>
>  #ifdef HAVE_SYSLOG
> -else if (!strncasecmp(s->error_fname, "syslog", 6)) {
> +else if (strcasecmp(s->error_fname, "syslog") == 0
> + || strncasecmp(s->error_fname, "syslog:", 7) == 0) {
>  if ((fname = strchr(s->error_fname, ':'))) {
>  /* s->error_fname could be [level]:[tag] (see #60525) */
>  const char *tag;

Shouldn't we normalize the use of strcmp instead of strcasecmp?
In any case it must be entirely normalized to one or the other.

Linux is a case-sensitive OS in the first place, and if configured
with SYSLOG: today it is broken when you hit core, which ignores
that code path. Since the behavior has always been syslog: I'm
not seeing a benefit to case insensitivity.

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

[Jim Jagielski]

The current situation is, from what I can tell, worse and more pervasive than 
the original bug.

> On Apr 18, 2018, at 10:01 AM, Yann Ylavic  wrote:
> 
> This isn't fair Jim, the previous code didn't work as expected either, IMHO.
> 
> Regarding PR 62277 for instance, it worked because it attach()ed SHMs
> of unrelated balancers instead of creating new ones (this was the
> paper over SysV vs Posix, not the actual code which I think shows the
> real/potential issue on some systems).
> 
> For this PR 62308, let's see if this is a crash or the annoying AH02599 
> "only".
> In both cases "mea culpa maxima" (flogging myself and so on) but yes
> changes can be buggy and I don't see why you seem to imply that all
> this was gratuitous and for the sake of changing/breaking code. It was
> intended to be bug fixes only, any bug revealed by the previous being
> fixed itself fixed, when should we give up? I don't...
> 
> Please let's be constructive and not impugn motives on why a code is
> changed, it's sometimes simply needed, and in any case open to
> review/feedback/veto/tests at any time, including when it's proposed
> for backport.
> 
> 
> On Wed, Apr 18, 2018 at 1:56 PM, Jim Jagielski  wrote:
>> Most likely it is due to some assumptions in slotmem based on the underlying
>> shm implementation, ie: SysV or Posix.
>> 
>> I would be remiss is pointing out that here is yet another case where
>> instead of a simple fix for a bug, we instead refactored a sh*t-ton of code
>> and in the process, broke stuff.
>> 
>> Can we PLEASE avoid using bug reports as opportunities to
>> show everyone how smart we are and rewrite whole swaths of
>> code... please!
>> 
>> 
>> On Apr 17, 2018, at 12:37 PM, Exonetric  wrote:
>> 
>> 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: [Bug 62308] New: Apache crashes after graceful restart with AH02599: slotmem (failed size check)

[Yann Ylavic]

This isn't fair Jim, the previous code didn't work as expected either, IMHO.

Regarding PR 62277 for instance, it worked because it attach()ed SHMs
of unrelated balancers instead of creating new ones (this was the
paper over SysV vs Posix, not the actual code which I think shows the
real/potential issue on some systems).

For this PR 62308, let's see if this is a crash or the annoying AH02599 "only".
In both cases "mea culpa maxima" (flogging myself and so on) but yes
changes can be buggy and I don't see why you seem to imply that all
this was gratuitous and for the sake of changing/breaking code. It was
intended to be bug fixes only, any bug revealed by the previous being
fixed itself fixed, when should we give up? I don't...

Please let's be constructive and not impugn motives on why a code is
changed, it's sometimes simply needed, and in any case open to
review/feedback/veto/tests at any time, including when it's proposed
for backport.


On Wed, Apr 18, 2018 at 1:56 PM, Jim Jagielski  wrote:
> Most likely it is due to some assumptions in slotmem based on the underlying
> shm implementation, ie: SysV or Posix.
>
> I would be remiss is pointing out that here is yet another case where
> instead of a simple fix for a bug, we instead refactored a sh*t-ton of code
> and in the process, broke stuff.
>
> Can we PLEASE avoid using bug reports as opportunities to
> show everyone how smart we are and rewrite whole swaths of
> code... please!
>
>
> On Apr 17, 2018, at 12:37 PM, Exonetric  wrote:
>
> 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)

[Jim Jagielski]

There are, IMO at least, 3 types of "regression" that we should be
concerned about or that some people are concerned about:

  1. New features:
 Undoubtedly, new features will likely have bugs and
 no by adding new features we could be adding bugs
 which could be seen as a regression.

  2. Simple fixes:
 A simple fix causes a regression.

  3. Wholesale refactoring:
 IMO, this is the one which is the most problematic for
 us lately. We have seen several cases where a simple
 bug or a desire to "make this part of the code better"
 has resulted in huge amounts of code churn, major rewrites
 and major refactoring.

My PoV is that:

 o We need to continue to add new features. We must provide better
   QA and testing.

 o We need to avoid our natural inclinations to look at "fixing
   bugs" as an opportunity for major refactors. If people want
   to major refactor, fine. But that stays in trunk. What is
   important is that we patch the bug 1st. Premature re-factoring
   is as bad as premature optimization.

Re: svn commit: r1829430 - /httpd/httpd/patches/2.4.x/core-check_errorlog_dir_syslog.patch

[Jim Riggs]

I didn't think of this before, but there is one edge case this would miss: if 
someone (for whatever reason) wants a relative ErrorLog *file* named `syslog*', 
for example `ErrorLog "syslog-httpd.log"' or `ErrorLog "syslog.log"'. It 
appears that this is already broken in server/log.c, though. Also, log.c is 
using str(n)casecmp. The following would make things consistent and handle this 
weird edge case. Thoughts?

Index: server/core.c
===
--- server/core.c   (revision 1829431)
+++ server/core.c   (working copy)
@@ -4867,7 +4867,8 @@
 static int check_errorlog_dir(apr_pool_t *p, server_rec *s)
 {
 if (!s->error_fname || s->error_fname[0] == '|'
-|| strcmp(s->error_fname, "syslog") == 0) {
+|| strcasecmp(s->error_fname, "syslog") == 0
+|| strncasecmp(s->error_fname, "syslog:", 7) == 0) {
 return APR_SUCCESS;
 }
 else {
@@ -5281,7 +5282,9 @@
 apr_file_printf(out, "ServerRoot: \"%s\"\n", ap_server_root);
 tmp = ap_server_root_relative(p, sconf->ap_document_root);
 apr_file_printf(out, "Main DocumentRoot: \"%s\"\n", tmp);
-if (s->error_fname[0] != '|' && strcmp(s->error_fname, "syslog") != 0)
+if (s->error_fname[0] != '|'
+&& strcasecmp(s->error_fname, "syslog") != 0
+&& strncasecmp(s->error_fname, "syslog:", 7) != 0)
 tmp = ap_server_root_relative(p, s->error_fname);
 else
 tmp = s->error_fname;
@@ -5456,4 +5459,3 @@
 core_cmds,/* command apr_table_t */
 register_hooks/* register hooks */
 };
-
Index: server/log.c
===
--- server/log.c(revision 1829431)
+++ server/log.c(working copy)
@@ -396,7 +396,8 @@
 }

 #ifdef HAVE_SYSLOG
-else if (!strncasecmp(s->error_fname, "syslog", 6)) {
+else if (strcasecmp(s->error_fname, "syslog") == 0
+ || strncasecmp(s->error_fname, "syslog:", 7) == 0) {
 if ((fname = strchr(s->error_fname, ':'))) {
 /* s->error_fname could be [level]:[tag] (see #60525) */
 const char *tag;



> On 18 Apr 2018, at 04:57, elu...@apache.org wrote:
> 
> Author: elukey
> Date: Wed Apr 18 09:57:08 2018
> New Revision: 1829430
> 
> URL: http://svn.apache.org/viewvc?rev=1829430=rev
> Log:
> core-check_errorlog_dir_syslog.patch: add suggestions from STATUS
> 
> Credis to jhriggs and jailletc36
> 
> 
> Modified:
>httpd/httpd/patches/2.4.x/core-check_errorlog_dir_syslog.patch
> 
> Modified: httpd/httpd/patches/2.4.x/core-check_errorlog_dir_syslog.patch
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/patches/2.4.x/core-check_errorlog_dir_syslog.patch?rev=1829430=1829429=1829430=diff
> ==
> --- httpd/httpd/patches/2.4.x/core-check_errorlog_dir_syslog.patch (original)
> +++ httpd/httpd/patches/2.4.x/core-check_errorlog_dir_syslog.patch Wed Apr 18 
> 09:57:08 2018
> @@ -1,14 +1,23 @@
> Index: server/core.c
> ===
>  server/core.c   (revision 1829090)
> +--- server/core.c   (revision 1829429)
> +++ server/core.c   (working copy)
> @@ -4867,7 +4867,7 @@
>  static int check_errorlog_dir(apr_pool_t *p, server_rec *s)
>  {
>  if (!s->error_fname || s->error_fname[0] == '|'
> -|| strcmp(s->error_fname, "syslog") == 0) {
> -+|| !strncmp(s->error_fname, "syslog", 6)) {
> ++|| strncmp(s->error_fname, "syslog", 6) == 0) {
>  return APR_SUCCESS;
>  }
>  else {
> +@@ -5281,7 +5281,7 @@
> + apr_file_printf(out, "ServerRoot: \"%s\"\n", ap_server_root);
> + tmp = ap_server_root_relative(p, sconf->ap_document_root);
> + apr_file_printf(out, "Main DocumentRoot: \"%s\"\n", tmp);
> +-if (s->error_fname[0] != '|' && strcmp(s->error_fname, "syslog") != 0)
> ++if (s->error_fname[0] != '|' && strncmp(s->error_fname, "syslog", 6) != 
> 0)
> + tmp = ap_server_root_relative(p, s->error_fname);
> + else
> + tmp = s->error_fname;
> 

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

[Jim Jagielski]

Most likely it is due to some assumptions in slotmem based on the underlying
shm implementation, ie: SysV or Posix.

I would be remiss is pointing out that here is yet another case where
instead of a simple fix for a bug, we instead refactored a sh*t-ton of code
and in the process, broke stuff.

Can we PLEASE avoid using bug reports as opportunities to
show everyone how smart we are and rewrite whole swaths of
code... please!

> On Apr 17, 2018, at 12:37 PM, Exonetric  wrote:
> 
> 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: [Bug 62308] New: Apache crashes after graceful restart with AH02599: slotmem (failed size check)

[Yann Ylavic]

Do you see a crash for the httpd process?
Are you adding balancers only, BalancerMember(s), VirtualHost(s), all
of these to reproduce?

On Tue, Apr 17, 2018 at 6:37 PM, Exonetric  wrote:
> 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: Current trunk does not build on Win

[Steffen]

Thanks! Bill,

Building fine with r1829381 and initial tests looking ok.



On Tuesday 17/04/2018 at 19:57, William A Rowe Jr  wrote:
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)

[Graham Leggett]

On 17 Apr 2018, at 7:17 PM, Alain Toussaint  wrote:

>> 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).

Looking at http://www.linuxfromscratch.org/blfs/view/svn/server/apache.html it 
doesn’t appear that you’re shipping httpd at all, instead you’re directing 
people to get httpd from the ASF, and are supplying a patch to make it work 
with LFS. Both of these activities are entirely fine.

As an aside - httpd has a —enable-layout option in configure that defines where 
things should go. If you patch the following file how you want it and submit it 
to us, we can formally support LFS out the box and you can remove the need for 
your patch:

https://svn.apache.org/repos/asf/httpd/sandbox/replacelimit/config.layout

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

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

[Stefan Eissing]

> Am 17.04.2018 um 19:18 schrieb 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.

All my substantial functional additions had beta releases for months before 
being voted into the 2.4.x branch. With binary beta packages available for 
several platforms by several supporters.

William, this painting our world a dark and miserable place is coming back 
every few months. It is a disservice to the people who contribute changes here.

>> 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.

There are alternative ways to be creative and innovate than going through this 
PMC into a semi annual release.

Releasing a module (plus some small patches) on github opens ways for 
collaboration with people who like Apache and new stuff. Distros like Debian 
unstable and Fedora pick up stuff from there. PPAs for apt are made available. 
Steffen offers Windows builts.

The release cycle is hours, to the benefit of all interested. Be it a blocking 
bug fixed or a nice feature implemented. These are mostly people who do it for 
fun. Some even run large server clusters, so a „hobbyist“ label does not apply.

It‘s simply fun. It‘s how I think FOSS is supposed to work and has worked best 
in the past. I plan to continue doing it.

If that stuff makes it all back into the Apache svn is not that relevant to me. 
Because it‘s the least rewarding and fun part.

(I am just talking about my feelings here, YMMV.