Re: [VOTE] Release httpd-2.4.58-rc3 as httpd-2.4.58

[David Zuelke via dev]

FYI, the https://httpd.apache.org front page still lists 2.4.57 as the
latest version.

- David


On Wed, Oct 18, 2023 at 5:09 PM Stefan Eissing via dev 
wrote:

> With 8 +1 votes and no counters, this seems a go. If nothing else comes
> up, I'll do the release tomorrow noonish.
>
> Thanks all for the testing!
>
> Cheers,
> Stefan
>
> > Am 16.10.2023 um 17:08 schrieb Stefan Eissing via dev <
> dev@httpd.apache.org>:
> >
> > Hi all,
> >
> > after fixing my merge mistake in rc2 (sorry!), we go again:
> >
> > Please find below the proposed release tarball and signatures:
> >
> > https://dist.apache.org/repos/dist/dev/httpd/
> >
> > I would like to call a VOTE over the next few days to release
> > this candidate tarball httpd-2.4.58-rc3 as 2.4.58:
> > [ ] +1: It's not just good, it's good enough!
> > [ ] +0: Let's have a talk.
> > [ ] -1: There's trouble in paradise. Here's what's wrong.
> >
> > The computed digests of the tarball up for vote are:
> > sha256: 503a7da4a4a27fd496037998b17078dc9fe004db32c657c96cce8356b8aa2eb6
> *httpd-2.4.58-rc3.tar.gz
> > sha512:
> 5c11faf0572035ef67b27775d975999411c689cb774553175299a9e99b63d3d7138b0c7f15048ec28038494d8513689f916202c2289d557947d8b190d46ca9f3
> *httpd-2.4.58-rc3.tar.gz
> >
> > The SVN candidate source is found at tags/2.4.58-rc3-candidate.
> >
> > Cheers,
> > Stefan
>
>
>

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

[David Zuelke]

On Sat, Apr 21, 2018 at 12:45 PM, Graham Leggett <minf...@sharp.fm> wrote:
> On 19 Apr 2018, at 5:55 PM, David Zuelke <dzue...@salesforce.com> 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.
>>
>> I maintain the PHP/Apache/Nginx infrastructure at Heroku, and I was
>> able to use the following httpd releases only in the last ~2.5 years:
>>
>> - 2.4.16
>> - 2.4.18
>> - 2.4.20
>> - 2.4.29
>> -2.4.33
>>
>> Mostly because of regressions around mod_proxy(_fcgi), REDIRECT_URL, 
>> whatever.
>
> Did you bring these regressions to our attention? Regressions get fix very 
> quickly - there was an 18 month period between 2.4.20 and 2.4.29, what 
> stopped it being possible to upgrade in that time?

I double checked. It was actually 2.4.27, not 2.4.29; 15 months, not 18. My bad.

The issue was the PHP-FPM + mod_proxy_fcgi regression introduced in
2.4.21; it got reported pretty quickly but took a while to address.

It finally got fixed in 2.4.26:
https://bz.apache.org/bugzilla/show_bug.cgi?id=60576

But that fix broke SCRIPT_NAME:
https://bz.apache.org/bugzilla/show_bug.cgi?id=61202

So 2.4.27 was functional again.

That means between April 11, 2016, and July 11, 2017, httpd with
mod_proxy_fcgi and PHP-FPM was broken.

The original change was made against trunk
(https://bz.apache.org/bugzilla/show_bug.cgi?id=59618) and then
backported to 2.4.next.

>
> (As other people have said, there was no release between 2.4.16 and 2.4.18, 
> 2.4.19 was replaced two weeks later, and there were no releases for you to 
> have used between v2.4.29 and 2.4.33)
>
>> This is not any person's fault. This is the fault of the process. The
>> process can be repaired: bugfixes only in 2.4.x, do RC cycles for
>> bugfix releases as well (that alone makes the changelog look a lot
>> less confusing, which is useful for the project's image, see also the
>> Nginx marketing/FUD discussion in the other thread), and start testing
>> new features in modules first.
>
> Unfortunately this misses a fundamental reality of what the httpd project is 
> - we are the foundation under many many other things, and when we jump from 
> v2.4.x to v2.6.x, our complete ecosystem above us needs to be recompiled.

Going from 2.4.x to 2.6.0 doesn't mean that 2.4.x would no longer be
maintained. There could easily be some predictable, defined support
policy for keeping older versions alive.

The other thing is ABI versus API stability; you could say 2.x.
versions retain API compatibility, but not ABI compatibility, so while
modules would have to be rebuilt against newer version series, that
could in virtually all cases happen without having to touch the
module's code.

>> It makes such little sense to land h2 support in 2.4.something, as
>> opposed to having it as an official "brand new, try it out" subproject
>> first, and then bundle it with 2.6.
>
> Not only does it make sense, but it is vital we do so.
>
> We needed to get h2 support into the hands of end users - end users who were 
> not going to recompile their entire web stack, who install software from 
> distros who are not going to upgrade, who were deploying modules from vendors 
> that were not going to recompile.

But that's what I'm saying. Why was h2 not kept as a module (for the
few people that are already deploying HTTP/2 stacks), let it mature
this way, and then put it into everyone's hands as part of 2.6.0,
which could be the big shiny new feature, to give everyone an
incentive to move to that new major version?

> Our average user will deploy whatever comes by default on their operating 
> system, they’re not going to have a dedicated team that deploys a custom 
> stack for their application. It is vital we respect the needs of these groups 
> of users.

That is even more of an argument to move to a more predictable cycle
and have patch releases only fix issues, because it means new features
see the light of day more quickly, so more people who just use what
comes with their OS would benefit from them.

Nobody who uses Apache as part of Debian, Ubuntu, RHEL, whatever, gets
new 2.4.next features. Those distros freeze Apache at whatever is the
latest version when their cutoff date is due, and then only backport
security fixes.

>> Really, I'd suggest taking a close look at the PHP release cycle, with
>> their schedules, their RFC policies, everything. As I said in that
>> other thread, the PHP project was in exactly the same spot a few years
>> ago and they have pulled themselves out of that mess with amazing
>> results.
>
> Specifically what about the

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

[David Zuelke]

On Thu, Apr 19, 2018 at 11:07 PM, Mark Blackman <m...@exonetric.com> wrote:
>
>
>> On 19 Apr 2018, at 21:35, David Zuelke <dzue...@salesforce.com> wrote:
>>
>> 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*?

That remains to be defined. Generally, I'd say anything that doesn't
correct existing functionality, or anything that changes defaults, or
anything that changes behavior with existing settings, is a
feature/break/change and not a fix, so would belong in 2.next.0.

More or less the Semver approach, essentially.

See e.g. https://wiki.php.net/rfc/releaseprocess

David

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

[David Zuelke]

The main difference is that you have a release branch in which fixes
to bugs or regressions found during 2.4.x RCs can be made, while work
on 2.4.(x+1) can continue in the main 2.4 branch.

Another benefit is that people who do automated builds (e.g. me) can
grep for "RC" in the version number and have it fetch from
https://dist.apache.org/repos/dist/dev/httpd/ instead.

The changelogs are more readable as well, because it's obvious which
intermediary RC releases belong together. If you look at
https://archive.apache.org/dist/httpd/CHANGES_2.4, there is zero
indication that e.g. 2.4.31 was never released.


On Thu, Apr 19, 2018 at 10:53 PM, William A Rowe Jr  wrote:
> What possible improvement occurs if there is no branch discipline
> on 2.4.x development? We just echoed effectively your proposal,
> using numbers rather than RC designations, and still .33 has this
> host of issues. With no release since .29, the branch was in this
> continuous state of flux between 2.4.30 and 2.4.33. Testing the
> 2.4.30 release did not result in a better, eventual 2.4.31, testing
> .31 didn't result in a better .32, and even the final .33 had its own
> issues.
>
> This would have been precisely the same outcome between RC1
> and RC4, if the project doesn't keep the branch stable for even the
> week or months required to craft a successful release, and if that
> occurs on 2.4.x branch, that is an interruption of effort towards
> release n+1, frustrating contributors.
>
> Note we don't publish anything not approved by the PMC, so
> there would be the same "vote" to release an RC.
>
> Net <-> net, this is the status quo which failed us so badly this
> past winter (now with alphabetic characters!)
>
>
> On Thu, Apr 19, 2018 at 10:51 AM, Jim Jagielski  wrote:
>> The idea is encouraging and fostering a broader test audience.
>>
>>
>> On Apr 19, 2018, at 11:44 AM, William A Rowe Jr  wrote:
>>
>> Unless I misunderstand...
>>
>> 2.4.30-RC1 (rejected)
>> 2.4.30-RC2 (our .31, rejected)
>> 2.4.30-RC3 (our .32, rejected)
>> 2.4.30-RC4 -> 2.4.30 GA (our 2.4.33 release)
>>
>> With all the associated changes in between, no actual change in branch
>> management, scope, feature creep, etc?
>>
>> This sounds like dressing up the status quo with different labels.
>>
>>
>>
>> On Thu, Apr 19, 2018, 10:37 Jim Jagielski  wrote:
>>>
>>>
>>>
>>> > On Apr 19, 2018, at 11:26 AM, William A Rowe Jr 
>>> > wrote:
>>> >
>>> > On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski  wrote:
>>> >> With all this in mind, should we try to set things up so that the
>>> >> next release cycle uses the concept of RCs?
>>> >>
>>> >> If so, and if people like, I can come up with a baseline
>>> >> proposal on the process for us to debate and come to
>>> >> some consensus on.
>>> >
>>> > Would you define an RC? What changes are allowable in that branch?
>>>
>>>
>>> The idea is that right now we take an existing state in SVN
>>> and tag it as, for example, 2.4.121. We then vote on that tag
>>> and the artifacts released from that tag. No work is done on
>>> the 2.4 branch while testing is done so that we ensure that
>>> the SVN rev on branch == the one for the tag
>>
>>
>> Not necessary to freeze; a tag can always be applied to an older rev.
>>
>>> Instead, we tag at 2.4.121-RC1. We do the exact same. If the
>>> vote does not pass, we continue on the 2.4 branch, fix the
>>> issues, and then tag a 2.4.121-RC2. Rinse and repeat.
>>>
>>> If the vote does pass we tag the branch, which is still == RC#
>>> at this stage, as 2.4.121 (ap_release.h mods included). We
>>> still even at this stage test and vote on the release as we have
>>> for decades. If it passes, we release. If not, for some reason,
>>> we have burned the 2.4.121 release, bump to 2.4.122 and GOTO
>>> the above.
>>>
>>> This is the overall idea... more flesh to be added.
>>
>>

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

[David Zuelke]

On Thu, Apr 19, 2018 at 8:25 PM, Jim Jagielski <j...@jagunet.com> wrote:
>
>
>> On Apr 19, 2018, at 11:55 AM, David Zuelke <dzue...@salesforce.com> 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

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

[David Zuelke]

Yup, that's exactly it. Have a release branch, iterate there, and in
the meantime, work in the version series branch can continue. That
brings one huge benefit over the current model already: no freezes
necessary, no potential additional breaks after a "burned" version.

On Thu, Apr 19, 2018 at 9:19 PM, Rainer Jung  wrote:
> Am 19.04.2018 um 17:37 schrieb Jim Jagielski:
>>
>>
>>
>>> On Apr 19, 2018, at 11:26 AM, William A Rowe Jr 
>>> wrote:
>>>
>>> On Thu, Apr 19, 2018 at 10:11 AM, Jim Jagielski  wrote:

 With all this in mind, should we try to set things up so that the
 next release cycle uses the concept of RCs?

 If so, and if people like, I can come up with a baseline
 proposal on the process for us to debate and come to
 some consensus on.
>>>
>>>
>>> Would you define an RC? What changes are allowable in that branch?
>>
>>
>>
>> The idea is that right now we take an existing state in SVN
>> and tag it as, for example, 2.4.121. We then vote on that tag
>> and the artifacts released from that tag. No work is done on
>> the 2.4 branch while testing is done so that we ensure that
>> the SVN rev on branch == the one for the tag.
>>
>> Instead, we tag at 2.4.121-RC1. We do the exact same. If the
>> vote does not pass, we continue on the 2.4 branch, fix the
>> issues, and then tag a 2.4.121-RC2. Rinse and repeat.
>>
>> If the vote does pass we tag the branch, which is still == RC#
>> at this stage, as 2.4.121 (ap_release.h mods included). We
>> still even at this stage test and vote on the release as we have
>> for decades. If it passes, we release. If not, for some reason,
>> we have burned the 2.4.121 release, bump to 2.4.122 and GOTO
>> the above.
>>
>> This is the overall idea... more flesh to be added.
>
>
> IMHO we should aim at keeping the RC phase as stable as possible and focuse
> on the code from which we tagged RC1 and which we actually want to release.
> So after RC1 there should be only fixes for regressions, no other fixes or
> backports.
>
> Other projects for example branch at the start of the release process (using
> your version example 2.4.121 here):
>
> - branch 2.4.x as a 2.4.121 branch
> - tag 2.4.121-RC1 on that branch
> - allow for a week or two (?) of public testing
> - fix incoming regressions
>   - patches go via trunk to 2.4.x to 2.4.121 branch
> - cut new RCs if previous RC needed fixes
> - create final release tag from last RC plus some script driven version
> adjustments
> - do final release vote
>
> While we are doing RCs backport and other fixing work could proceed on the
> 2.4.x branch, because the RCs are created from the version branch.
>
> ... 2c ...
>
> Rainer

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

[David Zuelke]

On Wed, Apr 18, 2018 at 8:01 AM, Stefan Eissing
 wrote:
>
>
>> Am 17.04.2018 um 19:18 schrieb William A Rowe Jr :
>>
>>> 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.

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.

I maintain the PHP/Apache/Nginx infrastructure at Heroku, and I was
able to use the following httpd releases only in the last ~2.5 years:

- 2.4.16
- 2.4.18
- 2.4.20
- 2.4.29
 -2.4.33

Mostly because of regressions around mod_proxy(_fcgi), REDIRECT_URL, whatever.

This is not any person's fault. This is the fault of the process. The
process can be repaired: bugfixes only in 2.4.x, do RC cycles for
bugfix releases as well (that alone makes the changelog look a lot
less confusing, which is useful for the project's image, see also the
Nginx marketing/FUD discussion in the other thread), and start testing
new features in modules first.

It makes such little sense to land h2 support in 2.4.something, as
opposed to having it as an official "brand new, try it out" subproject
first, and then bundle it with 2.6.

Speaking of which, I'd also suggest dropping this odd/even number
meaning experimental/stable versioning scheme, since it only
aggravates the problem: never-ending experiments that go stale, maybe
even get half backported, and meanwhile are subconsciously perceived
as one more hurdle towards a next bigger release.

Really, I'd suggest taking a close look at the PHP release cycle, with
their schedules, their RFC policies, everything. As I said in that
other thread, the PHP project was in exactly the same spot a few years
ago and they have pulled themselves out of that mess with amazing
results.

I am also happy to make introductions to release managers and
maintainers there. Heck I am betting some of them would happily serve
as tutors for the httpd project ;) I'm certainly willing to help too.
But IMO you need a clean cut and shake up the entire process, not just
a little, because otherwise you won't get rid of some of the old
habits that have been plaguing the project.

David

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

[David Zuelke]

On Sat, Apr 14, 2018 at 4:34 PM, Nick Kew <n...@apache.org> wrote:
>
>> On 14 Apr 2018, at 14:48, Jim Jagielski <j...@jagunet.com> wrote:
>>
>> IMO, the below ignores the impacts on OS distributors who
>> provide httpd. We have seen how long it takes for them
>> to go from 2.2 to 2.4... I can't imagine the impact for our
>> end user community if "new features" cause a minor
>> bump all the time and we "force" distributions for
>> 2.4->2.6->2.8->2.10…
>
> Chicken  httpd version numbers creep in a petty pace from year to year,
> and packagers do likewise.  Contrast a product like, say, Firefox, where major
> versions just whoosh by, and distros increment theirs every few months.
>

It's not like distros pick up patch releases anyway. They backport
fixes to whatever they "froze" to upon first release, and that's it.

Debian and Ubuntu, for instance, just pick the latest PHP that's
released at the time the freeze for a version happens, and that's it.


>>> On Apr 13, 2018, at 2:28 PM, David Zuelke <dzue...@salesforce.com> wrote:
>>>
>>> Remember the thread I started on that quite a while ago? ;)
>
> Nope.

https://lists.apache.org/thread.html/9afe84b5c2e7691f0190210e2377a6d504a6a77ff1481812f44f65d4@%3Cdev.httpd.apache.org%3E

>>> - x.y.0 for new features
>>> - x.y.z for bugfixes only
>>> - stop the endless backporting
>>> - make x.y.0 releases more often
>
> An issue there is the API/ABI promise.  We are a stable product, and one of 
> our
> virtues is the guarantee that a third-party module written for x.y.z will 
> continue to
> work at both source and binary level for x.y.(z+n).
>
> Frequent x.y.0 releases devalue that promise unless we extend it to x.(y+m).*,
> which would in turn push us into new x.0.0 releases, and raise new questions
> over the whole organisation of our repos.
>
> I’m not saying you’re wrong: in fact I think there’s merit in the proposal.
> But it would need a considered roadmap from here to there.

Well, one important thing to keep in mind is that a x.y.0 release
doesn't preclude the x.(y-1) series from receiving fixes. Users don't
have to update immediately if they're using third-party modules, as
there would still be bug fixes for a while, and eventually only
security fixes, before the x.(y-1) series would be fully EOL.

PHP has a very predictable timeline for this:
http://php.net/supported-versions.php

It's also worth noting that with more frequent x.y.0 releases (say,
one per year), it's likely that internal changes will be a lot smaller
and more incremental. PHP is in a similar situation to HTTPD with its
extensions system, and extensions that worked with PHP 7.0 either
compiled fine against 7.1 and later 7.2 out of the box, or required
only very few modifications.

David

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

[David Zuelke]

Remember the thread I started on that quite a while ago? ;)

IMO:

- x.y.0 for new features
- x.y.z for bugfixes only
- stop the endless backporting
- make x.y.0 releases more often
- x.y.0 goes through alpha, beta, RC phases
- x.y.z goes through RC phases

That's how PHP has been doing it for a few years, and it's amazing how
well it works, how few regressions there are, and how predictable the
cycle is (they cut an x.y.zRC1 every four weeks like clockwork, with
exceptions only around late December because of holiday season).

This would also fix all the confusing cases where two or three faulty
releases get made, end up in the changelog, but ultimately are never
released.


On Fri, Apr 13, 2018 at 5:28 PM, William A Rowe Jr  wrote:
> Terrific analysis! But on the meta-question...
>
> Instead of changing the behavior of httpd on each and every subversion bump,
> is it time to revisit our revisioning discipline and hygiene?
>
> I promise to stay out of such discussion provided that one equally stubborn
> and intractable PMC member agrees to do the same, and let the balance of the
> PMC make our decision, moving forwards.
>
> On Fri, Apr 13, 2018, 06:11 Joe Orton  wrote:
>>
>> On Thu, Apr 12, 2018 at 09:38:46PM +0200, Ruediger Pluem wrote:
>> > On 04/12/2018 09:28 AM, Joe Orton wrote:
>> > > But logged is:
>> > >
>> > > ::1 - - [12/Apr/2018:08:11:12 +0100] "GET /agag HTTP/1.1" 404 12
>> > > HTTPS=on SNI=localhost.localdomain
>> > > 127.0.0.1 - - [12/Apr/2018:08:11:15 +0100] "GET /agag HTTP/1.1" 404 12
>> > > HTTPS=- SNI=-
>> > >
>> > > Now mod_ssl only sees the "off" SSLSrvConfigRec in the second vhost so
>> > > the logging is wrong.
>> >
>> > What does the same test result in with 2.4.29?
>>
>> Excellent question, I should have checked that.  Long e-mail follows,
>> sorry.
>>
>> In fact it is the same with 2.4.29, because the SSLSrvConfigRec
>> associated with the vhost's server_rec is the same as the default/base
>> (non-SSL) server_rec, aka base_server passed to post_config hooks aka
>> the ap_server_conf global.
>>
>> So, maybe I understand this a bit better now.
>>
>> Config with three vhosts / server_rec structs:
>> a) base server config :80 non-SSL (<-- ap_server_conf/base_server)
>> b) alpha vhost :443, explicit SSLEngine on, SSLCertificateFile etc
>> c) beta vhost :443, no SSL*
>>
>> For 2.4.29 mod_ssl config derived is:
>> a) SSLSrvConfigRec for base_server = { whatever config at global scope }
>> b) SSLSrvConfigRec for alpha = { sc->enabled = TRUE, ... }
>> c) SSLSrvConfigRec pointer for beta == SSLSrvConfigRec for base_server
>>in the lookup vector (pointer is copied prior to ALWAYS_MERGE flag)
>>
>> For 2.4.33 it is:
>> a) and b) exactly as before
>> c) separate SSLSrvConfigRec for beta = { merged copy of config at global }
>>time because of the ALWAYS_MERGE flag, i.e. still sc->enabled = UNSET
>>
>> When running ssl_init_Module(post_config hook), with 2.4.29:
>> - SSLSrvConfig(base_server)->enabled = FALSE because UNSET previously
>> - SSLSrvConfig(base_server)->vhost_id gets overwritten with vhost_id
>>   for beta vhost because it's later in the loop and there's no check
>>
>> And with 2.4.33:
>> - SSLSrvConfig(beta)->enabled is UNSET but gets flipped to ENABLED,
>>   then startup fails (the issue in question)
>>
>> w/my patch for 2.4.33:
>> - SSLSrvConfig(beta)->enabled is FALSE and startup works
>>
>> At run-time a request via SSL which matches the beta vhost via SNI/Host:
>>
>> For 2.4.29:
>> - r->server is the beta vhost and mySrvConfig(r->server) still gives
>>   you the ***base_server*** SSLSrvConfigRec i.e. sc->enabled=FALSE
>> - thus e.g. ssl_hook_Fixup() does nada
>>
>> For 2.4.33 plus my patch:
>> - r->server is the beta vhost and mySrvConfig(r->server) gives
>>   you the SSLSrvConfigRec which is also sc->enabled = FALSE
>> - thus e.g. ssl_hook_Fixup() also does nada
>>
>> I was trying to convince myself whether mySrvConfig(r->server) is going
>> to change between 2.4.29 and .33+patch in this case, and I think it
>> should be identical, because it is *only* the handling of ->enabled
>> which has changed with _ALWAYS_MERGE.
>>
>> TL;DR:
>> 1. my head hurts
>> 2. I think my patch is OK
>>
>> Anyone read this far?

