Re: Cloudflare, Google Chrome, and Firefox Add HTTP/3 Support

[Mark Blackman]

> On 26 Sep 2019, at 18:54, Alex Hautequest  wrote:
> 
> https://news.slashdot.org/story/19/09/26/1710239/cloudflare-google-chrome-and-firefox-add-http3-support
> 
> With that, the obvious question: what about Apache?

What’s the incentive to add it? 


- Mark

RE: release?

[Mark Blackman]

Hi,

Is this release likely to be ready before August 10? I am guessing "no" at this 
point, but wanted to get an idea early.

Cheers,
Mark

-Original Message-
From: Rainer Jung [mailto:rainer.j...@kippdata.de]
Sent: 20 July 2019 10:44
To: dev@httpd.apache.org
Subject: Re: release?

m 20.07.2019 um 10:38 schrieb Marion & Christophe JAILLET:
> Hi,
>
> PR60757 and corresponding r1853560 could be a good candidate for backport.
>
> I don't have a configuration for testing so I won't propose it myself
> for backport, but the patch looks simple.

I have added this one (mod_proxy_hcheck in BalancerMember) and two other ones 
("Mute frequent debug message in mod_proxy_hcheck" and "bytraffic needs 
byrequests") to STATUS right now.

Regards,

Rainer

> Le 18/07/2019 à 16:06, Stefan Eissing a écrit :
>> It would be great if we could make a release this month. There are
>> several fixes and improvements already backported and a few
>> outstanding issues that need a vote or two.
>>
>> Please have a look if you find the time. I think Daniel expressed
>> willingness to RM this? That'd be great!
>>
>> Cheers, Stefan


---
This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient (or have received this e-mail in error) please 
notify the sender immediately and delete this e-mail. Any unauthorized copying, 
disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to https://www.db.com/disclosures for additional EU corporate and 
regulatory disclosures and to 
http://www.db.com/unitedkingdom/content/privacy.htm for information about 
privacy.

Re: Load balancing and load determination

[Mark Blackman]

> On 30 Oct 2018, at 12:53, Jim Jagielski  wrote:
> 
> As some of you know, one of my passions and area of focus is
> on the use of Apache httpd as a reverse proxy and, as such, load
> balancing, failover, etc are of vital interest to me.
> 
> One topic which I have mulling over, off and on, has been the
> idea of some sort of universal load number, that could be used
> and agreed upon by web servers. Right now, the reverse proxy
> "guesses" the load on the backend servers which is OK, and
> works well enough, but it would be great if it actually "knew"
> the current loads on those servers. I already have code that
> shares basic architectural info, such as number of CPUs, available
> memory, loadavg, etc which can help, of course, but again, all
> this info can be used to *infer* the current status of those backend
> servers; it doesn't really provide what the current load actually
> *is*.
> 
> So I was thinking maybe some sort of small, simple and "fast"
> benchmark which could be run by the backends as part of their
> "status" update to the front-end reverse proxy server... something
> that shows general capability at that point in time, like Hanoi or
> something similar. Or maybe some hash function. Some simple code
> that could be used to create that "universal" load number.
> 
> Thoughts? Ideas? Comments? Suggestions? :)

What problem are you trying to solve? Broadly, I think they best you can do is 
ask the backends to include a response header indicating their current appetite 
for more connections.

- Mark

Re: t/modules/buffer.t failing in 2.4.36, LWP bug [Was: [VOTE] Release httpd-2.4.36]

[Mark Blackman]

> On 14 Oct 2018, at 12:33, Rainer Jung  wrote:
> 
> Am 13.10.2018 um 11:46 schrieb Rainer Jung:
>> Am 11.10.2018 um 20:55 schrieb Ruediger Pluem:
>>> 
>>> 
>>> On 10/11/2018 08:10 PM, Christophe JAILLET wrote:
 No issue on my Ubuntu 18.04 VM.
 
 On what configuration are you running your tests, Rüdiger? macOS, just 
 like Jim?
