From scottflores@example.net Wed Apr 06 02:10:37 2005 Return-Path: <scottflores@example.net> Delivered-To: scottflores@example.net Received: (qmail 10749 invoked from network); 6 Apr 2005 02:10:37 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 6 Apr 2005 02:10:37 -0000 Received: (qmail 68909 invoked by uid 500); 6 Apr 2005 02:10:37 -0000 Delivered-To: scottflores@example.net Received: (qmail 68628 invoked by uid 500); 6 Apr 2005 02:10:36 -0000 Mailing-List: contact scottflores@example.net; run by ezmlm Precedence: bulk list-help: <mailto:scottflores@example.net> list-unsubscribe: <mailto:scottflores@example.net> List-Post: <mailto:scottflores@example.net> Reply-To: scottflores@example.net Delivered-To: mailing list scottflores@example.net Received: (qmail 68595 invoked by uid 99); 6 Apr 2005 02:10:35 -0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from mail.lucid.net.au (HELO mail.lucid.net.au) (83.161.120.155) by apache.org (qpsmtpd/0.28) with ESMTP; Tue, 05 Apr 2005 19:10:34 -0700 Received: by mail.lucid.net.au (Postfix, from userid 502) id EE3E75FB6; Wed, 6 Apr 2005 12:10:30 +1000 (EST) Date: Wed, 6 Apr 2005 12:10:30 +1000 From: Jason Lingohr <scottflores@example.net> To: scottflores@example.net Subject: Serving XML doco from httpd Message-ID: <scottflores@example.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/83.161.120.155i X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N I know that someone has mentioned how to configure httpd to get .xml doco served right, but I can't find it. I'm at work and don't have direct file access to my checkouts at home ;) Jason --------------------------------------------------------------------- To unsubscribe, e-mail: scottflores@example.net For additional commands, e-mail: scottflores@example.net From scottflores@example.net Thu Apr 07 03:46:23 2005 Return-Path: <scottflores@example.net> Delivered-To: scottflores@example.net Received: (qmail 97224 invoked from network); 7 Apr 2005 03:46:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 7 Apr 2005 03:46:23 -0000 Received: (qmail 58686 invoked by uid 500); 7 Apr 2005 03:46:16 -0000 Delivered-To: scottflores@example.net Received: (qmail 58601 invoked by uid 500); 7 Apr 2005 03:46:15 -0000 Mailing-List: contact scottflores@example.net; run by ezmlm Precedence: bulk list-help: <mailto:scottflores@example.net> list-unsubscribe: <mailto:scottflores@example.net> List-Post: <mailto:scottflores@example.net> Reply-To: scottflores@example.net Delivered-To: mailing list scottflores@example.net Received: (qmail 58570 invoked by uid 99); 7 Apr 2005 03:46:15 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from i.meepzor.com (HELO Boron.MeepZor.Com) (83.161.120.155) by apache.org (qpsmtpd/0.28) with ESMTP; Wed, 06 Apr 2005 20:46:14 -0700 Received: from Boron.MeepZor.Com (localhost [83.161.120.155]) by Boron.MeepZor.Com (8.12.8/8.12.8) with ESMTP id j373jq6o006877; Wed, 6 Apr 2005 23:45:53 -0400 Received: (from cvs@localhost) by Boron.MeepZor.Com (8.12.8/8.12.8/Submit) id j373jqwL006875; Wed, 6 Apr 2005 23:45:52 -0400 Date: Wed, 6 Apr 2005 23:45:52 -0400 Message-Id: <scottflores@example.net> Content-Type: text/plain X-Application: $Id: report-status.pl,v 1.3 2005/03/30 10:13:06 coar Exp $ MIME-Version: 1.0 Subject: [STATUS] (httpd-docs-2.0) Wed Apr 6 23:45:52 2005 From: Rodent of Unusual Size <scottflores@example.net> To: Apache httpd documenters <scottflores@example.net> X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Apache HTTP Server 2.0 Documentation Status File. Last modified: $Date: 2004-11-21 09:35:21 -0500 (Sun, 21 Nov 2004) $ For more information on how to contribute to the Apache Documentation Project, please see http://httpd.apache.org/docs-project/ This document contains only documentation issues related to 2.0 alone. For general documentation issues, or those that relate both to 2.0 and to future versions, please see the same file in httpd-2.0 HEAD. --------------------------------------------------------------------- To unsubscribe, e-mail: scottflores@example.net For additional commands, e-mail: scottflores@example.net From scottflores@example.net Thu Apr 07 12:09:13 2005 Return-Path: <scottflores@example.net> Delivered-To: scottflores@example.net Received: (qmail 17297 invoked from network); 7 Apr 2005 12:09:13 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 7 Apr 2005 12:09:13 -0000 Received: (qmail 63687 invoked by uid 500); 7 Apr 2005 12:09:11 -0000 Delivered-To: scottflores@example.net Received: (qmail 63666 invoked by uid 500); 7 Apr 2005 12:09:11 -0000 Mailing-List: contact scottflores@example.net; run by ezmlm Precedence: bulk list-help: <mailto:scottflores@example.net> list-unsubscribe: <mailto:scottflores@example.net> List-Post: <mailto:scottflores@example.net> Reply-To: scottflores@example.net Delivered-To: mailing list scottflores@example.net Received: (qmail 63652 invoked by uid 99); 7 Apr 2005 12:09:11 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from smtp.cogeco.net (HELO fep5.cogeco.net) (83.161.120.155) by apache.org (qpsmtpd/0.28) with ESMTP; Thu, 07 Apr 2005 05:09:10 -0700 Received: from Pierre (50-184.ri.cgocable.ca [83.161.120.155]) by fep5.cogeco.net (Postfix) with SMTP id 171D637DF for <scottflores@example.net>; Thu, 7 Apr 2005 08:09:08 -0400 (EDT) Message-ID: <000c01c53b6a$9e0929e0$6400a8c0@Pierre> From: "Andrew" <scottflores@example.net> To: <scottflores@example.net> References: <scottflores@example.net> Subject: Unsuscribe Date: Thu, 7 Apr 2005 08:09:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ----- Original Message ----- From: "Rodent of Unusual Size" <scottflores@example.net> To: "Apache httpd documenters" <scottflores@example.net> Sent: Wednesday, April 06, 2005 11:45 PM Subject: [STATUS] (httpd-docs-2.0) Wed Apr 6 23:45:52 2005 > Apache HTTP Server 2.0 Documentation Status File. > Last modified: $Date: 2004-11-21 09:35:21 -0500 (Sun, 21 Nov 2004) $ > > For more information on how to contribute to the Apache Documentation > Project, please see http://httpd.apache.org/docs-project/ > > This document contains only documentation issues related to 2.0 alone. > For general documentation issues, or those that relate both to 2.0 and > to future versions, please see the same file in httpd-2.0 HEAD. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: scottflores@example.net > For additional commands, e-mail: scottflores@example.net > > --------------------------------------------------------------------- To unsubscribe, e-mail: scottflores@example.net For additional commands, e-mail: scottflores@example.net From scottflores@example.net Fri Apr 08 02:17:36 2005 Return-Path: <scottflores@example.net> Delivered-To: scottflores@example.net Received: (qmail 79982 invoked from network); 8 Apr 2005 02:17:36 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 8 Apr 2005 02:17:36 -0000 Received: (qmail 54765 invoked by uid 500); 8 Apr 2005 02:17:35 -0000 Delivered-To: scottflores@example.net Received: (qmail 54725 invoked by uid 500); 8 Apr 2005 02:17:34 -0000 Mailing-List: contact scottflores@example.net; run by ezmlm Precedence: bulk list-help: <mailto:scottflores@example.net> list-unsubscribe: <mailto:scottflores@example.net> List-Post: <mailto:scottflores@example.net> Reply-To: scottflores@example.net Delivered-To: mailing list scottflores@example.net Received: (qmail 54707 invoked by uid 99); 8 Apr 2005 02:17:34 -0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from mail.lucid.net.au (HELO mail.lucid.net.au) (83.161.120.155) by apache.org (qpsmtpd/0.28) with ESMTP; Thu, 07 Apr 2005 19:17:32 -0700 Received: by mail.lucid.net.au (Postfix, from userid 502) id 36E7C5FB8; Fri, 8 Apr 2005 12:17:29 +1000 (EST) Date: Fri, 8 Apr 2005 12:17:29 +1000 From: Jason Lingohr <scottflores@example.net> To: scottflores@example.net Subject: svn commit auth problem Message-ID: <scottflores@example.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/83.161.120.155i X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N I'm having an issue committing the backport of the htdbm doco. Firstly, I need something confirmed... are we committers meant to checkout stuff using the https: prefix always? I (maybe accidently) checked out the 2.0.x branch with only http, and got this error upon committing: svn: Commit failed (details follow): svn: CHECKOUT of '/repos/asf/!svn/ver/106092/httpd/httpd/branches/2.0.x/docs/man': authorization failed (https://svn.apache.org) So I figured it was the URI being wrong, and did a svn switch --relocate command, to no avail. Jason --------------------------------------------------------------------- To unsubscribe, e-mail: scottflores@example.net For additional commands, e-mail: scottflores@example.net From scottflores@example.net Sun Apr 10 11:54:18 2005 Return-Path: <scottflores@example.net> Delivered-To: scottflores@example.net Received: (qmail 16865 invoked from network); 10 Apr 2005 11:54:18 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 10 Apr 2005 11:54:18 -0000 Received: (qmail 62434 invoked by uid 500); 10 Apr 2005 11:54:17 -0000 Delivered-To: scottflores@example.net Received: (qmail 62156 invoked by uid 500); 10 Apr 2005 11:54:17 -0000 Mailing-List: contact scottflores@example.net; run by ezmlm Precedence: bulk list-help: <mailto:scottflores@example.net> list-unsubscribe: <mailto:scottflores@example.net> List-Post: <mailto:scottflores@example.net> Reply-To: scottflores@example.net Delivered-To: mailing list scottflores@example.net Received: (qmail 62138 invoked by uid 99); 10 Apr 2005 11:54:16 -0000 X-ASF-Spam-Status: No, hits=0.1 required=10.0 tests=FORGED_RCVD_HELO X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from striker.nl (HELO mail.striker.nl) (83.161.120.155) by apache.org (qpsmtpd/0.28) with ESMTP; Sun, 10 Apr 2005 04:54:16 -0700 Received: from localhost (localhost.localdomain [83.161.120.155]) by mail.striker.nl (Postfix) with ESMTP id 088A11CC5BD for <scottflores@example.net>; Sun, 10 Apr 2005 13:54:01 +0200 (CEST) Received: from mail.striker.nl ([83.161.120.155]) by localhost (argh.striker.nl [83.161.120.155]) (amavisd-new, port 10024) with ESMTP id 11757-01 for <scottflores@example.net>; Sun, 10 Apr 2005 13:54:00 +0200 (CEST) Received: from [83.161.120.155] (Grmbl.striker.nl [83.161.120.155]) by mail.striker.nl (Postfix) with ESMTP id 0B0AA1CC591 for <scottflores@example.net>; Sun, 10 Apr 2005 13:53:59 +0200 (CEST) Message-ID: <scottflores@example.net> Date: Sun, 10 Apr 2005 13:54:12 +0200 From: Sander Striker <scottflores@example.net> User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: scottflores@example.net Subject: Re: svn commit auth problem References: <scottflores@example.net> In-Reply-To: <scottflores@example.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p9 (Debian) at striker.nl X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Jason Lingohr wrote: > I'm having an issue committing the backport of the htdbm doco. > > Firstly, I need something confirmed... are we committers meant to checkout > stuff using the https: prefix always? Yes. You can only commit over https://, so unless you are not planning on committing, check out over https:// as well. > I (maybe accidently) checked out the > 2.0.x branch with only http, and got this error upon committing: > > svn: Commit failed (details follow): > svn: CHECKOUT of > '/repos/asf/!svn/ver/106092/httpd/httpd/branches/2.0.x/docs/man': > authorization failed (https://svn.apache.org) ^^^^^^^^^^^^^^^^^^^^^^ Seems to be ok. > So I figured it was the URI being wrong, and did a svn switch --relocate > command, to no avail. What does svn info say? Does it show you the correct url? Sander --------------------------------------------------------------------- To unsubscribe, e-mail: scottflores@example.net For additional commands, e-mail: scottflores@example.net From scottflores@example.net Sun Apr 10 12:33:23 2005 Return-Path: <scottflores@example.net> Delivered-To: scottflores@example.net Received: (qmail 21670 invoked from network); 10 Apr 2005 12:33:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 10 Apr 2005 12:33:23 -0000 Received: (qmail 92493 invoked by uid 500); 10 Apr 2005 12:33:22 -0000 Delivered-To: scottflores@example.net Received: (qmail 92218 invoked by uid 500); 10 Apr 2005 12:33:21 -0000 Mailing-List: contact scottflores@example.net; run by ezmlm Precedence: bulk list-help: <mailto:scottflores@example.net> list-unsubscribe: <mailto:scottflores@example.net> List-Post: <mailto:scottflores@example.net> Reply-To: scottflores@example.net Delivered-To: mailing list scottflores@example.net Received: (qmail 92204 invoked by uid 99); 10 Apr 2005 12:33:21 -0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=FORGED_HOTMAIL_RCVD2,NORMAL_HTTP_TO_IP,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: domain of scottflores@example.net designates 83.161.120.155 as permitted sender) Received: from main.gmane.org (HELO ciao.gmane.org) (83.161.120.155) by apache.org (qpsmtpd/0.28) with ESMTP; Sun, 10 Apr 2005 05:33:16 -0700 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DKbZw-0007dW-KM for scottflores@example.net; Sun, 10 Apr 2005 14:30:16 +0200 Received: from anantes-252-1-47-241.w82-126.abo.wanadoo.fr ([83.161.120.155]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <scottflores@example.net>; Sun, 10 Apr 2005 14:30:16 +0200 Received: from chbok by anantes-252-1-47-241.w82-126.abo.wanadoo.fr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <scottflores@example.net>; Sun, 10 Apr 2005 14:30:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: scottflores@example.net From: alain B <scottflores@example.net> Subject: httpd 2.0 doc French : /vhosts/ Date: Sun, 10 Apr 2005 14:33:12 +0200 Lines: 2344 Message-ID: <scottflores@example.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------010509050906060904010001" X-Complaints-To: scottflores@example.net X-Gmane-NNTP-Posting-Host: anantes-252-1-47-241.w82-126.abo.wanadoo.fr User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.7.2) Gecko/20040804 X-Accept-Language: fr, en Sender: news <scottflores@example.net> X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N --------------010509050906060904010001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hello, after a few weeks of work, i finished to translate and review the all /vhosts/ folder. So you'll notice that some files are just reviewed, and others must be reviewed by someone else. *** fr_FR *** Bonjour, après quelques semaines de travail, j'ai terminé de traduire et relire tout le répertoire /vhost/. Donc, vous noterez que certains fichiers ont simplement été relus, et d'autres doivent être relus par quelqu'un d'autre. --Alain --------------010509050906060904010001 Content-Type: text/xml; name="index.xml.fr" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="index.xml.fr" <?xml version='1.0' encoding='ISO-8859-1' ?> <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd"> <?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?> <!-- English Revision: 151405 --> <!-- french translation by alain B, review by ####### --> <!-- Copyright 2005 The Apache Software Foundation or its licensors, as applicable. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --> <manualpage metafile="index.xml.meta"> <parentdocument href="../"/> <title>Documentation sur les serveurs virtuels Apache</title> <summary> <p>Le principe des <cite>Serveurs Virtuels</cite> consiste à faire fonctionner un ou plusieurs serveurs Web (comme <code>www.company1.com</code> et <code>www.company2.com</code>) sur une même machine. Les serveurs virtuels peuvent être soit "<a href="ip-based.html">par-IP</a>" où une adresse IP est attribuée pour chaque serveur Web, soit "<a href="name-based.html" >par-nom</a>" où plusieurs noms de domaine se côtoient sur des mêmes adresses IP. L'utilisateur final ne perçoit pas qu'en fait il s'agit d'un même serveur physique.</p> <p>Apache a été le précurseur des serveurs proposant cette méthode de serveurs virtuels basés sur les adresses IP. Ses versions 1.1 et suivantes ont toujours proposées ces deux méthodes de serveurs virtuels par-IP et par-nom. Cette deuxième méthode est parfois également appelée <em>host-based</em> ou <em>serveur virtuel non-IP</em>.</p> <p>Vous trouverez ci-dessous une liste documentaire qui vous expliquera en détails le fonctionnement des serveurs virtuels sous Apache 1.3 et ses versions suivantes.</p> </summary> <seealso><module>mod_vhost_alias</module></seealso> <seealso><a href="name-based.html">Serveurs virtuels par-nom</a></seealso> <seealso><a href="ip-based.html">Serveurs virtuels par-IP</a></seealso> <seealso><a href="examples.html">Exemples de serveurs virtuels</a></seealso> <seealso><a href="fd-limits.html">Limites des descripteurs de fichiers</a></seealso> <seealso><a href="mass.html">Hébergement virtuel en masse</a></seealso> <seealso><a href="details.html">Détails sur les critères de choix du serveur</a></seealso> <section id="support"><title>Support des serveurs virtuels</title> <ul> <li><a href="name-based.html">Serveurs Virtuels par-Nom</a> (Un ou plusieurs sites Web par adresse IP)</li> <li><a href="ip-based.html">Serveurs Virtuels par-IP</a> (Une adresse IP pour chaque site Web)</li> <li><a href="examples.html">Exemples de configurations classiques de Serveurs Virtuels </a></li> <li><a href="fd-limits.html">Limites des descripteurs de fichiers</a> (ou, <em>trop de fichiers journaux</em>)</li> <li><a href="mass.html">Configuration dynamique en masse de Serveurs Virtuels</a></li> <li><a href="details.html">Explication approfondie des critères de sélection d'un Serveur Virtuel</a></li> </ul> </section> <section id="directives"><title>Directives de configuration</title> <ul> <li><directive type="section" module="core">VirtualHost</directive></li> <li><directive module="core">NameVirtualHost</directive></li> <li><directive module="core">ServerName</directive></li> <li><directive module="core">ServerAlias</directive></li> <li><directive module="core">ServerPath</directive></li> </ul> <p>Pour vérifier et analyser la configuration de vos serveurs virtuels, vous pouvez utiliser l'argument <code>-S</code> sur la ligne de commande lançant le programme Apache comme ceci&nbsp;:</p> <example> /usr/local/apache2/bin/httpd -S </example> <p>Cette commande affichera dans le détail comment Apache a traité son fichier de configuration. Les erreurs de configuration peuvent être corrigées par l'examen attentif des adresses IP et des noms de serveurs. (Consultez la documentation du programme <program>httpd</program> pour les autres arguments de la ligne de commande)</p> </section> </manualpage> --------------010509050906060904010001 Content-Type: text/xml; name="name-based.xml.fr" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="name-based.xml.fr" <?xml version='1.0' encoding='ISO-8859-1' ?> <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd"> <?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?> <!-- English Revision: 151405 --> <!-- French translation by alain B, review by --> <!-- Copyright 2005 The Apache Software Foundation or its licensors, as applicable. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --> <manualpage metafile="name-based.xml.meta"> <parentdocument href="./">Serveurs virtuels</parentdocument> <title>Support Apache des serveurs virtuels par nom</title> <summary> <p>Ce document décrit quand et comment utiliser des serveurs virtuels par nom.</p> </summary> <seealso><a href="ip-based.html">Support Apache des serveurs virtuels par IP</a></seealso> <seealso><a href="details.html">Détails sur le fonctionnement des serveurs virtuels</a></seealso> <seealso><a href="mass.html">Configuration dynamique des hébergements virtuels de masse</a></seealso> <seealso><a href="examples.html">Exemples d'utilisations de VirtualHost</a></seealso> <seealso><a href="examples.html#serverpath">Utilisation de la directive ServerPath</a></seealso> <section id="namevip"><title>Serveurs virtuels par nom vs. par IP</title> <p>Les hébergements virtuels par IP utilisent l'adresse IP de la connexion afin de déterminer quel serveur virtuel doit servir. Par conséquent, vous devez disposer d'adresses IP différentes pour chaque hébergement. Avec un hébergement virtuel par nom, le serveur doit s'appuyer sur les informations transmises par le client dans les en-têtes HTTP de ses requêtes. La technique présentée ici vous permet de disposer de serveurs virtuels différents partagés sur une même adresse IP.</p> <p>L'hébergement virtuel par nom est habituellement plus simple, car il vous suffit de configurer votre serveur DNS pour que chaque domaine pointe sur l'adresse IP correspondante, et de configurer votre serveur Apache HTTP afin qu'il reconnaisse ces domaines. Il réduit aussi la pénurie en adresses IP. Par conséquent, vous devriez utiliser l'hébergement virtuel par nom à moins d'avoir une raison spécifique de préférer l'hébergement virtuel par IP. Certaines de ces raisons vous sont exposées ci-après&nbsp;:</p> <ul> <li>Certains anciens navigateurs ne sont pas compatibles avec les serveurs virtuels par nom, car pour fonctionner, un client doit transmettre un champ d'en-tête HTTP Host. Cet en-tête est exigé pour HTTP/1.1, et peut être implémenté sur des navigateurs modernes HTTP/1.0 grâce à une extension. Si vous devez maintenir des clients obsolètes tout en utilisant l'hébergement virtuel par nom, il existe une technique qui est traitée à la fin de ce document.</li> <li>L'hébergement virtuel par nom ne peut pas être utilisé avec des serveurs sécurisés SSL à cause de la nature même du protocole SSL.</li> <li>Certains systèmes d'exploitation et équipements réseaux emploient des techniques de gestion de la bande passante qui ne peuvent pas différencier des domaines autrement que par des adresses IP séparées.</li> </ul> </section> <section id="using"><title>Utilisation de serveurs virtuels par nom</title> <related> <modulelist> <module>core</module> </modulelist> <directivelist> <directive module="core">DocumentRoot</directive> <directive module="core">NameVirtualHost</directive> <directive module="core">ServerAlias</directive> <directive module="core">ServerName</directive> <directive module="core">ServerPath</directive> <directive module="core" type="section">VirtualHost</directive> </directivelist> </related> <p>Pour utiliser des serveurs virtuels par nom, vous devez désigner l'adresse IP (et si possible le port) sur le serveur devant accepter les requêtes pour des domaines. Cette configuration utilise la directive <directive module="core">NameVirtualHost</directive>. Dans un cas normal où n'importe quelle adresse IP peut être utilisée, vous pouvez ajouter <code>*</code> comme argument de la directive <directive module="core">NameVirtualHost</directive>. Si vous prévoyez d'utiliser de multiples ports (comme l'emploi de SSL), vous devriez ajouter le port à cet argument tel que <code>*:80</code>. Notez que la simple mention d'une adresse IP dans une directive <directive module="core">NameVirtualHost</directive> ne suffit pas à faire écouter le serveur sur cette IP. Consultez <a href="../bind.html">la page sur les liaisons</a> pour plus de détails. Par ailleurs, chaque adresse IP spécifiée ici doit être associée avec une interface réseau sur le serveur.</p> <p>L'étape suivante est la création d'une section <directive type="section" module="core">VirtualHost</directive> pour chacun des serveurs à créer. L'argument de la directive <directive type="section" module="core">VirtualHost</directive> doit être le même que celui de la directive <directive module="core">NameVirtualHost</directive> (c'est-à-dire l'adresse IP ou <code>*</code> pour toutes les adresses). Dans chaque section <directive type="section" module="core">VirtualHost</directive>, vous devez définir au minimum une directive <directive module="core">ServerName</directive> pour désigner le serveur concerné et une directive <directive module="core">DocumentRoot</directive> pour préciser l'emplacement sur le système de fichiers du contenu de ce serveur.</p> <note><title>Le serveur principal disparaît</title> <p>Si vous ajoutez des serveurs virtuels à un serveur Web existant, vous devez également créer une section <directive type="section" module="core">VirtualHost</directive> redéfinissant ce serveur existant. Les directives <directive module="core">ServerName</directive> et <directive module="core">DocumentRoot</directive> incluses dans ce serveur virtuel doivent être les mêmes que pour les directives globales <directive module="core">ServerName</directive> et <directive module="core">DocumentRoot</directive>. Positionnez ce serveur virtuel en premier dans le fichier de configuration pour en faire le serveur par défaut.</p> </note> <p>Par exemple, supposez que vous servez le domaine <code>www.domain.tld</code> et que vous souhaitez ajouter le serveur virtuel <code>www.otherdomain.tld</code> qui pointe sur la même adresse IP. Il vous suffit d'ajouter la configuration suivante à <code>httpd.conf</code>&nbsp;:</p> <example> NameVirtualHost *:80<br /> <br /> &lt;VirtualHost *:80&gt;<br /> <indent> ServerName www.domain.tld<br /> ServerAlias domain.tld *.domain.tld<br /> DocumentRoot /www/domain<br /> </indent> &lt;/VirtualHost&gt;<br /> <br /> &lt;VirtualHost *:80&gt;<br /> <indent>ServerName www.otherdomain.tld<br /> DocumentRoot /www/otherdomain<br /> </indent> &lt;/VirtualHost&gt;<br /> </example> <p>Autrement, vous pouvez spécifiez une adresse IP explicite à la place de <code>*</code> dans les deux directives <directive module="core" >NameVirtualHost</directive> et <directive type="section" module="core" >VirtualHost</directive>. Par exemple, cette méthode est utile si vous souhaitez faire tourner quelques serveurs virtuels par nom sur une même adresse IP, et d'autres, soit par IP, soit basés sur un autre jeu de serveurs virtuels par nom sur une autre adresse IP.</p> <p>Plusieurs serveurs sont accessibles par plus d'un nom. Il suffit de placer la directive <directive module="core">ServerAlias</directive> dans une section <directive type="section" module="core">VirtualHost</directive>. Par exemple, dans la première section <directive type="section" module="core">VirtualHost</directive> ci-dessus, la directive <directive module="core">ServerAlias</directive> indique aux utilisateurs les autres noms permis pour accéder au même site Web&nbsp;:</p> <example> ServerAlias domain.tld *.domain.tld </example> <p>ainsi, toutes les requêtes portant sur un domaine <code>domain.tld</code> sera servi par le serveur virtuel <code>www.domain.tld</code>. Les caractères joker <code>*</code> et <code>?</code> peuvent être utilisés pour les correspondances. Bien entendu, vous ne pouvez pas inventer des noms et les placer dans une directive <directive module="core">ServerName</directive> ou <code>ServerAlias</code>. Tout d'abord, votre serveur DNS doit être correctement configuré pour lier ces noms à une adresse IP associée avec votre serveur.</p> <p>Finalement, vous pouvez affiner la configuration des serveurs virtuels en plaçant d'autres directives à l'intérieur des sections <directive type="section" module="core">VirtualHost</directive>. La plupart des directives peut être placée dans ces sections en y changeant seulement la configuration du serveur virtuel associé. Pour connaître si une directive particulière est permise, consultez <a href="../mod/directive-dict.html#Context">la page de contexte</a>. Le jeu de directives configurées dans le contexte du <em>serveur principal</em> (en dehors de toutes sections <directive type="section" module="core">VirtualHost</directive>) sera utilisé seulement s'il n'y a pas de configuration surclassante par un serveur virtuel.</p> <p>Maintenant, lorsqu'une requête arrive, le serveur va d'abord tester si elle utilise une adresse IP qui correspond à <directive module="core" >NameVirtualHost</directive>. Si c'est le cas, il regardera chaque section <directive type="section" module="core">VirtualHost</directive> avec l'adresse correspondante et essaiera d'en trouver une où le nom de domaine requis correspond à <directive module="core">ServerName</directive> ou <code>ServerAlias</code>. S'il en trouve une, il utilisera sa configuration pour le serveur. Si aucun serveur virtuel ne correspond, alors <em>le premier serveur virtuel listé</em> dont l'adresse IP correspond sera employé.</p> <p>En conséquence, le premier serveur virtuel listé est le serveur virtuel <em>default</em>. La directive <directive module="core">DocumentRoot</directive> du <em>serveur principal</em> <strong>ne</strong> sera <strong>jamais</strong> employée lorsqu'une adresse IP correspond dans une directive <directive module="core">NameVirtualHost</directive>. Si vous ne voulez pas avoir de configuration spéciale pour les requêtes qui ne sont pas attachées à un serveur virtuel en particulier, mettez cette configuration dans une section <directive type="section" module="core">VirtualHost</directive> que vous placerez en premier dans le fichier de configuration.</p> </section> <section id="compat"><title>Compatibilité avec les navigateurs anciens</title> <p>Comme mentionné plus tôt, certains clients ne transmettent pas les données nécessaires pour le bon fonctionnement des serveurs virtuels. Ces clients recevront toujours les pages du premier serveur virtuel listé pour cette adresse IP (le serveur virtuel par nom <cite>primaire</cite>).</p> <note><title>De combien plus âgé&nbsp;?</title> <p>Veuillez noter que quand nous disons plus âgé, nous disons vraiment plus âgé. Vous seriez malchanceux de rencontrer de tels navigateurs encore utilisés de nos jours. Toutes les versions actuelles des navigateurs transmettent leur en-tête <code>Host</code> comme exigé par les serveurs virtuels par nom.</p> </note> <p>Il existe une solution avec la directive <directive module="core">ServerPath</directive>, bien que légèrement encombrante&nbsp;:</p> <p>Exemple de configuration&nbsp;:</p> <example> NameVirtualHost 83.161.120.155<br /> <br /> &lt;VirtualHost 83.161.120.155&gt;<br /> <indent> ServerName www.domain.tld<br /> ServerPath /domain<br /> DocumentRoot /web/domain<br /> </indent> &lt;/VirtualHost&gt;<br /> </example> <p>Qu'est-ce que cela signifie&nbsp;? Il signifie qu'une requête pour tout URI qui commence par "<code>/domain</code>" sera servie par le serveur virtuel <code>www.domain.tld</code>. Ainsi, les pages sont accessibles à <code>http://www.domain.tld/domain/</code> pour tous les clients, bien que ceux qui transmettent un en-tête <code>Host:</code> peuvent également y accéder à <code>http://www.domain.tld/</code>.</p> <p>Pour rendre cette technique fonctionnelle, mettez un lien dans votre serveur virtuel primaire vers <code>http://www.domain.tld/domain/</code>. Ensuite, dans les pages de ce serveur virtuel, assurez vous ne n'utiliser que des liens relatifs (<em>par exemple</em>, "<code>file.html</code>" ou "<code>../icons/image.gif</code>") ou des liens contenant le préfixe <code>/domain/</code> (<em>par exemple</em>, "<code>http://www.domain.tld/domain/misc/file.html</code>" ou "<code>/domain/misc/file.html</code>").</p> <p>Cela requiert un peu de discipline, mais si vous suivez cette ligne de conduite, vous serez assuré que vos pages s'afficheront dans tous les navigateurs, nouveaux et anciens.</p> </section> </manualpage> --------------010509050906060904010001 Content-Type: text/xml; name="details.xml.fr" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="details.xml.fr" <?xml version='1.0' encoding='ISO-8859-1' ?> <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd"> <?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?> <!-- English Revision: 151405 --> <!-- French translation by Vincent Deffontaines, review by alain B --> <!-- Copyright 2005 The Apache Software Foundation or its licensors, as applicable. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --> <manualpage metafile="details.xml.meta"> <parentdocument href="./">Serveurs virtuels</parentdocument> <title>Détails sur le fonctionnement des serveurs virtuels</title> <summary> <p>Le code gérant les serveurs virtuels a été réécrit à partir de zéro dans <strong>Apache 1.3</strong>. Ce document vise à expliquer dans le détail comment Apache procède lors du choix de l'utilisation d'un serveur virtuel en fonction d'une requête reçue. L'apparition de la directive <directive module="core">NameVirtualHost</directive> a rendu beaucoup plus facile et plus sûre la configuration des serveurs virtuels par rapport aux versions précédant la 1.3.</p> <p>Si vous voulez juste <cite>que ça marche</cite> sans en comprendre le fonctionnement, voici <a href="examples.html">quelques exemples</a>.</p> </summary> <section id="configparsing"><title>Interprétation des fichiers de configuration</title> <p>Un <em>serveur principal (main_server)</em> contient toutes les définitions qui apparaissent en dehors des sections <code>&lt;VirtualHost&gt;</code>. Les serveurs virtuels, aussi appelés <em>vhosts</em> (pour virtual hosts), sont définis par les sections <directive type="section" module="core">VirtualHost</directive>.</p> <p>Les directives <directive module="mpm_common">Listen</directive>, <directive module="core">ServerName</directive>, <directive module="core">ServerPath</directive>, et <directive module="core">ServerAlias</directive> peuvent être placées n'importe où dans le cadre de définition d'un serveur. Cependant, chaque fois que l'une d'elles est lue, elle écrase ses instances précédentes (dans le contexte du même serveur).</p> <p>La valeur par défaut du champ <code>Listen</code> pour le serveur principal est de 80. Le serveur principal n'a pas de valeur par défaut pour <code>ServerPath</code> ni pour <code>ServerAlias</code>. La valeur par défaut de <code>ServerName</code> est déduite à partir de l'adresses IP du serveur.</p> <p>La directive Listen associée au serveur principal a deux utilités. La première détermine le port réseau sur lequel Apache va écouter. La deuxième spécifie le port qui sera utilisé dans les URIs absolus lors des redirections.</p> <p>À la différence du serveur principal, les ports des serveurs virtuels <em>n</em>'affectent <em>pas</em> les ports sur lesquels Apache se met à l'écoute.</p> <p>Chaque adresse incluse dans une directive <code>VirtualHost</code> peut disposer d'un port optionnel. Si le port n'est pas précisé, il prend par défaut la dernière valeur de <code>Listen</code> lue dans la configuration du serveur principal. Le port particulier <code>*</code> représente un joker qui correspond à tous les ports. L'ensemble des adresses (y compris les résultats multiples <code>A</code> issus des requêtes DNS) est appelé <em>jeu d'adresses</em> du serveur virtuel.</p> <p>À moins qu'une directive <directive module="core">NameVirtualHost</directive> ne soit utilisée pour une adresse IP spécifique, le premier serveur virtuel avec cette adresse est considéré comme un <em>serveur virtuel par-IP</em>. L'adresse IP peut également prendre la valeur joker <code>*</code>.</p> <p>Dans les cas où l'on souhaite utiliser un <em>serveur virtuel par nom</em>, la directive <code>NameVirtualHost</code> <em>doit</em> apparaître avec l'adresse IP choisie. En d'autres termes, vous devez spécifier dans votre fichier de configuration l'adresse IP des noms de domaine (CNAME) de vos serveurs virtuels par nom au moyen de la directive <code>NameVirtualHost</code>.</p> <p>On peut utiliser plusieurs directives <code>NameVirtualHost</code> pour un groupe de directives <code>VirtualHost</code>, mais seule une directive <code>NameVirtualHost</code> doit être utilisée pour chaque couple IP:port donné.</p> <p>L'ordre d'apparition des directives <code>NameVirtualHost</code> et <code>VirtualHost</code> est sans importance, ce qui fait que les deux exemples suivants ont des effets identiques (seul l'ordre des directives <code>VirtualHost</code> pour <em>un</em> jeu d'adresses est important, voir ci-dessous)&nbsp;:</p> <table><tr> <td><example> NameVirtualHost 83.161.120.155<br /> &lt;VirtualHost 83.161.120.155&gt;<br /> # serveur A<br /> ...<br /> &lt;/VirtualHost&gt;<br /> &lt;VirtualHost 83.161.120.155&gt;<br /> # serveur B<br /> ...<br /> &lt;/VirtualHost&gt;<br /> <br /> NameVirtualHost 83.161.120.155<br /> &lt;VirtualHost 83.161.120.155&gt;<br /> # serveur C<br /> ...<br /> &lt;/VirtualHost&gt;<br /> &lt;VirtualHost 83.161.120.155&gt;<br /> # serveur D<br /> ...<br /> &lt;/VirtualHost&gt; </example></td> <td><example> &lt;VirtualHost 83.161.120.155&gt;<br /> # serveur A<br /> &lt;/VirtualHost&gt;<br /> &lt;VirtualHost 83.161.120.155&gt;<br /> # serveur C<br /> ...<br /> &lt;/VirtualHost&gt;<br /> &lt;VirtualHost 83.161.120.155&gt;<br /> # serveur B<br /> ...<br /> &lt;/VirtualHost&gt;<br /> &lt;VirtualHost 83.161.120.155&gt;<br /> # serveur D<br /> ...<br /> &lt;/VirtualHost&gt;<br /> <br /> NameVirtualHost 83.161.120.155<br /> NameVirtualHost 83.161.120.155<br /> <br /> </example></td> </tr></table> <p>(Il est conseillé d'adopter le choix de gauche pour faciliter la lisibilité des fichiers de configuration.)</p> <p>Après la lecture de la directive <code>VirtualHost</code>, le serveur virtuel se voit attribuer une valeur <code>Listen</code> par défaut qui est la valeur du port associé au premier nom spécifié dans sa directive <code>VirtualHost</code>.</p> <p>La liste complète des noms d'une directive <code>VirtualHost</code> est gérée exactement comme des <code>ServerAlias</code> (mais ne sont pas écrasés par d'autres <code>ServerAlias</code>) si tous les noms sont résolus dans ce jeu d'adresse. À noter que les états <code>Listen</code> de ce serveur virtuel sont sans incidence sur les ports attibués au jeu d'adresses.</p> <p>Pendant la phase d'initialisation, une liste de chaque adresse IP est générée et introduite dans une table de 'hash'. Si une adresse IP est utilisée dans une directive <code>NameVirtualHost</code>, cette liste contient les noms des serveurs virtuels pour cette adresse. Si aucun serveur virtuel n'est défini pour cette adresse, la directive <code>NameVirtualHost</code> est ignorée et un message est envoyé au journal d'erreurs. Quand un serveur virtuel par IP est utilisé, la table de 'hash' reste vide.</p> <p>La fonction de 'hash' étant rapide, le temps d'exécution d'un 'hash' sur une adresse IP lors d'une requête est minimale et quasiment imperceptible. De plus, la table est optimisée pour les adresses IP dont le dernier octet est le seul à changer.</p> <p>Pour chaque serveur virtuel, diverses valeurs sont initialisées par défaut. En particulier&nbsp;:</p> <ol> <li>Dans le cas où un serveur virtuel ne contient pas de directives <directive module="core">ServerAdmin</directive>, <directive module="core">ResourceConfig</directive>, <directive module="core">AccessConfig</directive>, <directive module="core">Timeout</directive>, <directive module="core">KeepAliveTimeout</directive>, <directive module="core">KeepAlive</directive>, <directive module="core">MaxKeepAliveRequests</directive>, ou <directive module="core">SendBufferSize</directive>, alors la valeur de chacun de ces paramètres est héritée de celle du serveur principal. (C'est à dire, héritée de la valeur finale après lecture de la configuration du serveur principal.)</li> <li>Les permissions par défaut sur les répertoires de chaque serveur virtuel sont assemblées avec celles du serveur principal. Elles concernent également toutes les informations de configuration par répertoire pour tous les modules.</li> <li>Les configurations par serveur pour chaque module sont assemblées à partir de celles du serveur principal.</li> </ol> <p>L'essentiel des valeurs de configuration des serveurs virtuels provient de valeurs par défaut issues du serveur principal. Donc, l'emploi de ces directives propres au serveur virtuel dans le fichier de configuration est largement déconseillé -- l'ensemble de la configuration du serveur principal est lu avant que ces valeurs par défaut soient appliquées aux serveur virtuels. Ainsi, même si la définition d'une valeur apparaît après celle d'un serveur virtuel, cette valeur peut affecter la configuration du serveur virtuel.</p> <p>Dans le cas où le serveur principal n'a pas de <code>ServerName</code> à ce stade, le nom de la machine sur laquelle tourne le programme <program>httpd</program> est utilisé à sa place. Nous appellerons <em>jeu d'adresses du serveur principal</em>, les adresses IP renvoyées par une résolution DNS sur le <code>ServerName</code> du serveur principal.</p> <p>Pour tous les champs <code>ServerName</code> non définis, dans le cas d'une configuration en serveur virtuel par nom, la valeur adoptée par défaut est la première adresse donnée dans la section <code>VirtualHost</code> qui définit le serveur virtuel.</p> <p>Si un serveur virtuel contient la valeur magique <code>_default_</code>, il fonctionne sur le même <code>ServerName</code> que le serveur principal.</p> </section> <section id="hostmatching"><title>Choix du serveur virtuel</title> <p>À la réception d'une requête, le serveur procède comme suit pour déterminer quel serveur virtuel utiliser&nbsp;:</p> <section id="hashtable"><title>Vérification dans la table de hash</title> <p>Après que le client se soit connecté une première fois, l'adresse IP avec laquelle le client s'est connecté est recherchée dans la table de hash IP interne.</p> <p>Si la résolution de l'adresse IP n'aboutit pas (adresse IP non trouvée), la requête est servie par le serveur virtuel <code>_default_</code> s'il est défini pour le port correspondant à la requête. Sinon, elle est servie par le serveur principal.</p> <p>Si l'adresse IP n'est pas trouvée dans la table de hash, la recherche du numéro de port peut aussi se terminer par une correspondance à un <code>NameVirtualHost *</code> qui est géré ensuite comme les autres serveur virtuels par noms.</p> <p>Si une liste est bien trouvée dans la table pour l'adresse IP recherchée, l'étape suivante est de déterminer s'il s'agit d'un serveur virtuel par nom ou par IP.</p> </section> <section id="ipbased"><title>Serveur virtuel par IP</title> <p>Si l'entrée trouvée dispose d'une liste de noms vide, c'est qu'il s'agit d'un serveur virtuel par IP, et aucun autre choix n'est plus à faire&nbsp;; la requête est servie par ce serveur virtuel.</p> </section> <section id="namebased"><title>Serveur virtuel par nom</title> <p>Si l'entrée trouvée correspond à un serveur virtuel par nom, la liste de noms contient au moins une structure de serveurs virtuels. Les serveurs virtuels se présentent dans cette liste dans le même ordre que la lecture des directives <code>VirtualHost</code> dans le fichier de configuration.</p> <p>Le premier serveur virtuel de cette liste (donc, le premier serveur virtuel attribué à une adresse IP donnée dans le fichier de configuration) se voit attribuer la plus grande priorité, ce qui signifie que c'est lui qui traite les requêtes présentant un nom de serveur invalide ou ne présentant pas de champ <code>Host:</code> dans l'en-tête.</p> <p>Si un champ <code>Host:</code> est transmis dans l'en-tête de la requête, son occurrence est recherchée dans la liste et le premier serveur virtuel qui présente un <code>ServerName</code> ou un <code>ServerAlias</code> correspondant est choisi pour servir la requête. Il est possible que le champ <code>Host:</code> contienne un numéro de port, mais Apache utilise toujours le port sur lequel il a effectivement reçu la requête.</p> <p>Dans le cas où le client a envoyé une requête en HTTP/1.0 sans un champ d'en-tête <code>Host:</code>, il est impossible de déterminer le serveur auquel le client veut se connecter&nbsp;; l'URI de la requête est recherché dans tous les <code>ServerPath</code> existants. Le premier chemin trouvé est utilisé et la requête est servie par le serveur virtuel correspondant.</p> <p>Si aucun serveur virtuel n'est trouvé, la requête est servie par le premier serveur virtuel qui écoute sur le port demandé et qui est sur la liste associée à l'adresse IP vers laquelle la requête a été envoyée (comme déjà précisé ci-avant).</p> </section> <section id="persistent"><title>Connexions persistantes</title> <p>La recherche par adresse IP décrite ci-avant n'est faite qu'<em>une fois</em> pour chaque session TCP/IP, alors que la recherche par nom est réalisée pour <em>chaque</em> requête au cours d'une connexion persistante (KeepAlive). En d'autres termes, il est possible pour un client de faire des requêtes sur différents serveurs virtuels par nom, au cours d'une unique connexion persistante.</p> </section> <section id="absoluteURI"><title>URI absolu</title> <p>Au cas où l'URI de la requête est absolu, et que son nom de serveur et son port correspondent au serveur principal (ou l'un des serveurs virtuels configurés), <em>et</em> qu'ils correspondent à l'adresse et au port de la requête, alors l'URI est amputé de son préfixe protocole/nom de serveur/port et traité par le serveur correspondant (principal ou virtuel). Si cette correspondance n'existe pas, l'URI reste inchangé et la requête est considérée comme une requête d'un serveur mandataire.</p> </section> <section id="observations"><title>Observations</title> <ul> <li>Les serveurs virtuels par nom et par IP n'interfèrent jamais entre eux. Les serveurs virtuels par IP ne sont joignables qu'au travers de leur(s) adresse(s) IP propre(s), en aucun cas par aucune autre adresse. Les serveurs virtuels par nom ne sont accessibles que par leur(s) adresse(s) IP qui ne peuvent être définies qu'au moyen de la directive <code>NameVirtualHost</code>.</li> <li>Les vérifications sur <code>ServerAlias</code> et <code>ServerPath</code> ne sont jamais réalisées pour les serveurs virtuels par IP.</li> <li>L'ordre dans lequel sont agencés dans le fichier de configuration le serveur virtuel <code>_default_</code>, les serveurs virtuels par nom et par IP, et la directive <code>NameVirtualHost</code> est sans incidence sur le fonctionnement. Seul l'ordre des serveurs virtuels par nom pour une adresse donnée a une importance. Le serveur virtuel par nom qui est présent en premier dans la configuration se voit attribué la priorité la plus haute pour les requêtes arrivant sur son jeu d'adresses IP.</li> <li>Pour des raisons de sécurité, le numéro de port présenté dans le champ d'en-tête <code>Host:</code> n'est jamais utilisé pour les tests de correspondances. Apache ne prend en compte que le numéro de port sur lequel le client a envoyé la requête.</li> <li>Si une directive <code>ServerPath</code> existe, et se trouve être préfixe d'une autre directive <code>ServerPath</code> qui apparaît plus loin dans la configuration, la première sera toujours utilisée et la deuxième jamais. (Ceci ne se produit que dans le cas où aucun champ <code>Host:</code> n'a été présenté par le client pour distinguer les deux.)</li> <li>Dans le cas où deux serveurs virtuels par IP ont une adresse en commun, le serveur virtuel qui apparaît en premier dans la configuration est toujours choisi. Ce genre de chose peut arriver par inadvertance. Le serveur envoie une alerte dans le journal d'erreurs si ce cas se présente.</li> <li>Le serveur virtuel <code>_default_</code> ne sert la requête que si aucun autre serveur virtuel travaillant sur l'adresse IP <em>et</em> le port demandés n'est trouvé. La requête n'est traitée que si le numéro de port qui a reçu la requête est associé au serveur virtuel <code>_default_</code> (qui par défaut, correspond à <code>Listen</code>). Un port joker peut être spécifié (<em>comme dans</em> <code>_default_:*</code>) pour récupérer les requêtes sur tous les ports ouverts. Ceci est également applicable aux serveurs virtuels <code>NameVirtualHost *</code>.</li> <li>Le serveur principal ne sert à servir les requêtes que lorsque l'adresse IP et le port demandés par le client ne correspondent à aucun serveur virtuel (y compris un serveur virtuel <code>_default_</code>). En d'autres termes, le serveur principal n'est utile que pour les combinaisons adresse/port non spécifiées (sauf quand un serveur virtuel <code>_default_</code> correspond au port).</li> <li>Ni les serveurs virtuels <code>_default_</code>, ni le serveur principal ne sont utilisés pour traiter une requête avec un champ d'en-tête <code>Host:</code> manquant ou vide lorsque l'adresse (et le port) de connexion correspondent à des serveurs virtuels par nom, par exemple, dans une directive <code>NameVirtualHost</code>.</li> <li>Il ne faut jamais employer de noms DNS dans des directives <code>VirtualHost</code>, car cela oblige le serveur a s'appuyer sur le DNS au moment du démarrage. De plus, vous vous exposez à des problèmes de sécurité si vous n'avez pas la maîtrise du DNS pour la totalité de vos domaines. Voir la documentation <a href="../dns-caveats.html">disponible ici</a>, ainsi que les deux points précisés ci-après.</li> <li>Un nom de serveur <code>ServerName</code> devrait toujours être indiqué pour chaque serveur virtuel. Sans cela, une résolution DNS est nécessaire pour chaque serveur virtuel.</li> </ul> </section> </section> <section id="tips"><title>Trucs et astuces</title> <p>En plus des points évoqués sur la page des <a href="../dns-caveats.html#tips">problèmes liés au DNS</a>, voici quelques points intéressants&nbsp;:</p> <ul> <li>Toujours positionner les définitions relatives au serveur principal avant toute définition <code>VirtualHost</code>. (Ceci améliore grandement la lisibilité de la configuration -- la manière dont la configuration est interprétée après la lecture des fichiers ne met pas en évidence le fait que les définitions positionnées avant et surtout après les serveurs virtuels peuvent impacter le fonctionnement des serveurs virtuels.)</li> <li>Toujours regrouper les définitions <code>NameVirtualHost</code> et <code>VirtualHost</code> dans la configuration pour une meilleure lisibilité.</li> <li>Éviter les <code>ServerPaths</code> qui sont préfixes d'autres <code>ServerPaths</code>. Si cela ne peut être évité, veillez à ce que le serveur virtuel contenant le préfixe le plus long (donc le plus précis) apparaisse dans le fichier de configuration avant le plus court. (<em>par exemple</em>, "ServerPath /abc" est à spécifier après "ServerPath /abc/def").</li> </ul> </section> </manualpage> --------------010509050906060904010001 Content-Type: text/xml; name="examples.xml.fr" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="examples.xml.fr" <?xml version='1.0' encoding='ISO-8859-1' ?> <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd"> <?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?> <!-- English Revision: 151405 --> <!-- French translation by Vincent Deffontaines, Alain B., review by --> <!-- Copyright 2005 The Apache Software Foundation or its licensors, as applicable. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --> <manualpage metafile="examples.xml.meta"> <parentdocument href="./">Serveurs virtuels</parentdocument> <title>Exemples d'utilisations de VirtualHost</title> <summary> <p>Le but de ce document est d'essayer de répondre aux questions les plus répandues sur la configuration des serveurs virtuels. Les scénarios présentés ici se rencontrent quand plusieurs serveurs Webs doivent tourner sur une seule et même machine au moyen de serveurs virtuels <a href="name-based.html">par nom</a> ou <a href="ip-based.html">par IP</a>.</p> </summary> <section id="purename"><title>Fonctionnement de plusieurs serveurs virtuels par nom sur une seule adresse IP.</title> <p>Votre serveur ne dispose que d'une seule adresse IP, et de nombreux alias (CNAMES) pointent vers cette adresse dans le DNS. Pour l'exemple, <code>www.example1.com</code> et <code>www.example2.org</code> doivent tourner sur cette machine.</p> <note><title>Note&nbsp;:</title><p>La configuration de serveurs virtuels sous Apache ne provoque pas leur apparition magique dans la configuration du DNS. Il <em>faut</em> que leurs noms soient définis dans le DNS, et qu'ils y soient résolus sur l'adresse IP du serveur, faute de quoi personne ne pourra visiter votre site Web. Il est possible d'ajouter des entrées dans le fichier <code>hosts</code> pour tests locaux, mais qui ne fonctionneront que sur la machine possédant ces entrées.</p> </note> <example> <title>Configuration du serveur</title> # Apache doit écouter sur le port 80<br /> Listen 80<br /> <br /> # Toutes les adresses IP doivent répondre aux requêtes sur les # serveurs virtuels NameVirtualHost *:80<br /> <br /> &lt;VirtualHost *:80&gt;<br /> <indent> DocumentRoot /www/example1<br /> ServerName www.example1.com<br /> <br /> # Autres directives ici<br /> <br /> </indent> &lt;/VirtualHost&gt;<br /> <br /> &lt;VirtualHost *:80&gt;<br /> <indent> DocumentRoot /www/example2<br /> ServerName www.example2.org<br /> <br /> # Autres directives ici<br /> <br /> </indent> &lt;/VirtualHost&gt; </example> <p>Les astérisques correspondent à toutes les adresses, si bien que le serveur principal ne répondra jamais à aucune requête. Comme <code>www.example1.com</code> se trouve en premier dans le fichier de configuration, il a la plus grande priorité et peut être vu comme serveur <cite>par défaut</cite> ou <cite>primaire</cite>&nbsp;; ce qui signifie que toute requête reçue ne correspondant pas à une des directives <code>ServerName</code> sera servie par ce premier <code>VirtualHost</code>.</p> <note> <title>Note&nbsp;:</title> <p>Si vous le souhaitez, vous pouvez remplacer <code>*</code> par l'adresse IP du système. Dans ce cas, l'argument de <code>VirtualHost</code> <em>doit</em> correspondre à l'argument de <code>NameVirtualHost</code>&nbsp;:</p> <example> NameVirtualHost 83.161.120.155<br /> <br /> &lt;VirtualHost 83.161.120.155&gt;<br /> # etc ... </example> <p>En général, il est commode d'utiliser <code>*</code> sur les systèmes dont l'adresse IP n'est pas constante - par exemple, pour des serveurs dont l'adresse IP est attribuée dynamiquement par le FAI, et où le DNS est géré au moyen d'un DNS dynamique quelconque. Comme <code>*</code> signifie <cite>n'importe quelle adresse</cite>, cette configuration fonctionne sans devoir être modifiée quand l'adresse IP du système est modifiée.</p> </note> <p>La configuration ci-dessus est en pratique utilisée dans la plupart des cas pour les serveurs virtuels par nom. En fait, le seul cas où cette configuration ne fonctionne pas est lorsque différents contenus doivent être servis en fonction de l'adresse IP et du port contactés par le client.</p> </section> <section id="twoips"><title>Serveurs virtuels par nom sur plus d'une seule adresse IP.</title> <note> <title>Note&nbsp;:</title><p>Toutes les techniques présentées ici peuvent être étendues à un plus grand nombre d'adresses IP.</p> </note> <p>Le serveur a deux adresses IP. Sur l'une (<code>83.161.120.155</code>), le serveur "principal" <code>server.domain.com</code> doit répondre, et sur l'autre (<code>83.161.120.155</code>), deux serveurs virtuels (ou plus) répondront.</p> <example> <title>Configuration du serveur</title> Listen 80<br /> <br /> # Serveur "principal" sur 83.161.120.155<br /> ServerName server.domain.com<br /> DocumentRoot /www/mainserver<br /> <br /> # l'autre adresse <br /> NameVirtualHost 83.161.120.155<br /> <br /> &lt;VirtualHost 83.161.120.155&gt;<br /> <indent> DocumentRoot /www/example1<br /> ServerName www.example1.com<br /> <br /> # D'autres directives ici ...<br /> <br /> </indent> &lt;/VirtualHost&gt;<br /> <br /> &lt;VirtualHost 83.161.120.155&gt;<br /> <indent> DocumentRoot /www/example2<br /> ServerName www.example2.org<br /> <br /> # D'autres directives ici ...<br /> <br /> </indent> &lt;/VirtualHost&gt; </example> <p>Toute requête arrivant sur une autre adresse que <code>83.161.120.155</code> sera servie par le serveur principal. Les requêtes vers <code>83.161.120.155</code> avec un nom de serveur inconnu, ou sans en-tête <code>Host:</code>, seront servies par <code>www.example1.com</code>.</p> </section> <section id="intraextra"><title>Servir le même contenu sur des adresses IP différentes (telle qu'une adresse interne et une externe).</title> <p>La machine serveur dispose de deux adresses IP (<code>83.161.120.155</code> et <code>83.161.120.155</code>). Cette machine est placée à la fois sur le réseau interne (l'Intranet) et le réseau externe (Internet). Sur Internet, le nom <code>server.example.com</code> pointe vers l'adresse externe (<code>83.161.120.155</code>), mais sur le réseau interne, ce même nom pointe vers l'adresse interne (<code>83.161.120.155</code>).</p> <p>Le serveur peut être configuré pour répondre de la même manière aux requêtes internes et externes, au moyen d'une seule section <code>VirtualHost</code>.</p> <example> <title>Configuration du serveur</title> NameVirtualHost 83.161.120.155<br /> NameVirtualHost 83.161.120.155<br /> <br /> &lt;VirtualHost 83.161.120.155 83.161.120.155&gt;<br /> <indent> DocumentRoot /www/server1<br /> ServerName server.example.com<br /> ServerAlias server<br /> </indent> &lt;/VirtualHost&gt; </example> <p>Ainsi, les requêtes en provenance de chacun des deux réseaux seront servies par le même <code>VirtualHost</code>.</p> <note> <title>Note&nbsp;:</title><p>Sur le réseau interne, il est possible d'utiliser le nom raccourci <code>server</code> au lieu du nom complet <code>server.example.com</code>.</p> <p>Notez également que dans l'exemple précédent, vous pouvez remplacer la liste des adresses IP par des <code>*</code> afin que le serveur réponde de la même manière sur toutes ses adresses.</p> </note> </section> <section id="port"><title>Servir différents sites sur différents ports.</title> <p>Vous disposez de plusieurs domaines pointant sur la même adresse IP et vous voulez également servir de multiples ports. Vous y parviendrez en définissant les ports dans la directive "NameVirtualHost". Si vous tentez d'utiliser &lt;VirtualHost name:port&gt; sans directive NameVirtualHost name:port, ou tentez d'utiliser la directive Listen, votre configuration ne fonctionnera pas.</p> <example> <title>Configuration du serveur</title> Listen 80<br /> Listen 8080<br /> <br /> NameVirtualHost 83.161.120.155:80<br /> NameVirtualHost 83.161.120.155:8080<br /> <br /> &lt;VirtualHost 83.161.120.155:80&gt;<br /> <indent> ServerName www.example1.com<br /> DocumentRoot /www/domain-80<br /> </indent> &lt;/VirtualHost&gt;<br /> <br /> &lt;VirtualHost 83.161.120.155:8080&gt;<br /> <indent> ServerName www.example1.com<br /> DocumentRoot /www/domain-8080<br /> </indent> &lt;/VirtualHost&gt;<br /> <br /> &lt;VirtualHost 83.161.120.155:80&gt;<br /> <indent> ServerName www.example2.org<br /> DocumentRoot /www/otherdomain-80<br /> </indent> &lt;/VirtualHost&gt;<br /> <br /> &lt;VirtualHost 83.161.120.155:8080&gt;<br /> <indent> ServerName www.example2.org<br /> DocumentRoot /www/otherdomain-8080<br /> </indent> &lt;/VirtualHost&gt; </example> </section> <section id="ip"><title>Hébergement virtuel basé sur IP</title> <p>Le serveur dispose de deux adresses IP (<code>83.161.120.155</code> et <code>83.161.120.155</code>) correspondant respectivement aux noms <code>www.example1.com</code> et <code>www.example2.org</code>.</p> <example> <title>Configuration du serveur</title> Listen 80<br /> <br /> &lt;VirtualHost 83.161.120.155&gt;<br /> <indent> DocumentRoot /www/example1<br /> ServerName www.example1.com<br /> </indent> &lt;/VirtualHost&gt;<br /> <br /> &lt;VirtualHost 83.161.120.155&gt;<br /> <indent> DocumentRoot /www/example2<br /> ServerName www.example2.org<br /> </indent> &lt;/VirtualHost&gt; </example> <p>Les requêtes provenant d'adresses non spécifiées dans l'une des directives <code>&lt;VirtualHost&gt;</code> (comme pour <code>localhost</code> par exemple) seront dirigées vers le serveur principal, s'il en existe un.</p> </section> <section id="ipport"><title>Hébergements virtuels mixtes basés sur les ports et sur les IP</title> <p>Le serveur dispose de deux adresses IP (<code>83.161.120.155</code> et <code>83.161.120.155</code>) correspondant respectivement aux noms <code>www.example1.com</code> et <code>www.example2.org</code>. Pour chacun d'eux, nous voulons un hébergement sur les ports 80 et 8080.</p> <example> <title>Configuration du serveur</title> Listen 83.161.120.155:80<br /> Listen 83.161.120.155:8080<br /> Listen 83.161.120.155:80<br /> Listen 83.161.120.155:8080<br /> <br /> &lt;VirtualHost 83.161.120.155:80&gt;<br /> <indent> DocumentRoot /www/example1-80<br /> ServerName www.example1.com<br /> </indent> &lt;/VirtualHost&gt;<br /> <br /> &lt;VirtualHost 83.161.120.155:8080&gt;<br /> <indent> DocumentRoot /www/example1-8080<br /> ServerName www.example1.com<br /> </indent> &lt;/VirtualHost&gt;<br /> <br /> &lt;VirtualHost 83.161.120.155:80&gt;<br /> <indent> DocumentRoot /www/example2-80<br /> ServerName www.example1.org<br /> </indent> &lt;/VirtualHost&gt;<br /> <br /> &lt;VirtualHost 83.161.120.155:8080&gt;<br /> <indent> DocumentRoot /www/example2-8080<br /> ServerName www.example2.org<br /> </indent> &lt;/VirtualHost&gt; </example> </section> <section id="mixed"><title>Hébergements virtuels mixtes basé sur les noms et sur IP</title> <p>Pour certaines adresses, des serveurs virtuels seront définis par nom, et pour d'autres, ils seront définis par IP.</p> <example> <title>Configuration du serveur</title> Listen 80<br /> <br /> NameVirtualHost 83.161.120.155<br /> <br /> &lt;VirtualHost 83.161.120.155&gt;<br /> <indent> DocumentRoot /www/example1<br /> ServerName www.example1.com<br /> </indent> &lt;/VirtualHost&gt;<br /> <br /> &lt;VirtualHost 83.161.120.155&gt;<br /> <indent> DocumentRoot /www/example2<br /> ServerName www.example2.org<br /> </indent> &lt;/VirtualHost&gt;<br /> <br /> &lt;VirtualHost 83.161.120.155&gt;<br /> <indent> DocumentRoot /www/example3<br /> ServerName www.example3.net<br /> </indent> &lt;/VirtualHost&gt;<br /> <br /> # "par-IP"<br /> &lt;VirtualHost 83.161.120.155&gt;<br /> <indent> DocumentRoot /www/example4<br /> ServerName www.example4.edu<br /> </indent> &lt;/VirtualHost&gt;<br /> <br /> &lt;VirtualHost 83.161.120.155&gt;<br /> <indent> DocumentRoot /www/example5<br /> ServerName www.example5.gov<br /> </indent> &lt;/VirtualHost&gt; </example> </section> <section id="proxy"><title>Utilisation simultanée de <code>Virtual_host</code> et de mod_proxy</title> <p>L'exemple suivant montre comment une machine peut mandater un serveur virtuel fonctionnant sur le serveur d'une autre machine. Dans cet exemple, un serveur virtuel de même nom est configuré sur une machine à l'adresse <code>83.161.120.155</code>. La directive <directive module="mod_proxy">ProxyPreserveHost On</directive> est employée pour permette au nom de domaine d'être préservé lors du transfert, au cas où plusieurs noms de domaines cohabitent sur une même machine.</p> <example> &lt;VirtualHost *:*&gt;<br /> ProxyPreserveHost On<br /> ProxyPass / http://83.161.120.155<br /> ProxyPassReverse / http://83.161.120.155/<br /> ServerName hostname.example.com<br /> &lt;/VirtualHost&gt; </example> </section> <section id="default"><title>Utilisation de serveurs virtuels <code>_default_</code></title> <section id="defaultallports"><title>Serveurs virtuels <code>_default_</code> pour tous les ports</title> <p>Exemple de capture de <em>toutes</em> les requêtes émanant d'adresses IP ou de ports non connus, <em>c'est-à-dire</em>, d'un couple adresse/port non traité par aucun autre serveur virtuel.</p> <example> <title>Configuration du serveur</title> &lt;VirtualHost _default_:*&gt;<br /> <indent> DocumentRoot /www/default<br /> </indent> &lt;/VirtualHost&gt; </example> <p>L'utilisation d'un tel serveur virtuel avec un joker pour le port empêche de manière efficace qu'une requête n'atteigne le serveur principal.</p> <p>Un serveur virtuel par défaut ne servira jamais une requête qui est envoyée vers un couple adresse/port utilisée par un serveur virtuel par nom. Si la requête contient un en-tête <code>Host:</code> inconnu, ou si celui-ci est absent, elle sera toujours servie par le serveur virtuel primaire par nom (celui correspondant à ce couple adresse/port trouvé en premier dans le fichier de configuration).</p> <p>Vous pouvez utiliser une directive <directive module="mod_alias">AliasMatch</directive> ou <directive module="mod_rewrite">RewriteRule</directive> afin de réécrire une requête pour une unique page d'information (ou pour un script).</p> </section> <section id="defaultdifferentports"><title>Serveurs virtuels <code>_default_</code> pour des ports différents</title> <p>La configuration est similaire à l'exemple précédent, mais le serveur écoute sur plusieurs ports et un second serveur virtuel <code>_default_</code> pour le port 80 est ajouté.</p> <example> <title>Configuration du serveur</title> &lt;VirtualHost _default_:80&gt;<br /> <indent> DocumentRoot /www/default80<br /> # ...<br /> </indent> &lt;/VirtualHost&gt;<br /> <br /> &lt;VirtualHost _default_:*&gt;<br /> <indent> DocumentRoot /www/default<br /> # ...<br /> </indent> &lt;/VirtualHost&gt; </example> <p>Le serveur virtuel par défaut défini pour le port 80 (il doit impérativement être placé avant un autre serveur virtuel par défaut traitant tous les ports grâce au joker *) capture toutes les requêtes envoyées sur une adresse IP non spécifiée. Le serveur principal n'est jamais utilisé pour servir une requête.</p> </section> <section id="defaultoneport"><title>Serveurs
{'source': 'Apache Software Foundation Public Mail Archives'}