Keep Server Online
If you find the Apache Lounge, the downloads and overall help useful, please express your satisfaction with a donation.
or
A donation makes a contribution towards the costs, the time and effort that's going in this site and building.
Thank You! Steffen
Your donations will help to keep this site alive and well, and continuing building binaries. Apache Lounge is not sponsored.
| |
|
Topic: httpd.conf - (copy old or edit new after upgrade) |
|
| Author |
|
solorize
Joined: 16 Nov 2019 Posts: 4 Location: UK, London
|
Posted: Sun 04 Jun '23 14:49 Post subject: httpd.conf - (copy old or edit new after upgrade) |
|
|
Hi, hopefully this is an easy question.
Every time I upgrade Apache webserver I take a copy
of my current HTTP.CONF file, and then once the
updated version of Apache webserver has been installed.
I then go through and edit the new HTTP.CONF file
to replicate the code that I had in my previous file
(which has customised edits to the code, that I have made).
What I would like to know is; am a wasting my time doing
this, when I could just copy my current HTTP.CONF file
over the new one?
Or
Could the new HTTP.CONF file have additional / modified code
that the older version may not have? So would not be recommended
for me to do this and would always be best to just edit the new file
after and update, to avoid possible problems.
Thanks in advance |
|
| Back to top |
|
mrdj1024
Joined: 03 Apr 2023 Posts: 92 Location: Bridgeton,NJ,USA
|
Posted: Mon 05 Jun '23 4:14 Post subject: |
|
|
keep the old one
those rarely change. |
|
| Back to top |
|
DnvrSysEngr

Joined: 15 Apr 2012 Posts: 229 Location: Denver, CO USA
|
Posted: Mon 05 Jun '23 6:52 Post subject: |
|
|
I second that. I keep my old Conf folder as it has everything just the way I want/need it. I may peruse the Conf folder that comes with the new build that I just downloaded, but 99.9% of the time there is nothing new / important / relevant in the Conf folders for my setup.
FWIW - Same holds true for NGinx conf files. |
|
| Back to top |
|
James Blond Moderator

Joined: 19 Jan 2006 Posts: 7476 Location: EU, Germany, Next to Hamburg
|
Posted: Mon 05 Jun '23 8:43 Post subject: |
|
|
| I use git for tracking all my changes. So there are no backup copies flying around. And I can roll back if needed. |
|
| Back to top |
|
solorize
Joined: 16 Nov 2019 Posts: 4 Location: UK, London
|
Posted: Mon 05 Jun '23 19:38 Post subject: |
|
|
Thankyou both for confirming.
I will give it a go when I next update Apache.
Hopefully this will save me a bit of time
not having to edit the new one  |
|
| Back to top |
|
mrdj1024
Joined: 03 Apr 2023 Posts: 92 Location: Bridgeton,NJ,USA
|
Posted: Tue 06 Jun '23 0:12 Post subject: |
|
|
you can do the same for php updates aswell so you dont have to constantly configure the php.ini file everytime a new update is released.
if your using php 8.1 you can update everytime it updates by downloading the new php version,just make sure its in the same php branch,like 8.0 with 8.0 or 8.1 with 8.1 etc.
also make sure that if your using apache you get the thread safe php builds.
upgrading from php 8 to 8.1 wont work using this method.
it works only for php updates in the same "family"
just copy and paste and overwrite the files in your php folder with the new ones
same principle applies to mariadb/mysql versions in the same release family. |
|
| Back to top |
|
tangent Moderator
Joined: 16 Aug 2020 Posts: 452 Location: UK
|
Posted: Sun 11 Jun '23 11:44 Post subject: |
|
|
My strategy is to make minimal changes to the default httpd.conf file, by referencing an optional include file added at the end, e.g.
| Code: | # Include custom settings for my server.
#
IncludeOptional C:/Apache24/common/conf/httpd-my.conf |
I locate this configuration file below an additional common directory, which contains other items that need to be separate from the Apache release files, e.g. common/conf, common/certs, common/cgi, etc.
You may need to comment out the default listener on port 80, if you don't need it, and the script alias default location if you choose to relocate it, e.g.
| Code: | # Listen 80
# ScriptAlias /cgi-bin/ "${SRVROOT}/cgi-bin/" |
|
|
| Back to top |
|
FeloniusMonkey
Joined: 09 Jun 2026 Posts: 1 Location: USA, Philadelphia
|
Posted: Wed 10 Jun '26 16:22 Post subject: |
|
|
| mrdj1024 wrote: | keep the old one
those rarely change. |
Sorry to jump on an old thread, but it seems appropriate. I'm upgrading from 2.4.65 to 2.4.68, and the stock httpd.conf has undergone some considerable updates.
Unremarkably, the module load order has been completely shuffled. However, after "unshuffling" the order to match my existing 2.4.65 based config file (for comparison), and I noticed a fair amount of modules have been both both activated and deactivated in the stock config.
Typically, I try to incorporate stock variations like this in my configuration. But these activations/deactivations have me concerned. I do not assume them to be arbitrary; they may be for good reason.
I've compared the AHS source between 2.4.65 and 2.4.68, and couldn't find anything that would cause these differences, which has led me to the conclusion that ApacheLounge controls the generation of that module list in httpd.conf.
Would anyone here mind filling me in on what went into these recent changes to the ApacheLounge httpd.conf template?
Thanks! |
|
| Back to top |
|
tangent Moderator
Joined: 16 Aug 2020 Posts: 452 Location: UK
|
Posted: Wed 10 Jun '26 17:00 Post subject: |
|
|
| FeloniusMonkey wrote: | Typically, I try to incorporate stock variations like this in my configuration. But these activations/deactivations have me concerned. I do not assume them to be arbitrary; they may be for good reason.
|
This issue cropped up with the transition from release 2.4.65 to 2.4.66, as discussed half way down this post https://www.apachelounge.com/viewtopic.php?p=43970.
At this point, due to the complexity of maintaining multiple builds for x64/x86, VS17/18, etc, Steffen switched to using CMake.
The above post notes that the CMake build orders the module entries in the httpd.conf file differently (semi-sorted) to those from the ASF non-CMake build. This historical difference exists, even though the CMakeLists.txt file used in the build comes from the ASF.
On that basis, these changes are not arbitrary, and I'd recommend revising your configuration to work around the current layout if you can. As I mentioned above, I tend to put my configuration in an extra include file, which means I need to make minimal changes to the default httpd.conf file, or the release code filesystem layout. |
|
| Back to top |
|
|
|
|
|
|