>>> 
>>> Centos 7.5 64 Bit
>>> 
>>> Regards
>>> 
>>> Rüdiger
>> The test fails for me as well for 2.4.36 on SLES12. Small bodies are OK, 
>> large not. The limit is somewhere between 1.3 and 1.5 MB, not always the 
>> same. The test hangs there until mod_reqtimeout times out after a minute, 
>> complaining that it could not read more data from the client. If I reduce 
>> the multiplicator 100 to eg. 20 it always passes.
>> If I start the test server using "t/TEST -start-httpd" and then use curl to 
>> POST data, I can even POST much bigger data and get the correct result back. 
>> I use
>>   curl -v --data-binary @BIGFILE http://localhost:8529/apache/buffer_in/ > 
>> response-body
>> So I assume it is a problem of interaction between the server reading the 
>> POST body and the client sending it.
>> My test framework was freshly assembled recently, so lots of current modules.
>> The setup is based on OpenSSL 1.1.1 in the server and in the test framework, 
>> but the actual test runs over http, so I don't expect any OpenSSL related 
>> reason for the failure.
> 
> I did some more tests including using LWP directly and sniffing the packets 
> on the network plus with mod_dumpio and also doing truss / strace.
> 
> I can reproduce even when sending using LWP directly or just the POST binary 
> coming with LWP. I can not reproduce with curl.
> 
> With mod_dumpio and in a network sniff plus truss it looks like the client 
> simply stops sending once it got the first response bytes. LWP seems to 
> select the socket FD for read and write. As long as only write gets 
> signalled, it happily sends data. Once it gets write plus read signalled, it 
> switches over to read and no longer checks for write. Since our server side 
> implementation is streaming and starts to send the reflected bytes right 
> away, this LWP behavior breaks the request.

Hmm, it almost seems like that test/reflector module doesn’t reflect the 
protocol definition though, https://tools.ietf.org/html/rfc7231#section-1
"A server listens on a connection for a request,
   parses each message received, interprets the message semantics in
   relation to the identified request target, and responds to that
   request with one or more response messages”
I would interpret that “message received" as the server is expected to wait 
until the entire request is received, aside from the case of "Expect: 
100-continue” and even that alludes to waiting.
https://tools.ietf.org/html/rfc7231#section-6.2.1 

"The server intends to send a final response after the request has been fully 
received and acted upon."
What do you think?
- Mark

Re: NOTICE: Intent to T 2.4.36

[Mark Blackman]

> On 10 Oct 2018, at 21:04, Jim Jagielski  wrote:
> 
>> 
>> Does the TLSv1.3 support need to be production ready?
>> 
>> TLSv1.3 is presumably an opt-in feature and as long as it doesn’t endanger 
>> existing behaviours, I would have assumed it’s relatively safe to release 
>> with caveats in the docs. 
>> Of course, once there’s more take-up of TLSv1.3, then the test suite needs 
>> to be useful. Getting real-world feedback about something completely new 
>> that doesn’t endanger existing behaviours outside of TLSv1.3 is probably 
>> worthwhile.
> 
> The issue is that such a major feature enhancement touches a lot of code. 
> That can cause regressions.
> 
> Sometimes, some people try to reduce and restrict development and new 
> features using that as an argument. I, and numerous others, have consistently 
> disagreed with that as a convincing argument against adding stuff to 2.4.x. 
> In this particular situation, the "usual suspect(s)" were actually very 
> gung-ho on release, despite this being the exact kind of situation they would 
> normally balk against. I was noting the discrepancy and wondering the 
> reasoning…

Fair enough, I hadn’t checked to see how invasive the change was. I had assumed 
a lot of "#ifdef TLSV13” protecting current behaviours.

- Mark

Re: NOTICE: Intent to T 2.4.36

[Mark Blackman]

> On 10 Oct 2018, at 20:28, Jim Jagielski  wrote:
> 
> 
> 
>> On Oct 10, 2018, at 3:01 PM, William A Rowe Jr > > wrote:
>> 
>> On Wed, Oct 10, 2018 at 1:45 PM Jim Jagielski > > wrote:
>> I thought the whole intent for a quick 2.4.36 was for TLSv1.3 support.
>> 
>> If that's not ready for prime time, then why a release??
>> 
>> AIUI, it isn't that httpd isn't ready for release, or even httpd-test 
>> framework.
>> Until all the upstream CPAN modules behave reasonably with openssl 1.1.1
>> we will continue to see odd test results.
> 
> The question is How Comfortable Are We That TLSv1.3 Support Is Production 
> Ready?
> 
> This release seems very, very rushed to me. It seems strange that for someone 
> who balks against releasing s/w that hasn't been sufficiently tested, or 
> could cause regressions, and that the sole reason for this particular release 
> is TLSv1.3 support which seems insufficiently tested, you are 
> uncharacteristic cool with all this.