Re: 2.4.27

[David Zuelke]

You need to use SetHandler. You can't use rewrites with ProxyPass because of 
the order of evaluation.

Example config:

Define php-fpm unix:/tmp/php-fpm.sock|fcgi://php-fpm
# make sure the proxy is registered with the unix socket; we can then use just 
"fcgi://php-fpm" in proxy and rewrites directives
# we have to do this because we can't rewrite to a UDS location and because PHP 
doesn't support the unix:...|fcgi://... syntax
# this is also a lot more convenient for users
# http://thread.gmane.org/gmane.comp.apache.devel/52892

# we must declare a parameter in here or it'll not register the proxy ahead 
of time
# min=0 is an obvious candidate since that's the default value already and 
sensible
ProxySet min=0


# pass requests to .php files to mod_proxy_fcgi
# this requires Apache 2.4.10+ and PHP 5.5.15+ to work properly

 # make sure the file exists so that if 
not, Apache will show its 404 page and not FPM
SetHandler proxy:fcgi://php-fpm




You can then simply rewrite to index.php etc, and it'll work.

Further questions should be taken to the users list though, as this one here is 
for development of httpd...


> On 17. Jul 2017, at 19:25, Helmut K. C. Tessarek  wrote:
> 
> On 2017-07-17 03:50, Luca Toscano wrote:
>> mod-proxy-fcgi is the preferred solution over mod-fcgi, and we have
>> documentation about it. Any specific reason to use libapache2-mod-fcgid?
>> (asking for curiosity and/or to decide if a doc update is needed :)
> 
> I am using mod_proxy_fcgi exactly for that reason (stated on
> https://wiki.apache.org/httpd/php). But the documentation
> (https://wiki.apache.org/httpd/PHP-FPM) is IMO a bit off.
> 
>> Can you please be more specific? What errors do you see? In case please
>> open a task in bugzilla so we'll be able to debug it :)
> 
> Even according to the documentation for mod_proxy_fcgi, UDS does not
> support connection reuse.
> In my case it broke POST requests. I then googled and found a bunch of
> articles and stackexchange entries that suggested to remove the
> enablereuse=on option from the Proxy section.
> 
> Only after removing the Proxy directive completely, everything started
> to work as expected.
> 
> Except from the mod_rewrite issue I experience. I'm still debugging it,
> but mod_rewrite behaves differently between mod_php and mod_proxy_fcgi,
> which should not happen at all, since rewrite shouldn't care or know
> about the backend. I also googled and found a few entries, none of which
> helped me:
> 
> https://stackoverflow.com/questions/44054617/mod-rewrite-in-2-4-25-triggering-fcgi-primary-script-unknown-error-in-php-fpm
> 
> http://www.coders.pro/2017/01/qq-htm/
> 
>>Using ProxyPassMatch is not only dangerous, it also has precedence over
>>a FilesMatch directive, which in turn limits your ability to restrict
>>access to certain resources. At least that was the case a couple of
>>years back.
>> 
>> Dangerous in what way? Can you please be more specific and/or add examples?
> 
> I'm sorry, my bad. I should not have generalized it. ProxyPass and
> ProxyPassMatch _can_ be dangerous. I see 2 main issues:
> 
> 1) The match part can be set too wide, which could allow php-fpm to
> interpret the wrong file.
> 
> 2) The documentation also states:
> Warning: when you ProxyPass a request to another server (in this case,
> the php-fpm daemon), authentication restrictions, and other
> configurations placed in a Directory block or .htaccess file, may be
> bypassed.
> 
> So ProxyPass has precedence over other directives. It is evaluated
> first. This can lead to a number of problems.
> Anyway, as long as you are aware of it, the impact can be minimized. Yet
> I believe it is too dangerous for the average Joe.
> 
> -- 
> regards Helmut K. C. Tessarek  KeyID 0xF7832007C11F128D
> Key fingerprint = 28A3 1666 4FE8 D72C CFD5 8B23 F783 2007 C11F 128D
> 
> /*
>   Thou shalt not follow the NULL pointer for chaos and madness
>   await thee at its end.
> */

Re: 2.4.27

[David Zuelke]

On 10. Jul 2017, at 16:04, Reindl Harald  wrote:
> 
> Am 06.07.2017 um 19:28 schrieb Jacob Champion:
>> Administrators using prefork who would like to switch to HTTP/2 in the 
>> future need to understand the limitations of the prefork architecture they 
>> have selected. And sure, our users can request that we implement a solution 
>> that "just works" with prefork, with the parent dispatcher that Stefan has 
>> mentioned, and we can weigh the cost/benefit of implementing it. But IMO 
>> it's not that onerous to ask our users to upgrade to a modern MPM if they 
>> want a nice new protocol
> 
> well, when i see how fragile the combination of httpd and php-fpm still is, 
> thanks, but no
> 
> Apache:
> COMPATIBILITY: mod_proxy_fcgi: Revert to 2.4.20 FCGI behavior for the default 
> ProxyFCGIBackendType, fixing a regression with PHP-FPM. PR 61202
> 
> PHP:
> Fixed bug #74738 (Multiple [PATH=] and [HOST=] sections not properly parsed).
> https://bugs.php.net/bug.php?id=74738

That PHP bug affects parsing of PHP-FPM's config file. It has nothing to do 
with the FastCGI interface or its runtime behavior.

Re: Summary: Broken FastCGI with httpd

[David Zuelke]

On 26.01.2017, at 18:03, Jim Jagielski  wrote:
> 
> As of HEAD on trunk, configs with the below seem to
> work as expected:
> 
>   AddType application/x-php7-fpm .php
>   Action application/x-php7-fpm /fpm virtual
>   
>SetHandler proxy:fcgi://localhost:9001
>   
> 
> --
> 
>   
> SetHandler "proxy:fcgi://localhost:9001
>   
> 
> What other scenarios should we be looking at?

Maybe add tests for "proxy:unix:/path/to/fpm.sock|fcgi://dummy", and balancers 
as well?

Re: Summary: Broken FastCGI with httpd

[David Zuelke]

On 26.01.2017, at 06:16, Eric Covener <cove...@gmail.com> wrote:
> 
> On Wed, Jan 25, 2017 at 6:12 PM, David Zuelke <d...@heroku.com> wrote:
>>>  AddType application/x-php7-fpm .php
>>>  Action application/x-php7-fpm /php7-fpm virtual
>>>  
>>>SetHandler proxy:fcgi://localhost:9000
>>>  
>>> 
>>> setup. This shows what the httpd conf looks like...
>>> can you provide a barebones fpm setup?
>>> 
>>> Thx!
>> 
>> Just curious; what's the practical difference between that and something 
>> like:
>> 
>> 
>> # make sure the file exists so that if not, 
>> Apache will show its 404 page and not FPM
>>SetHandler proxy:fcgi://…
>>
>> 
> 
> I think only the former would pass the original requested path as
> PATH_INFO, unless there was more config w/ the latter (e.g. sending
> everything to some single front controller so this snippet always sees
> index.php)

Appears to depend on the rewrite (all of these with 2.4.18, SetHandler, and 
cgi.fix_pathinfo=1):

GET index.php/ohai:

$_SERVER['PATH_TRANSLATED'] redirect:/index.php/ohai
$_SERVER['PATH_INFO']   /ohai
$_SERVER['SCRIPT_NAME'] /index.php
$_SERVER['REQUEST_URI'] /index.php/ohai
$_SERVER['SCRIPT_FILENAME'] /app/index.php

RewriteRule ^(.+)$ index.php/$1 [L], GET /ohai:

$_SERVER['PATH_TRANSLATED'] redirect:/index.php/ohai
$_SERVER['PATH_INFO']   /ohai
$_SERVER['SCRIPT_NAME'] /index.php
$_SERVER['REQUEST_URI'] /ohai
$_SERVER['REDIRECT_URL']/ohai
$_SERVER['SCRIPT_FILENAME'] /app/index.php

RewriteRule ^ index.php [L], GET /ohai:

$_SERVER['SCRIPT_NAME'] /index.php
$_SERVER['REQUEST_URI'] /ohai
$_SERVER['REDIRECT_URL']/ohai
$_SERVER['SCRIPT_FILENAME'] /app/index.php

Last case is missing PATH_INFO and PATH_TRANSLATED. That's what many PHP 
frameworks (e.g. Laravel or Symfony) use, and I think they pull the URL 
straight from REQUEST_URI now.

David

Re: Reset out x.minor.z definition of 'minor' at httpd?

[David Zuelke]

On 20.01.2017, at 21:37, Graham Leggett <minf...@sharp.fm> wrote:
> 
> On 20 Jan 2017, at 7:47 PM, David Zuelke <d...@heroku.com> wrote:
> 
>> I'd actually like to question the whole practice of porting features back to 
>> older branches. I think that's the core reason why trunk is in total 
>> disarray, and why no substantial releases have been made. There is just no 
>> reason for anyone to push forward the state of 2.6 or even 3.0 if you can 
>> just backport whatever you want.
> 
> The reason this is bad is because Apache httpd comes with a module ecosystem 
> - when you move from httpd v2.0 to v2.2 to v2.4 to v2.6, or rules are that 
> the ABI can break, and therefore all modules that depend on that version must 
> be recompiled. This includes modules that are closed source and offered by a 
> proprietary vendor, or are open source but provided in binary form by a 
> distro.

Yeah, I hadn't considered proprietary modules.

To take the PHP example, ABI and API changes are usually minimal, so most 
extensions build pretty cleanly; if not, then they can be fixed, and with most 
stuff on GitHub these days, that's usually a PR away. Development cycles of 
extensions have definitely sped up together with the language runtime.

Do people who run a non-distro httpd really install distro-provided modules 
though?


> Right now, you can get new features on the httpd v2.4 branch, but ONLY if 
> that feature does not break existing behaviour in any way. This is entirely 
> reasonable, convenient, and what we’ve been doing since the 1990s.
> 
>> Just define 2.4 as "bug fixes only" the moment 2.6 is released, and start 
>> the process of getting 2.6 out ASAP. In fact, why not declare 2.4 that right 
>> now? It's already "stable". It doesn't need more features that suddenly 
>> change behavior from 2.4.28 to 2.4.29 or whatever (that's the opposite of 
>> what users are looking for).
>> 
>> That's how PHP does it now... new features can go into x.y.0, and once that 
>> is released (actually, once it's in beta stage), anything that is not a 
>> small fix needs to wait for x.y+1.0 or x+1.0.0. Which is not a big deal 
>> because these releases land every year now, like clockwork.
> 
> So you have to wait a year for new features to see a release? Definitely not 
> keen on that.

Yeah, new features as in new functions, or new language constructs. Useful, 
because it makes for a consistent API in userland for x.y release series. Not 
applicable to httpd as a model, I'm sure.

> 
>> I have said this in the other thread that hasn't gotten much traction ("A 
>> new release process?"). The PHP team was in the exact same spot as HTTPD a 
>> few years ago. No substantial progress, stale branches, no light at the end 
>> of the tunnel, and a lot of fighting.
> 
> We’ve had a significant amount of progress, a trunk that is so stable that 
> almost all fixes and features can be backported to v2.4 without any fear of 
> incompatibility, and the “fighting” is limited to very few individuals.

Alright :)

My calling of trunk as being in "disarray" was also due to some people often 
vocally complaining about stale or half-done features that have been in there 
for (allegedly) years, without a backport etc. Didn't mean it as an insult to 
anyone!

David

Re: Summary: Broken FastCGI with httpd

[David Zuelke]

On 25.01.2017, at 20:12, Jim Jagielski  wrote:
> 
> Can you provide to me a pgp-fpm.conf that you use... Basically,
> I want to create an environ that exactly uses the
> 
>   AddType application/x-php7-fpm .php
>   Action application/x-php7-fpm /php7-fpm virtual
>   
> SetHandler proxy:fcgi://localhost:9000
>   
> 
> setup. This shows what the httpd conf looks like...
> can you provide a barebones fpm setup?
> 
> Thx!

Just curious; what's the practical difference between that and something like:


 # make sure the file exists so that if not, 
Apache will show its 404 page and not FPM
SetHandler proxy:fcgi://…



?

David

Re: Summary: Broken FastCGI with httpd

[David Zuelke]

On 24.01.2017, at 01:24, Jim Jagielski  wrote:
> 
> 
>> On Jan 23, 2017, at 4:35 PM, Jacob Champion  wrote:
>> 
>> 
>> What situations lead to CONTENT_TYPE being set to a PATH_INFO delimiter? I'm 
>> not sure what this is supposed to do.
>> 
> 
> The *idea* was to look for ".php" in the actual URL for example :)

It doesn't have to be ".php" for PHP to be able to run it. You can execute any 
file extension (that sometimes requires fiddling with settings, e.g. with 
PHP-FPM, but still).

David

Re: Reset out x.minor.z definition of 'minor' at httpd?

[David Zuelke]

> On 20.01.2017, at 15:34, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> 
> On Thu, Jan 19, 2017 at 6:12 PM, David Zuelke <d...@heroku.com> wrote:
>> I don't know any framework/language/library out there that handles it that 
>> strictly. Nginx, or Ruby, or PHP, or whatever...
>> 
>> From x.y.z to x.y.z+1, retain full compatibility.
>> 
>> From x.y.z to x.y+1.0, keep external API compatibility, break ABI if needed, 
>> break internal API if absolutely needed
>> 
>> From x.y.z to x+1.0.0, break anything you want.
>> 
>> One issue IMO is that there are a lot of things in flight for 2.6 and 3.0, 
>> and some of these are features, while other are big architectural overhauls. 
>> The former are for 2.6, and the latter very clearly belong into 3.0. There's 
>> no reason why both can't be worked on concurrently.
> 
> That's what I'm proposing... a model where x.y.[0-#] releases remain 
> consistent,
> like all the packages you mention above, and unlike httpd.
> 
> I liked your highlight of "if [absolutely] needed". That's where our
> trunk (2.next)
> has spent four years diverging from 2.current, mostly unnecessarily.
> 
> The fact that the code *could* be backported to 2.4.x (in your PHP and Ruby
> examples, such backports aren't even acceptable) means that it *could* have
> stayed consistent on our 2.next trunk.

I'd actually like to question the whole practice of porting features back to 
older branches. I think that's the core reason why trunk is in total disarray, 
and why no substantial releases have been made. There is just no reason for 
anyone to push forward the state of 2.6 or even 3.0 if you can just backport 
whatever you want.

Just define 2.4 as "bug fixes only" the moment 2.6 is released, and start the 
process of getting 2.6 out ASAP. In fact, why not declare 2.4 that right now? 
It's already "stable". It doesn't need more features that suddenly change 
behavior from 2.4.28 to 2.4.29 or whatever (that's the opposite of what users 
are looking for).

That's how PHP does it now... new features can go into x.y.0, and once that is 
released (actually, once it's in beta stage), anything that is not a small fix 
needs to wait for x.y+1.0 or x+1.0.0. Which is not a big deal because these 
releases land every year now, like clockwork.

I have said this in the other thread that hasn't gotten much traction ("A new 
release process?"). The PHP team was in the exact same spot as HTTPD a few 
years ago. No substantial progress, stale branches, no light at the end of the 
tunnel, and a lot of fighting.

A structured release process fixed all that.

David

Re: Alternate versioning proposal: patch line releases

[David Zuelke]

On 20.01.2017, at 02:00, Eric Covener  wrote:
> 
> On Thu, Jan 19, 2017 at 6:49 PM, Jacob Champion  wrote:
>> We branch off from the 2.4.25 tag. This is our low-risk 2.4.25.x patch line.
>> There are no new features or large code changes to this branch, there are no
>> refactorings or whitespace changes or huge cleanups; the only changes that
>> land here are targeted bug fixes to 2.4.25.
> 
> My fear here is that nearly nobody would ever end up using these patch
> line releases, but we'd probably never know for sure.

Or adopt them, but never move off them,

And the other question then becomes... for how long will that particular patch 
version receive updates? Or even backports of fixes that are much harder than 
in a newer version? How many patch release series are allowed to exist at the 
same time?

Etc etc. I think this would turn into a huge burden, and cause confusion for 
users.

Re: Reset out x.minor.z definition of 'minor' at httpd?

[David Zuelke]

I don't know any framework/language/library out there that handles it that 
strictly. Nginx, or Ruby, or PHP, or whatever...

From x.y.z to x.y.z+1, retain full compatibility.

From x.y.z to x.y+1.0, keep external API compatibility, break ABI if needed, 
break internal API if absolutely needed

From x.y.z to x+1.0.0, break anything you want.

One issue IMO is that there are a lot of things in flight for 2.6 and 3.0, and 
some of these are features, while other are big architectural overhauls. The 
former are for 2.6, and the latter very clearly belong into 3.0. There's no 
reason why both can't be worked on concurrently.


> On 19.01.2017, at 22:43, William A Rowe Jr  wrote:
> 
> I think one of our disconnects with 2.4 -> 2.6 is that in any other
> framework, there would be no ABI breakage in 2.6. That breakage
> would be deferred to and shipped as 3.0.
> 
> The httpd project choose to call 2.minor releases as breaking
> changes. Due to poor design choices, or frequent refactorings,
> this essentially shifted our release numbering schema down one
> digit. So 2.6.0 is not an enhancement release, but a major release
> in the general understanding of these things. This might be the root
> of Jim's and my failure to come to any consensus.
> 
> Right now, there are a number of gratuitous breaking changes on trunk
> that change binary ABI. I'm considering a trunk fork to preserve these
> changes (branches/3.x-future/?) and reverting every change to trunk/
> which was otherwise a no-op. Namespace, decoration, anything that
> prevents a user from loading a 2.4.x module in 2.next. And then we
> can look at what is a valid reason to take us to 3.0.
> 
> There might be some minor breakage that requires a recompilation,
> such as a user module allocating a req_rec. That is solved by setting
> a showstopper to the 2.next release to introduce _create() accessors
> to every structure belonging to the httpd API.  There would be side
> determinations... would we institute such a  change with the release
> of 2.5, or 2.6, or 3.0?
> 
> Once this is complete, binary breaking ABI changes would live in
> their own feature development forks. They would never be folded
> into trunk until there was a group consensus to push forward to
> version next.0.0 in the immediate future. trunk/ would cease to be
> a sandbox of ideas unready for release.
> 
> It's likely a couple-week process that I can't start till the end of next
> week. But I think the frustration about not being able to ship new
> features has a lot to do with our history of breaking API's every time
> we ticked up the version minor number.
> 
> It might be that we won't end up shipping 2.6 because other good
> and necessary binary-breaking-changes occur between now and
> in the near future, or that these exist on trunk. But if we defer the
> gruntwork of renaming things and whitespace mop-up etc until
> a short several-week period prior to the actual major.0.0 release,
> then we can keep trunk/ in a much more releasable state for all
> the new features.
> 
> We may have the impetus for a 3.0 release in the near future, we
> may not, but I'm sure the idea that 2.5 is a 'major' ABI-breaking
> release is not serving us well.

Re: Alternate versioning proposal: patch line releases

[David Zuelke]

Please no .micro releases. Most of the world is now trying to stick to 
http://semver.org principles.

Why not just keep 2.4 for maintenance, and start working on 2.6 immediately? Or 
2.5?

I honestly think that the current "odd numbers are unstable" approach is not 
helpful with this whole situation. That's what betas and RCs are for, and that 
gets you a more regular cadence in releases, which helps with overall velocity.

HTTPD could even adopt a Debian/Ubuntu like policy, where there is a new 
2.next.0 every year or two, and whatever doesn't make the cut-off date has to 
wait until the following iteration. That's been working really well for PHP in 
recent years, too.

All this proposal does, IMO, is just move the whole problem one decimal point 
to the right.


On 20.01.2017, at 00:49, Jacob Champion  wrote:
> 
> This is somewhat orthogonal to Bill's current suggestion. It solves a 
> different set of problems, more related to the short-term 
> features-versus-regressions argument and less related to the long-term ABI 
> arguments. Both are important to me, and I agree with many pieces of what 
> both Jim and Bill are saying.
> 
> (This is a combination of a bunch of different ideas from different people, 
> on this list and off, so thank you all for discussing.)
> 
> == Proposal ==
> 
> We branch off from the 2.4.25 tag. This is our low-risk 2.4.25.x patch line. 
> There are no new features or large code changes to this branch, there are no 
> refactorings or whitespace changes or huge cleanups; the only changes that 
> land here are targeted bug fixes to 2.4.25.
> 
> 2.4.25.x is on a cadence: it's T'd like clockwork every month. Releases 
> from that line still follow the necessary voting procedure. Meanwhile, once 
> we decide we have enough new features for 2.4.26, we T that. If 2.4.26 
> releases, and we decide we need some fixes, we spin up a 2.4.26.x branch and 
> move to a cadence on it.
> 
> Requirements for a backport to the new low-risk 2.4.25.x branch:
> - Your change must have landed in 2.4.x.
> - Your change must be linked to a PR for a bug/regression.
> - Your change is the smallest/simplest fix necessary (for some definition of 
> small/simple that your fellow voters agree with).
> - You must have a test (or set of tests) committed to the test suite that 
> proves this change fixes the bug. (I.e. it fails before the change and 
> succeeds afterwards.)
> 
> Three votes are still required, and the commits to the test suite are part of 
> the voting review. If you can convince three other people that a test is not 
> worth the effort, you can override this requirement with an additional vote 
> (four total).
> 
> == Why? ==
> 
> The even-versus-odd, features-versus-regression idea seemed to have some 
> traction, but it means that fixes block features during an even release and, 
> to a certain extent, vice-versa during an odd release.
> 
> In this proposal, you have to really be serious about a bug fix to get it 
> into the patch line -- a double backport plus a mandatory addition to the 
> test suite -- but you're rewarded by knowing that your change *will* be T'd 
> within the month. And the next feature release won't be blocked on fixes.
> 
> It gives us some emergency flexibility too. God forbid, say the 2.4.26 
> release introduces some absolute mayhem, we're deadlocked on some breaking 
> change or massive argument, users don't want to move to 2.4.26 and things are 
> going nowhere fast for 2.4.27. Fine. 2.4.25.x is still alive as long as there 
> are enough PMC members interested in releasing from it; the cadence only ends 
> when we decide it does. The downside is that we then have two parallel 
> "latest" versions for 2.4.x, but if you can convince three PMC members that 
> this situation is better than being frozen, so be it.
> 
> End users and maintainers should eventually feel, once we work out the kinks, 
> that the risk of upgrading to 2.4.x.y is never more than the risk of 
> upgrading to 2.4.x was. We should feel like our releases are never frozen, 
> even if we disagree about some major new feature -- we can always fix stuff 
> for users while we argue. The test suite will grow as long as patch lines are 
> released. And if it gets good enough, some day far in the future, patch lines 
> will become less and less necessary.
> 
> Thoughts?
> 
> --Jacob

Re: Summary: Broken FastCGI with httpd

[David Zuelke]

On 19.01.2017, at 19:00, Jacob Champion  wrote:
> 
> On 01/18/2017 01:00 PM, Jim Jagielski wrote:
>> After all, it's easier for the FCGI server to know the SCRIPT_NAME
>> than httpd to "guess"...
> 
> I think the recent breakage calls this assumption into question. The server 
> admin knows exactly where the scripts are in the use cases we're currently 
> discussing; why should the backend have to "know" anything in those 
> situations?
> 
> It's worth noting that letting PHP try to split apart SCRIPT_FILENAME on its 
> own has led to security issues in the past [1,2]. They were mitigated by 
> other means on the PHP side, I believe, but we can avoid recurrences in 
> future FCGI implementations.
> 
>>> On Jan 18, 2017, at 2:01 PM, Jacob Champion  wrote:
>>> We only get QUERY_STRING right. (Well, I won't say SCRIPT_FILENAME is 
>>> "wrong", since there is no standard definition, but it's not helpful.) 
>>> SCRIPT_NAME is supposed to point to a possible script-path (see RFC 3875 
>>> for definitions), '/hello.php' in this instance. PATH_INFO and 
>>> PATH_TRANSLATED should not include 'hello.php' in their values.
>> 
>> That is because we have no idea what SCRIPT_NAME is...
> 
> One way to approach unknowns is to have httpd and/or the backend guess at 
> things; another way (that we can't start doing until a version-bump release) 
> is to refuse to send back a FastCGI request unless we know exactly what these 
> variables should be. That lets the user fix the issue and gain a better 
> understanding of what is going on, instead of relying on us and the backend 
> to perform magic together during the correct phase of the moon.
> 
>> With the "guess" that
>> it is /php7-fpm, then PATH_INFO kind of makes sense, since it is
>> the portion of the URI following the script. And considering
>> that we use
>> 
>>   Action application/x-php7-fpm /php7-fpm virtual
>> 
>> the 2nd parameter is specifically noted as *being the cgi-script* and
>> so of course httpd assumes that /php7-fpm is SCRIPT_NAME, because
>> we explicitly called it that :)
> 
> Fine by me. So then, in my opinion, it seems like one part of moving forward 
> should be to deprecate the use of Action to invoke script multiplexers like 
> PHP-FPM, and document accordingly. I.e. if you're not redirecting to *the 
> script*, as in standard CGI, no Action for you.
> 
> (That explicitly deprecates the mod_fastcgi model for use with PHP-FPM, which 
> would also be fine by me. I don't like the way it couples the public 
> URI-space to an implementation detail.)
> 
> Are there similar arguments for the variable values discussed in PR 51517? It 
> used ProxyPassMatch, not Action, for its implementation.

ProxyPassMatch has its own set of problems in combination with rewrites in e.g. 
.htaccess. The only method that I've found works reliably with any .htaccess 
rule that also works with e.g. mod_php is through SetHandler in 2.4.10+.


>> Would it make sense, mostly from a PHP point-of-view, to send
>> something like SCRIPT_FILENAME_RAW (or even
>> APACHE_SCRIPT_FILENAME)... Or does that simply complicate an already
>> fuzzy and nebulous situation?
> 
> I think it probably makes things worse. It's just one more non-standard 
> variable for us to maintain and backends to manipulate.

Agreed


>> Is [1] being used as the canonical place for this discussion w/ the
>> PHP Group?
>> 
>> 1. https://github.com/php/php-src/pull/694#issuecomment-271963956
> 
> I'm not sure if there is a canonical place yet...
> 
>http://news.php.net/php.internals/97810
> 
> is another possibility, if the conversation is picked up.

Yeah, not much interest yet, sorry :( Jim, I think you have a php.net account; 
are you also on that mailing list and can chime in?


> --Jacob
> 
> [1] https://forum.nginx.org/read.php?2,88845,88845#msg-88845
> [2] https://bugs.php.net/bug.php?id=55181
>(can't find a CVE right now, sorry)
> 

Re: Summary: Broken FastCGI with httpd

[David Zuelke]

> On 17.01.2017, at 23:16, Jacob Champion  wrote:
> 
> (This conversation is currently spread over Bugzilla, IRC, GitHub, and 
> php-internals. Here's my attempt at summarizing it for all of you. If you 
> have no interest in CGI or FastCGI, stop reading now.)

Thanks for picking this up!


> 2) Define what SCRIPT_FILENAME means.
> 
> SCRIPT_FILENAME isn't actually a CGI 1.1 standard variable. We appear to have 
> defined it as "whatever r->filename contains", so we've effectively coupled 
> our implementation details to external clients. PHP-FPM and fcgiwrap, for 
> example, assume that SCRIPT_FILENAME should point to the script that should 
> be executed to handle the request. We need to standardize it.

There's one more caveat around SCRIPT_FILENAME, I think: it might not be the 
same for httpd and the FCGI backend if they're running on separate machines!

David

Re: Post 2.4.25

[David Zuelke]

On 31 Dec 2016, at 00:09, Stefan Fritsch  wrote:
> * the longer 2.6/3.0 takes the more half-baked/half-finished stuff 
> accumulates 
> that needs to be fixed before a release.
> 
> But I don't have any ideas how to resolve this.

Did you see my "A new release process?" thread? :)

A new release process?

[David Zuelke]

Hi everyone,

Given the several current threads where there's arguing about what and how and 
when to release features, backported or not, I'd like to offer a tale of a 
project that was, more or less, in the same dire spot, and pulled itself out of 
that misery with great success and universal acclaim.

That project is PHP.

Back in 2010, it was stuck at version 5.3.something, there was no standards 
around what feature goes into a minor release, how a feature is even accepted 
for inclusion, how security updates were treated, and so forth.

Enter: https://wiki.php.net/rfc/releaseprocess

The tl;dr of this approach is that

- any x.y.z release only introduces bugfixes. These releases are done every 
four weeks, like clockwork. If a fix doesn't make the cut for a release, it'll 
end up in the next one;
- x.y.0 releases, on the other hand, may introduce new features, fixes, and 
deprecations, but no breaking changes;
- x.0.0 releases are the big ones (think PHP 7.0.0 in late 2015). where 
backward compatibility may be changed, etc.

This makes for very predictable update cycles, and for pretty easy updating, as 
it's very very unusual that a x.y.z release breaks existing behavior. At the 
same time, since x.y.0 releases are made roughly once a year, bigger changes do 
not exist in a limbo branch forever, but will see the light of day eventually 
(and, again, after a predictable amount of time). There is a defined roadmap 
with active/security maintenance status and EOL dates for all versions; see 
http://php.net/supported-versions.php

From a user perspective, this change has been fantastic. Once virtually 
stagnant, development of the language itself has been much more active; users 
have a much better idea up front around when fixes or features will land; 
upgrades have become easy as there are clear definitions of what kind of 
changes a version may contain.

But most importantly, the language itself has seen a steady flow of new 
features as a result from this discipline. For features and bigger changes, an 
RFC is written with rationale, analysis, suggestion of implementation, and then 
it can be voted on. Once accepted, it can be committed, reviewed, and merged. 
Even for "outside" contributors, this process is transparent, and the mental 
threshold towards contribution has been lowered greatly, as acceptance of an 
RFC basically means that the feature will go into a new release anywhere 
between within a few months and a year and a bit (depending on when in the 
release cycle it happens).

There are a bunch of technicalities that would need adjusting to fit HTTPD, 
such as release intervals, release management (for PHP, every x.y.* series has 
two managers who jointly coordinate releases), etc, but overall the idea is, 
IMO, worth considering.

As a, more or less, "outside observer", I happen to think that the current 
method of voting on finals, instead of a practice of rolling out RCs (that are 
then left up for testing for at least a week), is fundamentally broken. The 2.4 
changelog in particular is littered with releases that were never officially 
published. For users, that's really confusing. For maintainers, it's painful to 
start over the process each time, and it sometimes leads to months and months 
without a release that contains certain fixes. Then a backport goes wrong 
(still using SVN, in my opinion, does not help there, but that's a whole 
different discussion :)), and a regression is in the latest release until 
someone eventually picks up a fix. 

Much of this, and many of the "what do we backport from trunk" and "I'd like to 
squeeze in a change I've had sitting around locally, please wait with the new 
release, because who knows when the next one after that will be" are, from what 
I can tell, a significant source of discord on this mailing list. All these 
unnecessary distractions that deteriorate personal relationships, while at the 
same time slowing down the pace of the project (several people have already 
pointed out Nginx's rate of innovation in comparison) and raising the threshold 
for contributions, can be fixed. PHP is the perfect example, and I think HTTPD 
would be wise to at least consider following this example.

Happy New Year!

David

Re: 2.4.24 soon?

[David Zuelke]

On 21.07.2016, at 16:27, Eric Covener  wrote:

> We have httpoxy as well as a rewrite+fastcgi regression in the queue.
> Jim, do you have a near-term release in you we can plan around?

Just to *bump* this one up... ;)

David

Re: 2.4.18?

[David Zuelke]

On 18.11.2015, at 08:11, Noel Butler  wrote:

> absolutely not! I personally only update  phpmyadmin once, on initial major 
> release, because I (like many others) were so of updating it every few days .

> You obviously dont manage very many public facing servers then, I have that 
> advantage of looking at it from both sides, when I do testing - I test based 
> on what sys admins want.

Please don't make your inability to quickly roll out updated versions my 
problem.

I want SO_REUSEPORT for my users, but with the REDIRECT_URL regression, I am 
stuck on 2.4.16.

You're always free to skip a release, so what's the issue?

Re: mod_proxy: PHP SCRIPT_FILENAME (PHP-FPM using UDS) and Apache documentation

[David Zuelke]

You should not append the trailing slash. REQUEST_URI gets appended, hence the 
double slash.


On 10.09.2014, at 10:26, Martynas Bendorius marty...@martynas.it wrote:

 Yes, I've tried their latest versions from GIT (with the #65641 fix (PHP-FPM 
 incorrectly defines the SCRIPT_NAME variable when using Apache)).
 
 It still has the same problem with SCRIPT_FILENAME. Is there a special reason 
 why / is required at the end? As it doesn't seem to break anything when the 
 trailing slash is omitted from the end.
 
 Thank you!
 
 Best regards,
 Martynas Bendorius
 
 On 9/10/14 8:17 PM, Jim Jagielski wrote:
 I know that PHP is current doing a LOT of fixes on
 hPHP-FPM...
 
 On Sep 10, 2014, at 12:00 PM, Martynas Bendorius marty...@martynas.it 
 wrote:
 
 Hello,
 
 http://httpd.apache.org/docs/current/mod/mod_proxy.html#handler breaks 
 PHP-FPM SCRIPT_FILENAME. It contains double // at the beginning of it 
 like:
 SCRIPT_FILENAME: //home/admin/domains/testing.tld/public_html/test.php
 
 While it should be:
 SCRIPT_FILENAME: /home/admin/domains/testing.tld/public_html/test.php
 
 Replacing localhost/ to just localhost fixes the problem (removing / 
 from the end).
 
 I mean:
 SetHandler  proxy:unix:/path/to/app.sock|fcgi://localhost
 
 Instead of:
 SetHandler  proxy:unix:/path/to/app.sock|fcgi://localhost/
 
 Should it be considered a typo in Apache documentation or a bug in the way 
 PHP-FPM SAPI translates the path?
 
 Thank you!
 
 --
 Best regards,
 Martynas Bendorius
 
 

Re: FYI: Looking for a release of 2.4.x soonish

[David Zuelke]

UDS have been supported since 2.4.8, see 
https://issues.apache.org/bugzilla/show_bug.cgi?id=54101#c21


On 08.07.2014, at 11:22, Yonah Russ yonah.r...@gmail.com wrote:

 Hi,
 Is there any update on this?
 What is the status of 
 https://issues.apache.org/bugzilla/show_bug.cgi?id=54101#c1 ?
 Will the UDS patch make it into this release?
 
 Thanks,
 Yonah
 
 
 On Wed, Jun 25, 2014 at 1:05 AM, Yann Ylavic ylavic@gmail.com wrote:
 On Tue, Jun 24, 2014 at 8:40 PM, Jim Jagielski j...@jagunet.com wrote:
  I'm hoping to encourage us to push out the next 2.4 release within
  the next coupla weeks, maybe after the July 4th US-based
  holiday.
 
  Comments?
 
 +1, thanks!
 

Backport SetHandler for reverse proxies to 2.4.x?

[David Zuelke]

Hi all,

is there any chance to get 
http://svn.apache.org/viewvc?view=revisionrevision=1573626 merged into 2.4.x 
as well, for 2.4.10?

Would be pretty handy for a lot of people; it's a lot easier to use than 
rewrites or ProxyPass(Match) directives.

David