Subject: Re-direct in vhost

From: "Arthur Chan" <[email-masked]>
Date: Mon, 22 Sep 2003 18:04:25 +0800

Hi all.
Currently I've one vhost on Port 443 and while others listen on Port 80.
I would like to test the scenario of putting *everything* on openSSL ie
listening on Port 443.
Do I assume right that all I need is a "redirect" from the Port 80 vhost to
Port 443 ?
TIA :-)

______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl)                   www.modssl.org
User Support Mailing List                      [email-masked]
Automated List Manager                            [email-masked]

---

From: Kiyoshi Watanabe <[email-masked]>
Date: Thu, 25 Sep 2003 01:20:26 +0900 (JST)

Hello Arthur,

I do not understand your question clearly. What concerns in
your mind? 

-Kiyoshi
Kiyoshi Watanabe

---

From: Mads Toftum <[email-masked]>
Date: Wed, 24 Sep 2003 18:37:40 +0200

> > Do I assume right that all I need is a "redirect" from the Port 80 vhost to

Yes, that sounds about right. Something like this should do:

Listen 80

<VirtualHost *:80>
ServerName example.com
RedirectPermanent / https://example.com
</VirtualHost>

vh

Mads Toftum
--
Speaking at http://ApacheCon.com/
T03, "Apache 2 mod_ssl tutorial" (3h)
WE03, "Troubleshooting Apache configurations" 
WE11, "Apache mod_rewrite, the Swiss Army Knife of URL manipulation" 
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl)                   www.modssl.org
User Support Mailing List                      [email-masked]
Automated List Manager                            [email-masked]

---

From: Ken Kittlitz <[email-masked]>
Date: Thu, 25 Sep 2003 20:50:52 -0600

Hi folks,

Any idea what would cause the "ap:http:method" context key that 
ap_http_method tries to query not to get set during an HTTPS request?  In 
other words, the following #define from httpd.h:

#define ap_http_method(r)   (((r)->ctx != NULL && ap_ctx_get((r)->ctx, 
"ap::http::method") != NULL) ? ((char *)ap_ctx_get((r)->ctx, 
"ap::http::method")) : "http")

always returns the defalt "http".  ap_default_port suffers a similar 
problem. The Apache I'm running is a 1.3 version obtained from an 
'apache-ssl' Debian package.  It handles HTTPS request just fine, but you'd 
never guess that from calling ap_http_method :-/

The binary's compile settings are below.  Any help would be 
appreciated.  Thanks!

/usr/sbin/apache-ssl -V
Server version: Apache/1.3.27 Ben-SSL/1.48 (Unix) Debian GNU/Linux
Server built:   Jun 26 2003 16:53:19
Server's Module Magic Number: 19990320:13
Server compiled with....
  -D EAPI
  -D HAVE_MMAP
  -D HAVE_SHMGET
  -D USE_SHMGET_SCOREBOARD
  -D USE_MMAP_FILES
  -D NO_WRITEV
  -D HAVE_FCNTL_SERIALIZED_ACCEPT
  -D HAVE_SYSVSEM_SERIALIZED_ACCEPT
  -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
  -D HARD_SERVER_LIMIT=4096
  -D HTTPD_ROOT="/usr"
  -D SUEXEC_BIN="/usr/lib/apache-ssl/suexec"
  -D DEFAULT_PIDLOG="/var/run/apache-ssl.pid"
  -D DEFAULT_SCOREBOARD="/var/run/apache-ssl.scoreboard"
  -D DEFAULT_LOCKFILE="/var/run/apache-ssl.lock"
  -D DEFAULT_ERRORLOG="/var/log/apache-ssl/error.log"
  -D TYPES_CONFIG_FILE="/etc/mime.types"
  -D SERVER_CONFIG_FILE="/etc/apache-ssl/httpd.conf"
  -D ACCESS_CONFIG_FILE="/etc/apache-ssl/access.conf"
  -D RESOURCE_CONFIG_FILE="/etc/apache-ssl/srm.conf"
---
Ken Kittlitz
Vice-President, Javien Canada Inc.
http://www.javien.com

---

From: Cliff Woolley <[email-masked]>
Date: Thu, 25 Sep 2003 22:56:44 -0400 (EDT)

On Thu, 25 Sep 2003, Ken Kittlitz wrote:

>   ...

Why in the world would Debian ship an Apache-SSL package with EAPI
support???  Maybe it's for backward binary compatibility with an older
Debian distro that used mod_ssl?  Anyway, certainly the reason this is not
working right is that Apache-SSL (aka Ben-SSL) (as opposed to mod_ssl,
which is the one supported by this mailing list) does not use EAPI at all,
so it would not be calling the appropriate EAPI hooks at the right time to
get those ctx variables set.

Start from scratch with a stock Apache build (and get 1.3.28 while you're
at it), and install mod_ssl from www.modssl.org.  Then your EAPI will work
right.

--Cliff

---

From: Ken Kittlitz <[email-masked]>
Date: Thu, 25 Sep 2003 21:09:04 -0600

At 10:56 PM 9/25/2003 -0400, Cliff Woolley wrote:
>  Anyway, certainly the reason this is not

Yup, that would explain it... thanks.

>at it), and install mod_ssl from www.modssl.org.  Then your EAPI will work

Yeah, I normally use mod_ssl and have never had a problem;  it's the 
customer who decided to install Ben-SSL on their system.  Mea culpa for not 
realizing it was unrelated to mod_ssl. I'll try to show them the light ;-)
---
Ken Kittlitz
Vice-President, Javien Canada Inc.
http://www.javien.com