Does the TLSv1.3 support need to be production ready?

TLSv1.3 is presumably an opt-in feature and as long as it doesn’t endanger 
existing behaviours, I would have assumed it’s relatively safe to release with 
caveats in the docs. 
Of course, once there’s more take-up of TLSv1.3, then the test suite needs to 
be useful. Getting real-world feedback about something completely new that 
doesn’t endanger existing behaviours outside of TLSv1.3 is probably worthwhile.

- Mark

Re: slotmem + balancer

[Mark Blackman]

> On 8 May 2018, at 18:19, Jim Jagielski  wrote:
> 
> I am under the impression is that we should likely restore mod_slotmem_shm
> back to its "orig" condition, either:
> 
>o 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/slotmem/mod_slotmem_shm.c?view=markup=1822341
>  
>o 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/slotmem/mod_slotmem_shm.c?view=markup=1782069
>  
> 
> 
> and try to rework all of this. I fear that all the subsequent work has really 
> made this module extremely fragile. We need, IMO, a very minimal fix for PR 
> 62044
> 
> Just for the heck of it, didn't r1822341 
>  actually *FIX* 
> the PR? 


Hi,


To follow-up as the reporter of 62044, the original problem was a segmentation 
fault due to an entirely different 3rd party vendor module, which Apache 2.4.32 
magically fixed, no idea how. However, the segfaults meant that the SHMs and/or 
SHM placeholder files weren't getting correctly cleaned up on restarts (in 
2.4.29). I think it is important for httpd to handle the segfault case well 
because 3rd party modules can cause problems that httpd can’t anticipate. 
Ultimately, httpd is creating a bunch of persistent external state that it 
should make an effort to deal with cleanly when httpd stops unexpectedly and is 
subsequently restarted.

We restart/reload Apache frequently enough that preserving balancer state is 
useful but not critical.

I think you will find it difficult to re-work effectively unless you can 
identify representative test cases possibly including a segfault.

For me the most important characteristics of the fix were (a) to more 
accurately identify genuine virtual host changes (rather than simple line 
number shifts) that might invalidate balancer state and at least in some cases, 
to pick up existing SHMs left-over from the last httpd start. 

- Mark

Re: A proposal...

[Mark Blackman]

> On 23 Apr 2018, at 19:17, Christophe Jaillet  
> wrote:
> 
> Le 23/04/2018 à 16:00, Jim Jagielski a écrit :
>> It seems that, IMO, if there was not so much concern about "regressions" in 
>> releases, this whole revisit-versioning debate would not have come up. This 
>> implies, to me at least, that the root cause (as I've said before) appears 
>> to be one related to QA and testing more than anything. Unless we address 
>> this, then nothing else really matters.
>> We have a test framework. The questions are:
>>  1. Are we using it?
>>  2. Are we using it sufficiently well?
>>  3. If not, what can we do to improve that?
>>  4. Can we supplement/replace it w/ other frameworks?
>> It does seem to me that each time we patch something, there should be a test 
>> added or extended which covers that bug. We have gotten lax in that. Same 
>> for features. And the more substantial the change (ie, the more core code it 
>> touches, or the more it refactors something), the more we should envision 
>> what tests can be in place which ensure nothing breaks.
>> In other words: nothing backported unless it also involves some changes to 
>> the Perl test framework or some pretty convincing reasons why it's not 
>> required.
> 
> Hi,
> +1000 on my side for more tests.
> 
> But, IMHO, the perl framework is complex to understand for most of us.

Do you believe the Perl element is contributing to the complexity? I’d say Perl 
is perfect for this case in general, although I would have to look at it first 
to confirm.

I certainly believe adequate testing is a bigger and more important problem to 
solve than versioning policies, although some versioning policies might make it 
simpler to allow enough time for decent testing to happen. I personally have a 
stronger incentive to help with testing, than I do with versioning policies.

- Mark

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

[Mark Blackman]

> On 20 Apr 2018, at 01:39, Daniel Ruggeri  wrote:
> 
> I'm not sure where in the conversation to add this, but I do want to
> point out a mechanical concern.
> 
> 
> If we end up with API and feature freeze on branch 2.4, then we'd expect
> to roll 2.6. Soon enough, we'll hit a situation where 2.6 (as a release
> branch) can't get a feature or the next great thing because of a
> required API incompatible change. We would then kick out 2.8, 2.10 and
> so on and so forth. This seems like it would satisfy both the
> keep-the-stuff-stable as well as the give-users-new-stuff "sides".
> 
> 
> Mechanically, this can become tiresome for a volunteer as we work
> through the STATUS ceremony for each of the branches. I remember that
> being less than enjoyable when 2.0, 2.2 and 2.4 were all release
> branches. I'm fearful of a future where we may have five branches and a
> bugfix applicable to all (or worse... a security fix that would dictate
> all should be released/disclosed at the same time).

Presumably most/all of that toil can be automated away as you have started 
doing, so that human intervention is only required where human judgement is 
actually required?  Does httpd have some massive CD/CI pipeline in the 
background I don’t see or could it do with one? 

- Mark

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

[Mark Blackman]

> On 19 Apr 2018, at 21:35, David Zuelke  wrote:
> 
> On Thu, Apr 19, 2018 at 8:25 PM, Jim Jagielski  wrote:
>> 
>> 
>>> On Apr 19, 2018, at 11:55 AM, David Zuelke  wrote:
>>> 
>>> 
>>> I hate to break this to you, and I do not want to discredit the
>>> amazing work all the contributors here are doing, but httpd 2.4 is of
>>> miserable, miserable quality when it comes to breaks and regressions.
>>> 
>> 
>> Gee Thanks! That is an amazing compliment to be sure. I have
>> NO idea how ANYONE could take that in any way as discrediting
>> the work being done.
>> 
>> Sarcasm aside, could we do better? Yes. Can we do better? Yes.
>> Should we do better? Yes. Will we do better? Yes.
>> 
>> BTW, you DID see how h2 actually came INTO httpd, didn't you??
> 
> Of course, but that's exactly my point. It was introduced not in
> 2.4.0, but in 2.4.17. Five "H2…" config directives are available in
> 2.4.18+ only, one in 2.4.19+, and three in 2.4.24+.
> 
> I'm not saying no directives should ever be added in point releases or
> anything, but the constant backporting of *features* to 2.4 has
> contributed to the relatively high number of regressions, and to a
> lack of progress on 2.6/3.0, because, well, if anything can be put
> into 2.4.next, why bother?
> 
> David

What’s the rule for *features*?

- Mark

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: [Bug 62044] shared memory segments are not found in global list, but appear to exist in kernel.

[Mark Blackman]

> On 2 Feb 2018, at 14:19, Jim Jagielski  wrote:
> 
> To be honest, I don't think we ever envisioned an actual environ
> where the config files change every hour and the server gracefully
> restarted... I think our working assumptions have been that actual
> config file changes are "rare", hence the number of modules that
> allow for "on-the-fly" reconfiguration which avoid the need for
> restarts.
> 
> So this is a nice "edge case"
> 

Think mass hosting of 1+ reverse-proxy front-ends all in the same Apache 
instance, with self-service updates to configs as well as a staging 
environment.The 24-hour cycle is like this..

1am: Full stop (SIGTERM) and start of Apache with all configurations, primarily 
to permit log file rotation.

Then, on the hour, any configuration changes requested will be made live by 
auto-generation of a giant 200k+ configuration then a HUP (not a USR1) signal 
to keep the same parent, but a bunch of fresh children. As these are mostly 
reverse proxies, we generate thousands of balancer and balancermember 
directives per configuration.

In the background, once a minute, a background process is always checking for 
responses and forcibly restarting Apache (SIGTERM then SIGKILL if necessary) if 
it doesn’t respond.

Finally, bear in mind that line number changes can occur merely because a new 
virtualhost was added ahead of a given virtualhost, so some kind of tracking 
UUID for a virtualhost based on whatever non-line-number properties is probably 
useful.

- Mark

Re: [Bug 62044] shared memory segments are not found in global list, but appear to exist in kernel.

[Mark Blackman]

