There is a directive called "Include" With this directive you can specify any number of directives in a file and then define the Include pointing to the same file wherever you may need. For instance <VirtualHost *:80> Include conf/common.conf </VirtualHost> <Virtualhost *:443> SSLEngine on SSLCertificatefile conf/x509.crt SSLCertitificateKeyFile conf/rsa.key Include conf/common.conf </Virtualhost> and common.conf can have: ServerName myserver.exam.com DocumentRoot /var/www DirectoryIndex index.html FallbackResource /index.html Redirect /one/ /two/ Header set myheader "Hello" # and all directives you may need. 2017-05-20 2:53 GMT+02:00 Adam Powell <adam@xxxxxxxxxxxxxxxxx>: > Hello, > > I am a user of Apache in the sense that I install it, configure it and run > it to host sites...I'm hoping this is the correct list to send this to. > > Anyway, I recently did my first "from scratch" Apache install, build and > configuration in a cloud server (I had always used cPanel & WHM before). > > My suggestion is that Apache should "assume" that port 80 for HTTP and port > 443 for HTTPS and that they both serve the same content. > > I'm not suggesting people shouldn't be able to customize it, but adding > duplicate and redundant directives for each Virtual Host for HTTP and HTTPS > seems unneeded. > > In short, I'm suggesting a "smart default" that in the absence of a specific > Virtual Host configuration for HTTPS, just assumes that the HTTPS matches > the HTTP config for that Virtual Host. > > Background: I got Apache (2.4.x) up and running on a Debian VM, configured > all my Virtual Hosts, installed an SLL certificate and went to view the > HTTPS version of a site. > > I was redirected to the 'default' page for the server (not the default page > for the Virtual Host). > > I then realized I needed additional, identical rules for that Virtual Host > for HTTPS on port 443...simply put, it seems like that extra level of > configuration shouldn't be required...that it should work that way > automagically unless specifically configured otherwise. > > If not, I'd love to know why that's a bad idea. > > Thanks! > > Adam Powell > http://www.adaminfinitum.com > -- Daniel Ferradal IT Specialist email dferradal at gmail.com linkedin es.linkedin.com/in/danielferradal --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx