Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: AW: SSL enabled name virtual hosts
Date: Mon, 6 Mar 2006 09:55:29 +0100
Message-ID: 
 <F6E88684A95CDB4DBBD5B9F4C1C4B09B020EB15D@vis01-mx02.vis.internal.vodafone.com>
Thread-Topic: SSL enabled name virtual hosts
Thread-Index: AcZA8pRPX5Vq85uaQbm/kKeL9X6LBgACLJ9Q
From: =?iso-8859-1?Q?Pl=FCm=2C_R=FCdiger=2C_VIS?=
 <ruediger.pluem@vodafone.com>
To: <dev@httpd.apache.org>


> -----Urspr=FCngliche Nachricht-----
> Von: William A. Rowe, Jr.=20
> Stop bitching about a 10 year old spec.  It's trivial, use a=20
> modern browser (beyond today - none exist yet) that can do=20
> Connection-Upgrade and agree about the text of the headers=20
> before the ssl handshake is performed.  The browser people=20
> haven't caught up, because it's a non-trivial problem to=20
> represent that the agreed-upon connection is secure to the=20
> user, or that a secure connection is available to be toggled,=20
> or whatever.  These aren't https:// requests, they are=20
> http:// with extra semantics.  Modern clients such as remote=20
> printing over http and neon/curl libraries already support it=20
> now, IIUC.  As does httpd 2.2.

Or wait for RFC3546 (ftp://ftp.rfc-editor.org/in-notes/rfc3546.txt)
be implemented in the browsers and servers. IE 7 beta is said to
support it and upcoming openssl 0.9.9 is likely to support it.
After that we can start implementing in httpd.

Regards

R=FCdiger