> On 1 Feb 2018, at 16:27, Yann Ylavic <ylavic@gmail.com> wrote:
> 
>> On Thu, Feb 1, 2018 at 5:15 PM, Yann Ylavic <ylavic@gmail.com> wrote:
>> On Thu, Feb 1, 2018 at 4:32 PM, Mark Blackman <m...@exonetric.com> wrote:>
>> 
>>> SHM clean-up is the key here and any patch that doesn’t contribute to
>>> that has no immediate value for me.
>> 
>> What you may want to try is remove "s->defn_line_number" from the id there:
>> https://github.com/apache/httpd/blob/trunk/modules/proxy/mod_proxy_balancer.c#L787
>> If your configuration file changes often, that contributes to changing
>> the name of the SHM...
> 
> FWIW, here is (attached) the patch I'm thinking about.
> 

Thanks, the configuration changes once an hour or so. Typically, we have about 
1000 active shared memory segments (yes, they are SHMs) attached to the httpd 
processes.

For now, we’ll just have to implement a SHM clean-up in the start/stop wrappers 
until we can address the root cause or find a cleaner mitigation, which your 
patch might help with.

- Mark

Re: [Bug 62044] shared memory segments are not found in global list, but appear to exist in kernel.

[Mark Blackman]

> On 1 Feb 2018, at 12:36, Yann Ylavic <ylavic@gmail.com> wrote:
> 
> Hi Mark,
> 
> On Thu, Feb 1, 2018 at 10:29 AM, Mark Blackman <m...@exonetric.com> wrote:>
>> 
>> 
>> Just to confirm, you expect that patch to handle SHM clean-up even in
>> the “nasty error” case?
> 
> Not really, no patch can avoid a crash for a crashing code :/
> The "stop_signals-PR61558.patch" patch avoids a known httpd crash in
> some circumstances, but...

Well, I just mean, if sig_coredump gets called, will the patch result in the 
normal SHM clean-up routines getting called, where they would have not been 
called before?  SHM clean-up is the key here and any patch that doesn’t 
contribute to that has no immediate value for me.

> 
>> I suspect that nasty error is triggered by
>> the Weblogic plugin based on the adjacency in the logs, but the
>> tracing doesn’t reveal any details, so an strace will probably be
>> required to get more detail.

Tracing has confirmed this really is a segmentation fault despite the lack of 
host-level messages and that reading a 3rd party module (but not Weblogic) is 
the last thing that happens before the segmentation fault and that pattern is 
fairly consistent. Now we need to ensure coredumps are generated.

Finally, there are no orphaned child httpd processes with a PPID of 1.  Just 
thousands and thousands of SHM segments with no processes attached to them.

Regards,
Mark

Re: [Bug 62044] shared memory segments are not found in global list, but appear to exist in kernel.

[Mark Blackman]

On 31 Jan 2018, at 22:41, Yann Ylavic  wrote:
> 
> Hi Mark,
> 
> let's continue this debugging on dev@ if you don't mind..
> 
>> On Wed, Jan 31, 2018 at 10:15 PM,   wrote:
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=62044
>> 
>> --- Comment #32 from m...@blackmans.org ---
>> so sig_coredump is being triggered by an unknown signal, multiple times a 
>> day.
>> It's not a segfault, nothing in /var/log/messages. That results in a bunch of
>> undeleted shared memory segments and probably some that will no longer be in
>> the global list, but still present in the kernel.
> 
> In 2.4.29, i.e. without patch [1], sig_coredump might be triggered by
> any signal received by httpd during a restart, and the signal handle
> crashes itself (double fault) so the process is forcibly SIGKILLed
> (presumably, no trace in /var/log/messages...).
> This was reported and discussed in [2], and seems to quite correspond
> to what you observe in your tests.
> 
> Moreover, if the parent process crashes nothing will delete the
> IPC-SysV SHMs (hence the leak in the system), while children processes
> may continue to be attached which prevents a new parent process to
> start (until children stop or are forcibly killed)...
> 
> When this happens, you should see non-root processes attached to PPID
> 1 (e.g. with "ps -ef"), "-f /path/to/httpd.conf" in the command line
> might help distinguish the different httpd instances to monitor
> processes.
> 
> If this is the case, you probably should try patch [1].
> If not, I can't explain why in httpd logs a process with a different
> PID appears after the SIGHUP, it must have been started
> (automatically?) after the previous one crashed.
> Here the generation number can't help, a new process always start at
> generation #0.
> 
> Regards,
> Yann.
> 
> [1] 
> https://svn.apache.org/repos/asf/httpd/httpd/patches/2.4.x/stop_signals-PR61558.patch
> [2] https://bz.apache.org/bugzilla/show_bug.cgi?id=61558

