If you really don't need vhost-specific HTTPS configurations (have wildcard certificate?), you can probably make HTTPS copies of all of your HTTP vhosts with some clever use of mod_proxy and mod_rewrite. I wouldn't recommend going this way though, sounds like interesting exercise but more trouble than benefits in production.
> Debian uses "Include" by default because of it's built-in `a2ensite` > shortcut. Even with the Include (as your code illustrates) there needs to be > a Virtual Host configuration block for HTTP on port 80 and for HTTPS on port > 443. You can still use your Include within that Include. Works great for me. > Unless specifically configured differently, why not assume they are the same > (as HTTP/port 80 for a matching Virtual Host)? Because: * Most real installations are more complex than that. * Apache configuration does not work this way (what if I don't want either of HTTP or HTTPS vhosts?) * Every HTTPS vhost normally needs some configuration, at least a separate certificate. * Finally, your proposed behavior is not even a good default these days (redirect from HTTP to HTTPS is). -- With Best Regards, Marat Khalili On May 20, 2017 7:46:39 PM GMT+03:00, Adam Powell <a...@adaminfinitum.com> wrote: >Hi Daniel, > >Thanks for trying to help but maybe I didn't explain this well enough. > >Debian uses "Include" by default because of it's built-in `a2ensite` >shortcut. > >Even with the Include (as your code illustrates) there needs to be a >Virtual Host configuration block for HTTP on port 80 and for HTTPS on >port >443. > >Unless specifically configured differently, why not assume they are the >same (as HTTP/port 80 for a matching Virtual Host)? > >I hope that helps clarify. > >Adam Powell >http://www.adaminfinitum.com > > >On Sat, May 20, 2017 at 6:05 AM, Daniel <dferra...@gmail.com> wrote: > >> 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 <a...@adaminfinitum.com>: >> > 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-unsubscr...@httpd.apache.org >> For additional commands, e-mail: users-h...@httpd.apache.org >> >>