Thanks, for now, we will treat the “nasty error” as a separate question to 
resolve and hope that clean-up patch deals with the immediate issue.

I had originally treated that “nasty error” as a reference to the “file exists” 
error.  However, based on your feedback and reviewing the logs, I would 
conclude that “nasty error” is the trigger, as you suggrest, and the lack of 
SHM clean-up and consequent collisions are collateral damage.

Just to confirm, you expect that patch to handle SHM clean-up even in the 
“nasty error” case?  I suspect that nasty error is triggered by the Weblogic 
plugin based on the adjacency in the logs, but the tracing doesn’t reveal any 
details, so an strace will probably be required to get more detail.

Bugzilla was slightly easier to get log data into as I cannot use work email 
for these conversations.

Cheers,
Mark

shared memory segment issue in 2.4.29

[Mark Blackman]

Hi,

Any chance I could persuade anyone on the list to look over 
https://bz.apache.org/bugzilla/show_bug.cgi?id=62044 
 and provide feedback?

Cheers,
Mark

Re: DISCUSS: Establishing a release cadence

[Mark Blackman]

> On 2 Nov 2017, at 10:51, Daniel Ruggeri  wrote:
> 
> Hi, all;
> 
>I know we've chatted about this somewhat in the past so I wanted to
> kick off a formal topic to see if we can establish consensus for a
> release cadence of httpd. As a strawman proposal, I'd like to suggest
> that we...
> 
>  * Ensure stable branches are always in a releasable state (I believe
> this to currently be the case, right?)
> 
>  * Codify and automate the creation/handling of the release bits in a
> CI/CD job plan
> 
>  * Plan to release whatever is in stable branches every quarter via the job
> 
>  * Plan to "release" unstable/trunk bundles monthly
> 
>  * Support the ability to run the job ad-hoc for emergency fixes
> 
> 
> As a swag, all of the above is to make the work of the RM relatively
> light so more folks from the community can/will participate. There have
> been a few cases where features or fixes have sat in 2.4 without release
> because Jim or Bill just hadn't kicked off the process and committed
> their free time to doing it. The other thought is to help provide some
> degree of regularity our community (users and devs alike) can come to
> expect as well as do whatever we can to easily get experimental trunk
> bits in peoples' hands for testing.
> 
> 
> Thoughts?

Broadly reasonable, I can volunteer some online hardware if it helps. You might 
be shorter of people than hardware though.

- Mark

Re: Thoughts on 2.5.0

[Mark Blackman]

> On 24 Oct 2017, at 14:42, Jim Jagielski  wrote:
> 
> I would like to start a discussion on 2.5.0 and give
> some insights on my thoughts related to it.
> 
> First and foremost: there is cool stuff in 2.5.0
> that I really, REALLY wish were in a releasable, usable
> artifact. Up to now, we've been doing these as backports
> to the 2.4.x tree with, imo at least, good success.
> 
> So I think the main questions regarding 2.5.0 is a list
> of items/issues that simply *cannot* be backported, due
> to API/ABI concerns. And then gauge the "value" of
> the items on that list.
> 
> Another would be to look at some of the items currently
> "on hold" for backporting, due to outstanding questions,
> tech issues, more needed work/QA, etc... IMO, if these
> backports lack "support" for 2.4.x, then I wonder how
> "reliable" they are (or how tested they are) in the 2.5.o
> tree. And if the answer is "we pull them out of 2.5.0"
> then the question after that is what really *are* the
> diffs between 2.5.0 and 2.4.x... If, however, the
> answer is "tagging 2.5.0 will encourage us to address
> those issues" then my question is "Why aren't we doing
> that now... for 2.4.x".
> 
> And finally: 2.4.x is now, finally, being the default
> version in distros, being the go-to version that people
> are using, etc... I would like us to encourage that
> momentum.

As an observer, I’d like to ask what your goals are for these branches and what 
kinds of expectations would you like consumers of these branches to have?

- Mark 

Re: [Discuss] Rolling a 'final' 2.2.33 release

[Mark Blackman]

> On 14 Jun 2017, at 22:12, William A Rowe Jr  wrote:
> 
> 
> Thoughts/comments? Patches to hold for before we roll? If I don't hear
> otherwise, and we stick to the simpler alternative, then I'd plan to roll
> these candidates Thursday.

Would it be an option to get a fix in for the single-character header bug? ( 
https://bz.apache.org/bugzilla/show_bug.cgi?id=61220 
 ) 

If you add

HttpProtocolOptions Unsafe LenientMethods Allow0.9

to a default httpd.conf

single character header lines are rejected with a 400 code.

macmini:httpd-2.2.33 mark$ telnet localhost 8033
Trying ::1...
Connected to localhost.
Escape character is '^]'.
GET / HTTP/1.1
Host: foobar
x: 0

HTTP/1.1 400 Bad Request
Date: Sun, 25 Jun 2017 21:43:53 GMT
Server: Apache/2.2.33 (Unix)
Content-Length: 226
Connection: close
Content-Type: text/html; charset=iso-8859-1



400 Bad Request

Bad Request
Your browser sent a request that this server could not understand.


Connection closed by foreign host.

Re: Post 2.4.25

[Mark Blackman]

> On 24 Dec 2016, at 16:32, Eric Covener  wrote:
> 
>> I'm not saying we don't do one so we can do the other; I'm
>> saying we do both, at the same time, in parallel. I still
>> don't understand why that concept is such an anathema to some
>> people.
> 
> I also worry about our ability to deliver a 3.0 with enough
> re-architecture for us and and function for users, vs a more
> continuous delivery (apologies for bringing buzzaords to dev@httpd)
> cadence on 2.4 as we've been in.

If you can find a way with limited resources, I would encourage doing both in 
parallel as well.

What are the 2.6/3.0 re-architecture goals/vision out of curiosity?

- Mark

module advice

[Mark Blackman]

Hi,

Not sure if this is the right mailing list for this question, and feel free to 
redirect me if so, however, if I want to write a module to examine an HTTP POST 
body and execute some action with the contents of the body, but only if the 
body matches some condition, should that be done with an input filter, taking a 
copy of the body and then end of the request, doing the matching and/or 
execution of the action? Or is there some way to plant a hook that gets 
executed after all the input filters have run and I just have the  whole 
request body sitting there ready for examination?

Currently, I believe an input filter is required to copy the request as it 
comes in, but it might be cleaner to just execute some code after the body has 
been received if practical.

Cheers,
Mark 

RE: [ANNOUNCE] Apache HTTP Server 2.4.23 Released [I]

[Mark Blackman]

Thanks for the speedy turn-around!

From: Luca Toscano [mailto:toscano.l...@gmail.com]
Sent: 04 August 2016 14:08
To: Apache HTTP Server Development List 
Subject: Re: [ANNOUNCE] Apache HTTP Server 2.4.23 Released [I]


https://httpd.apache.org front page updated!

Luca


---
This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient (or have received this e-mail in error) please 
notify the sender immediately and delete this e-mail. Any unauthorized copying, 
disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to https://www.db.com/disclosures for additional EU corporate and 
regulatory disclosures and to 
http://www.db.com/unitedkingdom/content/privacy.htm for information about 
privacy.

RE: [ANNOUNCE] Apache HTTP Server 2.4.23 Released [I]

[Mark Blackman]

Classification: For internal use only

Hi,

Could I recommend that text about Apache 2.2 EOL notification be added to the 
2.2 section on http://httpd.apache.org please?

Regards,
Mark

> -Original Message-
> From: Jim Jagielski [mailto:j...@jagunet.com]
> Sent: 05 July 2016 14:04
> To: httpd 
> Cc: us...@httpd.apache.org
> Subject: [ANNOUNCE] Apache HTTP Server 2.4.23 Released.
>
> ..
>
> Please note that Apache Web Server Project will only provide maintenance
> releases of the 2.2.x flavor through June of 2017, and will provide some
> security patches beyond this date through at least December of 2017.
> Minimal maintenance patches of 2.2.x are expected throughout this period,
> and users are strongly encouraged to promptly complete their transitions
> to the the 2.4.x flavor of httpd to benefit from a much larger assortment
> of minor security and bug fixes as well as new features.


---
This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient (or have received this e-mail in error) please 
notify the sender immediately and delete this e-mail. Any unauthorized copying, 
disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to https://www.db.com/disclosures for additional EU corporate and 
regulatory disclosures and to 
http://www.db.com/unitedkingdom/content/privacy.htm for information about 
privacy.

Re: End of the road of 2.2.x maintenance?

[Mark Blackman]

> On 10 May 2016, at 21:38, William A Rowe Jr  wrote:
> 
> 
> Are we ready to start the 12 month countdown as of the next/final bug
> fix release of 2.2, and highlight this in both the 2.2 and 2.4 announce
> broadcasts?
> 
> I'm hoping we conclude some fixes of 2.4 scoreboard regressions and
> get to the point of releasing 2.4 with mod_proxy_http2 sometime within
> the next month or so, and that we can reach a consensus about how
> we will proceed on the 2.2 branch, before we get to that release.
> 
> Feedback desired

As a big consumer of Apache 2.2 in my day job, where we are obliged to track 
Apache’s policies very closely, I would prefer to delay this a bit. When Apache 
announces the formal end-of-life date of 2.2, we will be required to engineer 
the migration of 6000+ wildly diverse sites to Apache 2.4 to meet internal 
audit policies. I would propose the 12 month countdown starts no earlier than 
Jan 2017 (as a consumer).

What’s the cost of maintaining (but maybe not updating) Apache 2.2?

Cheers,
Mark

Re: 2.2 and 2.4 and 2.6/3.0

[Mark Blackman]

 On 27 May 2015, at 13:54, Jim Jagielski j...@jagunet.com wrote:
 
 Anyone else think it's time to EOL 2.2 and focus
 on 2.4 and the next gen? My thoughts are that http/2
 and mod_h2 will drive the trunk design efforts and so
 it would be nice to focus energy on 2.4 and later...

Depends on what EOL means practically, of course. As someone whose day job is 
engineering the web platform for one of the big investment banks, I can tell 
you we only just got everyone moved over to 2.2 (i.e. several years after 1.3 
got canned in early 2010).

So while I’m not looking for the latest and greatest features in 2.2 at this 
stage, I do want to continue to see bug fixes and security issues addressed for 
at least another five years (ideally), and really 2 years at a minimum. I can 
easily see this might be asking too much of volunteers, but those are my 
“enterprise” expectations. 

- Mark

Re: commercial support

[Mark Blackman]

Is Apache 2.4 really just as fast as nginx for response times for an arbitrary 
number of concurrent connections?

Apache is great and it’s now so mature that most enterprises are very 
comfortable with it, but where nginx started with a very simple premise and 
have kept the scope restricted.

For me, Apache is a Swiss army knife that has a solution for nearly every use 
case and nginx is more like a surgeon’s scalpel, best of breed in that domain 
(maximal concurrent connections for minimum resource cost with minimum feature 
set), but unhelpful in other places.


Cheers,
Mark

 On 20 Nov 2014, at 22:00, Jim Jagielski j...@jagunet.com wrote:
 
 It's a shame that there isn't a company like Covalent
 around anymore that focuses on the Apache httpd web-server.
 nginx.com shows kinda clearly that having a motivated
 company behind a web-server helps grab market share and
 market awareness (they can continue to beat the drum about
 how fast and reliable they are, when so many benchmarks
 lately show that 2.4 is just as fast if not faster in
 actual response time, but we have limited ability to
 do that, and most reporters see us as Old news and
 nginx as the new hotness anyway)...
 
 So who wants to get together and create a company
 around httpd? :)
 
 Honestly though, how much of the uptake in nginx
 do people think is actually due to nginx being better
 or the best choice, and how much do you think is
 due simply because it's *seen* as better or that we
 are seen as old and tired?
 
 This is our 20year anniversary... It would be cool
 to use that to remind people! :)

Apache 2.2.28 release timing.

[Mark Blackman]

Hi,

This might be more of user than dev question, but as the discussions about 
timing were here, I’ll go with here.

http://mail-archives.apache.org/mod_mbox/httpd-dev/201407.mbox/20140721075315.ec908e91c20de17e6e448089a4bc3ed2.f963b4ea46.wbe%40email11.secureserver.net

suggested the 2.2.28 tagging and presumably release is imminent,  
however, http://svn.apache.org/repos/asf/httpd/httpd/tags/2.2.28 is still a 404.

I understand the mechanics of open source projects, so this is not a 
“hurry-up”, 
it’s just a can I get Apache 2.2.28 into my next hosting platform release or 
not”, 
the contents of which will be frozen on Aug. 15.

I’m mostly interested in the CVE updates, so I can tell users we’re clear of 
them. 
If the 2.2.28 release is not likely before Aug. 15, that’s fine, I just wanted 
to be sure.

Cheers,
Mark