From 6beeb1b708550be0d4a53b272283e17e5e35fe17 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sun, 7 Apr 2024 17:01:30 +0200 Subject: Adding upstream version 2.4.57. Signed-off-by: Daniel Baumann --- docs/manual/howto/access.html | 13 + docs/manual/howto/access.html.en | 229 +++++++++ docs/manual/howto/access.html.es | 236 +++++++++ docs/manual/howto/access.html.fr.utf8 | 242 +++++++++ docs/manual/howto/auth.html | 25 + docs/manual/howto/auth.html.en | 640 ++++++++++++++++++++++++ docs/manual/howto/auth.html.es | 717 +++++++++++++++++++++++++++ docs/manual/howto/auth.html.fr.utf8 | 681 +++++++++++++++++++++++++ docs/manual/howto/auth.html.ja.utf8 | 692 ++++++++++++++++++++++++++ docs/manual/howto/auth.html.ko.euc-kr | 355 +++++++++++++ docs/manual/howto/auth.html.tr.utf8 | 639 ++++++++++++++++++++++++ docs/manual/howto/cgi.html | 21 + docs/manual/howto/cgi.html.en | 601 ++++++++++++++++++++++ docs/manual/howto/cgi.html.es | 619 +++++++++++++++++++++++ docs/manual/howto/cgi.html.fr.utf8 | 643 ++++++++++++++++++++++++ docs/manual/howto/cgi.html.ja.utf8 | 593 ++++++++++++++++++++++ docs/manual/howto/cgi.html.ko.euc-kr | 533 ++++++++++++++++++++ docs/manual/howto/htaccess.html | 25 + docs/manual/howto/htaccess.html.en | 465 +++++++++++++++++ docs/manual/howto/htaccess.html.es | 464 +++++++++++++++++ docs/manual/howto/htaccess.html.fr.utf8 | 512 +++++++++++++++++++ docs/manual/howto/htaccess.html.ja.utf8 | 417 ++++++++++++++++ docs/manual/howto/htaccess.html.ko.euc-kr | 363 ++++++++++++++ docs/manual/howto/htaccess.html.pt-br | 407 +++++++++++++++ docs/manual/howto/http2.html | 13 + docs/manual/howto/http2.html.en | 346 +++++++++++++ docs/manual/howto/http2.html.es | 421 ++++++++++++++++ docs/manual/howto/http2.html.fr.utf8 | 429 ++++++++++++++++ docs/manual/howto/index.html | 25 + docs/manual/howto/index.html.en | 170 +++++++ docs/manual/howto/index.html.es | 163 ++++++ docs/manual/howto/index.html.fr.utf8 | 178 +++++++ docs/manual/howto/index.html.ja.utf8 | 132 +++++ docs/manual/howto/index.html.ko.euc-kr | 124 +++++ docs/manual/howto/index.html.zh-cn.utf8 | 121 +++++ docs/manual/howto/public_html.html | 25 + docs/manual/howto/public_html.html.en | 218 ++++++++ docs/manual/howto/public_html.html.es | 216 ++++++++ docs/manual/howto/public_html.html.fr.utf8 | 235 +++++++++ docs/manual/howto/public_html.html.ja.utf8 | 228 +++++++++ docs/manual/howto/public_html.html.ko.euc-kr | 190 +++++++ docs/manual/howto/public_html.html.tr.utf8 | 229 +++++++++ docs/manual/howto/reverse_proxy.html | 9 + docs/manual/howto/reverse_proxy.html.en | 360 ++++++++++++++ docs/manual/howto/reverse_proxy.html.fr.utf8 | 381 ++++++++++++++ docs/manual/howto/ssi.html | 21 + docs/manual/howto/ssi.html.en | 503 +++++++++++++++++++ docs/manual/howto/ssi.html.es | 361 ++++++++++++++ docs/manual/howto/ssi.html.fr.utf8 | 518 +++++++++++++++++++ docs/manual/howto/ssi.html.ja.utf8 | 515 +++++++++++++++++++ docs/manual/howto/ssi.html.ko.euc-kr | 458 +++++++++++++++++ 51 files changed, 16721 insertions(+) create mode 100644 docs/manual/howto/access.html create mode 100644 docs/manual/howto/access.html.en create mode 100644 docs/manual/howto/access.html.es create mode 100644 docs/manual/howto/access.html.fr.utf8 create mode 100644 docs/manual/howto/auth.html create mode 100644 docs/manual/howto/auth.html.en create mode 100644 docs/manual/howto/auth.html.es create mode 100644 docs/manual/howto/auth.html.fr.utf8 create mode 100644 docs/manual/howto/auth.html.ja.utf8 create mode 100644 docs/manual/howto/auth.html.ko.euc-kr create mode 100644 docs/manual/howto/auth.html.tr.utf8 create mode 100644 docs/manual/howto/cgi.html create mode 100644 docs/manual/howto/cgi.html.en create mode 100644 docs/manual/howto/cgi.html.es create mode 100644 docs/manual/howto/cgi.html.fr.utf8 create mode 100644 docs/manual/howto/cgi.html.ja.utf8 create mode 100644 docs/manual/howto/cgi.html.ko.euc-kr create mode 100644 docs/manual/howto/htaccess.html create mode 100644 docs/manual/howto/htaccess.html.en create mode 100644 docs/manual/howto/htaccess.html.es create mode 100644 docs/manual/howto/htaccess.html.fr.utf8 create mode 100644 docs/manual/howto/htaccess.html.ja.utf8 create mode 100644 docs/manual/howto/htaccess.html.ko.euc-kr create mode 100644 docs/manual/howto/htaccess.html.pt-br create mode 100644 docs/manual/howto/http2.html create mode 100644 docs/manual/howto/http2.html.en create mode 100644 docs/manual/howto/http2.html.es create mode 100644 docs/manual/howto/http2.html.fr.utf8 create mode 100644 docs/manual/howto/index.html create mode 100644 docs/manual/howto/index.html.en create mode 100644 docs/manual/howto/index.html.es create mode 100644 docs/manual/howto/index.html.fr.utf8 create mode 100644 docs/manual/howto/index.html.ja.utf8 create mode 100644 docs/manual/howto/index.html.ko.euc-kr create mode 100644 docs/manual/howto/index.html.zh-cn.utf8 create mode 100644 docs/manual/howto/public_html.html create mode 100644 docs/manual/howto/public_html.html.en create mode 100644 docs/manual/howto/public_html.html.es create mode 100644 docs/manual/howto/public_html.html.fr.utf8 create mode 100644 docs/manual/howto/public_html.html.ja.utf8 create mode 100644 docs/manual/howto/public_html.html.ko.euc-kr create mode 100644 docs/manual/howto/public_html.html.tr.utf8 create mode 100644 docs/manual/howto/reverse_proxy.html create mode 100644 docs/manual/howto/reverse_proxy.html.en create mode 100644 docs/manual/howto/reverse_proxy.html.fr.utf8 create mode 100644 docs/manual/howto/ssi.html create mode 100644 docs/manual/howto/ssi.html.en create mode 100644 docs/manual/howto/ssi.html.es create mode 100644 docs/manual/howto/ssi.html.fr.utf8 create mode 100644 docs/manual/howto/ssi.html.ja.utf8 create mode 100644 docs/manual/howto/ssi.html.ko.euc-kr (limited to 'docs/manual/howto') diff --git a/docs/manual/howto/access.html b/docs/manual/howto/access.html new file mode 100644 index 0000000..2e5d6ab --- /dev/null +++ b/docs/manual/howto/access.html @@ -0,0 +1,13 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: access.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: access.html.es +Content-Language: es +Content-type: text/html; charset=ISO-8859-1 + +URI: access.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/howto/access.html.en b/docs/manual/howto/access.html.en new file mode 100644 index 0000000..1bd3e0e --- /dev/null +++ b/docs/manual/howto/access.html.en @@ -0,0 +1,229 @@ + + + + + +Access Control - Apache HTTP Server Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.4

+
+
<-
+

Access Control

+
+

Available Languages:  en  | + es  | + fr 

+
+ +

Access control refers to any means of controlling access to any + resource. This is separate from authentication and authorization.

+
+ +
top
+
+

Related Modules and Directives

+ +

Access control can be done by several different modules. The most + important of these are mod_authz_core and + mod_authz_host. Also discussed in this document + is access control using mod_rewrite.

+ +
top
+
+

Access control by host

+

+ If you wish to restrict access to portions of your site based on the + host address of your visitors, this is most easily done using + mod_authz_host. +

+ +

The Require + provides a variety of different ways to allow or deny access to + resources. In conjunction with the RequireAll, RequireAny, and RequireNone directives, these + requirements may be combined in arbitrarily complex ways, to enforce + whatever your access policy happens to be.

+ +

+ The Allow, + Deny, and + Order directives, + provided by mod_access_compat, are deprecated and + will go away in a future version. You should avoid using them, and + avoid outdated tutorials recommending their use. +

+ +

The usage of these directives is:

+ + 
Require host address
+Require ip ip.address
+ + +

In the first form, address is a fully qualified + domain name (or a partial domain name); you may provide multiple + addresses or domain names, if desired.

+ +

In the second form, ip.address is an IP address, a + partial IP address, a network/netmask pair, or a network/nnn CIDR + specification. Either IPv4 or IPv6 addresses may be used.

+ +

See the + mod_authz_host documentation for further examples of this + syntax.

+ +

You can insert not to negate a particular requirement. + Note, that since a not is a negation of a value, it cannot + be used by itself to allow or deny a request, as not true + does not constitute false. Thus, to deny a visit using a negation, + the block must have one element that evaluates as true or false. + For example, if you have someone spamming your message + board, and you want to keep them out, you could do the + following:

+ + 
<RequireAll>
+    Require all granted
+    Require not ip 10.252.46.165
+</RequireAll>
+ + +

Visitors coming from that address (10.252.46.165) + will not be able to see the content covered by this directive. If, + instead, you have a machine name, rather than an IP address, you + can use that.

+ + 
Require not host host.example.com
+
+ + +

And, if you'd like to block access from an entire domain, + you can specify just part of an address or domain name:

+ + 
Require not ip 192.168.205
+Require not host phishers.example.com moreidiots.example
+Require not host gov
+ + +

Use of the RequireAll, RequireAny, and RequireNone directives may be + used to enforce more complex sets of requirements.

+ +
top
+
+

Access control by arbitrary variables

+ +

Using the <If>, + you can allow or deny access based on arbitrary environment + variables or request header values. For example, to deny access + based on user-agent (the browser type) you might do the + following:

+ + 
<If "%{HTTP_USER_AGENT} == 'BadBot'">
+    Require all denied
+</If>
+ + +

Using the Require + expr syntax, this could also be written as:

+ + + 
Require expr %{HTTP_USER_AGENT} != 'BadBot'
+ + +

Warning:

+

Access control by User-Agent is an unreliable technique, + since the User-Agent header can be set to anything at all, + at the whim of the end user.

+
+ +

See the expressions document for a + further discussion of what expression syntaxes and variables are + available to you.

+ +
top
+
+

Access control with mod_rewrite

+ +

The [F] RewriteRule flag causes a 403 Forbidden + response to be sent. Using this, you can deny access to a resource based + on arbitrary criteria.

+ +

For example, if you wish to block access to a resource between 8pm + and 7am, you can do this using mod_rewrite.

+ + 
RewriteEngine On
+RewriteCond "%{TIME_HOUR}" ">=20" [OR]
+RewriteCond "%{TIME_HOUR}" "<07"
+RewriteRule "^/fridge"     "-" [F]
+ + +

This will return a 403 Forbidden response for any request after 8pm + or before 7am. This technique can be used for any criteria that you wish + to check. You can also redirect, or otherwise rewrite these requests, if + that approach is preferred.

+ +

The <If> directive, + added in 2.4, replaces many things that mod_rewrite has + traditionally been used to do, and you should probably look there first + before resorting to mod_rewrite.

+ +
top
+
+

More information

+ +

The expression engine gives you a + great deal of power to do a variety of things based on arbitrary + server variables, and you should consult that document for more + detail.

+ +

Also, you should read the mod_authz_core + documentation for examples of combining multiple access requirements + and specifying how they interact.

+ +

See also the Authentication and Authorization + howto.

+
+
+

Available Languages:  en  | + es  | + fr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/access.html.es b/docs/manual/howto/access.html.es new file mode 100644 index 0000000..c5e562a --- /dev/null +++ b/docs/manual/howto/access.html.es @@ -0,0 +1,236 @@ + + + + + +Control de Acceso - Servidor HTTP Apache Versión 2.4 + + + + + + +
+

Módulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

+

Versión 2.4 del Servidor HTTP Apache

+
+
<-
+

Control de Acceso

+
+

Idiomas disponibles:  en  | + es  | + fr 

+
+ +

El control de acceso, hace referencia a todos los medios que proporcionan + una forma de controlar el acceso a cualquier recurso. Esta parte está + separada de autenticación y autorización.

+
+ +
top
+
+

Módulos y Directivas relacionados

+ +

El control de acceso puede efectuarse mediante diferentes módulos. Los + más importantes de éstos son mod_authz_core y + mod_authz_host. También se habla en este documento de + el control de acceso usando el módulo mod_rewrite.

+ +
top
+
+

Control de Acceso por host

+

+ Si lo que se quiere es restringir algunas zonas del sitio web, basándonos + en la dirección del visitante, esto puede ser realizado de manera + fácil con el módulo mod_authz_host. +

+ +

La directiva Require + proporciona una variedad de diferentes maneras de permitir o denegar el acceso a los recursos. Además puede ser usada junto con las directivas:RequireAll, RequireAny, y RequireNone, estos requerimientos pueden + ser combinados de forma compleja y arbitraria, para cumplir cualquiera que + sean tus políticas de acceso.

+ +

+ Las directivas Allow, + Deny, y + Order, + proporcionadas por mod_access_compat, están obsoletas y + serán quitadas en futuras versiones. Deberá evitar su uso, y también + los tutoriales desactualizaos que recomienden su uso. +

+ +

El uso de estas directivas es:

+ + + 
Require host address 

+Require ip ip.address
+
+ + +

En la primera línea, address es el FQDN de un nombre de + dominio (o un nombre parcial del dominio); puede proporcionar múltiples + direcciones o nombres de dominio, si se desea. +

+ +

En la segunda línea, ip.address es la dirección IP, una + dirección IP parcial, una red con su máscara, o una especificación red/nnn + CIDR. Pueden usarse tanto IPV4 como IPV6.

+ +

Consulte también la + documentación de mod_authz_host para otros ejemplos de esta sintaxis. +

+ +

Puede ser insertado not para negar un requisito en particular. + Note que, ya que not es una negación de un valor, no puede ser + usado por si solo para permitir o denegar una petición, como not true + que no contituye ser false. En consecuencia, para denegar una + visita usando una negación, el bloque debe tener un elemento que se evalúa como + verdadero o falso. Por ejemplo, si tienes a alguien espameandote tu tablón de + mensajes, y tu quieres evitar que entren o dejarlos fuera, puedes realizar + lo siguiente: +

+ + 
<RequireAll>
+    Require all granted
+    Require not ip 10.252.46.165
+</RequireAll>
+ + +

Los visitantes que vengan desde la IP que se configura (10.252.46.165) + no tendrán acceso al contenido que cubre esta directiva. Si en cambio, lo que se + tiene es el nombre de la máquina, en vez de la IP, podrás usar:

+ + 
Require not host host.example.com
+
+ + +

Y, Si lo que se quiere es bloquear el acceso desde dominio especifico, + podrás especificar parte de una dirección o nombre de dominio:

+ + 
Require not ip 192.168.205
+Require not host phishers.example.com moreidiots.example
+Require not host gov
+ + +

Uso de las directivas RequireAll, RequireAny, y RequireNone pueden ser usadas + para forzar requisitos más complejos.

+ +
top
+
+

Control de acceso por variables arbitrarias.

+ +

Haciendo el uso de <If>, + puedes permitir o denegar el acceso basado en variables de entrono arbitrarias + o en los valores de las cabeceras de las peticiones. Por ejemplo para denegar + el acceso basándonos en el "user-agent" (tipo de navegador así como Sistema Operativo) + puede que hagamos lo siguiente: +

+ + 
<If "%{HTTP_USER_AGENT} == 'BadBot'">
+    Require all denied
+</If>
+ + +

Usando la sintaxis de Require + expr , esto también puede ser escrito de la siguiente forma: +

+ + + 
Require expr %{HTTP_USER_AGENT} != 'BadBot'
+ + +

Advertencia:

+

El control de acceso por User-Agent es una técnica poco fiable, + ya que la cabecera de User-Agent puede ser modificada y establecerse + al antojo del usuario.

+
+ +

Vea también la página de expresiones + para una mayor aclaración de que sintaxis tienen las expresiones y que + variables están disponibles.

+ +
top
+
+

Control de acceso con mod_rewrite

+ +

El flag [F] de RewriteRule causa una respuesta 403 Forbidden + para ser enviada. USando esto, podrá denegar el acceso a recursos basándose + en criterio arbitrario.

+ +

Por ejemplo, si lo que desea es bloquear un recurso entre las 8pm y las + 7am, podrá hacerlo usando mod_rewrite:

+ + 
RewriteEngine On
+RewriteCond "%{TIME_HOUR}" ">=20" [OR]
+RewriteCond "%{TIME_HOUR}" "<07"
+RewriteRule "^/fridge"     "-"       [F]
+ + +

Esto devolverá una respuesta de error 403 Forbidden para cualquier petición + después de las 8pm y antes de las 7am. Esta técnica puede ser usada para cualquier + criterio que desee usar. También puede redireccionar, o incluso reescribir estas + peticiones, si se prefiere ese enfoque. +

+ +

La directiva <If>, + añadida en la 2.4, sustituye muchas cosas que mod_rewrite + tradicionalmente solía hacer, y deberá comprobar estas antes de recurrir a +

+ +
top
+
+

Más información

+ +

El motor de expresiones le da una gran + capacidad de poder para hacer una gran variedad de cosas basadas en + las variables arbitrarias del servidor, y debe consultar este + documento para más detalles.

+ +

También, deberá leer la documentación de mod_authz_core + para ejemplos de combinaciones de múltiples requisitos de acceso y especificar + cómo interactúan. +

+ +

Vea también los howtos de Authenticación y Autorización +

+
+
+

Idiomas disponibles:  en  | + es  | + fr 

+
top

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/access.html.fr.utf8 b/docs/manual/howto/access.html.fr.utf8 new file mode 100644 index 0000000..057d8e3 --- /dev/null +++ b/docs/manual/howto/access.html.fr.utf8 @@ -0,0 +1,242 @@ + + + + + +Contrôle d'accès - Serveur HTTP Apache Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.4

+
+
<-
+

Contrôle d'accès

+
+

Langues Disponibles:  en  | + es  | + fr 

+
+ +

Le contrôle d'accès fait référence à tout concept de contrôle + d'accès à une ressource quelconque. Il est distinct du processus d'authentification et d'autorisation.

+
+ +
top
+
+

Modules et directives concernés

+ +

Plusieurs modules peuvent intervenir dans le contrôle d'accès. + Les plus importants sont mod_authz_core et + mod_authz_host. Ce document illustre aussi comment + utiliser mod_rewrite pour le contrôle + d'accès.

+ +
top
+
+

Contrôle d'accès en fonction de l'hôte du +client

+

+ Si vous souhaitez restreindre l'accès à certaines parties de votre + site web en fonction de l'addresse de l'hôte de vos visiteurs, le + plus simple pour y parvenir consiste à utiliser le module + mod_authz_host. +

+ +

La directive Require permet d'accorder ou + d'interdire l'accès à certaines ressources de différentes manières. + Ces critères d'accès, en conjonction avec les directives RequireAll, RequireAny, et RequireNone, peuvent être + combinés d'une manière suffisamment complexe pour + satisfaire votre politique de contrôle d'accès.

+ +

+ Les directives Allow, Deny, et Order fournies par le module + mod_access_compat sont obsolètes, et sont appelées à + disparaître dans les versions futures. Il est donc déconseillé de + les utiliser, et de se fier aux tutoriels qui recommandent leur + utilisation. +

+ +

Les directives Require s'utilisent comme suit :

+ + 
Require host address
+Require ip ip.address
+ + +

Dans la première forme, nom-hôte est un nom de domaine + pleinement qualifié (fqdn), ou un nom de domaine partiel ; vous + pouvez spécifier plusieurs noms de domaines, si vous le désirez.

+ +

Dans la seconde forme, adresse-ip est une adresse IP + complète, une adresse IP partielle, une paire réseau/masque de + sous-réseau ou une spécification CIDR de la forme réseau/nnn. Il est + possible de spécifier des adresses IPv4 ou IPv6.

+ +

Voir la + documentation de mod_authz_host pour d'autres exemples de cette + syntaxe.

+ +

Vous pouvez insérer le mot-clé not pour inverser un + critère particulier. Notez que le mot not étant la + négation d'une valeur, il ne peut pas être utilisé pour autoriser + ou interdire une requête, car non vrai ne + sera pas interpreté par httpd comme faux. Ainsi, pour interdire la + visite d'une page à l'aide d'une négation, le bloc doit contenir un + élément évalué à vrai ou faux. + Par exemple, si quelqu'un est en train d'inonder + votre forum de messages indésirables, vous pouvez ajouter cette ligne pour lui refuser + l'accès :

+ + 
<RequireAll>
+    Require all granted
+    Require not ip 10.252.46.165
+</RequireAll>
+ + +

Les visiteurs possédant cette adresse (10.252.46.165) ne pourront pas voir le + contenu concerné par cette directive. Si vous voulez interdire + l'accès à une machine en fonction de son nom, vous pouvez ajouter + ceci :

+ + 
Require not host host.example.com
+
+ + +

Et si vous voulez interdire l'accès à un domaine particulier, + vous pouvez spécifier des adresses IP partielles ou des noms de + domaine, comme ceci :

+ + 
Require not ip 192.168.205
+Require not host phishers.example.com moreidiots.example
+Require not host gov
+ + +

Les directives RequireAll, RequireAny, et RequireNone permettent également de préciser des + critères d'accès plus complexes.

+ +
top
+
+

Contrôle d'accès en fonction de variables +arbitraires

+ +

Vous pouvez accorder ou refuser l'accès en fonction de variables + d'environnement arbitraires ou de valeurs d'en-têtes de la requête + en utilisant la directive <If>. Par exemple, pour interdire l'accès en + fonction du user-agent (le type de navigateur), vous pouvez + spécifier ceci :

+ + 
<If "%{HTTP_USER_AGENT} == 'BadBot'">
+    Require all denied
+</If>
+ + +

La syntaxe expr de la directive Require permet de réécrire + l'exemple précédent de la manière suivante :

+ + + 
Require expr %{HTTP_USER_AGENT} != 'BadBot'
+ + +

Avertissement :

+

Contrôler l'accès en fonction de l'en-tête + User-Agent n'est pas une technique fiable, car cet + en-tête peut être défini à une valeur quelconque, selon le bon + vouloir de l'utilisateur.

+
+ +

Voir le document à propos des expressions pour une description plus + approfondie des syntaxes d'expressions et des variables disponibles.

+ +
top
+
+

Utilisation de mod_rewrite pour le contrôle +d'accès

+ +

Le drapeau [F] de la directive RewriteRule permet d'envoyer une + réponse de type 403 Forbidden. Il vous permet donc d'interdire + l'accès à une ressource en fonction d'un critère arbitraire.

+ +

Par exemple, pour bloquer l'accès à une ressources entre 20h et + 7h du matin, vous pouvez utiliser mod_rewrite :

+ + 
RewriteEngine On
+RewriteCond "%{TIME_HOUR}" ">=20" [OR]
+RewriteCond "%{TIME_HOUR}" "<07"
+RewriteRule "^/fridge"     "-" [F]
+ + +

Toute requête arrivant après 20h ou avant 7h du matin provoquera + l'envoi d'une réponse de type 403 Forbidden. Vous pouvez utiliser + cette technique pour vérifier toutes sortes de critères. En outre, + si vous le préférez, vous pouvez rediriger ou réécrire la requête.

+ +

Notez que la directive <If>, introduite à partir de la version 2.4, + permet de remplacer le module mod_rewrite dans de + nombreuses situations où il était traditionnellement utilisé, et + il sera probablement préférable pour vous de tenter de l'utiliser + avant de vous tourner vers mod_rewrite.

+ +
top
+
+

Informations complémentaires

+ +

Le moteur d'expressions vous fournit + une grande puissance d'action en fonction de variables du serveur + arbitraires, et il vous est conseillé de consulter le document + correspondant pour plus de détails.

+ +

De même, vous devez lire la documentation du module + mod_authz_core pour des exemples de combinaison de + critères d'accès multiples, et en particulier la manière dont ces + derniers interagissent.

+ +

Voir aussi le How-To Authentification and + autorisation.

+
+
+

Langues Disponibles:  en  | + es  | + fr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/auth.html b/docs/manual/howto/auth.html new file mode 100644 index 0000000..5e5578d --- /dev/null +++ b/docs/manual/howto/auth.html @@ -0,0 +1,25 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: auth.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: auth.html.es +Content-Language: es +Content-type: text/html; charset=ISO-8859-1 + +URI: auth.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 + +URI: auth.html.ja.utf8 +Content-Language: ja +Content-type: text/html; charset=UTF-8 + +URI: auth.html.ko.euc-kr +Content-Language: ko +Content-type: text/html; charset=EUC-KR + +URI: auth.html.tr.utf8 +Content-Language: tr +Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/howto/auth.html.en b/docs/manual/howto/auth.html.en new file mode 100644 index 0000000..d8a9b0e --- /dev/null +++ b/docs/manual/howto/auth.html.en @@ -0,0 +1,640 @@ + + + + + +Authentication and Authorization - Apache HTTP Server Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.4

+
+
<-
+

Authentication and Authorization

+
+

Available Languages:  en  | + es  | + fr  | + ja  | + ko  | + tr 

+
+ +

Authentication is any process by which you verify that + someone is who they claim they are. Authorization is any + process by which someone is allowed to be where they want to + go, or to have information that they want to have.

+ +

For general access control, see the Access + Control How-To.

+
+ +
top
+
+

Related Modules and Directives

+ +

There are three types of modules involved in the authentication and +authorization process. You will usually need to choose at least one +module from each group.

+ + + +

In addition to these modules, there are also + mod_authn_core and + mod_authz_core. These modules implement core + directives that are core to all auth modules.

+ +

The module mod_authnz_ldap is both an + authentication and authorization provider. The module + mod_authz_host provides authorization + and access control based on hostname, IP address or characteristics + of the request, but is not part of the authentication provider + system. For backwards compatibility with the mod_access, there is + a new module mod_access_compat.

+ +

You probably also want to take a look at the Access Control howto, which discusses the + various ways to control access to your server.

+ +
top
+
+

Introduction

+

If you have information on your web site that is sensitive + or intended for only a small group of people, the techniques in + this article will help you make sure that the people that see + those pages are the people that you wanted to see them.

+ +

This article covers the "standard" way of protecting parts + of your web site that most of you are going to use.

+ +

Note:

+

If your data really needs to be secure, consider using + mod_ssl in addition to any authentication.

+
+
top
+
+

The Prerequisites

+

The directives discussed in this article will need to go + either in your main server configuration file (typically in a + <Directory> section), or + in per-directory configuration files (.htaccess files).

+ +

If you plan to use .htaccess files, you will + need to have a server configuration that permits putting + authentication directives in these files. This is done with the + AllowOverride directive, which + specifies which directives, if any, may be put in per-directory + configuration files.

+ +

Since we're talking here about authentication, you will need + an AllowOverride directive like the + following:

+ + 
AllowOverride AuthConfig
+ + +

Or, if you are just going to put the directives directly in + your main server configuration file, you will of course need to + have write permission to that file.

+ +

And you'll need to know a little bit about the directory + structure of your server, in order to know where some files are + kept. This should not be terribly difficult, and I'll try to + make this clear when we come to that point.

+ +

You will also need to make sure that the modules + mod_authn_core and mod_authz_core + have either been built into the httpd binary or loaded by the + httpd.conf configuration file. Both of these modules provide core + directives and functionality that are critical to the configuration + and use of authentication and authorization in the web server.

+
top
+
+

Getting it working

+

Here's the basics of password protecting a directory on your + server.

+ +

First, you need to create a password file. Exactly how you do + this will vary depending on what authentication provider you have + chosen. More on that later. To start with, we'll use a text password + file.

+ +

This file should be + placed somewhere not accessible from the web. This is so that + folks cannot download the password file. For example, if your + documents are served out of /usr/local/apache/htdocs, you + might want to put the password file(s) in + /usr/local/apache/passwd.

+ +

To create the file, use the htpasswd utility that + came with Apache. This will be located in the bin directory + of wherever you installed Apache. If you have installed Apache from + a third-party package, it may be in your execution path.

+ +

To create the file, type:

+ +

+ htpasswd -c /usr/local/apache/passwd/passwords rbowen +

+ +

htpasswd will ask you for the password, and + then ask you to type it again to confirm it:

+ +

+ # htpasswd -c /usr/local/apache/passwd/passwords rbowen
+ New password: mypassword
+ Re-type new password: mypassword
+ Adding password for user rbowen +

+ +

If htpasswd is not in your path, of course + you'll have to type the full path to the file to get it to run. + With a default installation, it's located at + /usr/local/apache2/bin/htpasswd

+ +

Next, you'll need to configure the server to request a + password and tell the server which users are allowed access. + You can do this either by editing the httpd.conf + file or using an .htaccess file. For example, if + you wish to protect the directory + /usr/local/apache/htdocs/secret, you can use the + following directives, either placed in the file + /usr/local/apache/htdocs/secret/.htaccess, or + placed in httpd.conf inside a <Directory + "/usr/local/apache/htdocs/secret"> section.

+ + 
AuthType Basic
+AuthName "Restricted Files"
+# (Following line optional)
+AuthBasicProvider file
+AuthUserFile "/usr/local/apache/passwd/passwords"
+Require user rbowen
+ + +

Let's examine each of those directives individually. The AuthType directive selects + the method that is used to authenticate the user. The most + common method is Basic, and this is the method + implemented by mod_auth_basic. It is important to be aware, + however, that Basic authentication sends the password from the client to + the server unencrypted. This method should therefore not be used for + highly sensitive data, unless accompanied by mod_ssl. + Apache supports one other authentication method: + AuthType Digest. This method is implemented by mod_auth_digest and was intended to be more secure. This is no + longer the case and the connection should be encrypted with mod_ssl instead.

+ +

The AuthName directive sets + the Realm to be used in the authentication. The realm serves + two major functions. First, the client often presents this information to + the user as part of the password dialog box. Second, it is used by the + client to determine what password to send for a given authenticated + area.

+ +

So, for example, once a client has authenticated in the + "Restricted Files" area, it will automatically + retry the same password for any area on the same server that is + marked with the "Restricted Files" Realm. + Therefore, you can prevent a user from being prompted more than + once for a password by letting multiple restricted areas share + the same realm. Of course, for security reasons, the client + will always need to ask again for the password whenever the + hostname of the server changes.

+ +

The AuthBasicProvider is, + in this case, optional, since file is the default value + for this directive. You'll need to use this directive if you are + choosing a different source for authentication, such as + mod_authn_dbm or mod_authn_dbd.

+ +

The AuthUserFile + directive sets the path to the password file that we just + created with htpasswd. If you have a large number + of users, it can be quite slow to search through a plain text + file to authenticate the user on each request. Apache also has + the ability to store user information in fast database files. + The mod_authn_dbm module provides the AuthDBMUserFile directive. These + files can be created and manipulated with the dbmmanage and htdbm programs. Many + other types of authentication options are available from third + party modules.

+ +

Finally, the Require + directive provides the authorization part of the process by + setting the user that is allowed to access this region of the + server. In the next section, we discuss various ways to use the + Require directive.

+
top
+
+

Letting more than one +person in

+

The directives above only let one person (specifically + someone with a username of rbowen) into the + directory. In most cases, you'll want to let more than one + person in. This is where the AuthGroupFile comes in.

+ +

If you want to let more than one person in, you'll need to + create a group file that associates group names with a list of + users in that group. The format of this file is pretty simple, + and you can create it with your favorite editor. The contents + of the file will look like this:

+ +

+ GroupName: rbowen dpitts sungo rshersey +

+ +

That's just a list of the members of the group in a long + line separated by spaces.

+ +

To add a user to your already existing password file, + type:

+ +

+ htpasswd /usr/local/apache/passwd/passwords dpitts +

+ +

You'll get the same response as before, but it will be + appended to the existing file, rather than creating a new file. + (It's the -c that makes it create a new password + file).

+ +

Now, you need to modify your .htaccess file or + <Directory> block + to look like the following:

+ + 
AuthType Basic
+AuthName "By Invitation Only"
+# Optional line:
+AuthBasicProvider file
+AuthUserFile "/usr/local/apache/passwd/passwords"
+AuthGroupFile "/usr/local/apache/passwd/groups"
+Require group GroupName
+ + +

Now, anyone that is listed in the group GroupName, + and has an entry in the password file, will be let in, if + they type the correct password.

+ +

There's another way to let multiple users in that is less + specific. Rather than creating a group file, you can just use + the following directive:

+ + 
Require valid-user
+ + +

Using that rather than the Require user rbowen + line will allow anyone in that is listed in the password file, + and who correctly enters their password.

+
top
+
+

Possible problems

+

Because of the way that Basic authentication is specified, + your username and password must be verified every time you + request a document from the server. This is even if you're + reloading the same page, and for every image on the page (if + they come from a protected directory). As you can imagine, this + slows things down a little. The amount that it slows things + down is proportional to the size of the password file, because + it has to open up that file, and go down the list of users + until it gets to your name. And it has to do this every time a + page is loaded.

+ +

A consequence of this is that there's a practical limit to + how many users you can put in one password file. This limit + will vary depending on the performance of your particular + server machine, but you can expect to see slowdowns once you + get above a few hundred entries, and may wish to consider a + different authentication method at that time.

+
top
+
+

Alternate password storage

+ +

Because storing passwords in plain text files has the above + problems, you may wish to store your passwords somewhere else, such + as in a database.

+ +

mod_authn_dbm and mod_authn_dbd are two + modules which make this possible. Rather than selecting AuthBasicProvider file, instead + you can choose dbm or dbd as your storage + format.

+ +

To select a dbm file rather than a text file, for example:

+ + 
<Directory "/www/docs/private">
+    AuthName "Private"
+    AuthType Basic
+    AuthBasicProvider dbm
+    AuthDBMUserFile "/www/passwords/passwd.dbm"
+    Require valid-user
+</Directory>
+ + +

Other options are available. Consult the + mod_authn_dbm documentation for more details.

+
top
+
+

Using multiple providers

+ +

With the introduction of the new provider based authentication and + authorization architecture, you are no longer locked into a single + authentication or authorization method. In fact any number of the + providers can be mixed and matched to provide you with exactly the + scheme that meets your needs. In the following example, both the + file and LDAP based authentication providers are being used.

+ + 
<Directory "/www/docs/private">
+    AuthName "Private"
+    AuthType Basic
+    AuthBasicProvider file ldap
+    AuthUserFile "/usr/local/apache/passwd/passwords"
+    AuthLDAPURL ldap://ldaphost/o=yourorg
+    Require valid-user
+</Directory>
+ + +

In this example the file provider will attempt to authenticate + the user first. If it is unable to authenticate the user, the LDAP + provider will be called. This allows the scope of authentication + to be broadened if your organization implements more than + one type of authentication store. Other authentication and authorization + scenarios may include mixing one type of authentication with a + different type of authorization. For example, authenticating against + a password file yet authorizing against an LDAP directory.

+ +

Just as multiple authentication providers can be implemented, multiple + authorization methods can also be used. In this example both file group + authorization as well as LDAP group authorization is being used.

+ + 
<Directory "/www/docs/private">
+    AuthName "Private"
+    AuthType Basic
+    AuthBasicProvider file
+    AuthUserFile "/usr/local/apache/passwd/passwords"
+    AuthLDAPURL ldap://ldaphost/o=yourorg
+    AuthGroupFile "/usr/local/apache/passwd/groups"
+    Require group GroupName
+    Require ldap-group cn=mygroup,o=yourorg
+</Directory>
+ + +

To take authorization a little further, authorization container + directives such as + <RequireAll> + and + <RequireAny> + allow logic to be applied so that the order in which authorization + is handled can be completely controlled through the configuration. + See Authorization + Containers for an example of how they may be applied.

+ +
top
+
+

Beyond just authorization

+ +

The way that authorization can be applied is now much more flexible + than just a single check against a single data store. Ordering, logic + and choosing how authorization will be done is now possible.

+ +

Applying logic and ordering

+

Controlling how and in what order authorization will be applied + has been a bit of a mystery in the past. In Apache 2.2 a provider-based + authentication mechanism was introduced to decouple the actual + authentication process from authorization and supporting functionality. + One of the side benefits was that authentication providers could be + configured and called in a specific order which didn't depend on the + load order of the auth module itself. This same provider based mechanism + has been brought forward into authorization as well. What this means is + that the Require directive + not only specifies which authorization methods should be used, it also + specifies the order in which they are called. Multiple authorization + methods are called in the same order in which the + Require directives + appear in the configuration.

+ +

With the introduction of authorization container directives + such as + <RequireAll> + and + <RequireAny>, + the configuration also has control over when the + authorization methods are called and what criteria determines when + access is granted. See + Authorization Containers + for an example of how they may be used to express complex + authorization logic.

+ +

By default all + Require + directives are handled as though contained within a + <RequireAny> + container directive. In other words, if + any of the specified authorization methods succeed, then authorization + is granted.

+ + + +

Using authorization providers for access control

+

Authentication by username and password is only part of the + story. Frequently you want to let people in based on something + other than who they are. Something such as where they are + coming from.

+ +

The authorization providers all, + env, host and ip let you + allow or deny access based on other host based criteria such as + host name or ip address of the machine requesting a + document.

+ +

The usage of these providers is specified through the + Require directive. + This directive registers the authorization providers + that will be called during the authorization stage of the request + processing. For example:

+ + 
Require ip address
+
+ + +

where address is an IP address (or a partial IP + address) or:

+ + 
Require host domain_name
+
+ + +

where domain_name is a fully qualified domain name + (or a partial domain name); you may provide multiple addresses or + domain names, if desired.

+ +

For example, if you have someone spamming your message + board, and you want to keep them out, you could do the + following:

+ + 
<RequireAll>
+    Require all granted
+    Require not ip 10.252.46.165
+</RequireAll>
+ + +

Visitors coming from that address will not be able to see + the content covered by this directive. If, instead, you have a + machine name, rather than an IP address, you can use that.

+ + 
<RequireAll>
+    Require all granted
+    Require not host host.example.com
+</RequireAll>
+ + +

And, if you'd like to block access from an entire domain, + you can specify just part of an address or domain name:

+ + 
<RequireAll>
+    Require all granted
+    Require not ip 192.168.205
+    Require not host phishers.example.com moreidiots.example
+    Require not host ke
+</RequireAll>
+ + +

Using <RequireAll> + with multiple <Require> directives, each negated with not, + will only allow access, if all of negated conditions are true. In other words, + access will be blocked, if any of the negated conditions fails.

+ + + +

Access Control backwards compatibility

+

One of the side effects of adopting a provider based mechanism for + authentication is that the previous access control directives + Order, + Allow, + Deny and + Satisfy are no longer needed. + However to provide backwards compatibility for older configurations, these + directives have been moved to the mod_access_compat module.

+ +

Note

+

The directives provided by mod_access_compat have + been deprecated by mod_authz_host. + Mixing old directives like Order, Allow or Deny with new ones like + Require is technically possible + but discouraged. The mod_access_compat module was created to support + configurations containing only old directives to facilitate the 2.4 upgrade. + Please check the upgrading guide for more + information. +

+
+ + +
top
+
+

Authentication Caching

+

There may be times when authentication puts an unacceptable load + on a provider or on your network. This is most likely to affect users + of mod_authn_dbd (or third-party/custom providers). + To deal with this, HTTPD 2.3/2.4 introduces a new caching provider + mod_authn_socache to cache credentials and reduce + the load on the origin provider(s).

+

This may offer a substantial performance boost to some users.

+
top
+
+

More information

+

You should also read the documentation for + mod_auth_basic and mod_authz_host + which contain some more information about how this all works. The + directive <AuthnProviderAlias> can also help + in simplifying certain authentication configurations.

+ +

The various ciphers supported by Apache for authentication data are + explained in Password + Encryptions.

+ +

And you may want to look at the Access + Control howto, which discusses a number of related topics.

+ +
+
+

Available Languages:  en  | + es  | + fr  | + ja  | + ko  | + tr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/auth.html.es b/docs/manual/howto/auth.html.es new file mode 100644 index 0000000..fd72860 --- /dev/null +++ b/docs/manual/howto/auth.html.es @@ -0,0 +1,717 @@ + + + + + +Autenticación y Autorización - Servidor HTTP Apache Versión 2.4 + + + + + + +
+

Módulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

+

Versión 2.4 del Servidor HTTP Apache

+
+
<-
+

Autenticación y Autorización

+
+

Idiomas disponibles:  en  | + es  | + fr  | + ja  | + ko  | + tr 

+
+
Esta traducción podría estar + obsoleta. Consulte la versión en inglés de la + documentación para comprobar si se han producido cambios + recientemente.
+ +

Autenticación es cualquier proceso por el cuál se verifica que uno es + quien dice ser. Autorización es cualquier proceso en el cuál cualquiera + está permitido a estar donde se quiera, o tener información la cuál se + quiera tener. +

+ +

Para información de control de acceso de forma genérica visiteHow to de Control de Acceso.

+
+ +
top
+
+

Módulos y Directivas Relacionados

+ +

Hay tres tipos de módulos involucrados en los procesos de la autenticación + y autorización. Normalmente deberás escoger al menos un módulo de cada grupo.

+ + + +

A parte de éstos módulos, también están + mod_authn_core y + mod_authz_core. Éstos módulos implementan las directivas + esenciales que son el centro de todos los módulos de autenticación.

+ +

El módulo mod_authnz_ldap es tanto un proveedor de + autenticación como de autorización. El módulo + mod_authz_host proporciona autorización y control de acceso + basado en el nombre del Host, la dirección IP o características de la propia + petición, pero no es parte del sistema proveedor de + autenticación. Para tener compatibilidad inversa con el mod_access, + hay un nuevo modulo llamado mod_access_compat.

+ +

También puedes mirar el how-to de Control de Acceso , donde se plantean varias formas del control de acceso al servidor.

+ +
top
+
+

Introducción

+

Si se tiene información en nuestra página web que sea información + sensible o pensada para un grupo reducido de usuarios/personas, + las técnicas que se describen en este manual, le servirán + de ayuda para asegurarse de que las personas que ven esas páginas sean + las personas que uno quiere.

+ +

Este artículo cubre la parte "estándar" de cómo proteger partes de un + sitio web que muchos usarán.

+ +

Nota:

+

Si de verdad es necesario que tus datos estén en un sitio seguro, + considera usar mod_ssl como método de autenticación adicional a cualquier forma de autenticación.

+
+
top
+
+

Los Prerequisitos

+

Las directivas que se usan en este artículo necesitaran ponerse ya sea + en el fichero de configuración principal del servidor ( típicamente en + la sección + <Directory> de httpd.conf ), o + en cada uno de los ficheros de configuraciones del propio directorio + (los archivos .htaccess).

+ +

Si planea usar los ficheros .htaccess , necesitarás + tener en la configuración global del servidor, una configuración que permita + poner directivas de autenticación en estos ficheros. Esto se hace con la + directiva AllowOverride, la cual especifica + que directivas, en su caso, pueden ser puestas en cada fichero de configuración + por directorio.

+ +

Ya que estamos hablando aquí de autenticación, necesitarás una directiva + AllowOverride como la siguiente: +

+ + 
AllowOverride AuthConfig
+ + +

O, si solo se van a poner las directivas directamente en la configuración + principal del servidor, deberás tener, claro está, permisos de escritura + en el archivo.

+ +

Y necesitarás saber un poco de como está estructurado el árbol de + directorios de tu servidor, para poder saber donde se encuentran algunos + archivos. Esto no debería ser una tarea difícil, aún así intentaremos + dejarlo claro llegado el momento de comentar dicho aspecto.

+ +

También deberás de asegurarte de que los módulos + mod_authn_core y mod_authz_core + han sido incorporados, o añadidos a la hora de compilar en tu binario httpd o + cargados mediante el archivo de configuración httpd.conf. Estos + dos módulos proporcionan directivas básicas y funcionalidades que son críticas + para la configuración y uso de autenticación y autorización en el servidor web.

+
top
+
+

Conseguir que funcione

+

Aquí está lo básico de cómo proteger con contraseña un directorio en tu + servidor.

+ +

Primero, necesitarás crear un fichero de contraseña. Dependiendo de que + proveedor de autenticación se haya elegido, se hará de una forma u otra. Para empezar, + usaremos un fichero de contraseña de tipo texto.

+ +

Este fichero deberá estar en un sitio que no se pueda tener acceso desde + la web. Esto también implica que nadie pueda descargarse el fichero de + contraseñas. Por ejemplo, si tus documentos están guardados fuera de + /usr/local/apache/htdocs, querrás poner tu archivo de contraseñas en + /usr/local/apache/passwd.

+ +

Para crear el fichero de contraseñas, usa la utilidad + htpasswd que viene con Apache. Esta herramienta se + encuentra en el directorio /bin en donde sea que se ha + instalado el Apache. Si ha instalado Apache desde un paquete de terceros, + puede ser que se encuentre en su ruta de ejecución.

+ +

Para crear el fichero, escribiremos:

+ +

+ htpasswd -c /usr/local/apache/passwd/passwords rbowen +

+ +

htpasswd te preguntará por una contraseña, y después + te pedirá que la vuelvas a escribir para confirmarla:

+ +

+ $ htpasswd -c /usr/local/apache/passwd/passwords rbowen
+ New password: mypassword
+ Re-type new password: mypassword
+ Adding password for user rbowen +

+ +

Si htpasswd no está en tu variable de entorno "path" del + sistema, por supuesto deberás escribir la ruta absoluta del ejecutable para + poder hacer que se ejecute. En una instalación por defecto, está en: + /usr/local/apache2/bin/htpasswd

+ +

Lo próximo que necesitas, será configurar el servidor para que pida una + contraseña y así decirle al servidor que usuarios están autorizados a acceder. + Puedes hacer esto ya sea editando el fichero httpd.conf + de configuración o usando in fichero .htaccess. Por ejemplo, + si quieres proteger el directorio + /usr/local/apache/htdocs/secret, puedes usar las siguientes + directivas, ya sea en el fichero .htaccess localizado en + following directives, either placed in the file + /usr/local/apache/htdocs/secret/.htaccess, o + en la configuración global del servidor httpd.conf dentro de la + sección <Directory + "/usr/local/apache/htdocs/secret"> , como se muestra a continuación:

+ + 
<Directory "/usr/local/apache/htdocs/secret">
+AuthType Basic
+AuthName "Restricted Files"
+# (Following line optional)
+AuthBasicProvider file
+AuthUserFile "/usr/local/apache/passwd/passwords"
+Require user rbowen
+</Directory>
+ + +

Vamos a explicar cada una de las directivas individualmente. + La directiva AuthType selecciona el método + que se usa para autenticar al usuario. El método más común es + Basic, y éste es el método que implementa + mod_auth_basic. Es muy importante ser consciente, + de que la autenticación básica, envía las contraseñas desde el cliente + al servidor sin cifrar. + Este método por tanto, no debe ser utilizado para proteger datos muy sensibles, + a no ser que, este método de autenticación básica, sea acompañado del módulo + mod_ssl. + Apache soporta otro método más de autenticación que es del tipo + AuthType Digest. Este método, es implementado por el módulo mod_auth_digest y con el se pretendía crear una autenticación más + segura. Este ya no es el caso, ya que la conexión deberá realizarse con mod_ssl en su lugar. +

+ +

La directiva AuthName + establece el Realm para ser usado en la autenticación. El + Realm tiene dos funciones principales. + La primera, el cliente presenta a menudo esta información al usuario como + parte del cuadro de diálogo de contraseña. La segunda, que es utilizado por + el cliente para determinar qué contraseña enviar a para una determinada zona + de autenticación.

+ +

Así que, por ejemple, una vez que el cliente se ha autenticado en el área de + los "Ficheros Restringidos", entonces re-intentará automáticamente + la misma contraseña para cualquier área en el mismo servidor que es marcado + con el Realm de "Ficheros Restringidos" + Por lo tanto, puedes prevenir que a un usuario se le pida mas de una vez por su + contraseña, compartiendo así varias áreas restringidas el mismo Realm + Por supuesto, por razones de seguridad, el cliente pedirá siempre por una contraseña, + siempre y cuando el nombre del servidor cambie. +

+ +

La directiva AuthBasicProvider es, + en este caso, opcional, ya que file es el valor por defecto + para esta directiva. Deberás usar esta directiva si estas usando otro medio + diferente para la autenticación, como por ejemplo + mod_authn_dbm o mod_authn_dbd.

+ +

La directiva AuthUserFile + establece el path al fichero de contraseñas que acabamos de crear con el + comando htpasswd. Si tiene un número muy grande de usuarios, + puede ser realmente lento el buscar el usuario en ese fichero de texto plano + para autenticar a los usuarios en cada petición. + Apache también tiene la habilidad de almacenar información de usuarios en + unos ficheros de rápido acceso a modo de base de datos. + El módulo mod_authn_dbm proporciona la directiva AuthDBMUserFile. Estos ficheros pueden ser creados y + manipulados con el programa dbmmanage y htdbm. + Muchos otros métodos de autenticación así como otras opciones, están disponibles en + módulos de terceros + Base de datos de Módulos disponibles.

+ +

Finalmente, la directiva Require + proporciona la parte del proceso de autorización estableciendo el o los + usuarios que se les está permitido acceder a una región del servidor. + En la próxima sección, discutiremos las diferentes vías de utilizar la + directiva Require.

+
top
+
+

Dejar que más de una persona + entre

+

Las directivas mencionadas arriba sólo permiten a una persona + (especialmente con un usuario que en ej ejemplo es rbowen) + en el directorio. En la mayoría de los casos, se querrá permitir el acceso + a más de una persona. Aquí es donde la directiva + AuthGroupFile entra en juego.

+ +

Si lo que se desea es permitir a más de una persona el acceso, necesitarás + crear un archivo de grupo que asocie los nombres de grupos con el de personas + para permitirles el acceso. El formato de este fichero es bastante sencillo, + y puedes crearlo con tu editor de texto favorito. El contenido del fichero + se parecerá a:

+ +

+ GroupName: rbowen dpitts sungo rshersey +

+ +

Básicamente eso es la lista de miembros los cuales están en un mismo fichero + de grupo en una sola linea separados por espacios.

+ +

Para añadir un usuario a tu fichero de contraseñas existente teclee:

+ +

+ htpasswd /usr/local/apache/passwd/passwords dpitts +

+ +

Te responderá lo mismo que anteriormente, pero se añadirá al fichero + existente en vez de crear uno nuevo. (Es decir el flag -c será + el que haga que se genere un nuevo + fichero de contraseñas).

+ +

Ahora, tendrá que modificar su fichero .htaccess para que sea + parecido a lo siguiente:

+ + 
AuthType Basic
+AuthName "By Invitation Only"
+# Optional line:
+AuthBasicProvider file
+AuthUserFile "/usr/local/apache/passwd/passwords"
+AuthGroupFile "/usr/local/apache/passwd/groups"
+Require group GroupName
+ + +

Ahora, cualquiera que esté listado en el grupo GroupName, + y tiene una entrada en el fichero de contraseñas, se les + permitirá el acceso, si introducen su contraseña correctamente.

+ +

Hay otra manera de dejar entrar a varios usuarios, que es menos específica. + En lugar de crear un archivo de grupo, sólo puede utilizar la siguiente + directiva:

+ + 
Require valid-user
+ + +

Usando ésto en vez de la línea Require user rbowen + permitirá a cualquier persona acceder, la cuál aparece en el archivo de + contraseñas, y que introduzca correctamente su contraseña. Incluso puede + emular el comportamiento del grupo aquí, sólo manteniendo un fichero de + contraseñas independiente para cada grupo. La ventaja de este enfoque es + que Apache sólo tiene que comprobar un archivo, en lugar de dos. La desventaja + es que se tiene que mantener un montón de ficheros de contraseña de grupo, y + recuerde hacer referencia al fichero correcto en la directiva + AuthUserFile.

+
top
+
+

Posibles Problemas

+

Debido a la forma en que se especifica la autenticación básica, + su nombre de usuario y la contraseña deben ser verificados cada vez + que se solicita un documento desde el servidor. Esto es, incluso si  + se  vuelve a cargar la misma página, y para cada imagen de la página (si +    provienen de un directorio protegido). Como se puede imaginar, esto +    ralentiza las cosas un poco. La cantidad que ralentiza las cosas es + proporcional al tamaño del archivo de contraseñas, porque tiene que + abrir ese archivo, recorrer lista de usuarios hasta que llega a su nombre. + Y tiene que hacer esto cada vez que se carga una página.

+ +

Una consecuencia de esto, es que hay un limite práctico de cuantos + usuarios puedes introducir en el fichero de contraseñas. Este límite + variará dependiendo de la máquina en la que tengas el servidor, + pero puedes notar ralentizaciones en cuanto se metan cientos de entradas, + y por lo tanto consideraremos entonces otro método de autenticación + en ese momento. +

+
top
+
+

Método alternativo de almacenamiento de las + contraseñas

+ +

Debido a que el almacenamiento de las contraseñas en texto plano tiene + el problema mencionado anteriormente, puede que se prefiera guardar + las contraseñas en otro lugar como por ejemplo una base de datos. +

+ +

Los módulos mod_authn_dbm y mod_authn_dbd son + dos módulos que hacen esto posible. En vez de seleccionar la directiva de fichero + AuthBasicProvider , en su lugar + se puede elegir dbm o dbd como formato de almacenamiento.

+ +

Para seleccionar los ficheros de tipo dbm en vez de texto plano, podremos hacer algo parecido a lo siguiente:

+ + 
<Directory "/www/docs/private">
+    AuthName "Private"
+    AuthType Basic
+    AuthBasicProvider dbm
+    AuthDBMUserFile "/www/passwords/passwd.dbm"
+    Require valid-user
+</Directory>
+ + +

Hay otras opciones disponibles. Consulta la documentación de + mod_authn_dbm para más detalles.

+
top
+
+

Uso de múltiples proveedores

+ +

Con la introducción de la nueva autenticación basada en un proveedor y + una arquitectura de autorización, ya no estaremos restringidos a un único + método de autenticación o autorización. De hecho, cualquier número de + los proveedores pueden ser mezclados y emparejados para ofrecerle + exactamente el esquema que se adapte a sus necesidades. + En el siguiente ejemplo, veremos como ambos proveedores tanto el fichero + como el LDAP son usados en la autenticación: +

+ + 
<Directory "/www/docs/private">
+    AuthName "Private"
+    AuthType Basic
+    AuthBasicProvider file ldap
+    AuthUserFile "/usr/local/apache/passwd/passwords"
+    AuthLDAPURL ldap://ldaphost/o=yourorg
+    Require valid-user
+</Directory>
+ + +

En este ejemplo el fichero, que actúa como proveedor, intentará autenticar + primero al usuario. Si no puede autenticar al usuario, el proveedor del LDAP + será llamado para que realice la autenticación. + Esto permite al ámbito de autenticación ser amplio, si su organización + implementa más de un tipo de almacén de autenticación. + Otros escenarios de autenticación y autorización pueden incluir la + mezcla de un tipo de autenticación con un tipo diferente de autorización. + Por ejemplo, autenticar contra un fichero de contraseñas pero autorizando + dicho acceso mediante el directorio del LDAP.

+ +

Así como múltiples métodos y proveedores de autenticación pueden + ser implementados, también pueden usarse múltiples formas de + autorización. + En este ejemplo ambos ficheros de autorización de grupo así como + autorización de grupo mediante LDAP va a ser usado: +

+ + 
<Directory "/www/docs/private">
+    AuthName "Private"
+    AuthType Basic
+    AuthBasicProvider file
+    AuthUserFile "/usr/local/apache/passwd/passwords"
+    AuthLDAPURL ldap://ldaphost/o=yourorg
+    AuthGroupFile "/usr/local/apache/passwd/groups"
+    Require group GroupName
+    Require ldap-group cn=mygroup,o=yourorg
+</Directory>
+ + +

Para llevar la autorización un poco más lejos, las directivas + de autorización de contenedores tales como + <RequireAll> + and + <RequireAny> + nos permiten aplicar una lógica de en qué orden se manejará la autorización dependiendo + de la configuración y controlada a través de ella. + Mire también Contenedores de + Autorización para ejemplos de cómo pueden ser aplicados.

+ +
top
+
+

Más allá de la Autorización

+ +

El modo en que la autorización puede ser aplicada es ahora mucho más flexible + que us solo chequeo contra un almacén de datos (contraseñas). Ordenando la + lógica y escoger la forma en que la autorización es realizada, ahora es posible +

+ +

Aplicando la lógica y ordenación

+

Controlar el cómo y en qué orden se va a aplicar la autorización ha + sido un misterio en el pasado. En Apache 2.2 un proveedor del + mecanismo de autenticación fue introducido para disociar el proceso actual + de autenticación y soportar funcionalidad. + Uno de los beneficios secundarios fue que los proveedores de autenticación + podían ser configurados y llamados en un orden especifico que no dependieran + en el orden de carga del propio modulo. + Este proveedor de dicho mecanismo, ha sido introducido en la autorización + también. Lo que esto significa es que la directiva + Require + no sólo especifica que método de autorización deberá ser usado, si no + también especifica el orden en que van a ser llamados. Múltiples + métodos de autorización son llamados en el mismo orden en que la directiva + Require aparece en la + configuración. +

+ +

+ Con la Introducción del contenedor de directivas de autorización tales como + <RequireAll> + y + <RequireAny>, + La configuración también tiene control sobre cuándo se llaman a los métodos + de autorización y qué criterios determinan cuándo se concede el acceso. + Vease + Contenedores de autorización + Para un ejemplo de cómo pueden ser utilizados para expresar una lógica + más compleja de autorización. +

+ +

+ Por defecto todas las directivas + Require + son manejadas como si estuvieran contenidas en una directiva + <RequireAny>. + En otras palabras, Si alguno de los métodos de autorización + especificados tiene éxito, se concede la autorización. +

+ + + +

Uso de los proveedores de autorización para + el control de acceso

+ +

+ La autenticación de nombre de usuario y contraseña es sólo parte + de toda la historia que conlleva el proceso. Frecuentemente quiere + dar acceso a la gente en base a algo más que lo que son. + Algo como de donde vienen. +

+ +

+ Los proveedores de autorización all, + env, host y ip + te permiten denegar o permitir el acceso basándose en otros + criterios como el nombre de la máquina o la IP de la máquina que + realiza la consulta para un documento. +

+ +

+ El uso de estos proveedores se especifica a través de la directiva + Require. + La directiva registra los proveedores de autorización que serán llamados + durante la solicitud de la fase del proceso de autorización. Por ejemplo: +

+ + 
Require ip address
+
+ + +

+ Donde address es una dirección IP (o una dirección IP parcial) + o bien: +

+ + 
Require host domain_name
+
+ + +

+ Donde domain_name es el nombre completamente cualificado de un nombre + de dominio (FQDN) (o un nombre parcial del dominio); + puede proporcionar múltiples direcciones o nombres de dominio, si se desea. +

+ +

+ Por ejemplo, si alguien envía spam a su tablón de mensajes y desea + mantenerlos alejados, podría hacer lo siguiente:

+ + 
<RequireAll>
+    Require all granted
+    Require not ip 10.252.46.165
+</RequireAll>
+ + +

+ Visitantes que vengan desde esa IP no serán capaces de ver el contenido + que cubre esta directiva. Si, en cambio, lo que se tiene es el nombre de + la máquina, en vez de la dirección IP, podría usar: +

+ + 
<RequireAll>
+    Require all granted
+    Require not host host.example.com
+</RequireAll>
+ + +

+ Y, si lo que se quiere es bloquear el acceso desde un determinado dominio + (bloquear el acceso desde el dominio entero), puede especificar parte + de la dirección o del propio dominio a bloquear: +

+ + 
<RequireAll>
+    Require all granted
+    Require not ip 192.168.205
+    Require not host phishers.example.com moreidiots.example
+    Require not host ke
+</RequireAll>
+ + +

+ Usando <RequireAll> + con múltiples directivas <Require>, cada una negada con un not, + Sólo permitirá el acceso, si todas las condiciones negadas son verdaderas. + En otras palabras, el acceso será bloqueado, si cualquiera de las condiciones + negadas fallara. +

+ + + +

Compatibilidad de Control de Acceso con versiones + anteriores

+ +

+ Uno de los efectos secundarios de adoptar proveedores basados en + mecanismos de autenticación es que las directivas anteriores + Order, + Allow, + Deny y + Satisfy ya no son necesarias. + Sin embargo, para proporcionar compatibilidad con configuraciones antiguas, + estas directivas se han movido al módulo mod_access_compat. +

+ +

Nota:

+

+ Las directivas proporcionadas por mod_access_compat + han quedado obsoletas por mod_authz_host. Mezclar + directivas antiguas como + Order, + Allow ó + Deny con las nuevas + como + Require + es técnicamente posible pero desaconsejable. El módulo + mod_access_compat se creó para soportar configuraciones + que contuvieran sólo directivas antiguas para facilitar la actualización + a la versión 2.4. + Por favor revise la documentación de + actualización para más información al + respecto. +

+
+ + +
top
+
+

Cache de Autenticación

+

+ Puede haber momentos en que la autenticación ponga una carga + inaceptable en el proveedor (de autenticación) o en tu red. + Esto suele afectar a los usuarios de mod_authn_dbd + (u otros proveedores de terceros/personalizados). + Para lidiar con este problema, HTTPD 2.3/2.4 introduce un nuevo proveedor + de caché mod_authn_socache para cachear las credenciales + y reducir la carga en el proveedor(es) original. +

+

+ Esto puede ofrecer un aumento de rendimiento sustancial para algunos usuarios. +

+
top
+
+

Más información

+ +

+ También debería leer la documentación para + mod_auth_basic y mod_authz_host + la cuál contiene más información de como funciona todo esto. + La directiva <AuthnProviderAlias> puede también ayudar + a la hora de simplificar ciertas configuraciones de autenticación. +

+ +

+ Los diferentes algoritmos de cifrado que están soportados por Apache + para la autenticación se explican en + Cifrado de Contraseñas. +

+ +

+ Y tal vez quiera ojear la documentación de "how to" + Control de Acceso donde se mencionan temas + relacionados.

+ +
+
+

Idiomas disponibles:  en  | + es  | + fr  | + ja  | + ko  | + tr 

+
top

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/auth.html.fr.utf8 b/docs/manual/howto/auth.html.fr.utf8 new file mode 100644 index 0000000..760a222 --- /dev/null +++ b/docs/manual/howto/auth.html.fr.utf8 @@ -0,0 +1,681 @@ + + + + + +Authentification et autorisation - Serveur HTTP Apache Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.4

+
+
<-
+

Authentification et autorisation

+
+

Langues Disponibles:  en  | + es  | + fr  | + ja  | + ko  | + tr 

+
+ +

L'authentification est un processus qui vous permet de vérifier + qu'une personne est bien celle qu'elle prétend être. L'autorisation + est un processus qui permet à une personne d'aller là où elle veut + aller, ou d'obtenir les informations qu'elle désire.

+ +

Pour le contrôle d'accès en général, voir le How-To Contrôle d'accès.

+
+ +
top
+
+

Modules et directives concernés

+ +

Trois groupes de modules sont concernés par le processus +d'authentification et d'autorisation. Vous devrez utiliser au moins un +module de chaque groupe.

+ + + +

On peut aussi ajouter mod_authn_core et + mod_authz_core. Ces modules implémentent des + directives générales qui opèrent au dessus de tous les modules + d'authentification.

+ +

Le module mod_authnz_ldap est un fournisseur + d'authentification et d'autorisation. Le module + mod_authz_host fournit une autorisation et un + contrôle d'accès basés sur le nom du serveur, l'adresse IP ou + certaines caractéristiques de la requête, mais ne fait pas partie du + système fournisseur d'authentification. Le module + mod_access_compat a été créé à des fins de + compatibilité ascendante avec mod_access.

+ +

Vous devriez aussi jeter un coup d'oeil au manuel de recettes de Contrôle d'accès, qui décrit les différentes + méthodes de contrôle d'accès à votre serveur.

+ +
top
+
+

Introduction

+

Si votre site web contient des informations sensibles ou + destinées seulement à un groupe de personnes restreint, les + techniques exposées dans cet article vont vous aider à vous assurer + que les personnes qui ont accès à ces pages sont bien celles + auxquelles vous avez donné l'autorisation d'accès.

+ +

Cet article décrit les méthodes "standards" de protection de + parties de votre site web que la plupart d'entre vous sont appelés à + utiliser.

+ +

Note :

+

Si vos données ont un réel besoin de sécurisation, prévoyez + l'utilisation de mod_ssl en plus de toute méthode + d'authentification.

+
+
top
+
+

Les prérequis

+

Les directives décrites dans cet article devront être insérées + soit au niveau de la configuration de votre serveur principal (en + général dans une section <Directory>), soit au niveau de la + configuration des répertoires (fichiers .htaccess)

+ +

Si vous envisagez l'utilisation de fichiers + .htaccess, la configuration de votre serveur devra + permettre l'ajout de directives d'authentification dans ces + fichiers. Pour ce faire, on utilise la directive AllowOverride, qui spécifie quelles + directives pourront éventuellement contenir les fichiers de + configuration de niveau répertoire.

+ +

Comme il est ici question d'authentification, vous aurez besoin + d'une directive AllowOverride + du style :

+ + 
AllowOverride AuthConfig
+ + +

Si vous avez l'intention d'ajouter les directives directement + dans le fichier de configuration principal, vous devrez bien entendu + posséder les droits en écriture sur ce fichier.

+ +

Vous devrez aussi connaître un tant soit peu la structure des + répertoires de votre serveur, ne serait-ce que pour savoir où se + trouvent certains fichiers. Cela ne devrait pas présenter de grandes + difficultés, et nous essaierons de clarifier tout ça lorsque le besoin + s'en fera sentir.

+ +

Enfin, vous devrez vous assurer que les modules + mod_authn_core et mod_authz_core + ont été soit compilés avec le binaire httpd, soit chargés par le + fichier de configuration httpd.conf. Ces deux modules fournissent + des directives générales et des fonctionnalités qui sont critiques + quant à la configuration et l'utilisation de l'authentification et + de l'autorisation au sein du serveur web.

+
top
+
+

Mise en oeuvre

+

Nous décrivons ici les bases de la protection par mot de passe + d'un répertoire de votre serveur.

+ +

Vous devez en premier lieu créer un fichier de mots de passe. La + méthode exacte selon laquelle vous allez créer ce fichier va varier + en fonction du fournisseur d'authentification choisi. Mais nous + entrerons dans les détails plus loin, et pour le moment, nous nous + contenterons d'un fichier de mots de passe en mode texte.

+ +

Ce fichier doit être enregistré à un endroit non accessible + depuis le web, de façon à ce que les clients ne puissent pas le + télécharger. Par exemple, si vos documents sont servis à partir de + /usr/local/apache/htdocs, vous pouvez enregistrer le + fichier des mots de passe dans + /usr/local/apache/passwd.

+ +

L'utilitaire htpasswd fourni avec Apache + permet de créer ce fichier. Vous le trouverez dans le répertoire + bin de votre installation d'Apache. Si vous avez + installé Apache à partir d'un paquetage tiers, il sera probablement + dans le chemin par défaut de vos exécutables.

+ +

Pour créer le fichier, tapez :

+ +

+ htpasswd -c /usr/local/apache/passwd/passwords rbowen +

+ +

htpasswd vous demandera d'entrer le mot de + passe, et de le retaper pour confirmation :

+ +

+ # htpasswd -c /usr/local/apache/passwd/passwords rbowen
+ New password: mot-de-passe
+ Re-type new password: mot-de-passe
+ Adding password for user rbowen +

+ +

Si htpasswd n'est pas dans le chemin par + défaut de vos exécutables, vous devrez bien entendu entrer le chemin + complet du fichier. Dans le cas d'une installation par défaut, il se + trouve à /usr/local/apache2/bin/htpasswd.

+ +

Ensuite, vous allez devoir configurer le serveur de façon à ce + qu'il demande un mot de passe et lui préciser quels utilisateurs ont + l'autorisation d'accès. Pour ce faire, vous pouvez soit éditer le + fichier httpd.conf, soit utiliser un fichier + .htaccess. Par exemple, si vous voulez protéger le + répertoire /usr/local/apache/htdocs/secret, vous pouvez + utiliser les directives suivantes, soit dans le fichier + /usr/local/apache/htdocs/secret/.htaccess, soit dans le + fichier httpd.conf à l'intérieur d'une section <Directory + "/usr/local/apache/htdocs/secret"> :

+ + 
AuthType Basic
+AuthName "Restricted Files"
+# (Following line optional)
+AuthBasicProvider file
+AuthUserFile "/usr/local/apache/passwd/passwords"
+Require user rbowen
+ + +

Examinons ces directives une à une. La directive AuthType définit la méthode + utilisée pour authentifier l'utilisateur. La méthode la plus + courante est Basic, et elle est implémentée par + mod_auth_basic. Il faut cependant garder à l'esprit + que l'authentification Basic transmet le mot de passe depuis le + client vers le serveur en clair. Cette méthode ne devra donc pas + être utilisée pour la transmission de données hautement sensibles si + elle n'est pas associée au module mod_ssl. Apache + supporte une autre méthode d'authentification : AuthType + Digest. Cette méthode est implémentée par le module mod_auth_digest et a été conçue pour + améliorer la sécurité. Ce but n'a cependant pas été atteint et il est préférable + de chiffrer la connexion avec mod_ssl.

+ +

La directive AuthName définit + l'Identificateur (Realm) à utiliser avec + l'authentification. L'identificateur possède deux fonctions. Tout + d'abord, le client présente en général cette information à + l'utilisateur dans le cadre de la boîte de dialogue de mot de passe. + Ensuite, le client l'utilise pour déterminer quel mot de passe + envoyer pour une zone authentifiée donnée.

+ +

Ainsi par exemple, une fois un client authentifié dans la zone + "Fichiers réservés", il soumettra à nouveau + automatiquement le même mot de passe pour toute zone du même serveur + marquée de l'identificateur "Fichiers réservés". De + cette façon, vous pouvez éviter à un utilisateur d'avoir à saisir + plusieurs fois le même mot de passe en faisant partager le même + identificateur entre plusieurs zones réservées. Bien entendu et pour + des raisons de sécurité, le client devra redemander le mot + de passe chaque fois que le nom d'hôte du serveur sera modifié.

+ +

La directive AuthBasicProvider est, dans ce + cas, facultative, car file est la valeur par défaut + pour cette directive. Par contre, cette directive sera obligatoire + si vous utilisez une autre source d'authentification comme + mod_authn_dbm ou + mod_authn_dbd.

+ +

La directive AuthUserFile définit le chemin + du fichier de mots de passe que nous venons de créer avec + htpasswd. Si vous possédez un grand nombre + d'utilisateurs, la durée de la recherche dans un fichier texte pour + authentifier un utilisateur à chaque requête va augmenter + rapidement, et pour pallier cet inconvénient, Apache peut aussi + stocker les données relatives aux + utilisateurs dans des bases de données rapides. Le module + mod_authn_dbm fournit la directive AuthDBMUserFile. Les programmes dbmmanage et htdbm permettent de + créer et manipuler ces fichiers. Enfin, de nombreux modules tiers + fournissent d'autres types d'authentification.

+ +

Enfin, la directive Require implémente la partie + autorisation du processus en définissant l'utilisateur autorisé à + accéder à cette zone du serveur. Dans la section suivante, nous + décrirons les différentes méthodes d'utilisation de la directive + Require.

+
top
+
+

Autorisation d'accès à +plusieurs personnes

+

Les directives ci-dessus n'autorisent qu'une personne (quelqu'un + possédant le nom d'utilisateur rbowen) à accéder au + répertoire. Dans la plupart des cas, vous devrez autoriser + l'accès à plusieurs personnes. C'est ici + qu'intervient la directive AuthGroupFile.

+ +

Si vous voulez autoriser l'accès à plusieurs personnes, vous + devez créer un fichier de groupes qui associe des noms de groupes + avec une liste d'utilisateurs de ce groupe. Le format de ce fichier + est très simple, et vous pouvez le créer avec votre éditeur favori. + Son contenu se présente comme suit :

+ +

+ Nom-de-groupe: rbowen dpitts sungo rshersey +

+ +

Il s'agit simplement une liste des membres du groupe sous la + forme d'une ligne séparée par des espaces.

+ +

Pour ajouter un utilisateur à votre fichier de mots de passe + préexistant, entrez :

+ +

+ htpasswd /usr/local/apache/passwd/passwords dpitts +

+ +

Vous obtiendrez le même effet qu'auparavant, mais le mot de passe + sera ajouté au fichier, plutôt que d'en créer un nouveau (C'est le + drapeau -c qui permet de créer un nouveau fichier de + mots de passe)..

+ +

Maintenant, vous devez modifier votre fichier + .htaccess ou la section <Directory> comme suit :

+ + 
AuthType Basic
+AuthName "By Invitation Only"
+# Optional line:
+AuthBasicProvider file
+AuthUserFile "/usr/local/apache/passwd/passwords"
+AuthGroupFile "/usr/local/apache/passwd/groups"
+Require group GroupName
+ + +

Maintenant, quiconque appartient au groupe + Nom-de-groupe, et possède une entrée dans le fichier + password pourra accéder au répertoire s'il tape le bon + mot de passe.

+ +

Il existe une autre méthode moins contraignante pour autoriser + l'accès à plusieurs personnes. Plutôt que de créer un fichier de + groupes, il vous suffit d'ajouter la directive suivante :

+ + 
Require valid-user
+ + +

Le remplacement de la ligne Require user rbowen par + la ligne Require valid-user autorisera l'accès à + quiconque possédant une entrée dans le fichier password, et ayant + tapé le bon mot de passe.

+
top
+
+

Problèmes possibles

+

L'authentification Basic est spécifiée d'une telle manière que + vos nom d'utilisateur et mot de passe doivent être vérifiés chaque + fois que vous demandez un document au serveur, et ceci même si vous + rechargez la même page, et pour chaque image contenue dans la page + (si elles sont situées dans un répertoire protégé). Comme vous + pouvez l'imaginer, ceci ralentit un peu le fonctionnement. La mesure + dans laquelle le fonctionnement est ralenti est proportionnelle à la + taille du fichier des mots de passe, car ce dernier doit être ouvert + et la liste des utilisateurs parcourue jusqu'à ce que votre nom soit + trouvé, et ceci chaque fois qu'une page est chargée.

+ +

En conséquence, ce ralentissement impose une limite pratique au + nombre d'utilisateurs que vous pouvez enregistrer dans un fichier de + mots de passe. Cette limite va varier en fonction des performances + de votre serveur, mais vous commencerez à remarquer un + ralentissement lorsque vous atteindrez quelques centaines + d'utilisateurs, et serez alors appelés à utiliser une méthode + d'authentification différente.

+
top
+
+

Autre méthode de stockage des mots de +passe

+ +

Suite au problème évoqué précédemment et induit par le stockage + des mots de passe dans un fichier texte, vous pouvez être appelé à + stocker vos mots de passe d'une autre manière, par exemple dans une + base de données.

+ +

Pour y parvenir, on peut utiliser les modules + mod_authn_dbm ou mod_authn_dbd. + Vous pouvez choisir comme format de stockage dbm ou + dbd à la place de file pour la directive + AuthBasicProvider.

+ +

Par exemple, pour sélectionner un fichier dbm à la place d'un + fichier texte :

+ + 
<Directory "/www/docs/private">
+
+    AuthName "Private"
+    AuthType Basic
+    AuthBasicProvider dbm
+    AuthDBMUserFile "/www/passwords/passwd.dbm"
+    Require valid-user
+
+</Directory>
+ + +

D'autres options sont disponibles. Consultez la documentation de + mod_authn_dbm pour plus de détails.

+
top
+
+

Utilisation de plusieurs fournisseurs +d'authentification

+ +

Depuis l'arrivée des nouvelles architecture d'autorisation et + d'authentification basées sur les fournisseurs, vous n'êtes plus + limité à une méthode d'authentification et d'autorisation + unique. En fait, on peut panacher autant de fournisseurs que l'on + veut, ce qui vous permet d'élaborer l'architecture qui correspond + exactement à vos besoins. Dans l'exemple suivant, on utilise + conjointement les fournisseurs d'authentification + file et LDAP :

+ + 
<Directory "/www/docs/private">
+
+    AuthName "Private"
+    AuthType Basic
+    AuthBasicProvider file ldap
+    AuthUserFile "/usr/local/apache/passwd/passwords"
+    AuthLDAPURL ldap://ldaphost/o=yourorg
+    Require valid-user
+
+</Directory>
+ + +

Dans cet exemple, le fournisseur file va tenter d'authentifier + l'utilisateur en premier. S'il n'y parvient pas, le fournisseur LDAP + sera sollicité. Ceci permet l'élargissement des possibilités + d'authentification si votre organisation implémente plusieurs types + de bases d'authentification. D'autres scénarios d'authentification + et d'autorisation peuvent associer un type d'authentification avec + un autre type d'autorisation. Par exemple, une authentification + basée sur un fichier de mots de passe peut permettre l'attribution + d'autorisations basée sur un annuaire LDAP.

+ +

Tout comme plusieurs fournisseurs d'authentification peuvent être + implémentés, on peut aussi utiliser plusieurs méthodes + d'autorisation. Dans l'exemple suivant, on utilise à la fois une + autorisation à base de fichier de groupes et une autorisation à base + de groupes LDAP.

+ + 
<Directory "/www/docs/private">
+
+    AuthName "Private"
+    AuthType Basic
+    AuthBasicProvider file
+    AuthUserFile "/usr/local/apache/passwd/passwords"
+    AuthLDAPURL ldap://ldaphost/o=yourorg
+    AuthGroupFile "/usr/local/apache/passwd/groups"
+    Require group GroupName
+    Require ldap-group cn=mygroup,o=yourorg
+
+</Directory>
+ + +

Pour un scénario d'autorisation un peu plus avancé, des + directives de conteneur d'autorisation comme <RequireAll> et + <RequireAny> permettent d'appliquer une + logique telle que l'ordre dans lequel les autorisations sont + appliquées peut être entièrement contrôlé au niveau de la + configuration. Voir Conteneurs + d'autorisations pour un exemple de ce contrôle.

+ +
top
+
+

Pour aller plus loin qu'une simple +autorisation

+ +

La manière dont les autorisations sont accordées est désormais + beaucoup plus souple qu'une simple vérification auprès d'une seule + base de données. Il est maintenant possible de choisir l'ordre, la + logique et la manière selon lesquels une autorisation est + accordée.

+ +

Appliquer logique et + ordonnancement

+

Le contrôle de la manière et de l'ordre selon lesquels le + processus d'autorisation était appliqué + constituait une sorte de mystère par + le passé. Dans Apache 2.2, un mécanisme d'authentification basé + sur les fournisseurs a été développé afin de séparer le + véritable processus d'authentification de l'autorisation et ses + différentes fonctionnalités. Un des avantages colatéraux + résidait dans le fait que les fournisseurs d'authentification + pouvaient être configurés et appelés selon un ordre particulier + indépendant de l'ordre de chargement du module auth proprement + dit. Ce mécanisme basé sur les fournisseurs a été étendu au + processus d'autorisation. Ceci signifie que la directive + Require définit + non seulement quelles méthodes d'autorisation doivent être + utilisées, mais aussi l'ordre dans lequel elles sont appelées. + Les méthodes d'autorisation sont appelées selon l'ordre dans + lequel les directives Require apparaissent dans la + configuration.

+ +

Avec l'introduction des directives de conteneur + d'autorisations <RequireAll> + et <RequireAny>, la + configuration contrôle aussi le moment où les méthodes + d'autorisation sont appelées, et quels critères déterminent + l'autorisation d'accès. Voir Conteneurs + d'autorisations pour un exemple de la manière de les + utiliser pour exprimer des logiques d'autorisation + complexes.

+ +

Par défaut, toutes les directives Require sont + traitées comme si elles étaient contenues dans une directive + <RequireAny>. En d'autres termes, il + suffit + qu'une méthode d'autorisation s'applique avec succès pour que + l'autorisation soit accordée.

+ + + +

Utilisation de fournisseurs + d'autorisation pour le contrôle d'accès

+

La vérification du nom d'utilisateur et du mot de passe ne + constituent qu'un aspect des méthodes d'authentification. + Souvent, le contrôle d'accès à certaines personnes n'est pas + basé sur leur identité ; il peut dépendre, par exemple de leur + provenance.

+ +

Les fournisseurs d'autorisation all, + env, host et ip vous + permettent d'accorder ou refuser l'accès en + fonction de critères tels que le nom d'hôte ou l'adresse + IP de la machine qui effectue la requête.

+ +

L'utilisation de ces fournisseurs est spécifiée à l'aide de + la directive Require. Cette directive + permet d'enregistrer quels fournisseurs d'autorisation + seront appelés dans le processus d'autorisation au cours du + traitement de la requête. Par exemple :

+ + 
Require ip address
+ + +

où adresse est une adresse IP (ou une adresse IP + partielle) ou :

+ + 
Require host domain_name
+ + +

où nom_domaine est un nom de domaine entièrement + qualifé (ou un nom de domaine partiel) ; vous pouvez indiquer + plusieurs adresses ou noms de domaines, si vous le désirez.

+ +

Par exemple, si vous voulez rejeter les spams dont une + machine vous inonde, vous pouvez utiliser ceci :

+ + 
<RequireAll>
+    Require all granted
+    Require not ip 10.252.46.165
+</RequireAll>
+ + +

Ainsi, les visiteurs en provenance de cette adresse ne + pourront pas voir le contenu concerné par cette directive. Si, + par contre, vous connaissez le nom de la machine, vous pouvez + utiliser ceci :

+ + 
<RequireAll>
+    Require all granted
+    Require not host host.example.com
+</RequireAll>
+ + +

Et si vous voulez interdire l'accès à toutes les machines + d'un domaine, vous pouvez spécifier une partie seulement de + l'adresse ou du nom de domaine :

+ + 
<RequireAll>
+    Require all granted
+    Require not ip 192.168.205
+    Require not host phishers.example.com moreidiots.example
+    Require not host ke
+</RequireAll>
+ + +

L'utilisation de la directive <RequireAll> + avec de multiples directives <Require>, toutes avec la négation + not, n'accordera l'accès que si toutes les + conditions négatives sont vérifiées. En d'autres termes, l'accès + sera refusé si au moins une des conditions négatives n'est pas + vérifiée.

+ + + +

Compatibilité ascendante du contrôle + d'accès

+

L'adoption d'un mécanisme à base de fournisseurs pour + l'authentification, a pour effet colatéral de rendre inutiles + les directives Order, Allow, Deny et Satisfy. Cependant, et à + des fins de compatibilité ascendante vers les anciennes + configurations, ces directives ont été déplacées vers le module + mod_access_compat.

+ +

Note

+

Les directives fournies par le module + mod_access_compat sont devenues obsolètes depuis + la refonte du module mod_authz_host. Mélanger d'anciennes + directives comme Order, Allow ou Deny avec des nouvelles comme + Require est techniquement + possible mais déconseillé. En effet, mod_access_compat a + été conçu pour supporter des configurations ne contenant que des anciennes + directives afin de faciliter le passage à la version 2.4. Voir le document + upgrading pour plus de détails. +

+
+ + +
top
+
+

Mise en cache de l'authentification

+

Dans certains cas, l'authentification constitue une charge + inacceptable pour un fournisseur d'authentification ou votre réseau. + Ceci est susceptible d'affecter les utilisateurs du module + mod_authn_dbd (ou les fournisseurs + tiers/personnalisés). Pour résoudre ce problème, HTTPD 2.3/2.4 + propose un nouveau fournisseur de mise en cache, + mod_authn_socache, qui permet de mettre en cache + les données d'authentification, et ainsi réduire la charge du/des + fournisseurs(s) originels.

+

Cette mise en cache apportera un gain en performance substantiel + à certains utilisateurs.

+
top
+
+

Pour aller plus loin . . .

+

Vous pouvez aussi lire la documentation de + mod_auth_basic et mod_authz_host + qui contient des informations supplémentaires à propos du + fonctionnement de tout ceci. + Certaines configurations d'authentification peuvent aussi être + simplifiées à l'aide de la directive <AuthnProviderAlias>.

+ +

Les différents algorithmes de chiffrement supportés par Apache + pour authentifier les données sont expliqués dans PasswordEncryptions.

+ +

Enfin vous pouvez consulter la recette Contrôle + d'accès, qui décrit un certain nombre de situations en relation + avec le sujet.

+ +
+
+

Langues Disponibles:  en  | + es  | + fr  | + ja  | + ko  | + tr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/auth.html.ja.utf8 b/docs/manual/howto/auth.html.ja.utf8 new file mode 100644 index 0000000..78519bd --- /dev/null +++ b/docs/manual/howto/auth.html.ja.utf8 @@ -0,0 +1,692 @@ + + + + + +認証、承認、アクセス制御 - Apache HTTP サーバ バージョン 2.4 + + + + + + +
+

モジュール | ディレクティブ | FAQ | 用語 | サイトマップ

+

Apache HTTP サーバ バージョン 2.4

+
+
<-
+

認証、承認、アクセス制御

+
+

翻訳済み言語:  en  | + es  | + fr  | + ja  | + ko  | + tr 

+
+
この日本語訳はすでに古くなっている + 可能性があります。 + 最近更新された内容を見るには英語版をご覧下さい。 +
+ +

「認証」とは、誰かが自分は誰であるかを主張した場合に、 + それを確認するための全過程を指します。「承認」とは、 + 誰かが行きたい場所に行けるように、あるいは欲しい情報を + 得ることができるようにするための全過程を指します。

+
+ +
top
+
+

関連するモジュールとディレクティブ

+

認証と承認の処理に関連する 3 種類のモジュールがあります。 +それぞれ少なくともひとつずつ必要です。

+ + + +

これらのモジュールに加えて、mod_authn_core + と mod_authz_core があります。 + この 2 つのモジュールは認証モジュールに共通なコアディレクティブを + 実装しています。

+ +

mod_authnz_ldap は認証プロバイダと承認プロバイダの + 両方の機能を持っています。 + mod_authz_host はホスト名、IP アドレスや + リクエストの特徴に基づいたアクセス制御を行いますが、 + 認証プロバイダのシステムの一部ではありません。 + mod_access との後方互換性のため、 + 新しいモジュールの mod_access_compat があります。

+ +

様々なアクセス制御の行ない方については、 + アクセス制御の方法をご覧ください。

+ +
top
+
+

はじめに

+

もし機密の情報や、ごくごく少数グループの人向けの情報を + ウェブサイトに置くのであれば、この文書に書かれている + テクニックを使うことで、そのページを見ている人たちが + 望みの人たちであることを確実にできるでしょう。

+ +

この文書では、多くの人が採用するであろう、 + ウェブサイトの一部分を保護する「一般的な」 + 方法についてカバーしています。

+ +

注意

+

データが本当に機密なのであれば、認証に加えてさらに + mod_ssl を使うと良いでしょう。

+
+
top
+
+

準備

+

この文書で取り扱われるディレクティブは、 + メインサーバ設定ファイル (普通は + <Directory> + セクション中) か、あるいはディレクトリ毎の設定ファイル + (.htaccess ファイル) かで用います。

+ +

.htaccess ファイルを用いるのであれば、 + これらのファイルに認証用のディレクティブを置けるように + サーバの設定をしないといけないでしょう。これは + AllowOverride + ディレクティブで可能になります。 + AllowOverride + ディレクティブでは、ディレクトリ毎の設定ファイル中に置くことのできる + ディレクティブを、もしあれば、指定します。

+ +

認証について話を進めているので、次のような + AllowOverride + ディレクティブが必要になるでしょう。

+ +

+ AllowOverride AuthConfig +

+ +

そうでなく、メインサーバ設定ファイルの中に + 直接置くのであれば、当然ながらそのファイルへの書き込み + 権限を持っていなければならないでしょう。

+ +

また、どのファイルがどこに保存されているか知るために、 + サーバのディレクトリ構造について少し知っておく + 必要があるでしょう。 + これはそんなに難しくないので、この文書中で + ディレクトリ構造について知っておく必要がある場面では、 + 明らかになるようにします。

+ +

mod_authn_core と mod_authz_core + の両方が httpd バイナリに静的に組み込み済みであるか、httpd.conf + 設定ファイルで動的にロードされるかして、httpd に組み込まれていなければ + なりません。これらの二つのモジュールは、設定ファイルのなかで非常に + 重要でウェブサーバの認証と承認で使用されるコアディレクティブと + その機能を提供しています。

+
top
+
+

動作させる

+

では、サーバ上のあるディレクトリをパスワードで保護する + 基本手順を示します。

+ +

まずはじめに、パスワードファイルを作ります。 + どの認証プロバイダを使うかによって、パスワードファイル生成の手順は + 大きく異なります。ここでの例では、手始めにテキストパスワードファイルを + 使います。

+ +

このパスワードファイルは、ウェブからアクセスできる場所に + 置くべきではありません。他の人がパスワードファイルを + ダウンロードできないようにするためです。例えば、 + /usr/local/apache/htdocs でドキュメントを + 提供しているのであれば、パスワードファイルは + /usr/local/apache/passwd + などに置いた方が良いでしょう。

+ +

ファイルを作るためには、Apache 付属の htpasswd + を使います。このコマンドは Apache をどこにインストールしようとも、 + インストールディレクトリの bin + ディレクトリ以下に置かれます。サードバーティ製のパッケージで + インストールした場合は、実行パスの中で見つかるでしょう。

+ +

ファイルを作るには、次のようにタイプしてください。

+ +

+ htpasswd -c /usr/local/apache/passwd/passwords rbowen +

+ +

htpasswd は、パスワードを要求し、その後 + 確認のためにもう一度入力するように要求してきます。

+ +

+ # htpasswd -c /usr/local/apache/passwd/passwords rbowen
+ New password: mypassword
+ Re-type new password: mypassword
+ Adding password for user rbowen +

+ +

もし htpasswd がパスの中に入っていない場合は、 + もちろん、実行するためにプログラムまでのフルパスを + タイプする必要があります。デフォルトのインストール状態であれば、 + /usr/local/apache/bin/htpasswd + にプログラムが置かれています。

+ +

次に、サーバがパスワードを要求するように設定して、 + どのユーザがアクセスを許されているかをサーバに知らせなければ + なりません。 httpd.conf を編集するか + .htaccess ファイルを使用するかで + 設定します。例えば、ディレクトリ + /usr/local/apache/htdocs/secret + を保護したい場合は、 + /usr/local/apache/htdocs/secret/.htaccess + か httpd.conf 中の <Directory + /usr/local/apache/htdocs/secret> セクションに + 配置して、次のディレクティブを使うことができます。

+ +

+ AuthType Basic
+ AuthName "Restricted Files"
+ # (Following line optional)
+ AuthBasicProvider file
+ AuthUserFile /usr/local/apache/passwd/passwords
+ Require user rbowen +

+ +

個々のディレクティブについて見てみましょう。 + AuthType + ディレクティブはどういう認証方法でユーザの認証を行うかを + 選択します。最も一般的な方法は Basic + で、これは mod_auth_basic + で実装されています。しかしながら、 + これは気を付けるべき重要なポイントなのですが、 + Basic 認証はクライアントからサーバへ、 + パスワードを暗号化せずに送ります。ですからこの方法は、 + mod_ssl と組み合わせない状態では、 + 特に機密性の高いデータに対しては用いるべきでは + ありません。 Apache ではもう一つ別の認証方法: + AuthType Digest をサポートしています。 + この方法は mod_auth_digest + で実装されていて、もっと安全です。 + 最近のクライアントは Digest + 認証をサポートしているようです。

+ +

AuthName + ディレクティブでは、認証に使う Realm (訳注: 領域) + を設定します。Realm は大きく分けて二つの機能を提供します。 + 一つ目は、クライアントがパスワードダイアログボックスの + 一部としてユーザにこの情報をよく提示する、というものです。 + 二つ目には、クライアントが与えられた認証領域に対してどのパスワードを + 送信すれば良いのかを決定するために使われる、という機能です。

+ +

例えば、"Restricted Files" 領域中で + 一度認証されれば、同一サーバ上で "Restricted Files" + Realm としてマークされたどんな領域でも、クライアントは + 自動的に同じパスワードを使おうと試みます。 + このおかげで、複数の制限領域に同じ realm を共有させて、 + ユーザがパスワードを何度も要求される事態を + 防ぐことができます。もちろん、セキュリティ上の理由から、 + サーバのホスト名が変わればいつでも必ず、 + クライアントは再びパスワードを尋ねる必要があります。

+ +

AuthBasicProvider + はデフォルト値が file なので、今回の場合は無くても構いません。 + mod_authn_dbm や mod_authn_dbd + といった他のモジュールを使う場合には必要になります。 +

+ +

AuthUserFile + ディレクティブは htpasswd で作った + パスワードファイルへのパスを設定します。 + ユーザ数が多い場合は、リクエスト毎のユーザの認証のための + プレーンテキストの探索が非常に遅くなることがあります。 + Apache ではユーザ情報を高速なデータベースファイルに + 保管することもできます。 + mod_authn_dbm モジュールが + AuthDBMUserFile + ディレクティブを提供します。これらのファイルは dbmmanage + プログラムで作成したり操作したりできます。 + Apache + モジュールデータベース中にあるサードパーティー製の + モジュールで、その他多くのタイプの認証オプションが + 利用可能です。

+ +

最後に、Require + ディレクティブが、サーバのこの領域にアクセスできるユーザを + 指定することによって、プロセスの承認部分を提供します。 + 次のセクションでは、Require + ディレクティブの様々な用法について述べます。

+
top
+
+

+複数の人が入れるようにする

+

上記のディレクティブは、ただ一人 (具体的にはユーザ名 + rbowen の誰か) がディレクトリに + 入れるようにします。多くの場合は、複数の人が + 入れるようにしたいでしょう。ここで + AuthGroupFile + の登場です。

+ +

もし複数の人が入れるようにしたいのであれば、 + グループに属するユーザの一覧の入っている、グループ名のついた + グループファイルを作る必要があります。このファイルの + 書式はきわめて単純で、お好みのエディタで生成できます。 + ファイルの中身は次のようなものです。

+ +

+ GroupName: rbowen dpitts sungo rshersey +

+ +

一行にスペース区切りで、グループに所属するメンバーの + 一覧をならべるだけです。

+ +

既に存在するパスワードファイルにユーザを加える場合は、 + 次のようにタイプしてください。

+ +

+ htpasswd /usr/local/apache/passwd/passwords dpitts +

+ +

以前と同じ応答が返されますが、新しいファイルを + 作るのではなく、既にあるファイルに追加されています。 + (新しいパスワードファイルを作るには -c + を使います。)

+ +

ここで次のようにして .htaccess ファイルを + 修正する必要があります。

+ +

+ AuthType Basic
+ AuthName "By Invitation Only"
+ # Optional line:
+ AuthBasicProvider file
+ AuthUserFile /usr/local/apache/passwd/passwords
+ AuthGroupFile /usr/local/apache/passwd/groups
+ Require group GroupName +

+ +

これで、グループ GroupName にリストされていて、 + password ファイルにエントリがある人は、 + 正しいパスワードをタイプすれば入ることができるでしょう。

+ +

もっと特定せずに複数のユーザが入れるようにする、 + もう一つの方法があります。グループファイルを作るのではなく、 + 次のディレクティブを使えばできます。

+ +

+ Require valid-user +

+ +

require user rbowen 行でなく、上記を使うと、 + パスワードファイルにリストされている人であれば誰でも + 許可されます。 + 単にパスワードファイルをグループ毎に分けておくことで、 + グループのような振る舞いをさせることもできます。 + このアプローチの利点は、Apache は二つではなく、 + ただ一つのファイルだけを検査すればよいという点です。 + 欠点は、たくさんのパスワードファイルを管理して、その中から + AuthUserFile + ディレクティブに正しいファイルを参照させなければならない点です。

+
top
+
+

起こりえる問題

+

Basic 認証が指定されている場合は、 + サーバにドキュメントをリクエストする度に + ユーザ名とパスワードを検査しなければなりません。 + これは同じページ、ページにある全ての画像を + リロードする場合であっても該当します + (もし画像も保護されたディレクトリから来るのであれば) 。 + 予想される通り、これは動作を多少遅くします。 + 遅くなる程度はパスワードファイルの大きさと比例しますが、 + これは、ファイルを開いてあなたの名前を発見するまで + ユーザ名のリストを読まなければならないからです。 + そして、ページがロードされる度にこれを行わなければ + なりません。

+ +

結論としては、一つのパスワードファイルに置くことのできる + ユーザ数には実質的な限界があります。 + この限界はサーバマシンの性能に依存して変わりますが、 + 数百のエントリを越えたあたりから速度低下が見られると予期されています。 + その時は他の認証方法を考慮に入れた方が良いでしょう。

+
top
+
+

パスワードの保存形式を変える

+ +

プレーンテキストでパスワードを保存する方法には上記の問題があり、 + データベースのような別の場所にパスワードを保存したいと思う + かもしれません。

+ +

mod_authn_dbm と mod_authn_dbd + を使うと、それができるようになります。 + AuthBasicSource + で file の代わりに、dbm あるいは dbd + を格納形式として選べます。

+ +

テキストファイルの代わりに dbm ファイルを選択する場合は、たとえば次のようにします。

+ +

+ <Directory /www/docs/private>
+ AuthName "Private"
+ AuthType Basic
+ AuthBasicProvider dbm
+ AuthDBMUserFile /www/passwords/passwd.dbm
+ Require valid-user
+ </Directory> +

+ +

この他のオプションも存在します。詳細に関しては + mod_authn_dbm のドキュメントをご覧ください。

+
top
+
+

複数のプロバイダを使用する

+ +

認証承認アーキテクチャに基づいている新しいプロバイダを使うと、 + 認証承認の方法をひとつに縛る必要がなくなります。 + いくつものプロバイダを組み合わせて、自分の望みの挙動にできます。 + 次の例では file 認証プロバイダと ldap 認証プロバイダを + 組み合わせています。

+ +

+ <Directory /www/docs/private>
+ AuthName "Private"
+ AuthType Basic
+ AuthBasicProvider file ldap
+ AuthUserFile /usr/local/apache/passwd/passwords
+ AuthLDAPURL ldap://ldaphost/o=yourorg
+ Require valid-user +

+ +

この例では、まず file プロバイダがユーザ認証を試みます。 + 認証できなかった場合には、ldap プロバイダが呼び出されます。 + 組織で複数の認証格納方法を使っている際などに、 + この方法を使って認証のスコープを拡大できます。 + もうひとつのシナリオは、ひとつの認証タイプと異なる承認を + 組み合わせる方法でしょう。たとえば、パスワードファイルで認証して、 + ldap ディレクトリで承認を行うといった場合です。

+ +

認証プロバイダを複数実装できるように、承認方法も複数使用できます。 + この例では file グループ承認と ldap グループ承認を使っています。

+ +

+ <Directory /www/docs/private>
+ AuthName "Private"
+ AuthType Basic
+ AuthBasicProvider file
+ AuthUserFile /usr/local/apache/passwd/passwords
+ AuthLDAPURL ldap://ldaphost/o=yourorg + AuthGroupFile /usr/local/apache/passwd/groups
+ Require group GroupName
+ Require ldap-group cn=mygroup,o=yourorg +

+ +

承認をより細かく制御したい場合は、 + <SatisfyAll> と + <SatisfyOne> + ディレクティブを使って AND/OR ロジックで指定し、設定ファイルで + 承認の処理順番の制御ができるようになっています。 + これらのディレクティブをどのように使えるか、網羅した例をご覧ください。

+ +
top
+
+

単純な承認のその先

+ +

承認の方法は、ひとつのデータソースを見て一回だけチェックするのと比べて、 + ずっと多彩な適用方法ができます。 + 承認処理の適用順序や制御、選択ができるようになりました。

+ +

AND/OR ロジックの適用と順序付け

+

承認がどのような順序で適用されているか、また、それをどのように制御するかは、 + これまで混乱を招いていました。 + Apache 2.2 ではプロバイダベースの認証メカニズムが導入され、 + 承認処理から認証処理とサポート機能とが切り分けられました。 + これによるひとつの効果として、 + 認証モジュールのロード順やモジュール自体の順序に依存することなく、 + 指定した順番で認証プロバイダが呼び出せるよう、 + 設定できるようになりました。 + このプロバイダメカニズムは承認処理でも導入されています。 + つまり、Require + ディレクティブは単にどの承認手法が使われるかを指定するだけではなく、 + それらの呼び出し順序も指定できるようになりました。 + 複数の承認手法があるとき、その呼び出し順は、設定ファイルの + Require ディレクティブ中で + 現れた順序と同じになります。

+ +

追加で導入された + <SatisfyAll>, + <SatisfyOne> + ディレクティブを使って、承認手法がいつ呼び出され、アクセスが許可された際に + どの手続きが適用されるか指定することができます。 + たとえば、次の承認ブロックのロジックを見てみましょう:

+ +

+ # if ((user == "John") ||
+ #    ((Group == "admin")
+ #     && (ldap-group <ldap-object> contains auth'ed_user)
+ #     && ((ldap-attribute dept == "sales")
+ #         || (file-group contains auth'ed_user))))
+ # then
+ #   auth_granted
+ # else
+ #   auth_denied
+ #
+ <Directory /www/mydocs>
+ + Authname ...
+ AuthBasicProvider ...
+ ...
+ Require user John
+ <SatisfyAll>
+ + Require Group admins
+ Require ldap-group cn=mygroup,o=foo
+ <SatisfyOne>
+ + Require ldap-attribute dept="sales"
+ Require file-group
+ + </SatisfyOne>
+ + </SatisfyAll>
+ + </Directory> +

+ +

デフォルトでは Require + ディレクティブは OR 操作として扱われます。つまり、もし指定した承認手法の + ひとつでも合格すれば、承認されます。 + Require ディレクティブのセットを + ひとつの <SatisfyAll> + ブロックで囲むとAND 操作となり、全ての承認手法で合格しなければ許可されません。

+ + + +

アクセス制御における Require と Reject の使い方

+

ユーザ名とパスワードによる認証は全体の一部分でしかありません。 + 誰がアクセスしてきたかといった情報以外の条件を使いたい、 + とよく思うことでしょう。 + たとえば、どこからアクセスしてきているか、といった具合です。

+ +

承認プロバイダ all, + env, + host, + ip + を使うと、リクエストを送信してきているマシンのホスト名や IP アドレス + といった、ホストベースでのアクセス制御ができます。

+ +

これらプロバイダの扱いは + Require や + Reject で + 指定されます。これらのディレクティブは承認プロバイダを登録し、 + リクエスト処理の承認段階で呼び出されます。たとえば:

+ +

+ Require ip address +

+ +

ここで、address は IP アドレス (あるいは IP アドレスの + 一部) か :

+ +

+ Require host domain_name +

+ +

ここで domain_name は FQDN (あるいはドメイン名の一部) + で、必要であれば複数のアドレスやドメイン名を書くことができます。

+ +

たとえば、スパムメッセージを送信してくる誰かを拒否したい場合、 + 次のようになります :

+ +

+ Reject ip 10.252.46.165 +

+ +

このディレクティブが有効な範囲のコンテンツに対しては、 + そのアドレスからアクセスしてきても見ることができません。 + もしマシン名がわかっていて IP アドレスよりもそちらで + 指定したいのであれば、そのマシン名が使えます。

+ +

+ Reject host host.example.com +

+ +

また、特定のドメインからのアクセス全てをブロックしたい場合は、 + IP アドレスの一部や、ドメイン名が指定できます :

+ +

+ <SatisfyAll>
+ + Reject ip 192.168.205
+ Reject host phishers.example.com moreidiots.example
Reject host ke
+ + </SatisfyAll> +

+ +

Reject ディレクティブを + <SatisfyAll> ブロックの中で使うと、 + 許可したいグループにのみアクセスができるように確認できます。

+ +

上記の例では <SatisfyAll> + を使って、アクセスに合格する前段階で、全ての + Reject ディレクティブが + 満たされていることを確認しています。

+ + + +

アクセス制御の後方互換性

+

認証プロバイダベースの機構があるため、以前使用されていたディレクティブ + Order, + Allow, + Deny, + Satisfy + は必要なくなりました。 + とはいうものの、古い設定ファイルでの後方互換性を提供するため、 + これらのディレクティブは mod_access_compat モジュールに移されました。

+ +

これらのディレクティブの抱えていた問題のひとつに、承認の設定行とアクセス制御の設定行の + 関係がとてもあいまいだったことが挙げられます。 + Satisfy ディレクティブは + リクエスト処理中でそれ自身を呼び出すことによって、これらの 2 つの処理段階を結びつけようとします。 + 現在は、これらのディレクティブは mod_access_compat に移動し、 + 新しい認証ディレクティブと古いアクセス制御ディレクティブを混ぜて使うことは + 難しくなっています。この問題のため、mod_authz_default モジュールを + ロードすることがとても重要で、必須になっています。 + mod_authz_default　モジュールの主な目的は、どの承認プロバイダで + 処理されなかった承認リクエストを受けることにあります。 + しかし、古いアクセス制御ディレクティブが用いられた場合には、 + アクセス制御と承認を結びつけて、すべての処理段階の出力結果を見てアクセスに合格するかを決めています。 + ですから、古いディレクティブがうまく動作しない場合は、 + mod_authz_default がロードされていないからかもしれない、 + と疑ってみてください。

+ + + +
top
+
+

追加情報

+

これら全てがどのように動作するかについて + もっと多くの情報が書かれている mod_auth_basic と + mod_authz_host + の文書も読むとよいでしょう。 + <AuthnProviderAlias> + ディレクティブを使うと、特定の認証設定が簡単に書けるようになります。

+ +

アクセス制御の方法も、 + 関連するトピックがたくさん記載されていますので、ご覧ください。

+ +
+
+

翻訳済み言語:  en  | + es  | + fr  | + ja  | + ko  | + tr 

+
top

コメント

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/auth.html.ko.euc-kr b/docs/manual/howto/auth.html.ko.euc-kr new file mode 100644 index 0000000..a6013b8 --- /dev/null +++ b/docs/manual/howto/auth.html.ko.euc-kr @@ -0,0 +1,355 @@ + + + + + +(Authentication), Ѻο(Authorization), +(Access Control) - Apache HTTP Server Version 2.4 + + + + + + +
+

| þ | FAQ | | Ʈ

+

Apache HTTP Server Version 2.4

+
+
<-
+

(Authentication), Ѻο(Authorization), +(Access Control)

+
+

:  en  | + es  | + fr  | + ja  | + ko  | + tr 

+
+
ֽ ƴմϴ. + ֱٿ ϼ.
+ +

(authentication) ڽ ϴ + Ȯϴ ̴. Ѻο(authorization) + Ȥ ϴ 򵵷 ϴ ̴.

+
+ +
top
+
+

þ

+
õ õ þ
+
top
+
+

Ұ

+

Ʈ ִ Ҽ 鸸 ̰ų + ̵鸸 , ۿ ϴ Ͽ + ϴ ִ.

+ +

Ʈ Ϻθ ȣϱ + ϴ "ǥ" ٷ.

+
top
+
+

⺻

+

ۿ ٷ þ ּ(Ϲ + <Directory> + )̳ 丮 (.htaccess ) + Ѵ.

+ +

.htaccess Ϸ Ͽ ִ + þ ϵ ؾ Ѵ. ̸ + 丮 Ͽ  þ ִ ϴ + AllowOverride þ + Ѵ.

+ +

⼭ ٷ , + AllowOverride þ ʿϴ.

+ +

+ AllowOverride AuthConfig +

+ +

Ȥ þ ּϿ ´ٸ, Ͽ + ־ Ѵ.

+ +

׸ ȣ ִ ˱ 丮 + ˾ƾѴ. ʰ, + ڼ ̴.

+
top
+
+

⺻ ϱ

+

丮 ȣ ȣϴ ⺻ + Ѵ.

+ +

ȣ Ѵ. + ־ Ѵ. ٸ ȣ ٿε + ϰϱ ؼ. , + /usr/local/apache/htdocs ִٸ ȣ() + /usr/local/apache/passwd д.

+ +

ġ Ե htpasswd Ͽ + ȣ . α׷ ġ ġ + bin 丮 ִ. + ԷѴ.

+ +

+ htpasswd -c /usr/local/apache/passwd/passwords rbowen +

+ +

htpasswd ȣ , Ȯ + ȣ ٽ Է϶ ûѴ.

+ +

+ # htpasswd -c /usr/local/apache/passwd/passwords rbowen
+ New password: mypassword
+ Re-type new password: mypassword
+ Adding password for user rbowen +

+ +

htpasswd ο ٸ + ü θ Էؾ Ѵ. ϴ + /usr/local/apache/bin/htpasswd + ִ.

+ +

ȣ ûϵ ϰ, +  ˷ Ѵ. + httpd.conf ϰų .htaccess + Ͽ Ѵ. , + /usr/local/apache/htdocs/secret 丮 + ȣϷ, Ʒ þ + /usr/local/apache/htdocs/secret/.htaccess ̳ + httpd.conf <Directory + /usr/local/apache/apache/htdocs/secret> ǿ + Ѵ.

+ +

+ AuthType Basic
+ AuthName "Restricted Files"
+ AuthUserFile /usr/local/apache/passwd/passwords
+ Require user rbowen +

+ +

þ ϳ 캸. AuthType þ ڸ + Ѵ. Ϲ Basic, + mod_auth_basic Ѵ. ׷ Basic + ȣ ȣȭ ʰ . + ׷Ƿ ڷḦ ȣϱ ϸ ȵȴ. + ġ AuthType Digest Ѵ. + mod_auth_digest ϸ, ſ + ϴ. ֱ Ŭ̾Ʈ鸸 Digest Ѵٰ + Ѵ.

+ +

AuthName þ + (realm) Ѵ. + ΰ Ѵ. ù° Ŭ̾Ʈ + ȣ ȭâ ش. ι° Ͽ + Ŭ̾Ʈ Ư  ȣ Ѵ.

+ +

, ϴ Ŭ̾Ʈ "Restricted Files" + Ͽٸ, Ŭ̾Ʈ ڵ + "Restricted Files" ǥõ + ȣ õѴ. ׷ + ϸ ڰ ȣ Է ʾƵ ȴ. + Ȼ Ŭ̾Ʈ ȣƮ ٸ ׻ + ȣ .

+ +

AuthUserFile + þ 츮 htpasswd ȣ + θ Ѵ. ڰ ٸ û Ź ڸ + ϱ Ϲ ˻ϴµ ð + ɸ ִ. ġ Ÿ̽ Ͽ + ִ. mod_authn_dbm AuthDBMUserFile þ + Ѵ. dbmmanage + α׷ Ͽ ȣ ٷ. ġ + Ÿ̽ ٸ ϴ ڰ + ִ.

+ +

Require + þ Ư ִ ڸ Ͽ + Ѻο Ѵ. require þ + ϴ پ Ѵ.

+
top
+
+

鿩

+

þ 丮 (ڸ rbowen) + 鿩. κ 鿩 + ̴. AuthGroupFile + .

+ +

鿩 ʹٸ ׷ ׷쿡  + ڵ ִ ˷ִ ׷ ʿϴ. + ſ Ͽ, ƹ γ ִ. ϳ + .

+ +

+ GroupName: rbowen dpitts sungo rshersey +

+ +

׳ ׷ ̴.

+ +

ȣϿ ڸ ߰Ϸ ԷѴ

+ +

+ htpasswd /usr/local/apache/passwd/passwords dpitts +

+ +

, ʰ Ͽ ڸ + ߰Ѵ. (-c ɼ ȣ ).

+ +

.htaccess Ѵ.

+ +

+ AuthType Basic
+ AuthName "By Invitation Only"
+ AuthUserFile /usr/local/apache/passwd/passwords
+ AuthGroupFile /usr/local/apache/passwd/groups
+ Require group GroupName +

+ +

׷ GroupName ׷쿡 ϸ + password Ͽ ׸ ִ ڰ ùٸ + ȣ Էϸ Ѵ.

+ +

Ϲ ڸ 鿩 ٸ ִ. ׷ + ʿ þ ϱ⸸ ϸ ȴ.

+ +

+ Require valid-user +

+ +

Require user rbowen þ ϸ + ȣϿ ִ ùٸ ȣ Էϱ⸸ ϸ + Ѵ. ׷캰 ٸ ȣ Ͽ ׷ + ȿ ִ. ġ ΰ(ȣϰ + ׷) ƴ Ѱ(ȣ) ˻ϸ ȴٴ + ̴. ׷ ȣ ؾ ϰ, AuthUserFile þ + Ȯ ȣ ؾ ϴ ̴.

+
top
+
+

߻ ִ

+

Basic û ڸ + ȣ ȮѴ. ħ + (׸ ȣ ȣϴ 丮 ִ ) ִ + ׸ ٽ ȮѴ. ϵ ӵ . + ȣ  ڸ ã + ϱ⶧ ȣ ũⰡ Ŀ . ׸ + ۾ û Ѵ.

+ +

׷ ȣϿ ִ ڼ + Ѱ谡 ִ. Ѱ ϴ ɿ ٸ, + ׸ 鰳 Ѵ´ٸ ٰ ϰ ٸ + ؾ Ѵ.

+
top
+
+

ٸ Ѱ?

+

ڸ ȣ ٰ ƴϴ. + ҿ ٸ ڸ 鿩 + ִ.

+ +

Allow + Deny þ + û ǻ ȣƮ Ȥ ȣƮ ּҸ + ϰų źѴ. Order þ + þ Ͽ, ġ  Ģ + ˸.

+ +

̵ þ .

+ +

+ Allow from address +

+ +

⼭ address IP ּ(Ȥ IP ּ Ϻ) + θ(Ȥ θ Ϻ)̴. Ѵٸ ּҳ + θ ִ.

+ +

, Խǿ ø ִٸ + ִ.

+ +

+ Deny from 205.252.46.165 +

+ +

ּҿ 湮ڴ þ ȣϴ + . IP ּ ǻ͸ + ִ.

+ +

+ Deny from host.example.com +

+ +

, ü ּҳ θ Ϻθ + Ѵ.

+ +

+ Deny from 192.101.205
+ Deny from cyberthugs.com moreidiots.com
+ Deny from ke +

+ +

Order + Deny Allow þ + Ͽ ϴ ִ.

+ +

+ Order deny,allow
+ Deny from all
+ Allow from dev.example.com +

+ +

Allow + þ ϸ, ش ȣƮ ڸ ϰ ű⿡ + ߰ ϹǷ ϴ Ѵ. + Ư ϱ Ѵ.

+
top
+
+

+

mod_auth_basic + mod_authz_host  ϴ + ִ.

+
+
+

:  en  | + es  | + fr  | + ja  | + ko  | + tr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/auth.html.tr.utf8 b/docs/manual/howto/auth.html.tr.utf8 new file mode 100644 index 0000000..fda3281 --- /dev/null +++ b/docs/manual/howto/auth.html.tr.utf8 @@ -0,0 +1,639 @@ + + + + + +Kimlik Doğrulama ve Yetkilendirme - Apache HTTP Sunucusu Sürüm 2.4 + + + + + + +
+

Modüller | Yönergeler | SSS | Terimler | Site Haritası

+

Apache HTTP Sunucusu Sürüm 2.4

+
+
<-
+

Kimlik Doğrulama ve Yetkilendirme

+
+

Mevcut Diller:  en  | + es  | + fr  | + ja  | + ko  | + tr 

+
+ +

Kimlik Doğrulama istediğiniz kişileri teyid etme işlemidir. + Yetkilendirme ise kişilerin nereye gireceklerine ve hangi bilgiye + ulaşacaklarına müsaade edilmesi işlemidir.

+ +

Genel erişim denetimi için Erişim Denetimi + Nasıl belgesine bakınız.

+
+ +
top
+
+

İlgili modüller ve Yönergeler

+ +

Kimlik Doğrulama ve yetkilendirme işlemi ile ilgili üç tür modül + vardır. Genellikle her bir gruptan en az bir modül seçeceksiniz.

+ + + +

Bu modüllere ek olarak, mod_authn_core ve + mod_authz_core modülleri bulunur. Bu modüller + yetkilendirme modüllerinin çekirdeğini oluşturan temel yönergeleri + gerçekler.

+ +

mod_authnz_ldap modülü kimlik doğrulama ve + yetkilendirme işlemlerinin ikisini birden gerçekleştirir. + mod_authz_host modülü bu işlemleri sunucu adına, IP + adresine ve isteğin karekteristiğine bağlı olarak gerçekleştirir. + Ancak kimlik doğrulama sisteminin bir parçası değildir. + mod_access ile geriye uyumluluk için + mod_access_compat diye bir modül daha vardır.

+ +

Muhtemelen göz atmak isteyeceğiniz Erişim + Denetimi nasıl belgesi, sunucuya erişimlerin çeşitli yollarından + bahsetmektedir.

+
top
+
+

Giriş

+

Sitenizde sadece küçük bir grup insana hitap eden ya da hassas + bilgileriniz varsa, bu makaledeki teknikleri kullanarak dilediğiniz + kişilerin sadece dilediğiniz sayfaları görüntülemesini + sağlayabilirsiniz.

+ +

Bu makale sitenizin bazı parçalarını korumak için kullanacağınız + "standart" yolları içermektedir.

+ +

Bilginize:

+

Eğer bilgileriniz gerçekten gizliliğe ihtiyaç duyuyorsa kimlik + doğrulamasına ilaveten mod_ssl modülünü de + kullanabilirsiniz.

+
+ +
top
+
+

Ön gereksinimler

+ +

Bu makalede bahsi geçen yönergeler ya ana sunucu yapılandırma + dosyasında (genellikle <Directory> bölümünde) ya da dizin içi + yapılandırma dosyalarında (.htaccess dosyaları) + bulunmak zorundadır.

+ +

Eğer .htaccess dosyalarını kullanmayı + tasarlıyorsanız, kimlik doğrulama yönergelerine bu dosyaların içine + koymaya izin veren sunucu yapılandırmasına ihtiyacınız olacaktır. + Bunun için, dizin içi yapılandırma dosyalarının içine hangi + yönergelerin konacağını belirleyen AllowOverride yönergesi kullanılır.

+ +

Kimlik doğrulamadan sözettiğimize göre, aşağıda gösterilen + şekilde bir AllowOverride yönergesine ihtiyacınız olacaktır:

+ + 
AllowOverride AuthConfig
+ + +

Yönergeleri doğrudan ana sunucunun yapılandırma dosyasına + koyacaksanız bu dosyaya yazma izniniz olmalıdır.

+ +

Bazı dosyaların nerede saklandığını bilmek için sunucunun dizin + yapısı hakkında biraz bilgi sahibi olmanız gerekmektedir. Bu çok da + zor olmamakla birlikte bu noktaya gelindiğinde konuyu + netleştireceğiz.

+ +

Ayrıca mod_authn_core ve + mod_authz_core modülleri ya httpd + çalıştırılabilirinin içinde derlenmiş olmalı ya da + httpd.conf yapılandırma dosyası ile yüklenmelidir. Bu + iki modül HTTP sunucusunda kimlik doğrulama ve yetkilendirme + kullanımı ve yapılandırması için büyük öneme sahip temel yönergeleri + ve işlevselliği sağlar.

+ +
top
+
+

Çalışmaya Başlama

+

Burada, sunucu üzerindeki bir dizini parolayla korumak için + gereken temel bilgiler verilecektir.

+ +

İlk olarak bir parola dosyası oluşturmalısınız. Bunu nasıl + yapacağınız, özellikle, seçtiğiniz kimlik doğrulayıcıya göre + değişiklik gösterir. Bunun üzerinde ileride daha fazla duracağız. + Başlangıç için parolaları bir metin dosyasında tutacağız.

+ +

Bu dosya belge kök dizini altında olmamalıdır. Böylece başkaları + parola dosyasını indiremezler. Örneğin belgeleriniz + /usr/local/apache/htdocs üzerinden sunuluyorsa parola + dosyanızı /usr/local/apache/passwd dizininde + tutabilirsiniz.

+ +

Dosyayı oluşturmak için Apache ile gelen + htpasswd uygulamasını kullanacağız. Bu uygulama + Apache'nin kurulumunda belirtilen bin dizininde + bulunur. Eğer Apache'yi üçüncü parti paketlerden kurduysanız, + çalıştırılabilir dosyaların bulunduğu yollar üzerinde olmalıdır.

+ +

Bir dosya oluşturmak için şunları yazın:

+ +

+ htpasswd -c /usr/local/apache/passwd/passwords umut +

+ +

htpasswd size parola soracaktır arkasından da + teyit etmek için parolayı tekrar girmenizi isteyecektir:

+ +

+ # htpasswd -c /usr/local/apache/passwd/passwords umut
+ New password: parolam
+ Re-type new password: parolam
+ Adding password for user umut +

+ +

Eğer htpasswd normal yollar üzerinde değilse + çalıştırmak için dosyanın bulunduğu tam yeri belirtmeniz + gerekecektir. Dosyanın öntanımlı kurulum yeri: + /usr/local/apache2/bin/htpasswd

+ +

Bundan sonra, sunucuyu, parola sorması için ve kimlerin erişim + izni olacağını belirlemek için yapılandıracaksınız. Bu işlemi + httpd.confdosyasını düzenleyerek ya da bir + .htaccess dosyası kullanarak yapabilirsiniz. Örneğin, + /usr/local/apache/htdocs/secret dizinini korumayı + amaçlıyorsanız, şu yönergeleri kullanabilirsiniz. Bu yönergeleri + /usr/local/apache/htdocs/secret/.htaccess dosyası içine + veya httpd.conf içindeki <Directory + "/usr/local/apache/htdocs/secret"> bölümüne koyabilirsiniz.

+ + 
AuthType Basic
+AuthName "Gizli Dosyalar"
+# (Aşağıdaki satırın kullanımı isteğe bağlıdır)
+AuthBasicProvider file
+AuthUserFile "/usr/local/apache/passwd/passwords"
+Require user umut
+ + +

Bu yönergeleri tek tek inceleyelim. + AuthType yönergesi + kullanıcının kimliğini doğrulamakta kullanılacak yöntemi seçer. En + çok kullanılan yöntem Basic'tir ve bu yöntem + mod_auth_basic modülüyle gerçeklenmiştir. Temel + (Basic) kimlik doğrulamasıyla gönderilen parolanın + şifrelenmeyeceğini unutmayın. Bu yöntem, bu sebepten dolayı + mod_ssl eşliğinde kullanılmadığı sürece yüksek + hassasiyete sahip bilgiler için kullanılmamalıdır. Apache bir başka + kimlik doğrulama yöntemini daha destekler: AuthType + Digest. Bu yöntem mod_auth_digest tarafından + gerçeklenmişti ve çok daha güvenli olacağı düşünülmüştü. Bu artık + geçerliliğini yitirdiğinden bağlantının bundan böyle + mod_ssl ile şifrelenmesi gerekmektedir.

+ +

AuthName yönergesi + ile kimlik doğrulamada kullanılacak Saha da + belirtilebilir. Saha kullanımının, başlıca iki işlevi vardır. + Birincisi, istemci sıklıkla bu bilgiyi kullanıcıya parola diyalog + kutusunun bir parçası olarak sunar. İkincisi, belirtilen kimlik + doğrulamalı alan için gönderilecek parolayı belirlerken istemci + tarafından kullanılır.

+ +

Örneğin, bir istemcinin "Gizli Dosyalar" alanında + kimliği doğrulanmış olsun. Aynı sunucu üzerinde "Gizli + Dosyalar" Sahası olarak belirlenmiş alanlarda aynı parola + özdevinimli olarak yinelenecektir. Böylece parola bir kere girilerek + aynı Sahayı paylaşan çok sayıda kısıtlanmış alana ulaşırken oluşacak + gecikmeden kullanıcı korunmuş olur. Güvenlik gerekçelerinden dolayı, + her sunucu adı değiştirilişinde istemcinin parolayı yeniden sorması + gerekir.

+ +

AuthBasicProvider + yönergesinin öntanımlı değeri file olduğundan, bu + durumda, bu yönergenin kullanımı isteğe bağlıdır. Ancak, eğer kimlik + doğrulaması için mod_authn_dbm ya da + mod_authn_dbd gibi farklı bir kaynak seçecekseniz + bu yönergeyi kullanmanız gerekecektir.

+ +

AuthUserFile + yönergesi htpasswd ile oluşturduğumuz parola + dosyasının yerini belirtmek için kullanılır. Eğer çok sayıda + kullanıcınız varsa her bir kullanıcıyı her kimlik doğrulama isteği + için kimlik bilgilerini bir metin dosyasında aramak gayet yavaş + olacaktır. Apache, kullanıcı bilgilerini hızlı bir veritabanı + dosyasında depolama özelliğine de sahiptir. Bu amaçla, + mod_authn_dbm modülünün + AuthDBMUserFile + yönergesi kullanılabilir. Bu dosyalar dbmmanage ve + htdbm programı ile oluşturulabilir ve değiştirilebilir. + Üçüncü parti modüllerinde çok sayıda + başka kimlik doğrulama türü de vardır.

+ +

Son olarak Require + yönergesi, sunucunun bu bölgesine erişimine izin verilen + kullanıcıları ayarlama işleminin kimlik doğrulamasıyla ilgili + kısmını sağlar. Bir sonraki bölümde Require yönergesini kullanmanın + çeşitli yoları üzerinde duracağız.

+
top
+
+

Birden çok kişiye izin vermek

+ +

Yukarıdaki yönergelerle bir dizinde sadece bir kişiye + (umut adlı kullanıcıya) izin verir. Çoğunlukla birden + çok kişiye izin verilmesi istenir. Bu durumda AuthGroupFile yönergesi + devreye girer.

+ +

Eğer birden çok kişiye izin vermek istiyorsanız içinde kullanıcı + isimlerinin olduğu bir grup dosyası oluşturmalısınız. Bu dosyanın + biçemi gayet basittir ve bunu herhangi bir metin düzenleyici ile + oluşturabilirsiniz. Bu dosyanın içeriği aşağıdaki gibi + görünecektir:

+ +

+ GroupName: umut samet engin kubilay +

+ +

Dosya, sadece, boşluklarla birbirinden ayrılmış gurup üyelerinin + isimlerinden oluşan uzun bir liste içerir.

+ +

Varolan parola dosyasına bir kullanıcı eklemek için şunu + yazın:

+ +

+ htpasswd /usr/local/apache/passwd/passwords birey +

+ +

Evvelce almış olduğunuz yanıtı yine alacaksınız ama bu sefer yeni + bir dosya oluşturulmak yerine var olan bir dosyaya eklenecektir. + (Yeni bir parola dosyası oluşturmak için -c seçeneği + kullanılır).

+ +

Şimdi, .htaccess dosyanızı veya + <Directory> bölümünüzü + aşağıda görüldüğü şekilde değiştirebilirsiniz:

+ + 
AuthType Basic
+AuthName "Davete Binaen"
+# Satır isteğe bağlıdır:
+AuthBasicProvider file
+AuthUserFile "/usr/local/apache/passwd/passwords"
+AuthGroupFile "/usr/local/apache/passwd/groups"
+Require group Grupismi
+ + +

Artık, Grupismi gurubunda listelenmiş ve + password dosyasında kaydı olan kişiye, parolayı doğru + yazdığı takdirde izin verilecektir.

+ +

Çoklu kullanıcıya izin veren biraz daha az kullanılan başka bir + yol daha mevcuttur. Bir gurup dosyası oluşturmaktansa, şu yönergeyi + kullanabilirsiniz:

+ + 
Require valid-user
+ + +

Require user umut satırı ile parola dosyasında + listelenmiş ve parolayı doğru olarak giren herhangi bir kişiye izin + vermektense, her grup için ayrı bir parola dosyası tutarak grup + davranışını taklit edebilirsiniz.

+ +
top
+
+

Olası Sorunlar

+

Temel kimlik doğrulama yolu belirtildiği için, sunucuya + yaptığınız her belge istediğinde kullanıcı adınızın ve parolanızın + doğrulanması gerekir. Hatta aynı sayfayı yeniden yüklerken ya da + sayfadaki her bir resim için bu yapılmalıdır (şayet korunmakta olan + bir dizinden geliyorsa). Bu işlem hızı azaltacaktır. Yavaşlama + miktarı parola dosyanızın büyüklüğü ile orantılı olacaktır, çünkü bu + işlem sırasında dosya açılacak ve kullanıcıların arasında isminiz + bulunana kadar liste aşağı doğru taranacaktır. Bu işlem sayfa her + yüklenişinde tekrar edilecektir.

+ +

Buradan çıkacak sonuç, bir parola dosyasına konulan kullanıcı + sayısında bir üst sınır olması gerekliliğidir. Bu sınır sunucunuzun + başarımına bağlı olarak değişiklik gösterir. Bir kaç yüz kayıtın + üstünde giriş yaptığınızda hız düşüşünü gözlemlebilirsiniz İşte bu + anda kimlik doğrulama için başka bir yöntem aramaya başlarsınız.

+ +
top
+
+

Diğer parola depolama yöntemleri

+ +

Parolaları basit bir metin dosyasında depolamak yukarıda + bahsedilen sorunlara yol açtığından parolaları başka bir yerde + depolamayı düşünebilirsiniz; örneğin bir veritabanında.

+ +

mod_authn_dbm ve mod_authn_dbd + modülleri bunu mümkün kılan iki modüldür. Depolama yönemi olarak + AuthBasicProvider file yerine, dbm + veya dbd kullanabilirsiniz.

+ +

Bir metin dosyası yerine bir dbm dosyası kullanım örneği:

+ + 
<Directory "/www/docs/private">
+    AuthName "Private"
+    AuthType Basic
+    AuthBasicProvider dbm
+    AuthDBMUserFile "/www/passwords/passwd.dbm"
+    Require valid-user
+</Directory>
+ + +

Başka seçenekler de mümkündür. Ayrınılar için + mod_authn_dbm belgesine başvurun.

+ +
top
+
+

Birden çok tedarikçi kullanmak

+ +

Kimlik doğrulama ve yetkilendirme mimarisine dayalı yeni + tedarikçiyi kullanarak tek bir yetkilendirme ya da kimlik doğrulama + yöntemine kilitlenip kalmayacaksınız. Aslında birden çok tedarikçi + ihtiyacınıza cevap vermek için bir arada kullanılabilir. Aşağıdaki + örnekte dosya ve LDAP tabanlı kimlik doğrulama tedarikçileri bir + arada kullanılmıştır.

+ + 
<Directory "/www/docs/private">
+    AuthName "Private"
+    AuthType Basic
+    AuthBasicProvider file ldap
+    AuthUserFile "/usr/local/apache/passwd/passwords"
+    AuthLDAPURL ldap://ldaphost/o=yourorg
+    Require valid-user
+</Directory>
+ + +

Bu örnekte dosya tedarikçisi, ilk olarak kullanıcının kimliğini + doğrulamaya teşebbüs edecektir. Kullanıcının kimliği + doğrulanamıyorsa LDAP tedarikçisi çağırılır. Eğer kurumunuz birden + çok kimlik doğrulama tedarikçisini yürürlüğe koyuyorsa bu, kimlik + doğrulama faaliyet alanının genişletilmesini sağlar. Diğer kimlik + kanıtlama ve yetkilendirme senaryoları tek bir kimlik doğrulaması + ile birden fazla yetkilendirme türüne izin verebilir.

+ +

Çok sayıda kimlik doğrulama tedarikçisi uygulamaya konulabileceği + gibi, çok sayıda yetkilendirme yöntemi de kullanılabilir. Bu örnekte + dosya için hem dosyalı hem de LDAP grup kimlik doğrulaması + kullanılmıştır.

+ + 
<Directory "/www/docs/private">
+    AuthName "Private"
+    AuthType Basic
+    AuthBasicProvider file
+    AuthUserFile "/usr/local/apache/passwd/passwords"
+    AuthLDAPURL ldap://ldaphost/o=yourorg
+    AuthGroupFile "/usr/local/apache/passwd/groups"
+    Require group GroupName
+    Require ldap-group cn=mygroup,o=yourorg
+</Directory>
+ + +

Kimlik doğrulama konusunu biraz daha genişletirsek, <RequireAll> ve + <RequireAny> gibi yetkilendirme taşıyıcısı + yönergelerle hangi iznin hangi sırayla uygulanacağını + belirlenebilir. Yetkilendirme Taşıyıcıları bölümünde bunun bir uygulama + örneğini görebilirsiniz.

+ +
top
+
+

Yetkilendirmenin biraz ötesi

+

Tek bir veri deposundan yapılacak tek bir sınamadan çok daha + esnek kimlik doğrulaması yapılabilir. Sıralama, mantık ve hangi + kimlik doğrulamasının kullanılacağını seçmek mümkündür.

+ +

Mantık ve sıralamanın uygulanması

+ +

Yetkilendirmenin hangi sırayla uygulanacağı ve nasıl + denetleneceği geçmişte biraz gizemli bir konuydu. Apache 2.2'de, + tedarikçi tabanlı kimlik doğrulamasının devreye girmesiyle asıl + kimlik doğrulama işlemini yetkilendirme ve destek işlevselliğinden + ayırmak mümkün oldu. Bunun faydalarından birisi de kimlik + doğrulama tedarikçilerinin yapılandırılabilmesi ve auth modülünün + kendi yükleme sırasından bağımsız olarak özel bir sırayla + çağrılabilmesidir. Bu tedarikçi tabanlı mekanizmanın aynısı + yetkilendirmeye de getirilmiştir. Bunun anlamı Require yönergesinde hangi + izin yönteminin kullanılması gerektiğinin belirtmesinin yanında + hangi sırayla çağırılacaklarının da belirlenebildiğidir. Çok + sayıda yetkilendirme yöntemi kullanıldığında, bunlar, Require yönergelerinin + yapılandırma dosyasında göründükleri sıra ile çağırılır.

+ +

<RequireAll> ve <RequireAny> gibi yetkilendirme + taşıyıcısı yönergelerin devreye girmesiyle yetkilendirme + yöntemlerinin ne zaman çağırılacağı ve çağırıldığında ve erişime + izin verirken hangi kuralların uygulanacağı konusunda denetim + yapılandırmanın eline geçmektedir. Karmaşık yetkilendime mantığını + ifade etmek için kullanılan bir örneği görmek için + Yetkilendirme + Taşıyıcıları bölümüne bakınız.

+ +

Öntanımlı olarak tüm + Require yönergeleri, <RequireAny> + taşıyıcı yönergesinin içine konur. Başka bir deyişle eğer + belirtilen kimlik doğrulama yöntemlerinden herhangi biri başarılı + olursa yetkilendirme de sağlanmış olur.

+ + + +

Erişim denetimi için yetkilendirme tedarikçilerinin + kullanımı

+ +

Kullanıcı adı ve parolasına göre kimlik doğrulama hikayenin + sadece bir bölümüdür. Sıklıkla insanlara kim olduklarına göre + değil birşeylere dayanarak izin vermek istersiniz. Örneğin nereden + geldikleri gibi.

+ +

all, env, host ve + ip gibi yetkilendirme tedarikçileri ile, bir belgenin + istendiği makinenin IP adresi veya konak ismi gibi bazı özelliklerine + dayalı olarak erişime izin verip vermeyeceğinizi belirtebilirsiniz.

+ +

Bu tedarikçilerin kullanımı Require yönergesinde açıklanmıştır. Bu yönergeler, + isteklerin işlenmesi sırasında yetkilendirme aşamasında + çağırılacak yetkilendirme tedarikçilerini kayda geçirir. Örneğin: +

+ + 
Require ip adres
+
+ + +

Burada, adres bir IP adresidir (veya kısmi bir IP + addresidir)

+ + 
Require host alan_adı
+
+ + +

Burada, alan_adı bir tam nitelikli alan adıdır + (ya da kısmi alan adıdır); gerekirse çok sayıda alan adı veya IP + adresi de belirtilebilir.

+ +

Örneğin, yorum alanını gereksiz iletilerle dolduran birini uzak + tutmak istediğinizi varsayalım. Bu kişiyi uzak tutmak için şunları + yapabilirsiniz:

+ + 
<RequireAll>
+    Require all granted
+    Require not ip 10.252.46.165
+</RequireAll>
+ + +

Bu adresden gelen ziyaretçiler bu yönergedeki içeriği + göremeyeceklerdir. Bunun yerine, elinizde IP adresi değil de + makine adı varsa şunu kullanabilirsiniz:

+ + 
<RequireAll>
+    Require all granted
+    Require not host host.example.com
+</RequireAll>
+ + +

Eğer alan adının tamanıdan gelecek olan bütün erişimleri + engellemek isterseniz adresin ya da alan adının bir parçasını + belirtin:

+ + 
<RequireAll>
+    Require all granted
+    Require not ip 192.168.205
+    Require not host phishers.example.com moreidiots.example
+    Require not host ke
+</RequireAll>
+ + +

<RequireAll> yönergesini çok sayıda + <Require> yönergesi ile birlikte kullanarak, + sadece not ile olumsuzlanan tüm koşulları gerçekleyen + bağlantılara erişim verilir. Başka bir deyişle, olumsuzlanan koşulları + gerçeklemeyen bağlantıların erişimi engellenir.

+ + + +

Erişim denetimi ve geriye uyumluluk

+ +

Kimlik doğrulama için tedarik tabanlı mekanizma kullanımının + yan etkilerinden birisi, + Order, + Allow, + Deny ve + Satisfy erişim + denetim yönergelerine artık ihtiyaç duyulmamasıdır. Ancak eski + yapılandırmalarla uyumluluğu sağlamak için bu yönergeler + mod_access_compat modülüne taşınmıştır.

+ +

Note

+

mod_access_compat ile sağlanan yönergelerin + kullanımı artık önerilmemekte, mod_authz_host + modülündeki yönergeler önerilmektedir. Order, Allow veya Deny ile + Require gibi daha yeni + olanlarının yenilerle karışık kullanımı teknik olarak mümkünse de + önerilmemektedir. mod_access_compat modülü, 2.4 + yükseltmesini kolaylaştırmak için sadece eski yönergeleri içeren + yapılandırmaları desteklemek üzere oluşturulmuştur. Daha ayrıntılı + bilgi için yükseltme belgesine bakınız. +

+
+ + +
top
+
+

Kimlik Doğrulama Arabelleği

+

Zaman zaman kimlik doğrulama ağınızda veya sağlayıcı(ları)nızda kabul + edilemez yükler oluşturur. Bu çoğunlukla mod_authn_dbd + (veya üçüncü parti/özel sağlayıcıların) kullanıcılarını etkiler. Bununla + ilgilenmek için httpd 2.3/2.4, kimlik bilgilerini arabelleklemek ve özgün + sağlayıcıların yüklerini azaltmak için yeni bir arabellekleme sağlayıcısı + olarak mod_authn_socache modülü ile gelmektedir.

+

Bu, bazı kullanıcılar için önemli bir başarım artışı sağlayabilir.

+
top
+
+

Daha fazla bilgi

+

Daha fazla bilgi için mod_auth_basic ve + mod_authz_host modüllerinin belgelerine bakınız. + AuthnProviderAlias + yönergesi ile bazı yapılandırmalarınızı basitleştirebilirsiniz.

+ +

Apache tarafından desteklenen şifrelerle ilgili bilgi için Parola Biçemleri + belgesine bakınız.

+ +

Erişim Denetimi nasıl belgesinden de + bazı bilgiler edinebilirsiniz.

+
+
+

Mevcut Diller:  en  | + es  | + fr  | + ja  | + ko  | + tr 

+
top

Yorumlar

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/cgi.html b/docs/manual/howto/cgi.html new file mode 100644 index 0000000..81f1cfc --- /dev/null +++ b/docs/manual/howto/cgi.html @@ -0,0 +1,21 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: cgi.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: cgi.html.es +Content-Language: es +Content-type: text/html; charset=ISO-8859-1 + +URI: cgi.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 + +URI: cgi.html.ja.utf8 +Content-Language: ja +Content-type: text/html; charset=UTF-8 + +URI: cgi.html.ko.euc-kr +Content-Language: ko +Content-type: text/html; charset=EUC-KR diff --git a/docs/manual/howto/cgi.html.en b/docs/manual/howto/cgi.html.en new file mode 100644 index 0000000..ef5d866 --- /dev/null +++ b/docs/manual/howto/cgi.html.en @@ -0,0 +1,601 @@ + + + + + +Apache Tutorial: Dynamic Content with CGI - Apache HTTP Server Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.4

+
+
<-
+

Apache Tutorial: Dynamic Content with CGI

+
+

Available Languages:  en  | + es  | + fr  | + ja  | + ko 

+
+
+ +
top
+
+

Introduction

+ + +
Related ModulesRelated Directives
+ +

The CGI (Common Gateway Interface) defines a way for a web + server to interact with external content-generating programs, + which are often referred to as CGI programs or CGI scripts. It + is a simple way to put dynamic content on + your web site, using whatever programming language you're most + familiar with. This document will be an introduction to setting + up CGI on your Apache web server, and getting started writing + CGI programs.

+
top
+
+

Configuring Apache to permit CGI

+ + +

In order to get your CGI programs to work properly, you'll + need to have Apache configured to permit CGI execution. There + are several ways to do this.

+ +
Note: If Apache has been built with shared module + support you need to ensure that the module is loaded; in your + httpd.conf you need to make sure the + LoadModule + directive has not been commented out. A correctly configured directive + may look like this: + + 
LoadModule cgid_module modules/mod_cgid.so
+ + + + On Windows, or using a non-threaded MPM like prefork, A correctly + configured directive may look like this: + + 
LoadModule cgi_module modules/mod_cgi.so
+
+ + +

ScriptAlias

+ + +

The + ScriptAlias + + directive tells Apache that a particular directory is set + aside for CGI programs. Apache will assume that every file in + this directory is a CGI program, and will attempt to execute + it, when that particular resource is requested by a + client.

+ +

The ScriptAlias + directive looks like:

+ + 
ScriptAlias "/cgi-bin/" "/usr/local/apache2/cgi-bin/"
+ + +

The example shown is from your default httpd.conf + configuration file, if you installed Apache in the default + location. The ScriptAlias + directive is much like the Alias directive, which defines a URL prefix that + is to mapped to a particular directory. Alias + and ScriptAlias are usually used for + directories that are outside of the DocumentRoot directory. The difference between + Alias and ScriptAlias + is that ScriptAlias has the added meaning + that everything under that URL prefix will be considered a CGI + program. So, the example above tells Apache that any request for a + resource beginning with /cgi-bin/ should be served from + the directory /usr/local/apache2/cgi-bin/, and should be + treated as a CGI program.

+ +

For example, if the URL + http://www.example.com/cgi-bin/test.pl + is requested, Apache will attempt to execute the file + /usr/local/apache2/cgi-bin/test.pl + and return the output. Of course, the file will have to + exist, and be executable, and return output in a particular + way, or Apache will return an error message.

+ + +

CGI outside of ScriptAlias directories

+ + +

CGI programs are often restricted to ScriptAlias'ed directories for security reasons. + In this way, administrators can tightly control who is allowed to + use CGI programs. However, if the proper security precautions are + taken, there is no reason why CGI programs cannot be run from + arbitrary directories. For example, you may wish to let users + have web content in their home directories with the + UserDir directive. + If they want to have their own CGI programs, but don't have access to + the main cgi-bin directory, they will need to be able to + run CGI programs elsewhere.

+ +

There are two steps to allowing CGI execution in an arbitrary + directory. First, the cgi-script handler must be + activated using the AddHandler or SetHandler directive. Second, + ExecCGI must be specified in the Options directive.

+ + +

Explicitly using Options to permit CGI execution

+ + +

You could explicitly use the Options directive, inside your main server configuration + file, to specify that CGI execution was permitted in a particular + directory:

+ + 
<Directory "/usr/local/apache2/htdocs/somedir">
+    Options +ExecCGI
+</Directory>
+ + +

The above directive tells Apache to permit the execution + of CGI files. You will also need to tell the server what + files are CGI files. The following AddHandler directive tells the server to treat all + files with the cgi or pl extension as CGI + programs:

+ + 
AddHandler cgi-script .cgi .pl
+ + + +

.htaccess files

+ + +

The .htaccess tutorial + shows how to activate CGI programs if you do not have + access to httpd.conf.

+ + +

User Directories

+ + +

To allow CGI program execution for any file ending in + .cgi in users' directories, you can use the + following configuration.

+ + 
<Directory "/home/*/public_html">
+    Options +ExecCGI
+    AddHandler cgi-script .cgi
+</Directory>
+ + +

If you wish designate a cgi-bin subdirectory of + a user's directory where everything will be treated as a CGI + program, you can use the following.

+ + 
<Directory "/home/*/public_html/cgi-bin">
+    Options ExecCGI
+    SetHandler cgi-script
+</Directory>
+ + + + +
top
+
+

Writing a CGI program

+ + +

There are two main differences between ``regular'' + programming, and CGI programming.

+ +

First, all output from your CGI program must be preceded by + a MIME-type header. This is HTTP header that tells the client + what sort of content it is receiving. Most of the time, this + will look like:

+ +

+ Content-type: text/html +

+ +

Secondly, your output needs to be in HTML, or some other + format that a browser will be able to display. Most of the + time, this will be HTML, but occasionally you might write a CGI + program that outputs a gif image, or other non-HTML + content.

+ +

Apart from those two things, writing a CGI program will look + a lot like any other program that you might write.

+ +

Your first CGI program

+ + +

The following is an example CGI program that prints one + line to your browser. Type in the following, save it to a + file called first.pl, and put it in your + cgi-bin directory.

+ + 
#!/usr/bin/perl
+print "Content-type: text/html\n\n";
+print "Hello, World.";
+ + +

Even if you are not familiar with Perl, you should be able + to see what is happening here. The first line tells Apache + (or whatever shell you happen to be running under) that this + program can be executed by feeding the file to the + interpreter found at the location /usr/bin/perl. + The second line prints the content-type declaration we + talked about, followed by two carriage-return newline pairs. + This puts a blank line after the header, to indicate the end + of the HTTP headers, and the beginning of the body. The third + line prints the string "Hello, World.". And that's the end + of it.

+ +

If you open your favorite browser and tell it to get the + address

+ +

+ http://www.example.com/cgi-bin/first.pl +

+ +

or wherever you put your file, you will see the one line + Hello, World. appear in your browser window. + It's not very exciting, but once you get that working, you'll + have a good chance of getting just about anything working.

+ +
top
+
+

But it's still not working!

+ + +

There are four basic things that you may see in your browser + when you try to access your CGI program from the web:

+ +
+
The output of your CGI program
+
Great! That means everything worked fine. If the output is correct, + but the browser is not processing it correctly, make sure you have the + correct Content-Type set in your CGI program.
+ +
The source code of your CGI program or a "POST Method Not + Allowed" message
+
That means that you have not properly configured Apache + to process your CGI program. Reread the section on + configuring + Apache and try to find what you missed.
+ +
A message starting with "Forbidden"
+
That means that there is a permissions problem. Check the + Apache error log and the section below on + file permissions.
+ +
A message saying "Internal Server Error"
+
If you check the + Apache error log, you will probably + find that it says "Premature end of + script headers", possibly along with an error message + generated by your CGI program. In this case, you will want to + check each of the below sections to see what might be + preventing your CGI program from emitting the proper HTTP + headers.
+
+ +

File permissions

+ + +

Remember that the server does not run as you. That is, + when the server starts up, it is running with the permissions + of an unprivileged user - usually nobody, or + www - and so it will need extra permissions to + execute files that are owned by you. Usually, the way to give + a file sufficient permissions to be executed by nobody + is to give everyone execute permission on the file:

+ +

+ chmod a+x first.pl +

+ +

Also, if your program reads from, or writes to, any other + files, those files will need to have the correct permissions + to permit this.

+ + + +

Path information and environment

+ + +

When you run a program from your command line, you have + certain information that is passed to the shell without you + thinking about it. For example, you have a PATH, + which tells the shell where it can look for files that you + reference.

+ +

When a program runs through the web server as a CGI program, + it may not have the same PATH. Any programs that you + invoke in your CGI program (like sendmail, for + example) will need to be specified by a full path, so that the + shell can find them when it attempts to execute your CGI + program.

+ +

A common manifestation of this is the path to the script + interpreter (often perl) indicated in the first + line of your CGI program, which will look something like:

+ + 
#!/usr/bin/perl
+ + +

Make sure that this is in fact the path to the + interpreter.

+
+ When editing CGI scripts on Windows, end-of-line characters may be + appended to the interpreter path. Ensure that files are then + transferred to the server in ASCII mode. Failure to do so may + result in "Command not found" warnings from the OS, due to the + unrecognized end-of-line character being interpreted as a part of + the interpreter filename. +
+ + +

Missing environment variables

+ + +

If your CGI program depends on non-standard environment variables, you will need to + assure that those variables are passed by Apache.

+ +

When you miss HTTP headers from the environment, make + sure they are formatted according to + RFC 2616, + section 4.2: Header names must start with a letter, + followed only by letters, numbers or hyphen. Any header + violating this rule will be dropped silently.

+ + + +

Program errors

+ + +

Most of the time when a CGI program fails, it's because of + a problem with the program itself. This is particularly true + once you get the hang of this CGI stuff, and no longer make + the above two mistakes. The first thing to do is to make + sure that your program runs from the command line before + testing it via the web server. For example, try:

+ +

+ cd /usr/local/apache2/cgi-bin
+ ./first.pl +

+ +

(Do not call the perl interpreter. The shell + and Apache should find the interpreter using the path information on the first line of + the script.)

+ +

The first thing you see written by your program should be + a set of HTTP headers, including the Content-Type, + followed by a blank line. If you see anything else, Apache will + return the Premature end of script headers error if + you try to run it through the server. See Writing a CGI program above for more + details.

+ + +

Error logs

+ + +

The error logs are your friend. Anything that goes wrong + generates message in the error log. You should always look + there first. If the place where you are hosting your web site + does not permit you access to the error log, you should + probably host your site somewhere else. Learn to read the + error logs, and you'll find that almost all of your problems + are quickly identified, and quickly solved.

+ + +

Suexec

+ + +

The suexec support program + allows CGI programs to be run under different user permissions, + depending on which virtual host or user home directory they are + located in. Suexec has very strict permission checking, and any + failure in that checking will result in your CGI programs + failing with Premature end of script headers.

+ +

To check if you are using suexec, run apachectl + -V and check for the location of SUEXEC_BIN. + If Apache finds an suexec binary there on startup, + suexec will be activated.

+ +

Unless you fully understand suexec, you should not be using it. + To disable suexec, simply remove (or rename) the suexec + binary pointed to by SUEXEC_BIN and then restart the + server. If, after reading about suexec, + you still wish to use it, then run suexec -V to find + the location of the suexec log file, and use that log file to + find what policy you are violating.

+ +
top
+
+

What's going on behind the scenes?

+ + +

As you become more advanced in CGI programming, it will + become useful to understand more about what's happening behind + the scenes. Specifically, how the browser and server + communicate with one another. Because although it's all very + well to write a program that prints "Hello, World.", it's not + particularly useful.

+ +

Environment variables

+ + +

Environment variables are values that float around you as + you use your computer. They are useful things like your path + (where the computer searches for the actual file + implementing a command when you type it), your username, your + terminal type, and so on. For a full list of your normal, + every day environment variables, type + env at a command prompt.

+ +

During the CGI transaction, the server and the browser + also set environment variables, so that they can communicate + with one another. These are things like the browser type + (Netscape, IE, Lynx), the server type (Apache, IIS, WebSite), + the name of the CGI program that is being run, and so on.

+ +

These variables are available to the CGI programmer, and + are half of the story of the client-server communication. The + complete list of required variables is at + Common Gateway + Interface RFC.

+ +

This simple Perl CGI program will display all of the + environment variables that are being passed around. Two + similar programs are included in the + cgi-bin + + directory of the Apache distribution. Note that some + variables are required, while others are optional, so you may + see some variables listed that were not in the official list. + In addition, Apache provides many different ways for you to + add your own environment variables + to the basic ones provided by default.

+ + 
#!/usr/bin/perl
+use strict;
+use warnings;
+
+print "Content-type: text/html\n\n";
+foreach my $key (keys %ENV) {
+    print "$key --> $ENV{$key}<br>";
+}
+ + + +

STDIN and STDOUT

+ + +

Other communication between the server and the client + happens over standard input (STDIN) and standard + output (STDOUT). In normal everyday context, + STDIN means the keyboard, or a file that a + program is given to act on, and STDOUT + usually means the console or screen.

+ +

When you POST a web form to a CGI program, + the data in that form is bundled up into a special format + and gets delivered to your CGI program over STDIN. + The program then can process that data as though it was + coming in from the keyboard, or from a file

+ +

The "special format" is very simple. A field name and + its value are joined together with an equals (=) sign, and + pairs of values are joined together with an ampersand + (&). Inconvenient characters like spaces, ampersands, and + equals signs, are converted into their hex equivalent so that + they don't gum up the works. The whole data string might look + something like:

+ +

+ name=Rich%20Bowen&city=Lexington&state=KY&sidekick=Squirrel%20Monkey +

+ +

You'll sometimes also see this type of string appended to + a URL. When that is done, the server puts that string + into the environment variable called + QUERY_STRING. That's called a GET + request. Your HTML form specifies whether a GET + or a POST is used to deliver the data, by setting the + METHOD attribute in the FORM tag.

+ +

Your program is then responsible for splitting that string + up into useful information. Fortunately, there are libraries + and modules available to help you process this data, as well + as handle other of the aspects of your CGI program.

+ +
top
+
+

CGI modules/libraries

+ + +

When you write CGI programs, you should consider using a + code library, or module, to do most of the grunt work for you. + This leads to fewer errors, and faster development.

+ +

If you're writing CGI programs in Perl, modules are + available on CPAN. The most + popular module for this purpose is CGI.pm. You might + also consider CGI::Lite, which implements a minimal + set of functionality, which is all you need in most programs.

+ +

If you're writing CGI programs in C, there are a variety of + options. One of these is the CGIC library, from + https://web.mit.edu/wwwdev/www/cgic.html.

+
top
+
+

For more information

+ + +

The current CGI specification is available in the + Common Gateway + Interface RFC.

+ +

When you post a question about a CGI problem that you're + having, whether to a mailing list, or to a newsgroup, make sure + you provide enough information about what happened, what you + expected to happen, and how what actually happened was + different, what server you're running, what language your CGI + program was in, and, if possible, the offending code. This will + make finding your problem much simpler.

+ +

Note that questions about CGI problems should never + be posted to the Apache bug database unless you are sure you + have found a problem in the Apache source code.

+
+
+

Available Languages:  en  | + es  | + fr  | + ja  | + ko 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/cgi.html.es b/docs/manual/howto/cgi.html.es new file mode 100644 index 0000000..bfaebd7 --- /dev/null +++ b/docs/manual/howto/cgi.html.es @@ -0,0 +1,619 @@ + + + + + +Tutorial de Apache: Contenido Dinámico con CGI - Servidor HTTP Apache Versión 2.4 + + + + + + +
+

Módulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

+

Versión 2.4 del Servidor HTTP Apache

+
+
<-
+

Tutorial de Apache: Contenido Dinámico con CGI

+
+

Idiomas disponibles:  en  | + es  | + fr  | + ja  | + ko 

+
+
Esta traducción podría estar + obsoleta. Consulte la versión en inglés de la + documentación para comprobar si se han producido cambios + recientemente.
+
+ +
top
+
+

Introducción

+ +
Módulos RelacionadosDirectivas Relacionadas
+ +

CGI (Common Gateway Interface) es un método por el cual + un servidor web puede interactuar con programas externos de + generación de contenido, a ellos nos referimos comúnmente como + programas CGI o scripts CGI. Es el método más común y sencillo de + mostrar contenido dinámico en su sitio web. Este documento es una + introducción para configurar CGI en su servidor web Apache, y de + iniciación para escribir programas CGI.

+
top
+
+

Configurando Apache para permitir CGI

+ + +

Para conseguir que sus programas CGI funcionen correctamente, + deberá configurar Apache para que permita la ejecución de CGI. Hay + distintas formas de hacerlo.

+ +
Nota: Si Apache ha sido compilado con soporte + de módulos compartidos, necesitará que el módulo de CGI esté cargado; + en su httpd.conf tiene que asegurarse de que la directiva + LoadModule + no ha sido comentada. Una directiva configurada correctamente sería así: + + 
LoadModule cgid_module modules/mod_cgid.so
+ + + En Windows, o si usa un mpm que no es multihilo, como prefork, una + directiva configurada correctamente podría definirse así: + + 
LoadModule cgi_module modules/mod_cgi.so
+
+ +

ScriptAlias

+ + +

La directiva + ScriptAlias + indica a Apache que un directorio se ha configurado específicamente + para programas CGI. Apache asumirá que cada fichero en este + directorio es un programa CGI, e intentará ejecutarlos cuando un + cliente solicita este recurso.

+ +

La directiva + ScriptAlias se puede + definir así:

+ + 
ScriptAlias "/cgi-bin/" "/usr/local/apache2/cgi-bin/"
+ + +

El ejemplo que se muestra es de un archivo de configuración + httpd.conf por defecto si usted instaló Apache + en la ubicación por defecto. La directiva + ScriptAlias es muy + parecida a la directiva Alias, + ésta define un prefijo de URL que se enlaza a un directorio + en particular. Alias y + ScriptAlias se usan generalmente para + directorios que se encuentran fuera del directorio + DocumentRoot. La diferencia + entre Alias y ScriptAlias + es que en ScriptAlias cualquier elemento + debajo de ese prefijo de URL será considerado un programa CGI. Así, + el ejemplo de más arriba le indica a Apache que + cualquier solicitud para un recurso que comience con + /cgi-bin/ debería servirse desde el directorio + /usr/local/apache2/cgi-bin/, y debería tratarse como un + programa CGI.

+ +

Por ejemplo, si se solicita la URL + http://www.example.com/cgi-bin/test.pl, + Apache intentará ejecutar el archivo + /usr/local/apache2/cgi-bin/test.pl y dar + el resultado. Por supuesto el archivo debe existir y ser ejecutable, + y dar el resultado de una manera específica o Apache devolverá + un mensaje de error.

+ + +

CGI fuera de directorios ScriptAlias

+ + +

Los programas CGI habitualmente se restringen a los directorios de + ScriptAlias por razones de + seguridad. De esta manera, los administradores pueden controlar de una + manera más segura quien puede ejecutar programas CGI. Aun así, si no + se toman suficientes precauciones, no hay ninguna razón por la que + programas CGI no se puedan ejecutar desde directorios seleccionados de + manera arbitraria. Por ejemplo, quizás quiera permitir que usuarios del + sistema tengan contenido web en sus directorios home con la directiva + UserDir. Si quieren + tener sus propios programas CGI, pero no tienen acceso al directorio + principal cgi-bin, necesitarán ser capaces de + ejecutar sus scripts CGI en algún otro sitio.

+ +

Hay dos pasos a seguir para permitir la ejecución CGI en directorios + seleccionados de manera arbitraria. Primero, el handler + cgi-script debe estar activado usando la directiva + AddHandler o la directiva + SetHandler. Segundo, el parámetro + ExecCGI debe estar definido en la directiva + Options.

+ + +

Usando Options de manera explícita para permitir ejecución de + CGI

+ + +

Puede usar la directiva + Options, en el archivo de + configuración principal para especificar que se permite la ejecución + de CGI en un directorio en particular:

+ + 
<Directory "/usr/local/apache2/htdocs/somedir">
+    Options +ExecCGI
+</Directory>
+ + +

Esta directiva de aquí arriba le indica a Apache que debe + permitir la ejecución de archivos CGI. También necesitará indicarle + al servidor que los archivos son archivos CGI. La directiva + AddHandler le indica al + servidor que debe tratar a todos los archivos con la extensión + cgi o pl como programas CGI:

+ + 
AddHandler cgi-script .cgi .pl
+ + + +

Ficheros .htaccess

+ + +

El tutorial .htaccess + enseña como activar programas CGI si no tienes acceso a + httpd.conf.

+ + +

Directorios de Usuario

+ + +

Para permitir la ejecución de programas CGI para cualquier + archivo que acabe en .cgi en directorios de usuario, + puedes usar la siguiente configuración:

+ + 
<Directory "/home/*/public_html">
+    Options +ExecCGI
+    AddHandler cgi-script .cgi
+</Directory>
+ + +

Si quiere designar un subdirectorio cgi-bin dentro + de un directorio de usuario en el que todos los ficheros serán + tratados como un programa CGI, puede usar lo siguiente:

+ + 
<Directory "/home/*/public_html/cgi-bin">
+    Options ExecCGI
+    SetHandler cgi-script
+</Directory>
+ + +
top
+
+

Escribiendo un programa CGI

+ + +

Hay dos diferencias principales entre programación ``regular'' y + programación en CGI.

+ +

Primera, el resultado al completo de tu programa CGI debe estar + precedido de una cabecera MIME-type. Esta + cabecera HTTP le indica al cliente que tipo de contenido está + recibiendo. La mayor parte de las veces, ésto será algo como:

+ +

+ Content-type: text/html +

+ +

Segunda, el resultado debe estar en formato HTML, o cualquier + otro formato que su navegador sea capaz de mostrar. La mayor + parte de las veces, será HTML, pero otras escribirá un programa + CGI que devuelve una imagen gif, u otro contenido no-HTML.

+ +

Aparte de estas dos cosas, escribir un programa en CGI se + parecerá bastante a cualquier otro programa que vaya a escribir. +

+ + +

Su primer programa CGI

+ + +

A continuación podrá ver un ejemplo de programa CGI que muestra + una línea de texto en su navegador. Escriba lo siguiente, + guárdelo en un archivo con el nombre first.pl, y + póngalo en su directorio cgi-bin.

+ + 
#!/usr/bin/perl
+print "Content-type: text/html\n\n";
+print "Hola, Mundo.";
+ + +

Incluso si Perl no le resulta familiar, podrá ver lo que está + ocurriendo aquí. La primera línea le dice a Apache (o a + cualquier shell en la que se esté ejecutando) que este programa + puede ejecutarse con el intérprete en la ubicación + /usr/bin/perl. La segunda línea imprime la + declaración de Content-Type que mencionamos antes, seguida de + dos pares de retornos de carro. Esto pone una línea en blanco + después de la cabecera para indicar el final de las cabeceras + HTTP, y el comienzo del cuerpo del contenido. La tercera + imprime la cadena de caracteres "Hola, Mundo.". Y ese es el + final del programa.

+ +

Si lo abre con su navegador favorito y le dice que solicite la + dirección

+ +

+ http://www.example.com/cgi-bin/first.pl +

+ +

o donde quiera que pusiera el archivo, verá una línea + Hola, Mundo. aparecerán la ventana del navegador. No es + muy emocionante, pero una vez que consiga que funcione podrá hacer + lo mismo con casi cualquier programa.

+ +
top
+
+

¡Pero todavía no funciona!

+ + +

Hay 4 cosas básicas que puede llegar a ver en su navegador cuando + intenta acceder a un programa CGI desde la web:

+ +
+
El resultado del programa CGI
+
¡Genial! Esto indica que todo funcionó correctamente. Si el + resultado es correcto, pero el navegador no lo procesa + correctamente, asegúrese de que tiene especificado + correctamente el Content-Type en su programa + CGI.
+ +
El código fuente de su programa CGI o un mensaje del tipo + "POST Method Not Allowed".
+ +
Eso significa que no ha configurado Apache de manera + apropiada para interpretar su programa CGI. Relea la sección + de Configurando Apache e intente + encontrar qué le falta.
+ +
Un mensaje que empieza con "Forbidden"
+
Eso significa que hay un problema de permisos. Compruebe el + Log de Errores de Apache y la + sección de más abajo de Permisos de + Fichero.
+ +
Un mensaje indicando "Internal Server Error"
+
Si comprueba el Log de errores de + Apache, probablemente encontrará que indica "Premature + end of script headers", posiblemente acompañado de otro + mensaje de error generado por su programa CGI. En este caso, + querrá comprobar cada una de las secciones de más adelante + para ver qué impide que su programa CGI genere las cabeceras + HTTP adecuadas.
+
+ +

Permisos de Fichero

+ + +

Recuerde que el servidor no se ejecuta con su usuario. Es decir, + cuando el servidor arranca, está funcionando con un usuario sin + privilegios, generalmente el usuario nobody, o + www-data, así que necesitará permisos extra para + ejecutar los archivos de los que usted es dueño. Generalmente, + el método para dar permisos suficientes para que se pueda + ejecutar con nobody es dar permisos de ejecución a + todo el mundo en el fichero:

+ +

+ chmod a+x first.pl +

+ +

Además, si su programa lee desde o escribe a cualquier otro/s + archivo/s, esos archivos necesitarán tener los permisos correctos + para permitir esas acciones.

+ + + +

Información de Ruta y Entorno

+ + +

Cuando ejecuta un programa desde la línea de comandos, usted tiene + cierta información que se le pasa a la shell sin que usted se + percate de ello. Por ejemplo, usted tiene un PATH, + que le indica a la shell dónde debe buscar archivos a los que usted + hace referencia.

+ +

Cuando un programa se ejecuta a través del servidor web como un + programa CGI, puede que no tenga el mismo PATH. + Cualquier programa que invoque desde su programa CGI (como por + ejemplo sendmail) necesitará que se le indique la + ruta absoluta, así la shell puede encontrarlos cuando intenta + ejecutar su programa CGI.

+ +

Una manifestación común de esto es la ruta del intérprete del + script (a menudo perl) indicado en la primera línea + de su programa CGI, que parecerá algo como:

+ + 
#!/usr/bin/perl
+ + +

Asegúrese de que éste es de hecho el path de su intérprete.

+
+ Cuando edita scripts CGI en Windows, los caracteres de retorno de + carro podrían añadirse a la línea donde se especifica el intérprete. + Asegúrese de que los archivos se transfieren al servidor en modo + ASCII. Fallar en esto puede acabar con avisos del tipo "Command not + found" del Sistema Operativo, debido a que éste no reconoce los + caracteres de final de línea interpretados como parte del nombre + de fichero del intérprete. +
+ + +

Faltan Variables de Entorno

+ + +

Si su programa CGI depende de variables de entorno no estándar, necesitará + asegurarse de que Apache pasa esas variables.

+ +

Cuando no encuentra ciertas cabeceras HTTP del entorno, asegúrese + de que están formateadas según el + RFC 2616, + sección 4.2: Nombres de Cabeceras deben empezar con una letra, + seguida solo de letras, números o guión. Cualquier cabecera + que no cumpla esta regla será ignorada de manera silenciosa.

+ + + +

Errores de Programa

+ + +

La mayor parte de las veces cuando un programa CGI falla, es por un + problema en el programa mismo. Esto ocurre generalmente cuando se + maneja bien con "esto del CGI", y ya no comete los dos errores + mencionados más arriba. Lo primero que hay que hacer es asegurarse + de que su programa se ejecuta correctamente en línea de comandos + antes de probarlo a través del servidor web. Por ejemplo, + intente:

+ +

+ cd /usr/local/apache2/cgi-bin
+ ./first.pl +

+ +

(No llame al intérprete de perl. La consola y Apache + tienen que poder encontrar el intérprete usando línea + línea de información en la primera + línea del script.)

+ +

Lo primero que debe ver escrito por su programa es un conjunto de + cabeceras HTTP, incluyendo el Content-Type, + seguido de una línea en blanco. Si ve alguna otra cosa, Apache + devolverá el error Premature end of script headers si + intenta lanzar el script en el servidor web. Vea + Escribiendo un programa CGI más arriba para + más detalle.

+ + +

Log de Errores

+ + +

El log de errores es su amigo. Cualquier cosa que vaya mal generará + un mensaje en el log de errores. Debería mirar siempre ahí primero. + Si el lugar donde está alojando su sitio web no permite que acceda + al log de errores, probablemente debería alojarlo en otro sitio. + Aprenda a leer el log de errores y se dará cuenta de que enseguida + averiguará el motivo del error y lo solucionará rápidamente.

+ + +

Suexec

+ + +

El programa de soporte suexec permite + que programas CGI se ejecuten con permisos de usuario distintos, + dependiendo del virtualhost o el directorio home donde se + encuentren. Suexec tiene una comprobación de permisos muy estricta, + y cualquier fallo en esa comprobación dará como resultado un error + con el mensaje Premature end of script headers.

+ +

Para comprobar si está usando Suexec, ejecute + apachectl -V y compruebe la ubicación de + SUEXEC_BIN. Si Apache encuentra un binario + suexec al arrancar, suexec se activará.

+ +

A menos que comprenda suxec perfectamente, no debería usarlo. + Para desactivar suexec, basta con eliminar el binario + suexec al que apunta SUEXEC_BIN y + reiniciar el servidor. Si después de leer sobre + suexec todavía quiere usarlo, entonces + ejecute suexec -V para encontrar la ubicación del + fichero log de suexec, y use ese log para encontrar que política no + está cumpliendo.

+ +
top
+
+

¿Qué ocurre entre bastidores?

+ + +

En cuanto tenga conocimiento avanzado de programación CGI, le será + útil comprender más de lo que ocurre entre bastidores. + Específicamente, cómo el navegador y el servidor se comunican el uno + con el otro. Porque aunque esté muy bien escribir un programa que + diga "Hola, Mundo.", no tiene una gran utilidad.

+ +

Variables de Entorno

+ + +

Las variables de entorno son valores que están ahí cuando + usa el ordenador. Son cosas útiles como el path (donde su ordenador + busca el archivo específico que se lanza cuando usted escribe un + comando), su nombre de usuario, el tipo de terminal que usa, etc. + Para una lista completa de la variables de entorno normales que se + se usan en su día a día escriba env en la línea de + comandos.

+ +

Durante la transacción CGI, el servidor y el navegador también + configuran variables de entorno, y así pueden comunicarse entre + ellos. Cosas como el tipo de navegador (Netscape, IE, Lynx), el tipo + de servidor (Apache, IIS, WebSite), el nombre del programa CGI que + se está ejecutando, etc.

+ +

Estas variables están disponibles para el programador de CGI, y son + la mitad de la historia de la comunicación cliente-servidor. La + lista completa de las variables necesarias se encuentra en + el RFC de Common Gateway + Interface.

+ +

Este sencillo programa CGI en Perl mostrará todas las variables + de entorno que se están pasando entre el cliente y el navegador. Dos + programas similares están incluidos en el directorio + cgi-bin de la distribución de Apache. Tenga en cuenta + que algunas variables son necesarias mientras que otras son + opcionales, así que es posible que vea algunas variables que no + están en la lista oficial. Adicionalmente, Apache aporta distintas + maneras diferentes para que pueda + añadir sus variables de entorno a las + básicas que se proveen por defecto.

+ + 
#!/usr/bin/perl
+use strict;
+use warnings;
+
+print "Content-type: text/html\n\n";
+          
+foreach my $key (keys %ENV) {
+    print "$key --> $ENV{$key}<br>";
+}
+ + + +

STDIN y STDOUT

+ + +

Otra comunicación entre el servidor y el cliente ocurre en la + entrada estándar (STDIN) y la salida estándar + (STDOUT). En el contexto normal de cada día, + STDIN es la entrada con el teclado, o un fichero que se + le da a un programa para que actúe sobre él, y STDOUT + generalmente es la consola o la pantalla.

+ +

Cuando hace POST con un formulario de web a un programa + CGI, los datos en ese formulario se empaquetan en un formato especial + que se entrega a su programa CGI en el STDIN. + Entonces el programa puede procesar la información como si le llegara + desde el teclado, o desde un fichero.

+ +

El "formato especial" es muy sencillo. Un nombre de campo y su + valor se asocian juntos con el signo igual (=), y pares de valores + se asocian juntos con el ampersand ó et en español (&). + Caracteres inconvenientes como los espacios, ampersands y signos de + igual, se convierten en su equivalente hexadecimal para no impidan + el funcionamiento correcto del programa. La cadena de datos al + completo será algo como:

+ +

+ name=Rich%20Bowen&city=Lexington&state=KY&sidekick=Squirrel%20Monkey +

+ +

A veces tendrá este tipo de cadena de caracteres al final de una + URL. Cuando esto ocurre, el servidor pone esa cadena en una variable + de entorno que se llama QUERY_STRING. Esto se llama + solicitud GET. Su formulario HTML especifica si se usa + un GET o un POST para entregar la + información, configurando el atributo METHOD en la + etiqueta FORM.

+ +

Su programa es el responsable de convertir esa cadena de + caracteres en información útil. Afortunadamente, hay librerías y + módulos disponibles que ayudan a procesar la información, así como a + gestionar los distintos aspectos de su programa CGI.

+ +
top
+
+

Módulos/librerías CGI

+ + +

Cuando escribe programas CGI, debería considerar usar una librería de + código, o módulo, para hacer todo el trabajo más arduo por usted. + Esto lleva a tener menos errores y un desarrollo de código más + rápido.

+ +

Si está escribiendo un programa CGI en Perl, existen módulos + disponibles en CPAN. El módulo más + conocido para este propósito es CGI.pm. Quizás quiera + considerar CGI::Lite, que implementa una funcionalidad + mínima, que es todo lo que se necesita en la mayoría de los programas.

+ +

Si está escribiendo programas CGI en C, hay varidad de opciones. Una + de estas es la librería CGIC, de + http://www.boutell.com/cgic/. +

+
top
+
+

Para más información

+ + +

La especificación actual de CGI está disponible en el + RFC de Common Gateway + Interface.

+ +

Cuando envíe una pregunta sobre un problema de CGI, o bien a una + lista de correo, o a un grupo de noticias, asegúrese de que facilita suficiente + información de lo que ha ocurrido, de lo que espera que ocurra, y de + lo que está ocurriendo en su lugar que es diferente, el servidor que + está ejecutando, en qué lenguaje CGI está hecho su programa, y si es + posible, el código que falla. Esto hará encontrar el problema mucho más + fácil.

+ +

Tenga en cuenta que las preguntas sobre problemas CGI + nunca deberían enviarse a la base de datos de bugs de + bugs de Apache a menos que esté seguro de haber encontrado un + problema en el código fuente de Apache.

+
+
+

Idiomas disponibles:  en  | + es  | + fr  | + ja  | + ko 

+
top

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/cgi.html.fr.utf8 b/docs/manual/howto/cgi.html.fr.utf8 new file mode 100644 index 0000000..8ce0d77 --- /dev/null +++ b/docs/manual/howto/cgi.html.fr.utf8 @@ -0,0 +1,643 @@ + + + + + +Tutoriel Apache : Contenu dynamique basé sur CGI - Serveur HTTP Apache Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.4

+
+
<-
+

Tutoriel Apache : Contenu dynamique basé sur CGI

+
+

Langues Disponibles:  en  | + es  | + fr  | + ja  | + ko 

+
+
+ +
top
+
+

Introduction

+ + +
Modules ApparentésDirectives Apparentées
+ +

CGI (Common Gateway Interface) définit une méthode d'interaction + entre un serveur web et des programmes générateurs de contenu + externes, plus souvent appelés programmes CGI ou scripts CGI. + Il s'agit d'une méthode simple pour ajouter du contenu dynamique à votre site + web en utilisant votre langage de programmation préféré. + Ce document est une introduction à la configuration de CGI sur votre + serveur web Apache, et une initiation à l'écriture de programmes + CGI.

+
top
+
+

Configurer Apache pour autoriser CGI

+ + +

Apache doit être configuré pour permettre l'exécution des + programmes CGI, pour que vos programmes CGI puissent fonctionner + correctement. Il existe plusieurs méthodes pour y parvenir.

+ +
Note: si Apache a été compilé avec le support + des modules partagés (DSO), vous devez vous assurer que le module CGI est + chargé ; vous devez pour cela vérifier que la directive LoadModule correspondante n'a pas été + commentée dans votre httpd.conf. Une directive correcte + doit ressembler à ceci : + + 
LoadModule cgid_module modules/mod_cgid.so
+ + + + Sous Windows, ou si l'on utilise un module MPM non-threadé comme prefork, + une directive correctement configurée sera du style : + + 
LoadModule cgi_module modules/mod_cgi.so
+
+ + +

ScriptAlias

+ + +

La directive ScriptAlias indique à Apache qu'un + répertoire particulier est dédié aux programmes CGI. Apache + considérera que tout fichier situé dans ce répertoire est un + programme CGI, et tentera de l'exécuter lorsque cette ressource + fera l'objet d'une requête client.

+ +

La directive ScriptAlias se présente comme suit + :

+ + 
ScriptAlias "/cgi-bin/" "/usr/local/apache2/cgi-bin/"
+ + +

Cet exemple est tiré de votre fichier de configuration + httpd.conf par défaut, si vous avez installé Apache + dans son répertoire par défaut. La directive ScriptAlias est similaire à la + directive Alias, qui + définit à quel répertoire particulier doit correspondre un préfixe + d'URL. Alias et + ScriptAlias sont généralement utilisés pour + accéder à des répertoires situés en dehors du répertoire défini + par la directive DocumentRoot. La différence entre + Alias et ScriptAlias + réside dans le fait que ScriptAlias indique + en plus que tout ce qui se trouve sous le préfixe d'URL doit être + considéré comme un programme CGI. Ainsi, l'exemple ci-dessus + indique à Apache que toute requête pour une ressource commençant + par /cgi-bin/ doit être servie depuis le répertoire + /usr/local/apache2/cgi-bin/, et doit être traitée en + tant que programme CGI.

+ +

Par exemple, si une requête pour l'URL + http://www.example.com/cgi-bin/test.pl est + effectuée, Apache tentera d'exécuter le fichier + /usr/local/apache2/cgi-bin/test.pl et en renverra la + sortie. Bien entendu, le fichier doit exister, être exécutable, et + retourner sa sortie d'une manière particulière, sinon Apache + renverra un message d'erreur.

+ + +

CGI en dehors des répertoires ScripAlias

+ + +

Pour des raisons de sécurité, la localisation des programmes + CGI est souvent restreinte aux + répertoires définis par ScriptAlias. De cette manière, les administrateurs + peuvent contrôler précisément qui est autorisé à utiliser les + programmes CGI. Cependant, si les précautions adéquates quant à + la sécurité sont prises, il n'y a aucune raison pour que les + programmes CGI ne puissent pas être exécutés depuis d'autres + répertoires. Par exemple, vous pouvez autoriser les utilisateurs à + enregistrer des contenus web dans leurs répertoires home à l'aide + de la directive UserDir. S'ils veulent mettre en + oeuvre leurs propres programmes CGI, mais n'ont pas l'autorisation + d'accès au répertoire cgi-bin principal, ils devront + être en mesure d'exécuter ces programmes depuis un autre + répertoire.

+ +

L'autorisation d'exécution des programmes CGI dans un + répertoire arbitraire se fait en deux étapes. En premier lieu, le + gestionnaire cgi-script doit être activé à l'aide + d'une directive AddHandler ou SetHandler. En second lieu, + ExecCGI doit être spécifié dans la directive Options.

+ + +

Utilisation d'options explicites pour permettre l'exécution + des programmes CGI

+ + +

Vous pouvez utiliser de manière explicite la directive + Options dans le fichier de + configuration de votre serveur principal, pour indiquer que + l'exécution des programmes CGI est permise depuis un répertoire + particulier :

+ + 
<Directory "/usr/local/apache2/htdocs/somedir">
+    Options +ExecCGI
+</Directory>
+ + +

La directive ci-dessus indique à Apache qu'il doit permettre + l'exécution des fichiers CGI. Vous devez aussi indiquer au serveur + quels fichiers sont des fichiers CGI. La directive AddHandler suivante indique au + serveur qu'il doit traiter tous les fichiers possédant une + extension cgi ou pl en tant que + programmes CGI :

+ + 
AddHandler cgi-script .cgi .pl
+ + + +

Fichiers .htaccess

+ + +

Le tutoriel + .htaccess montre comment activer les programmes + CGI si vous n'avez pas accès au + fichier httpd.conf.

+ + +

Répertoires utilisateurs

+ + +

Pour permettre l'exécution en tant que programme CGI de tout + fichier possédant l'extension .cgi et situé dans un + répertoire utilisateur, vous pouvez utiliser la configuration + suivante :

+ + 
<Directory "/home/*/public_html">
+    Options +ExecCGI
+    AddHandler cgi-script .cgi
+</Directory>
+ + +

Pour indiquer un sous-répertoire cgi-bin d'un + répertoire utilisateur où tout fichier sera traité en tant que + programme CGI, vous pouvez utiliser ceci :

+ + 
<Directory "/home/*/public_html/cgi-bin">
+    Options ExecCGI
+    SetHandler cgi-script
+</Directory>
+ + + + +
top
+
+

Ecrire un programme CGI

+ + +

Il y a deux différences principales entre la programmation + "standard" et la programmation CGI.

+ +

En premier lieu, toute sortie de votre programme CGI doit être + précédée d'un en-tête MIME-type. Il s'agit d'un + en-tête HTTP qui indique au client quel type de contenu il reçoit. + La plupart du temps, il se présente comme suit :

+ +

+ Content-type: text/html +

+ +

En second lieu, votre sortie doit être en HTML, ou tout autre + format qu'un navigateur est en mesure d'afficher. La plupart du + temps, il s'agira de HTML, mais occasionnellement, vous pouvez être + amené à écrire un programme CGI qui renvoie une image gif, ou un + autre type de contenu non-HTML.

+ +

A part ces deux différences, un programme CGI ressemblera à tout + autre programme que vous pourriez être amené à écrire.

+ +

Votre premier programme CGI

+ + +

L'exemple suivant est un exemple de programme CGI qui permet + d'afficher une ligne de caractères dans votre navigateur. Ecrivez + ce qui suit, enregistrez le dans un fichier nommé + premier.pl, et placez le dans votre répertoire + cgi-bin.

+ + 
#!/usr/bin/perl
+print "Content-type: text/html\n\n";
+print "Hello, World.";
+ + +

Même si Perl ne vous est pas familier, vous devriez être + capable de comprendre le fonctionnement de ce programme. La + première ligne indique à Apache (ou à toute interface à partir de + laquelle le programme s'exécute) que ce programme peut être + exécuté en fournissant son fichier à l'interpréteur + /usr/bin/perl. La seconde ligne affiche la + déclaration du type de contenu considéré, suivie de deux paires + "Retour chariot - Nouvelle ligne". Ceci a pour effet d'insérer une + ligne vide après l'en-tête pour marquer la fin des en-têtes HTTP, + et le début du corps du document. La troisième ligne affiche la + chaîne de caractères "Bonjour tout le monde . . .". Et c'est tout + ce dont vous avez besoin.

+ +

Si vous ouvrez votre navigateur favori et lui indiquez + l'adresse

+ +

+ http://www.example.com/cgi-bin/premier.pl +

+ +

ou toute autre URL correspondant à votre programme CGI, Vous + verrez la ligne Bonjour tout le monde . . . + s'afficher dans la fenêtre de votre navigateur. Ce n'est pas + extraordinaire, mais si vous y êtes parvenu, vous avez de bonnes + chances d'y parvenir pour tout autre programme plus + sophistiqué.

+ +
top
+
+

Mais ça ne marche toujours pas !

+ + +

Vous devriez voir au moins une des quatre sorties suivantes dans + votre navigateur lorsque vous essayez d'accéder à votre programme + CGI depuis le web :

+ +
+
Le flux de sortie de votre programme CGI
+
Impeccable ! Cela signifie que tout fonctionne correctement. + Si la sortie est correcte mais n'est pas traitée correctement par + le navigateur, assurez-vous d'avoir défini + Content-Type de manière appropriée dans votre + programme CGI.
+ +
Le code source de votre programme CGI ou un message "POST + Method Not Allowed"
+
Cela signifie que vous n'avez pas configuré Apache de manière + à ce qu'il puisse traiter votre programme CGI. Relisez la section + sur la configuration d'Apache, et + essayez de trouver votre erreur.
+ +
Un message commençant par "Forbidden"
+
Ce type de message est révélateur d'un problème de + droits. Consultez le journal des erreurs + d'Apache et la section ci-dessous sur les droits des fichiers.
+ +
Un message contenant "Internal Server Error"
+
Si vous consultez le journal des erreurs + d'Apache, vous y trouverez probablement des messages du type + "Premature end of script headers" (Fin prématurée des en-têtes de + script), éventuellement accompagnés d'un message d'erreur généré + par votre programme CGI. Dans ce cas, il va vous falloir lire + chacune des sections ci-dessous pour déterminer ce qui empêche + votre programme CGI de générer les en-têtes appropriés.
+
+ +

Droits des fichiers

+ + +

Souvenez-vous que le serveur ne s'exécute pas sous votre nom. + En d'autres termes, lorsque le serveur a démarré, il s'exécute + avec les droits d'un utilisateur non privilégié - en général + nobody, ou www - et en conséquence, il + aura besoin de droits supplémentaires pour pouvoir exécuter des + fichiers dont vous êtes le propriétaire. En général, pour qu'un + fichier ait des droits suffisants pour être exécutable par + nobody, il suffit de lui attribuer des droits + d'exécution pour tout le monde :

+ +

+ chmod a+x premier.pl +

+ +

En outre, si votre programme doit pouvoir accéder en lecture + et/ou écriture à d'autres fichiers, ces derniers devront avoir les + droits appropriés.

+ + + +

Chemin des exécutables (PATH) et variables + d'environnement

+ + +

Lorsque vous lancez un programme depuis la ligne de commande, + certaines informations sont passées au shell sans que vous vous en + doutiez. Par exemple, la variable PATH indique au + shell où il doit rechercher les exécutables auxquels vous faites + référence.

+ +

Lorsqu'un programme s'exécute depuis le serveur web en tant que + programme CGI, sa variable PATH n'aura peut-être pas + la même valeur. Tout programme que vous invoquez dans votre + programme CGI ( comme par exemple sendmail) devra + être spécifié par son chemin complet, de façon à ce que le shell + puisse le trouver lorsqu'il tentera d'exécuter votre programme + CGI.

+ +

Un exemple typique de spécification de programme est le chemin + vers l'interpréteur de script (souvent perl) que l'on + trouve à la première ligne de votre programme CGI et qui va + ressembler à ceci :

+ + 
#!/usr/bin/perl
+ + +

Assurez-vous qu'il s'agit bien du chemin correct vers + l'interpréteur.

+ +
+ Lors de l'édition de scripts CGI sous Windows, il se peut que des + caractères de fin de ligne soient ajoutés au chemin de + l'interpréteur. Assurez-vous donc que les fichiers sont bien + transmis au serveur en mode ASCII. Dans le cas contraire, l'OS + pourra envoyer des avertissements "Command not found" à cause des + caractères de fin de ligne non reconnus car considérés comme + faisant partie du nom de fichier de l'interpréteur. +
+ + + +

Variables d'environnement manquantes

+ + +

Si votre programme CGI dépend de variables + d'environnement non standards, vous devrez vous assurez que + ces variables lui sont bien transmises par Apache.

+ +

Lorsque des en-têtes HTTP ne sont pas transmis à + l'environnement, assurez-vous qu'ils sont bien formatés selon la + RFC 2616, section + 4.2 : les noms d'en-têtes doivent commencer par une lettre, + elle-même suivie de lettres, chiffres ou traits d'union. Tout + en-tête dont le nom viole cette règle sera ignoré.

+ + + +

Erreurs inhérentes au programme

+ + +

La plupart des échecs dans l'exécution d'un programme CGI + proviennent du programme lui-même. Ceci est particulièrement vrai + lorsque ce satané programme CGI se bloque, alors que vous avez + appris à ne plus commettre les deux erreurs précédentes. La + première chose à faire est de vous assurer que votre programme + s'exécute depuis la ligne de commande, avant de le tester à partir + du serveur web. Par exemple, essayez :

+ +

+ cd /usr/local/apache2/cgi-bin
+ ./premier.pl +

+ +

(N'invoquez pas l'interpréteur perl. Le shell et + Apache doivent être capable de le déterminer à partir de l'information sur le chemin située sur + la première ligne du script.)

+ +

La première chose que vous devriez voir affichée par votre + programme est un ensemble d'en-têtes HTTP, comprenant entre autres + le Content-Type, et suivi d'une ligne vide. Si vous + voyez quoi que ce soit d'autre, Apache renverra l'erreur + Premature end of script headers si vous tentez + d'exécuter le programme depuis le serveur. Voir Ecriture d'un programme CGI ci-dessus pour + plus de détails.

+ + +

Journalisation des erreurs

+ + +

Les journaux d'erreurs sont vos amis. Toute anomalie de + fonctionnement est consignée dans le journal des erreurs et c'est + ici que vous devez regarder en premier en cas de problème. Si + l'hébergeur de votre site ne vous donne pas accès au journal des + erreurs, vous avez tout intérêt à vous tourner vers quelqu'un + d'autre. Apprenez à déchiffrer les journaux d'erreurs, et vous + vous apercevrez que la plupart des problèmes seront rapidement + identifiés . . . et résolus.

+ + +

Suexec

+ + +

Le programme suexec permet + d'exécuter les programmes CGI avec des droits différents selon le + serveur virtuel ou le répertoire utilisateur dans lequel ils + se situent. Suexec effectue une vérification des droits très + stricte, et toute anomalie détectée au cours de cette vérification + entraînera un echec d'exécution de votre programme CGI avec + affichage de l'erreur Premature end of script + headers.

+ +

Pour savoir si vous pouvez utiliser suexec, tapez la commande + apachectl -V, et regardez le chemin indiqué par + SUEXEC_BIN. Si au démarrage d'Apache, ce dernier + trouve un exécutable suexec dans ce chemin, + suexec sera activé.

+ +

Si vous ne maîtrisez pas le fonctionnement de suexec, il vous + est déconseillé de l'utiliser. Pour désactiver suexec, supprimer + simplement (ou renommez) l'exécutable suexec + pointé par SUEXEC_BIN et redémarrez le serveur. Si + après une lecture de suexec, vous + décidez quand-même de l'utiliser, tapez la commande suexec + -V pour voir où se situe le journal de suexec, et utilisez + ce dernier pour déterminer quelles règles vous violez + éventuellement.

+ +
top
+
+

Que se passe-t-il en coulisse

+ + +

Lorsque vos compétences en programmation CGI seront plus + poussées, il s'avérera intéressant pour vous de mieux comprendre ce + qui se passe en coulisse, et en particulier la manière dont le + navigateur et le serveur dialoguent entre eux. En effet, bien qu'il + soit tout à fait louable d'écrire un programme qui affiche "Bonjour + tout le monde . . .", cela ne sert pas à grand chose.

+ +

Variables d'environnement

+ + +

Les variables d'environnement sont des valeurs qui gravitent + autour de vous lorsque vous utilisez votre ordinateur. Elles sont + très utiles, à l'instar de votre chemin par défaut (où votre + ordinateur va rechercher le fichier physique correspondant à la + commande que vous avez tapée), votre nom d'utilisateur, le type de + votre terminal, etc... Pour obtenir une liste complète des + variables d'environnement standards que vous utilisez tous les + jours, tapez env dans votre interpréteur + de commandes.

+ +

Au cours de la transaction CGI, le serveur et le navigateur + définissent aussi des variables d'environnement, de façon à ce + qu'ils puissent communiquer entre eux. Ces variables définissent + entre autre le type de navigateur (Netscape, IE, Lynx), le type de + serveur (Apache, IIS, WebSite), le nom du programme CGI en cours + d'exécution, etc...

+ +

Ces variables sont à la disposition du programmeur CGI, et + elles constituent 50% de la communication client-serveur. La liste + complète des variables requises se trouve à + Common Gateway + Interface RFC.

+ +

Ce programme CGI basique en Perl permet d'afficher toutes les + variables d'environnement qui sont échangées. Deux programmes + similaires sont fournis avec la distribution d'Apache et situés + dans le répertoire cgi-bin. + Notez que certaines variables sont + obligatoires, alors que d'autres sont optionnelles, si bien que + vous verrez s'afficher certaines variables qui ne font pas partie + de la liste officielle. De plus, Apache vous propose de nombreuses + méthodes pour ajouter vos propres + variables d'environnement aux variables de base fournies par + défaut.

+ + 
#!/usr/bin/perl
+use strict;
+use warnings;
+
+print "Content-type: text/html\n\n";
+foreach my $key (keys %ENV) {
+    print "$key --> $ENV{$key}<br>";
+}
+ + + +

STDIN et STDOUT

+ + +

L'entrée standard (STDIN) et la sortie standard + (STDOUT) constituent d'autres voies de communication + entre le client et le serveur. Dans un contexte normal, + STDIN correspond au clavier, ou à un fichier fourni + au programme à des fins de traitement, et STDOUT à la + console ou à l'écran.

+ +

Lorsque vous transmettez un formulaire web à un programme CGI + par la méthode POST, les données de ce formulaire + sont transcrites dans un format spécial et transmises à votre + programme CGI via STDIN. Le programme peut alors les + traiter comme si elles provenaient du clavier ou d'un + fichier.

+ +

Ce "format spécial" est très simple. Un nom de champ et sa + valeur sont reliés entre eux par un signe "égal" (=), et chacune + de ces paires nom champ/valeur est séparée de la suivante par un + "et" commercial (&). Les caractères + spéciaux comme les espaces, les "et" commerciaux, et les signes + "égal" sont convertis en leur équivalent hexadécimal pour éviter + qu'ils ne gâchent le travail. La chaîne contenant les données doit + ressembler à ceci :

+ +

+ name=Rich%20Bowen&city=Lexington&state=KY&sidekick=Squirrel%20Monkey +

+ +

Vous verrez aussi parfois une chaîne de ce type accolée à une + URL. Dans ce cas, le serveur enregistre cette chaîne dans la + variable d'environnement appelée QUERY_STRING. On a + alors affaire à une requête de type GET. Votre + formulaire HTML indique laquelle des méthodes GET ou + POST est utilisée pour transmettre les données, en + définissant l'attribut METHOD au niveau de la balise + FORM.

+ +

Votre programme est ensuite chargé d'extraire les informations + utiles de cette chaîne. Heureusement, des bibliothèques et des + modules sont à votre disposition pour vous aider à traiter ces + données, et à gérer les différents aspects de votre programme + CGI.

+ +
top
+
+

Bibliothèques et modules CGI

+ + +

Pour écrire un programme CGI, il vous est conseillé d'utiliser + une bibliothèque de code, ou un module, qui effectueront une grande + partie du travail de base pour vous. Ceci vous permettra de diminuer + le nombre d'erreurs et d'accélérer le développement.

+ +

Si vous écrivez des programmes CGI en Perl, des modules sont à + votre disposition à CPAN. A ce + sujet, le module le plus populaire est CGI.pm. Vous + pouvez aussi essayer CGI::Lite, qui implémente les + fonctionnalités strictement nécessaires, mais suffisantes pour + la majorité des programmes.

+ +

Si vous écrivez des programmes CGI en C, vous disposez de nombreuses + options. L'une d'elles est la bibliothèque CGIC de https://web.mit.edu/wwwdev/www/cgic.html.

+
top
+
+

Pour plus d'informations

+ + +

La spécification CGI actuelle est disponible dans la Common Gateway + Interface RFC.

+ +

Lorsque vous postez une question à propos d'un problème CGI que + vous rencontrez, que ce soit dans une liste de diffusion ou dans un + newsgroup, faites en sorte de fournir suffisamment d'informations + sur le problème rencontré, ce que vous attendiez exactement, et en + quoi ce qui se produit est réellement différent de ce que vous + attendiez, quel serveur vous utilisez, en quel langage votre + programme CGI a été écrit, et, si possible, son code source. Ceci + permettra une résolution plus aisée de votre problème.

+ +

Notez que les questions à propos de problèmes CGI ne doivent + jamais être postées dans la base de données de + bogues d'Apache, à moins que vous ne soyez sûr d'avoir trouvé un + problème dans le code source d'Apache.

+
+
+

Langues Disponibles:  en  | + es  | + fr  | + ja  | + ko 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/cgi.html.ja.utf8 b/docs/manual/howto/cgi.html.ja.utf8 new file mode 100644 index 0000000..476ac83 --- /dev/null +++ b/docs/manual/howto/cgi.html.ja.utf8 @@ -0,0 +1,593 @@ + + + + + +Apache Tutorial: CGI による動的コンテンツ - Apache HTTP サーバ バージョン 2.4 + + + + + + +
+

モジュール | ディレクティブ | FAQ | 用語 | サイトマップ

+

Apache HTTP サーバ バージョン 2.4

+
+
<-
+

Apache Tutorial: CGI による動的コンテンツ

+
+

翻訳済み言語:  en  | + es  | + fr  | + ja  | + ko 

+
+
この日本語訳はすでに古くなっている + 可能性があります。 + 最近更新された内容を見るには英語版をご覧下さい。 +
+
+ +
top
+
+

はじめに

+ + +
関連モジュール関連ディレクティブ
+ +

CGI (Common Gateway Interface) は、ウェブサーバが + コンテンツ生成をする外部プログラムと協調して動作するための方法を + 定義しています。そのプログラムはしばしば CGI プログラムや + CGI スクリプトと呼ばれます。CGI は、ウェブサイトに動的な + コンテンツを置くための最も簡単で一般的な方法です。このドキュメントは、 + Apache ウェブサーバで CGI を設定し、 + CGI プログラムを書き始めるための入門書となるでしょう。

+
top
+
+

CGI を許可するように Apache を設定する

+ + +

CGI プログラムを正しく動作させるには、CGI を許可するように + Apache の設定を行う必要があります。 + これを行なうための方法がいくつかあります。

+ +
+ 注: Apache が共有モジュール機能着きでビルドされている場合、 + モジュールがロードされていることを確認してください。 + つまり httpd.conf で + LoadModule + がコメントアウトされていないことを確認してください。 + 正常に設定されていれば次のようになるはずです: + +

+ LoadModule cgi_module modules/mod_cgi.so +

+ +

ScriptAlias

+ + +

ScriptAlias + ディレクティブを使用して、 + CGI プログラム用の特別な別ディレクトリを Apache に設定します。 + Apache は、このディレクトリ中の全てのファイルを CGI + プログラムであると仮定します。 + そして、この特別なリソースがクライアントから要求されると、 + そのプログラムの実行を試みます。

+ +

ScriptAlias + ディレクティブは以下のように使用します:

+ +

+ ScriptAlias /cgi-bin/ /usr/local/apache2/cgi-bin/ +

+ +

デフォルト位置に Apache をインストールしたならば、 + この例はデフォルト状態の httpd.conf + 設定ファイルに含まれています。 + ScriptAlias + ディレクティブは、URL の前に付加するディレクトリを定義する + Alias + ディレクティブとかなり似ています。 + Alias と ScriptAlias + は通常、DocumentRoot + ディレクトリ外のディレクトリのために使用されます。 + Alias と ScriptAlias + との差は、ScriptAlias が接頭辞で始まるすべての + URL は CGI プログラムとみなされるという追加の意味を含んでいることです。 + 従って、上記の例では、/cgi-bin/ + で始まるリソースへのあらゆるリクエストに対して、ディレクトリ + /usr/local/apache2/cgi-bin/ から提供し、それらを + CGI プログラムとして扱うよう Apache に示します。

+ +

例えば、URL http://www.example.com/cgi-bin/test.pl + が要求された場合、Apache は ファイル + /usr/local/apache2/cgi-bin/test.pl + を実行し、その出力を返すことを試みます。 + もちろん、ファイルが存在し、実行可能であり、決められた方法で出力を返します。 + そうでなければ、Apache はエラーメッセージを返します。

+ + +

ScriptAlias ディレクトリ外の CGI

+ + +

CGI プログラムは、セキュリティ上の理由から + ScriptAlias + されたディレクトリに制限されることがしばしばあります。この方法により、 + CGI プログラムを使用できるユーザを管理者が厳しく制御することができます。 + しかしながら、適切なセキュリティ事前対策がとられるならば、CGI + プログラムを任意のディレクトリで実行できないようにする理由はありません。 + 例えば、ユーザに UserDir + ディレクティブで彼らのホームディレクトリ配下にウェブコンテンツを持たせたいとします。 + もし、彼らが CGI プログラムを持つことを望んでいても、メインの + cgi-bin ディレクトリへのアクセスができない場合、 + CGI プログラムを実行することができる他の場所が必要になります。

+ +

任意のディレクトリで CGI の実行を許可するには二段階の設定が必要です。 + まず、AddHandler や SetHandler ディレクティブによって + cgi-script ハンドラが可能になっている必要があります。 + 次に、Options ディレクティブで + ExecCGI が指定されていなければなりません。

+ + +

CGI の実行を可能にするために Options を明示的に使用する

+ + +

サーバのメインの設定ファイル中で Options + ディレクティブを明示的に使用することで、特定のディレクトリ配下で + CGI の実行を許可するように指定することができます:

+ +

+ <Directory /usr/local/apache2/htdocs/somedir>
+ + Options +ExecCGI
+ + </Directory> +

+ +

上記ディレクティブは、CGI ファイルの実行を可能にするよう + Apache に伝えます。また、どのファイルが CGI ファイルかを + サーバに伝える必要があります。次の + AddHandler + ディレクティブの例では、cgi または pl + を拡張子に持つすべてのファイルを CGI + プログラムとしてみなすことをサーバに伝えます:

+ +

+ AddHandler cgi-script .cgi .pl +

+ + +

.htaccess ファイル

+ + +

.htaccess チュートリアル + は httpd.conf を変更できない場合にどうやって CGI プログラムを + 使えるようにするかを説明しています。

+ + +

User ディレクトリ

+ + +

.cgi で終わるすべてのファイルに対して CGI プログラムの + 実行を許可するには、以下の設定を使用できます。

+ +

+ <Directory /home/*/public_html>
+ + Options +ExecCGI
+ AddHandler cgi-script .cgi
+ + </Directory> +

+ +

ユーザディレクトリの cgi-bin サブディレクトリの + すべてのファイルを CGI プログラムとして指定したい場合には + 以下のようなものを使います。

+ +

+ <Directory /home/*/public_html/cgi-bin>
+ + Options ExecCGI
+ SetHandler cgi-script
+ + </Directory> +

+ + +
top
+
+

CGI プログラムを書く

+ + +

「通常の」プログラミングと CGI + プログラミングの間には主に二つの違いがあります。

+ +

一つは、CGI プログラムのすべての出力にはMIME タイプ + ヘッダを付けなければなりません。 + これはどのような種類のコンテンツを受け取っているかをクライアントに示す + HTTP ヘッダです。ほとんどの場合では、次のように出力します:

+ +

+ Content-type: text/html +

+ +

もう一つは、出力を HTML + か、ブラウザが表示することができる何か他の形式にする必要があります。 + 大抵の場合は HTML でしょうが、GIF イメージや他の非 HTML + コンテンツを出力する CGI プログラムを書くこともあるでしょう。

+ +

これら二点以外では、CGI プログラムを書くことは、 + あなたが書いている他のプログラムとよく似ているでしょう。

+ +

最初の CGI プログラム

+ + +

次に示すのは、ブラウザに 1 行印字する CGI + プログラムの例です。以下を入力し、first.pl + というファイルに保存し、それを cgi-bin + ディレクトリに置いてください。

+ +

+ #!/usr/bin/perl
+ print "Content-type: text/html\n\n";
+ print "Hello, World."; +

+ +

Perl に精通していなくても、 + 何が起こるかを理解することはできるでしょう。1 行目は、 + /usr/bin/perl で見つけられるインタプリタに + このファイルを供給することでこのプログラムが実行されることを + Apache に (シェル上で実行しようとしているならば、そのシェルに ) + 示します。2 行目は、前述したとおり content-type の定義を印字します。 + これには復帰改行の二つの組を後に付加します。 + これにより、ヘッダの終りに空行が置かれ、HTTP + ヘッダの終りとボディの始まりを示します。3 行目は、"Hello, World." + という文字列を印字し、これで終りとなります。

+ +

好みのブラウザを開き、アドレス

+ +

+ http://www.example.com/cgi-bin/first.pl +

+ +

あるいはファイルを置いたロケーションを指定すると、 + Hello, World. + という 1 行がブラウザウィンドに現れるでしょう。 + それはあまりエキサイティングなことではありません。 + しかし、これがうまく動けば、 + 他のどのようなものでも動かすことができるようになります。

+ +
top
+
+

しかし、まだ動かない !

+ + +

ウェブから CGI プログラムへのアクセスを行なったとき、 + ブラウザで見る可能性がある四つの基本的なことがあります:

+ +
+
CGI プログラムの出力
+
素晴らしい ! それはすべてがうまく動いたことを意味します。 + 出力が正常だけれども、ブラウザが正常に処理してくれない場合は、 + 正しい Content-Type を CGI プログラム内で + セットしたかを確認してください。
+ +
CGI プログラムのソースコード、または "POST Method Not Allowed" + というメッセージ
+
これは、CGI プログラムを処理できるよう Apache + を適切に設定していなかったことを意味します。「CGI を許可するように + Apache を設定する」の章を読み直し、 + あなたが何を間違えたかを探してみてください。 +
+ +
メッセージが "Forbidden" で始まっている
+
これはパーミッションの問題ということを意味します。 + Apache のエラーログと、後述の「ファイルのパーミッション」 + の章をチェックしてください。 +
+ +
"Internal Server Error" というメッセージ
+
Apache + のエラーログをチェックすると、"Premature end of script headers" + というログが記録されていると思います。そして、おそらく CGI + プログラムによって生成されたエラーメッセージも記録されているでしょう。 + この場合、CGI プログラムが適切な + HTTP ヘッダを出力できない原因を知るために、 + 以下の各章でチェックしてみてください。
+
+ +

ファイルのパーミッション

+ + +

サーバはあなたの権限で実行されていないのを忘れないように。 + つまり、起動するとき、サーバは特権をもたないユーザ - 通常 nobody + や www の権限で実行されます。したがって、あなたが所有する + ファイルを実行するには別のパーミッションが必要となります。 + 通常、nobody が実行するのに十分なパーミッションを与える方法は、 + ファイルに誰でも実行可能とするパーミッションを与えることです:

+ +

+ chmod a+x first.pl +

+ +

また、もしあなたのプログラムが他のファイルを読み書きするならば、 + それらのファイルは、これが可能となる正しいパーミッション + を持っている必要があります。

+ + + +

パス情報と環境

+ + +

コマンドラインからプログラムを実行するとき、 + 意識しなくてもシェルに渡される情報があります。 + 例えば、参照するファイルのためにどこを検索したらよいかを + シェルに伝える PATH があります。

+ +

プログラムが CGI プログラムとしてウェブサーバによって実行されるとき、 + それは同じ PATH ではないかもしれません。 + CGI プログラム内で呼び出すあらゆるプログラム + (例えば、sendmail のようなもの) は、 + フルパスで指定する必要があるでしょう。それにより、CGI + プログラムを実行しようとしたとき、 + シェルはそのようなプログラムを見つけることができます。

+ +

同様なことは、スクリプトのインタプリタ (しばしば perl) + へのパスで、CGI プログラムの 1 行目に次のように示されます:

+ +

+ #!/usr/bin/perl +

+ +

これがインタープリタへの実際のパスであることを確認しておきます。

+ + +

また、CGI プログラムが他の環境変数に依存している場合は、その環境変数が + Apache から渡されるようにする必要があります。

+ +

プログラムエラー

+ + +

CGI + プログラムが失敗するのは大抵、プログラム自身に問題がある場合です。 + 一度 CGI の使い方を理解し、前述の二つの誤りを犯していないならば、 + まず間違いなくそうでしょう。ブラウザを使ってテストする前に + まず確認することは、コマンドラインからプログラムが実行できることです。 + 例えば、以下を実行してみてください:

+ +

+ cd /usr/local/apache2/cgi-bin
+ ./first.pl +

+ +

(perl インタプリタは呼ばないでください。 + シェルと Apache がスクリプトの最初の行の パス情報 を使って見つけます。)

+ +

最初にプログラムから出力されるのは Content-Type を含み、 + 後に空行の続く HTTP ヘッダでなければなりません。他のものが出力されている + 場合は、Apache はこのプログラムをサーバ経由で実行しようとしたときには + Premature end of script headers エラーを出力します。詳細は + 上記の CGI プログラムを書く を読んでください。

+ + +

エラーログ

+ + +

エラーログは友達です。 + 全てのうまくいかないことは、エラーログにメッセージを生成します。 + 必ずそれを最初に見るべきです。 + もし、あなたがウェブサイトを主催している場所が + エラーログの参照を許していないならば、きっと他のサイトで主催するべきです。 + エラーログの読み方を学ぶことで、ほとんど全ての問題が迅速に確認され、 + 迅速に解決されるということが分かるでしょう。

+ + +

Suexec

+ + +

suexec サポートプログラムは + バーチャルホストやユーザのホームディレクトリの場所に依って + CGI プログラムを違うユーザ権限の下で走らせることを可能にします。 + Suexec の権限のチェックは非常に厳しく、それを満たさない場合は + CGI プログラムが Premature end of script headers エラーで + 実行されません。

+ +

suexec を使っているかどうかを調べためには apachectl + -V を実行して、SUEXEC_BIN の場所を調べてください。 + Apache がそこに suexec のバイナリを発見した場合は、suexec が + 使用されます。

+ +

suexec を完全に理解していない限り、使うべきではありません。 + suexec を無効にするには、SUEXEC_BIN から指されている + suexec バイナリを削除 (か名前を変更) するだけです。 + suexec を読んだ後で、まだそれを + 使いたいのであれば、suexec -V を実行して suexec の + ログファイルの位置を調べ、そのログファイルを使ってポリシー違反を + 見つけてください。

+ +
top
+
+

裏で何が起こっているのか?

+ + +

CGI プログラミングに習熟すると、 + 裏で起こっていることについて更に理解することの役に立ちます。 + ブラウザとサーバがどのように相互通信するかについては特にそうです。 + なぜなら、"Hello, World." + を印字するプログラムを書くことはおおいに結構ですが、 + それは特に有益ではありません。

+ +

環境変数

+ + +

環境変数は、 + あなたがコンピュータを使うときに辺りに存在している値です。 + それらは、パス + (コマンドをタイプしたときに実行する実際のファイルを探し出すところ)、 + ユーザ名、端末型などのような便利なものです。 + 通常、普段使用している環境変数の完全なリストを調べるには、 + コマンドプロンプトで env を入力します。

+ +

CGI の処理中、サーバとブラウザも環境変数を設定し、 + それにより相互に通信することができるようになります。 + その環境変数は、ブラウザタイプ (Netscape, IE, Lynx)、サーバタイプ + (Apache, IIS, WebSite)、実行されている CGI + プログラムの名前などです。

+ +

これらの変数は CGI プログラマが使用できます。 + そして、それはクライアントとサーバの通信の話の半分です。 + 必要な変数の完全なリストは http://hoohoo.ncsa.uiuc.edu/cgi/env.html にあります。

+ +

以下の単純な Perl CGI + プログラムは、渡される全ての環境変数を表示します。同様のプログラムは、 + Apache ディストリビューションの cgi-bin + ディレクトリに二つ含まれています。 + いくつかの変数が必須であり、いくつかは任意であることに注意してください。 + そして、公式のリストにはないいくつかの変数が表示されているかもしれません。 + さらに、Apache はデフォルトで用意されている基本的なものに + あなた自身の環境変数を加えるための、 + 多くの異なる方法を用意してします。

+ +

+ #!/usr/bin/perl
+ print "Content-type: text/html\n\n";
+ foreach $key (keys %ENV) {
+ + print "$key --> $ENV{$key}<br>";
+ + } +

+ + +

STDIN と STDOUT

+ + +

サーバとクライアント間のもう一つの通信は、標準入力 + (STDIN)と標準出力 (STDOUT) + を通じて行なわれます。通常の文脈において、STDIN + はキーボードやプログラムが動作するために与えられるファイルを意味し、 + STDOUT は通常コンソールまたはスクリーンを意味します。

+ +

ウェブフォームから CGI プログラムへPOST + したとき、フォームのデータは特別なフォーマットで束ねられ、 + STDIN を通して、CGI プログラムに引き渡されます。 + プログラムはデータがキーボード + もしくはファイルから来ていたかのように処理することができます。

+ +

「特別なフォーマット」はとても単純です。フィールド名と値はイコール + (=) で結ばれます。そして値の組はアンパサンド (&) で結ばれます。 + スペース、アンパサンド、イコールのような面倒な文字は、 + それらが動作を駄目にしないようにその文字に相当する 16 進に変換されます。 + 全データ文字列は、以下のようになります: +

+ +

+ name=Rich%20Bowen&city=Lexington&state=KY&sidekick=Squirrel%20Monkey +

+ +

時々、このような文字列が URL + に付加されるのを見るでしょう。その場合、サーバは + QUERY_STRING という環境変数にその文字列を入れます。それは + GET リクエストと呼ばれます。 + HTML フォームでは、データを渡すために GET と + POST のどちらを使用するかを、FORM タグの + METHOD 属性の設定で指定します。

+ +

CGI プログラムは、その文字列を役に立つ情報に分割する責任があります。 + 幸いにも、そのデータ処理を助けるライブラリやモジュールが存在します。 + これらは、CGI プログラムの他の面でも同様に役に立ちます。

+ +
top
+
+

CGI モジュール/ライブラリ

+ + +

CGI プログラムを書くとき、面倒な仕事の大部分をしてくれる + コードライブラリまたはモジュールを使うことを検討すべきです。 + これはエラーを減らし、早い開発につながります。

+ +

Perl で CGI プログラムを書いているなら、モジュールは CPAN で提供されています。 + この目的のための最も普及しているモジュールは CGI.pm です。 + CGI::Lite も検討しましょう。これは、ほとんどのプログラム + において必要とするすべての機能の最小セットの実装です。

+ +

C で CGI プログラムを書いているなら、いろいろな + オプションがあります。これらの内の一つは http://www.boutell.com/cgic/ + で提供されている CGIC ライブラリです。

+
top
+
+

更なる情報

+ + +

CGI に関する情報はウェブで数多く提供されています。CGI + の問題については Usenet の comp.infosystems.www.authoring.cgi で、 + 他のユーザと論議することができます。HTML Writers Guide の + -servers メーリングリストは、あなたの質問に回答してくれる偉大なリソースです。 + http://www.hwg.org/lists/hwg-servers/ + で更に多くを探し出すことができます。

+ +

そしてもちろん、おそらく CGI + プログラムの動作に関する詳細の全てが記述されている + CGI の仕様を読むべきです。オリジナルバージョンを + NCSA + で、アップデートされたドラフトを + Common Gateway Interface RFC + プロジェクトで参照することができます。

+ +

CGI の問題について、加わっているメーリングリストまたはニュース + グループに質問を送るとき、起こったもの、起こってほしいこと、 + 実際に起こったことがどう違うか、使用しているサーバ、 + CGI プログラムを記述している言語に関する十分な情報と、 + 可能であれば問題のコードを提供するようにしてください。 + そうすることで、問題がより間単に見つかるようになります。

+ +

Apache のソースコードにおいて問題を発見したことを確信していない限り、 + CGI の問題に関する質問を Apache + バグデータベースに送るべきでない + ことに注目してください。

+
+
+

翻訳済み言語:  en  | + es  | + fr  | + ja  | + ko 

+
top

コメント

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/cgi.html.ko.euc-kr b/docs/manual/howto/cgi.html.ko.euc-kr new file mode 100644 index 0000000..13f1372 --- /dev/null +++ b/docs/manual/howto/cgi.html.ko.euc-kr @@ -0,0 +1,533 @@ + + + + + +ġ 丮: CGI - Apache HTTP Server Version 2.4 + + + + + + +
+

| þ | FAQ | | Ʈ

+

Apache HTTP Server Version 2.4

+
+
<-
+

ġ 丮: CGI

+
+

:  en  | + es  | + fr  | + ja  | + ko 

+
+
ֽ ƴմϴ. + ֱٿ ϼ.
+
+ +
top
+
+

Ұ

+ + +
õ õ þ
+ +

CGI (Common Gateway Interface) CGI α׷ + Ȥ CGI ũƮ θ, ( ) ܺ + α׷ ϴ Ѵ. Ʈ + ϰ ̴. ġ + CGI ϴ Ұϰ, CGI α׷ + ۼغ.

+
top
+
+

CGI ϵ ġ ϱ

+ + +

CGI α׷ ùٷ Ϸ CGI ϵ + ġ ؾ Ѵ. ϴ .

+ +

ScriptAlias

+ + +

ScriptAlias + þ ϸ ġ Ư 丮 CGI α׷ + д. ġ 丮 ִ CGI + α׷̶ Ͽ Ŭ̾Ʈ ڿ ûϸ ڿ + Ϸ õѴ.

+ +

ScriptAlias + þ Ѵ.

+ +

+ ScriptAlias /cgi-bin/ /usr/local/apache2/cgi-bin/ +

+ +

ġ ⺻ ҿ ġ + httpd.conf Ͽ ִ ̴. ScriptAlias þ Alias þ URL + պκ Ư 丮 Ѵ. + Alias + ScriptAlias DocumentRoot 丮 ۿ ִ + 丮 Ѵ. Alias + ScriptAlias + ScriptAlias ߰ URL պκ + ϴ CGI α׷ ϴ ̴. + ׷ ġ /cgi-bin/ + ϴ ڿ ûϸ + /usr/local/apache2/cgi-bin/ 丮 + ãƼ CGI α׷ ó϶ ˸.

+ +

, URL + http://www.example.com/cgi-bin/test.pl + ûϸ ġ + /usr/local/apache2/cgi-bin/test.pl + Ͽ ȯѴ. ϰ డϸ +  ε ؾ Ѵ. ׷ ġ + .

+ + +

ScriptAlias 丮 ۿ ִ CGI

+ + +

Ȼ CGI α׷ ScriptAlias 丮 + Ѵ. ׷ ڴ CGI α׷ + ִ ִ. ׷ ġ + ߴٸ ƹ 丮 CGI α׷ + . , UserDir þ Ͽ + ڰ ڽ Ȩ丮 츦 + . ڰ ڽ CGI α׷ ϰ + cgi-bin 丮 ٱ ٸ, ٸ + CGI α׷ ϰ ̴.

+ +

ƹ 丮 CGI Ϸ + ʿϴ. , AddHandler SetHandler þ Ͽ + cgi-script ڵ鷯 ۵ؾ Ѵ. ι°, + Options þ + ExecCGI ؾ Ѵ.

+ + +

Options Ͽ CGI ϱ

+ + +

ּϿ Options þ Ͽ Ư + 丮 CGI ִ.

+ +

+ <Directory /usr/local/apache2/htdocs/somedir>
+ + Options +ExecCGI
+ + </Directory> +

+ +

þ ġ CGI Ѵ.  + CGI ˷ Ѵ. AddHandler þ + Ȯڰ cgi pl + CGI α׷̶ ˸.

+ +

+ AddHandler cgi-script .cgi .pl +

+ + +

.htaccess

+ + +

.htaccess 丮 + httpd.conf ٱ 쿡 CGI α׷ + ִ ˷ش.

+ + +

丮

+ + +

Ʒ ϸ 丮 .cgi + CGI α׷ Ѵ.

+ +

+ <Directory /home/*/public_html>
+ + Options +ExecCGI
+ AddHandler cgi-script .cgi
+ + </Directory> +

+ +

ϸ 丮 cgi-bin + 丮 ִ CGI α׷ νѴ.

+ +

+ <Directory /home/*/public_html/cgi-bin>
+ + Options ExecCGI
+ SetHandler cgi-script
+ + </Directory> +

+ + + +
top
+
+

CGI α׷ ۼϱ

+ + +

``Ϲ'' α׷ְ CGI α׷ ̿ ΰ + ֵ ִ.

+ +

ù° ̴ CGI α׷ ٸ ϱ + MIME-type ؾ Ѵٴ ̴. HTTP + Ŭ̾Ʈ Ŭ̾Ʈ  ްԵ ̸ ˸. + .

+ +

+ Content-type: text/html +

+ +

ι° ̴ HTML Ȥ ִ + ؾ Ѵٴ ̴. κ HTML , + gif ׸ HTML ƴ ϴ CGI + α׷ ۼϴ 쵵 ִ.

+ +

ΰ ϰ CGI α׷ ۼ ̹ + ٸ α׷ ſ ϴ.

+ +

ó CGI α׷

+ + +

CGI α׷ . + ״ first.pl̶ Ͽ ϰ, + cgi-bin 丮 Ѵ.

+ +

+ #!/usr/bin/perl
+ print "Content-type: text/html\n\n";
+ print "Hello, World."; +

+ +

Perl ͼ ʴ Ͼ + ִ. ù° ġ(Ȥ ϴ ) + /usr/bin/perl ġ ִ Ͽ + α׷ ϶ ˸. ι° + content-type ϰ carriage-return ٹٲ + ι Ѵ. ׷ ڿ HTTP ϴ + , Ѵ. ° "Hello, World." + ڿ Ѵ. ̰ ̴.

+ +

ϰ ּҸ ԷѴ

+ +

+ http://www.example.com/cgi-bin/first.pl +

+ +

Ҹ Էϸ, â Hello, World. + δ. е , ѹ ϴ + ٸ õ ִ.

+ +
top
+
+

׷ ʾƿ!

+ + +

CGI α׷ Ҷ ִ + ⺻ װ.

+ +
+
CGI α׷
+
! Ѵٴ ̴. Ȯ + ùٷ ó Ѵٸ, CGI α׷ + ùٸ Content-Type Ͽ ȮѴ.
+ +
CGI α׷ ҽڵ Ȥ "POST Method Not Allowed" +
+
CGI α׷ ϵ ġ + ʾҴٴ ̴. ġ ϱ + ٽ а κ ִ ãƺ.
+ +
"Forbidden" ϴ
+
ִٴ ̴. ġ + α Ʒ ϱ + Ȯ϶.
+ +
"Internal Server Error"
+
ġ α Ƹ + CGI α׷ Բ "Premature end of + script headers" ̴. Ʒ ϳ + ȮϿ  CGI α׷ HTTP + ߴ ˾ƺ.
+
+ +

ϱ

+ + +

Ű ϶. + , ϸ Ư ( + nobody www) Ѵ. + ׷ Ϸ ʿϴ. + Ͽ nobody ϱ⿡ + ֱ ο ش.

+ +

+ chmod a+x first.pl +

+ +

, α׷ ٸ аų ٸ Ͽ + ʿϴ.

+ + + +

ȯ

+ + +

࿡ α׷ ϸ ڵ  + ޵ȴ. , PATH + ã Ҹ ˷ش.

+ +

α׷ CGI α׷ Ҷ + PATH ٸ ִ. ( , + sendmail ) CGI α׷ ȿ ϴ + ɾ η ؾ ɾ ã + ִ.

+ +

CGI α׷ ù° ٿ + ũƮ ( perl) ο + ߻Ѵ.

+ +

+ #!/usr/bin/perl +

+ +

ȮѴ.

+ +

, CGI α׷ ٸ ȯ溯 + Ѵٸ ġ α׷ ؾ + Ѵ.

+ + + +

α׷

+ + +

CGI α׷ ϴ κ α׷ ü + ̴. Ư ΰ Ǽ ʾҰ + ִٸ ׷. ϱ + ࿡ α׷ غ. , + Ѵ.

+ +

+ cd /usr/local/apache2/cgi-bin
+ ./first.pl +

+ +

(perl ͸ . + ġ ũƮ ù° ٿ ִ Ͽ ͸ + ãƾ Ѵ.)

+ +

α׷ Content-Type + HTTP ϰ ؾ Ѵ. ٸ + Ѵٸ ġ Premature + end of script headers ȯѴ. ڼ + CGI α׷ ۼϱ ϶.

+ + +

α

+ + +

α״ ̴. ߸Ǹ α׿ + . α׸ Ѵ. Ʈ + ȣϴ α׸ ϰ Ѵٸ, Ƹ + ٸ ü ˾ƺ Ѵ. α׸ , + κ ľϿ ذ ִ.

+ + +

Suexec

+ + +

suexec α׷ + ϸ  ȣƮ Ȥ  丮 ִ + CGI α׷ ٸ ִ. + Suexec ſ ϰ ˻ϸ, ˻縦 ϳ + ϸ CGI α׷ ʰ Premature + end of script headers ȯѴ.

+ +

suexec ϰ ִ ˷ apachectl -V + Ͽ SUEXEC_BIN ġ ȮѴ. ġ + Ҷ ҿ suexec ߰ϸ, suexec + ִ.

+ +

suexec ߴٸ ؼ ȵȴ. + suexec SUEXEC_BIN ġ + ִ suexec (Ȥ ϸ + ٲٰ) ϸ ȴ. suexec ׷ + ϰ ʹٸ, suexec -V Ͽ suexec + α ġ ˾Ƴ αϿ  Ģ + ִ ã´.

+ +
top
+
+

ڿ °?

+ + +

CGI α׷ֿ ͼ ڿ ϸ + ȴ. ü ϴ + ϴ ̴. "Hello, World." ϴ + α׷ ۼ ̷ α׷ + ⶧̴.

+ +

ȯ溯

+ + +

ȯ溯 ǻ͸ ϴ + ٴϴ ̴. ȯ溯 path (ǻͰ Է + ɾ شϴ ã ), ڸ, ͹̳ + . Ϲ ȯ溯 + Ʈ env ԷѴ.

+ +

CGI Ҷ ȯ溯 + ȯѴ. (Netscape, IE, + Lynx), (ġ, IIS, WebSite), ϴ CGI + α׷ ִ.

+ +

CGI α׷Ӵ ̷ ְ, + ȯ溯 Ŭ̾Ʈ- ſ Ϻκ Ѵ. + ü ʼ http://hoohoo.ncsa.uiuc.edu/cgi/env.html ִ.

+ +

Ʒ Perl CGI α׷ ڽſ ޵ + ȯ溯 ش. ġ cgi-bin + 丮 ̿ α׷ ΰ ִ. + ʼ̰ ̴. ׷ Ͽ + δ. , ġ ⺻ ϴ ȯ溯 + ܿ ȯ溯 + ߰ ִ.

+ +

+ #!/usr/bin/perl
+ print "Content-type: text/html\n\n";
+ foreach $key (keys %ENV) {
+ + print "$key --> $ENV{$key}<br>";
+ + } +

+ + +

STDIN STDOUT

+ + +

, Ŭ̾Ʈ ǥԷ(STDIN) + ǥ(STDOUT) Ѵ. ϻ + STDIN Ű峪 α׷ óϴ + Ÿ, STDOUT ܼ̳ ȭ Ѵ.

+ +

CGI α׷ (form) POSTϸ + Ŀ Է ڷḦ Ư  CGI α׷ + STDIN Ѵ. ׷ α׷ Ű峪 + Ͽ ڷḦ óϵ ڷḦ ó ִ.

+ +

"Ư " ſ ϴ. ׸ ̸ ȣ(=) + ϰ, ׸ ̸ ֵ ۻ(&) + Ѵ. , ۻ, ȣ ڿ ڴ + ȥ ʵ 16 ȯѴ. ڷ ڿ + .

+ +

+ name=Rich%20Bowen&city=Lexington&state=KY&sidekick=Squirrel%20Monkey +

+ +

URL ڿ ̷ ڿ ȴ. + ڿ QUERY_STRING̶ ȯ溯 Ѵ. + ̸ GET û̶ Ѵ. FORM + ± METHOD Ӽ Ͽ HTML (form) + ڷḦ GET POST Ѵ.

+ +

α׷ ̷ ڿ ɰ + Ѵ. ̷ ڷ ó CGI α׷ ٸ + Ǵ ̺귯 ִ.

+ +
top
+
+

CGI /̺귯

+ + +

CGI α׷ ۼҶ ۾ ִ ڵ + ̺귯 Ȥ غ Ѵ. ̷ + ϸ װ ٰ α׷ ִ.

+ +

Perl CGI α׷ ۼѴٸ CPAN ã + ִ. CGI ߿ θ Ǵ + CGI.pm̴. κ α׷ ּ + CGI::Lite ִ.

+ +

C CGI α׷ ۼѴٸ . + ϳ http://www.boutell.com/cgic/ + ִ CGIC ̺귯.

+
top
+
+

...

+ + +

ſ CGI ִ. ׷ comp.infosystems.www.authoring.cgi + CGI ִ. HTML Writers Guild -servers + ϸƮ ã⿡ Ǹ Ҵ. http://www.hwg.org/lists/hwg-servers/ + ִ.

+ +

׸ CGI α׷ ۿ + CGI Ծ о 𸥴. NCSA + ְ, ʾ Common Gateway Interface + RFC Ʈ ִ.

+ +

ϸƮ ׷쿡 ݰ ִ CGI + Ҷ ߻ , ߻ +  ٸ, ϴ , CGI α׷ ۼ + , ϸ ش ڵ带 ڼ . ׷ ذå + ã .

+ +

ġ ҽڵ尡 ߸Ǿٰ Ȯ ʴ CGI + ġ ͺ̽ ø + ȵȴ.

+
+
+

:  en  | + es  | + fr  | + ja  | + ko 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/htaccess.html b/docs/manual/howto/htaccess.html new file mode 100644 index 0000000..1e6a6f0 --- /dev/null +++ b/docs/manual/howto/htaccess.html @@ -0,0 +1,25 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: htaccess.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: htaccess.html.es +Content-Language: es +Content-type: text/html; charset=ISO-8859-1 + +URI: htaccess.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 + +URI: htaccess.html.ja.utf8 +Content-Language: ja +Content-type: text/html; charset=UTF-8 + +URI: htaccess.html.ko.euc-kr +Content-Language: ko +Content-type: text/html; charset=EUC-KR + +URI: htaccess.html.pt-br +Content-Language: pt-br +Content-type: text/html; charset=ISO-8859-1 diff --git a/docs/manual/howto/htaccess.html.en b/docs/manual/howto/htaccess.html.en new file mode 100644 index 0000000..e16fc1f --- /dev/null +++ b/docs/manual/howto/htaccess.html.en @@ -0,0 +1,465 @@ + + + + + +Apache HTTP Server Tutorial: .htaccess files - Apache HTTP Server Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.4

+
+
<-
+

Apache HTTP Server Tutorial: .htaccess files

+
+

Available Languages:  en  | + es  | + fr  | + ja  | + ko  | + pt-br 

+
+ +

.htaccess files provide a way to make configuration +changes on a per-directory basis.

+
+ +
top
+
+

.htaccess files

+
Related ModulesRelated Directives
+ +
You should avoid using .htaccess files completely if you have access to + httpd main server config file. Using .htaccess files slows down your Apache http server. + Any directive that you can include in a .htaccess file is better set in a Directory block, as it will have the same effect with better performance.
+
top
+
+

What they are/How to use them

+ + +

.htaccess files (or "distributed configuration files") + provide a way to make configuration changes on a per-directory basis. A + file, containing one or more configuration directives, is placed in a + particular document directory, and the directives apply to that + directory, and all subdirectories thereof.

+ +

Note:

+

If you want to call your .htaccess file something + else, you can change the name of the file using the AccessFileName directive. For example, + if you would rather call the file .config then you + can put the following in your server configuration file:

+ + 
AccessFileName ".config"
+ +
+ +

In general, .htaccess files use the same syntax as + the main configuration + files. What you can put in these files is determined by the + AllowOverride directive. This + directive specifies, in categories, what directives will be + honored if they are found in a .htaccess file. If a + directive is permitted in a .htaccess file, the + documentation for that directive will contain an Override section, + specifying what value must be in AllowOverride in order for that + directive to be permitted.

+ +

For example, if you look at the documentation for the AddDefaultCharset + directive, you will find that it is permitted in .htaccess + files. (See the Context line in the directive summary.) The Override line reads + FileInfo. Thus, you must have at least + AllowOverride FileInfo in order for this directive to be + honored in .htaccess files.

+ +

Example:

+ + + + + + + + + +
Context:server config, virtual host, directory, .htaccess
Override:FileInfo
+ +

If you are unsure whether a particular directive is permitted in a + .htaccess file, look at the documentation for that + directive, and check the Context line for ".htaccess".

+
top
+
+

When (not) to use .htaccess files

+ +

In general, you should only use .htaccess files when + you don't have access to the main server configuration file. There is, + for example, a common misconception that user authentication should + always be done in .htaccess files, and, in more recent years, + another misconception that mod_rewrite directives + must go in .htaccess files. This is simply not the + case. You can put user authentication configurations in the main server + configuration, and this is, in fact, the preferred way to do + things. Likewise, mod_rewrite directives work better, + in many respects, in the main server configuration.

+ +

.htaccess files should be used in a case where the + content providers need to make configuration changes to the server on a + per-directory basis, but do not have root access on the server system. + In the event that the server administrator is not willing to make + frequent configuration changes, it might be desirable to permit + individual users to make these changes in .htaccess files + for themselves. This is particularly true, for example, in cases where + ISPs are hosting multiple user sites on a single machine, and want + their users to be able to alter their configuration.

+ +

However, in general, use of .htaccess files should be + avoided when possible. Any configuration that you would consider + putting in a .htaccess file, can just as effectively be + made in a <Directory> section in your main server + configuration file.

+ +

There are two main reasons to avoid the use of + .htaccess files.

+ +

The first of these is performance. When AllowOverride + is set to allow the use of .htaccess files, httpd will + look in every directory for .htaccess files. Thus, + permitting .htaccess files causes a performance hit, + whether or not you actually even use them! Also, the + .htaccess file is loaded every time a document is + requested.

+ +

Further note that httpd must look for .htaccess files + in all higher-level directories, in order to have a full complement of + directives that it must apply. (See section on how + directives are applied.) Thus, if a file is requested out of a + directory /www/htdocs/example, httpd must look for the + following files:

+ +

+ /.htaccess
+ /www/.htaccess
+ /www/htdocs/.htaccess
+ /www/htdocs/example/.htaccess +

+ +

And so, for each file access out of that directory, there are 4 + additional file-system accesses, even if none of those files are + present. (Note that this would only be the case if + .htaccess files were enabled for /, which + is not usually the case.)

+ +

In the case of RewriteRule directives, in + .htaccess context these regular expressions must be + re-compiled with every request to the directory, whereas in main + server configuration context they are compiled once and cached. + Additionally, the rules themselves are more complicated, as one must + work around the restrictions that come with per-directory context + and mod_rewrite. Consult the Rewrite Guide for more + detail on this subject.

+ +

The second consideration is one of security. You are permitting + users to modify server configuration, which may result in changes over + which you have no control. Carefully consider whether you want to give + your users this privilege. Note also that giving users less + privileges than they need will lead to additional technical support + requests. Make sure you clearly tell your users what level of + privileges you have given them. Specifying exactly what you have set + AllowOverride to, and pointing them + to the relevant documentation, will save yourself a lot of confusion + later.

+ +

Note that it is completely equivalent to put a .htaccess + file in a directory /www/htdocs/example containing a + directive, and to put that same directive in a Directory section + <Directory "/www/htdocs/example"> in your main server + configuration:

+ +

.htaccess file in /www/htdocs/example:

+ +

Contents of .htaccess file in + /www/htdocs/example

AddType text/example ".exm"
+
+ +

Section from your httpd.conf + file

<Directory "/www/htdocs/example">
+    AddType text/example ".exm"
+</Directory>
+
+ +

However, putting this configuration in your server configuration + file will result in less of a performance hit, as the configuration is + loaded once when httpd starts, rather than every time a file is + requested.

+ +

The use of .htaccess files can be disabled completely + by setting the AllowOverride + directive to none:

+ + 
AllowOverride None
+ +
top
+
+

How directives are applied

+ +

The configuration directives found in a .htaccess file + are applied to the directory in which the .htaccess file + is found, and to all subdirectories thereof. However, it is important + to also remember that there may have been .htaccess files + in directories higher up. Directives are applied in the order that they + are found. Therefore, a .htaccess file in a particular + directory may override directives found in .htaccess files + found higher up in the directory tree. And those, in turn, may have + overridden directives found yet higher up, or in the main server + configuration file itself.

+ +

Example:

+ +

In the directory /www/htdocs/example1 we have a + .htaccess file containing the following:

+ + 
Options +ExecCGI
+ + +

(Note: you must have "AllowOverride Options" in effect + to permit the use of the "Options" directive in + .htaccess files.)

+ +

In the directory /www/htdocs/example1/example2 we have + a .htaccess file containing:

+ + 
Options Includes
+ + +

Because of this second .htaccess file, in the directory + /www/htdocs/example1/example2, CGI execution is not + permitted, as only Options Includes is in effect, which + completely overrides any earlier setting that may have been in + place.

+ +

Merging of .htaccess with the main + configuration files

+ +

As discussed in the documentation on Configuration Sections, + .htaccess files can override the <Directory> sections for + the corresponding directory, but will be overridden by other types + of configuration sections from the main configuration files. This + fact can be used to enforce certain configurations, even in the + presence of a liberal AllowOverride setting. For example, to + prevent script execution while allowing anything else to be set in + .htaccess you can use:

+ + 
<Directory "/www/htdocs">
+    AllowOverride All
+</Directory>
+
+<Location "/">
+    Options +IncludesNoExec -ExecCGI
+</Location>
+ + +
This example assumes that your DocumentRoot is /www/htdocs.
+ + +
top
+
+

Authentication example

+ +

If you jumped directly to this part of the document to find out how + to do authentication, it is important to note one thing. There is a + common misconception that you are required to use + .htaccess files in order to implement password + authentication. This is not the case. Putting authentication directives + in a <Directory> + section, in your main server configuration file, is the preferred way + to implement this, and .htaccess files should be used only + if you don't have access to the main server configuration file. See above for a discussion of when you should and should + not use .htaccess files.

+ +

Having said that, if you still think you need to use a + .htaccess file, you may find that a configuration such as + what follows may work for you.

+ +

.htaccess file contents:

+ + 
AuthType Basic
+AuthName "Password Required"
+AuthUserFile "/www/passwords/password.file"
+AuthGroupFile "/www/passwords/group.file"
+Require group admins
+ + +

Note that AllowOverride AuthConfig must be in effect + for these directives to have any effect.

+ +

Please see the authentication tutorial for a + more complete discussion of authentication and authorization.

+
top
+
+

Server Side Includes example

+ +

Another common use of .htaccess files is to enable + Server Side Includes for a particular directory. This may be done with + the following configuration directives, placed in a + .htaccess file in the desired directory:

+ + 
Options +Includes
+AddType text/html shtml
+AddHandler server-parsed shtml
+ + +

Note that AllowOverride Options and AllowOverride + FileInfo must both be in effect for these directives to have any + effect.

+ +

Please see the SSI tutorial for a more + complete discussion of server-side includes.

+
top
+
+

Rewrite Rules in .htaccess files

+

When using RewriteRule in +.htaccess files, be aware that the per-directory context +changes things a bit. In particular, rules are taken to be relative to +the current directory, rather than being the original requested URI. +Consider the following examples:

+ +
# In httpd.conf
+RewriteRule "^/images/(.+)\.jpg" "/images/$1.png"
+
+# In .htaccess in root dir
+RewriteRule "^images/(.+)\.jpg" "images/$1.png"
+
+# In .htaccess in images/
+RewriteRule "^(.+)\.jpg" "$1.png"
+ + +

In a .htaccess in your document directory, the leading +slash is removed from the value supplied to RewriteRule, and in the +images subdirectory, /images/ is removed from +it. Thus, your regular expression needs to omit that portion as +well.

+ +

Consult the mod_rewrite documentation for +further details on using mod_rewrite.

+ +
top
+
+

CGI example

+ +

Finally, you may wish to use a .htaccess file to permit + the execution of CGI programs in a particular directory. This may be + implemented with the following configuration:

+ + 
Options +ExecCGI
+AddHandler cgi-script cgi pl
+ + +

Alternately, if you wish to have all files in the given directory be + considered to be CGI programs, this may be done with the following + configuration:

+ + 
Options +ExecCGI
+SetHandler cgi-script
+ + +

Note that AllowOverride Options and AllowOverride + FileInfo must both be in effect for these directives to have any + effect.

+ +

Please see the CGI tutorial for a more + complete discussion of CGI programming and configuration.

+ +
top
+
+

Troubleshooting

+ +

When you put configuration directives in a .htaccess + file, and you don't get the desired effect, there are a number of + things that may be going wrong.

+ +

Most commonly, the problem is that AllowOverride is not + set such that your configuration directives are being honored. Make + sure that you don't have a AllowOverride None in effect + for the file scope in question. A good test for this is to put garbage + in your .htaccess file and reload the page. If a server error is + not generated, then you almost certainly have AllowOverride + None in effect.

+ +

If, on the other hand, you are getting server errors when trying to + access documents, check your httpd error log. It will likely tell you + that the directive used in your .htaccess file is not + permitted.

+ +

+ [Fri Sep 17 18:43:16 2010] [alert] [client 192.168.200.51] /var/www/html/.htaccess: DirectoryIndex not allowed here +

+ +

This will indicate either that you've used a directive that is + never permitted in .htaccess files, or that you simply + don't have AllowOverride set to + a level sufficient for the directive you've used. Consult the + documentation for that particular directive to determine which is + the case.

+ +

Alternately, it may tell you that you had a syntax error in your + usage of the directive itself.

+ +

+ [Sat Aug 09 16:22:34 2008] [alert] [client 192.168.200.51] /var/www/html/.htaccess: RewriteCond: bad flag delimiters +

+ +

In this case, the error message should be specific to the + particular syntax error that you have committed.

+ +
+
+

Available Languages:  en  | + es  | + fr  | + ja  | + ko  | + pt-br 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/htaccess.html.es b/docs/manual/howto/htaccess.html.es new file mode 100644 index 0000000..ad63d84 --- /dev/null +++ b/docs/manual/howto/htaccess.html.es @@ -0,0 +1,464 @@ + + + + + +Tutorial del Servidor Apache HTTP: Ficheros .htaccess - Servidor HTTP Apache Versión 2.4 + + + + + + +
+

Módulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

+

Versión 2.4 del Servidor HTTP Apache

+
+
<-
+

Tutorial del Servidor Apache HTTP: Ficheros .htaccess

+
+

Idiomas disponibles:  en  | + es  | + fr  | + ja  | + ko  | + pt-br 

+
+ +

Los ficheros .htaccess facilitan una forma de realizar + cambios en la configuración en contexto directorio.

+
+ +
top
+
+

Ficheros .htaccess

+
Módulos RelacionadosDirectivas Relacionadas
+ +
Debería evitar usar ficheros .htaccess completamente si + tiene acceso al fichero de configuración principal de httpd. Usar ficheros + .htaccess ralentiza su servidor Apache http. Cualquier + directiva que pueda incluir en un fichero .htaccess + estará mejor configurada dentro de una sección + Directory, tendrá el mismo efecto y + mejor rendimiento.
+
top
+
+

Qué son/Cómo usarlos

+ + +

Los ficheros .htaccess (o "ficheros de configuración + distribuida") facilitan una forma de realizar cambios en la configuración + en contexto directorio. Un fichero, que contiene una o más directivas, se + coloca en un documento específico de un directorio, y estas directivas + aplican a ese directorio y todos sus subdirectorios.

+ +

Nota:

+

Si quiere llamar a su fichero .htaccess de otra manera, + puede cambiar el nombre del fichero usando la directiva AccessFileName. Por ejemplo, si usted prefiere + llamar al fichero .config, entonces puede poner lo siguiente + en el fichero de configuración de su servidor:

+ + 
AccessFileName ".config"
+ +
+ +

Generalmente, los ficheros .htaccess usan la misma sintáxis + que los ficheros de la configuración + principal. Lo que puede utilizar en estos ficheros lo determina la + directiva AllowOverride. Esta directiva + especifica, en categorías, qué directivas tendrán efecto si se encuentran en + un fichero .htaccess. Si se permite una directiva en un fichero + .htaccess, la documentación para esa directiva contendrá una + sección Override, especificando qué valor debe ir en + AllowOverride para que se permita esa + directiva.

+ +

Por ejemplo, si busca en la documentación la directiva AddDefaultCharset, encontrará que se permite en + ficheros .htaccess. (Vea la línea de Contexto en el sumario de + la directiva.) La línea Override muestra + FileInfo. De este modo, debe tener al menos + AllowOverride FileInfo para que esta directiva se aplique en + ficheros .htaccess.

+ +

Ejemplo:

+ + + + + + + + + +
Context:server config, virtual host, directory, .htaccess
Override:FileInfo
+ +

Si no está seguro de cuándo, una directiva en concreto, se puede usar en un + fichero .htaccess, consulte la documentación para esa directiva, + y compruebe la línea Context buscando ".htaccess".

+
top
+
+

Cuando (no) usar ficheros .htaccess

+ +

Generalmente, solo debería usar ficheros .htaccess cuando no + tiene acceso al fichero principal de configuración del servidor. Hay, por + ejemplo, una creencia errónea de que la autenticación de usuario debería + hacerse siempre dentro de ficheros .htaccess, y, más recientemente, otra creencia errónea de que las directivas de + mod_rewrite deben ir en ficheros .htaccess. + Esto sencillamente no es el caso. Puede poner las configuraciones de + autenticación de usuario en la configuración principal del servidor, y esto + es de hecho, el método preferido de configurar Apache. Del mismo modo, las + directivas mod_rewrite funcionan mejor, en muchos sentidos, en + el fichero de configuración principal del servidor.

+ +

Los ficheros .htaccess deberían usarse cuando su proveedor + de contenidos le permite hacer modificaciones de configuración + en contexto directorio, pero usted no tiene acceso de root en el servidor. + En el caso de que el administrador no esté dispuesto a hacer cambios + frecuentes en la configuración, puede que sea necesario permitir a usuarios + individuales realizar estos cambios de configuración en ficheros + .htaccess por ellos mismos. Lo cual ocurre a menudo, por + ejemplo, en casos donde los ISP están albergando múltiples sitios web de + usuario en una sola máquina, y quieren que sus usuarios tengan la + posibilidad de modificar sus configuraciones.

+ +

Aun así, generalmente, el uso de ficheros .htaccess debería + evitarse cuando sea posible. Cualquier configuración que consideraría poner + en un fichero .htaccess, puede usarse con la misma efectividad + en una sección <Directory> en el fichero de configuración + del servidor.

+ +

Hay dos razones para evitar el uso de ficheros .htaccess.

+ +

La primera es el rendimiento. Cuando AllowOverride + está configurado para permitir el uso de ficheros .htaccess, + httpd buscará ficheros .htaccess en cada directorio. Así, + permitiendo ficheros .htaccess provoca una pérdida de + rendimiento, ¡incluso aunque no los use! Además, los ficheros + .htaccess se cargan cada vez que se solicita un documento.

+ +

Además tenga en cuenta que httpd debe buscar ficheros + .htaccess en todos los directorios de mayor jerarquía, + para poder terner la lista completa de directivas que debe aplicar. (Vea + la sección sobre Cómo se aplican las directivas.) Así, si + se solicita un fichero de un directorio /www/htdocs/example, + httpd debe buscar los siguientes ficheros:

+ +

+ /.htaccess
+ /www/.htaccess
+ /www/htdocs/.htaccess
+ /www/htdocs/example/.htaccess +

+ +

De esta manera, por cada acceso a un fichero de ese directorio, hay 4 + accesos adicionales al sistema de ficheros, incluso si ninguno de esos + ficheros está presente. (Tenga en cuenta que este caso solo se daría si los + ficheros .htaccess están activados en /, que + generalmente no es el caso.).

+ +

En el caso de las directivas RewriteRule, en el contexto de + .htaccess estas expresiones regulares deben recompilarse con + cada solicitud a ese directorio, cuando en el contexto de configuración del + servidor solo se compilan una vez y se cachean. Adicionalmente, las reglas + en sí mismas son más complicadas, puesto que uno debe sortear las + restricciones que vienen acompañadas del contexto directorio y + mod_rewrite. Consulte la Guía de Rewrite para un mayor + detalle sobre este tema.

+ +

La segunda consideración es de seguridad. Estará permitiendo que usuarios + modifiquen la configuración del servidor, lo cual puede dar lugar a cambios sobre los que usted no tendrá ningún control. Medite profundamente si debe + dar a sus usuarios ese privilegio. Además tenga en cuenta que dar a los usuarios menos privilegios de los que necesitan dará lugar a más peticiones + de soporte. Asegúrese de que le indica a sus usuarios claramente el nivel de privilegios que les está dando. Especificando exactamente cómo ha + configurado AllowOverride, e invíteles + a revisar la documentación relacionada, lo cual le ahorrará + bastantes confusiones más adelante.

+ +

Tenga en cuenta que esto es equivalente por completo a poner un fichero + .htaccess en un directorio /www/htdocs/example + con una directiva, y poner la misma directiva en una sección + Directory <Directory "/www/htdocs/example"> en su + configuración principal del servidor:

+ +

Fichero .htaccess en /www/htdocs/example:

+ +

Contenido de fichero .htaccess en + /www/htdocs/example

AddType text/example ".exm"
+
+ +

Sección de su fichero httpd.conf

<Directory "/www/htdocs/example">
+    AddType text/example ".exm"
+</Directory>
+
+ +

Aun así, poniendo ésta en el fichero de configuración dará como resultado + una menor pérdida de rendimiento, y como la configuración se carga una vez + cuando el httpd arranca, en lugar de cada vez que se solicita un fichero.

+ +

El uso de ficheros .htaccess puede desactivarse por completo + configurando la directiva AllowOverride + a none:

+ + 
AllowOverride None
+ +
top
+
+

How directives are applied

+ +

Las directivas de configuración que se encuentran en el fichero + .htaccess se aplican al directorio en el que el fichero + .htaccess se encuentra, y a todos sus subdirectorios. Sin + embargo, es importante recordar que puede haber otros ficheros + .htaccess en directorios previos. Las directivas se aplican en + el orden en el que se encuentran. Por lo tanto, un fichero + .htaccess puede sobrescribir directivas que se encuentran + en ficheros .htaccess que se encuentran en directorios previos + del árbol de directorios. Y estos, en cambio, pueden haber sobrescrito + directivas que se encontraban más arriba, o en el fichero principal de + configuración del servidor mismo.

+ +

Ejemplo:

+ +

En el directorio /www/htdocs/example1 tenemos un fichero + .htaccess que contiene lo siguiente:

+ + 
Options +ExecCGI
+ + +

(Nota: debe terner "AllowOverride Options" configurado para + permitir el uso de la directiva "Options" en ficheros + .htaccess files.)

+ +

En el directorio /www/htdocs/example1/example2 tenemos un + fichero .htaccess que contiene:

+ + 
Options Includes
+ + +

Por este segundo fichero .htaccess, en el directorio + /www/htdocs/example1/example2, la ejecución de CGI execution no + está permitida, porque solo se ha definido Options Includes, + que sobrescribe completamente una configuración previa que se pudiera haber + definido.

+ +

Incorporando el .htaccess en los ficheros de + configuración principal

+ +

Como se ha comentado en la documentación en las Secciones de Configuración, los ficheros + .htaccess pueden sobrescribir las secciones <Directory> por el directorio + correspondiente, pero se sobrescribirán por otros tipos de secciones de + configuración de los ficheros de configuración principal. Este hecho se + puede usar para forzar ciertas configuraciones, incluso en presencia + de una configuración laxa de + AllowOverride. Por ejemplo, para + prevenir la ejecución de un script mientras se permite cualquier otra cosa + en .htaccess puede usar:

+ + 
<Directory "/www/htdocs">
+    AllowOverride All
+</Directory>
+
+<Location "/">
+    Options +IncludesNoExec -ExecCGI
+</Location>
+ + +
Este ejemplo asume que su DocumentRoot es /www/htdocs.
+ + +
top
+
+

Ejemplo de Autenticación

+ +

Si saltó directamente a esta parte del documento para averiguar como + hacer la autenticación, es important que tenga en cuenta una cosa. Hay una + creencia errónea de que necesita usar ficheros .htaccess para + configurar autenticación con contraseña. Este no es el caso. Colocar las + directivas de autenticación en una sección + <Directory>, en su fichero + de configuración principal, es el método recomendado para configurar esto, + y los ficheros .htaccess deberían usarse solamente si no tiene + acceso al fichero de configuración principal del servidor. Vea más arriba una explicación de cuando debería y cuando no + debería usar ficheros .htaccess.

+ +

Dicho esto, si todavía cree que debe usar el fichero + .htaccess, podrá ver que una configuración como la que sigue + podría servirle.

+ +

Contenido del fichero .htaccess:

+ + 
AuthType Basic
+AuthName "Password Required"
+AuthUserFile "/www/passwords/password.file"
+AuthGroupFile "/www/passwords/group.file"
+Require group admins
+ + +

Tenga en cuenta que AllowOverride AuthConfig debe estar + habilitado para que estas directivas tengan algún efecto.

+ +

Por favor vea el tutorial de autenticación para + una explicación más completa de la autenticación y la autorización.

+
top
+
+

Ejemplo de Server Side Includes

+ +

Otro uso común de ficheros .htaccess es activar Server Side + Includes para un directorio en particular. Esto puede hacerse + con las siguientes directivas de configuración, colocadas en un fichero + .htaccess y el directorio deseado:

+ + 
Options +Includes
+AddType text/html "shtml"
+AddHandler server-parsed shtml
+ + +

Tenga en cuenta que AllowOverride Options y + AllowOverride FileInfo deben estar activadas para que estas + directivas tengan efecto.

+ +

Por favor vea el tutorial de SSI para una + explicación más completa de server-side includes.

+
top
+
+

Reglas de Rewrite en ficheros .htaccess

+

Cuando use RewriteRule en + ficheros .htaccess, tenga en cuenta que el contexto + directorio cambia las cosas un poco. En concreto, las reglas son + relativas al directorio actual, en lugar de serlo de la petición de URI + solicitada originalmente. + Considere los siguientes ejemplos:

+ +
# En httpd.conf
+RewriteRule "^/images/(.+)\.jpg" "/images/$1.png"
+
+# En .htaccess en el directorio raíz
+RewriteRule "^images/(.+)\.jpg" "images/$1.png"
+
+# En .htaccess en images/
+RewriteRule "^(.+)\.jpg" "$1.png"
+ + +

En un .htaccess en cualquier directorio del DocumentRoot, la + barra ("/") inicial se elimina del valor facilitado a RewriteRule, y en el subdirectorio + images, se elimina /images/ también de este valor. + Así, su expresión regular necesita omitir también esa parte.

+ +

Consulte la documentación de mod_rewrite para + más detalles al usar mod_rewrite.

+ +
top
+
+

Ejemplo de CGI

+ +

Finalmente, puede que quiera usar un fichero .htaccess para + permitir la ejecución de programas CGI en un directorio en particular. Esto + se puede implementar con la siguiente configuración:

+ + 
Options +ExecCGI
+AddHandler cgi-script "cgi" "pl"
+ + +

Alternativamente, si quiere considerar como programas CGI todos los + ficheros de un directorio concreto, esto se puede conseguir con la siguiente + configuración:

+ + 
Options +ExecCGI
+SetHandler cgi-script
+ + +

Tenga en cuenta que AllowOverride Options y + AllowOverride FileInfo deben estar ambas activadas para que + estas directivas tengan efecto.

+ +

Por favor vea el tutorial CGI para mayor detalle + sobre programación y configuración de CGI.

+ +
top
+
+

Resolución de problemas

+ +

Cuando pone directivas en un fichero .htaccess y no obtiene + el efecto deseado hay una serie de cosas que pueden haber ido mal.

+ +

El problema más común es que AllowOverride + no está configurada para que sus directivas puedan surtir + efecto. Asegúrese de que no tiene AllowOverride None + configurado para el directorio en cuestión. Una buena forma de probar esto + es poner "basura" en su fichero .htaccess y recargar la página. + Si no se genera un error en el servidor, casi seguro que tiene configurado + AllowOverride None.

+ +

Si, por otro lado, obtiene errores de servidor al intentar acceder a + documentos, compruebe el log de errores de httpd. Seguramente le indiquen + que la directiva en uso en su fichero .htaccess no está + permitida.

+ +

+ [Fri Sep 17 18:43:16 2010] [alert] [client 192.168.200.51] /var/www/html/.htaccess: DirectoryIndex not allowed here +

+ +

Esto indicará que o bien ha usado una directiva que no se permite nunca + en ficheros .htaccess, o que simplementa no tiene + AllowOverride configurado + a un nivel suficiente para la directiva que ha usado. Consulte la + documentación para esa directiva en particular para determinar cual es el + caso.

+ +

Alternativamente, puede que le indique que hay un error de sintaxis en + el uso de la propia directiva.

+ +

+ [Sat Aug 09 16:22:34 2008] [alert] [client 192.168.200.51] /var/www/html/.htaccess: RewriteCond: bad flag delimiters +

+ +

En este caso, el mensaje de error debería ser específico para el error de + sintaxis concreto que ha cometido.

+ +
+
+

Idiomas disponibles:  en  | + es  | + fr  | + ja  | + ko  | + pt-br 

+
top

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/htaccess.html.fr.utf8 b/docs/manual/howto/htaccess.html.fr.utf8 new file mode 100644 index 0000000..2b71c5b --- /dev/null +++ b/docs/manual/howto/htaccess.html.fr.utf8 @@ -0,0 +1,512 @@ + + + + + +Tutoriel du serveur HTTP Apache : fichiers .htaccess - Serveur HTTP Apache Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.4

+
+
<-
+

Tutoriel du serveur HTTP Apache : fichiers .htaccess

+
+

Langues Disponibles:  en  | + es  | + fr  | + ja  | + ko  | + pt-br 

+
+ +

Les fichiers .htaccess fournissent une méthode pour +modifier la configuration du serveur au niveau de chaque répertoire.

+
+ +
top
+
+

Fichiers .htaccess

+ +
Modules ApparentésDirectives Apparentées
+
Les fichiers .htaccess ne doivent être utilisés + que si vous n'avez pas accès au fichier de configuration du serveur + principal. L'utilisation des fichiers .htaccess + ralentit le fonctionnement de votre serveur HTTP Apache. Il est toujours + préférable de définir les directives que vous pouvez inclure dans un + fichier .htaccess dans une section Directory, car elles produiront le + même effet avec de meilleures performances.
+
top
+
+

Que sont ce fichiers, comment les utiliser ?

+ + +

Les fichiers .htaccess (ou "fichiers de + configuration distribués") fournissent une méthode pour modifier la + configuration du serveur au niveau d'un répertoire. Un fichier, + contenant une ou plusieurs directives de configuration, est placé + dans un répertoire de documents particulier, et ses directives + s'appliquent à ce répertoire et à tous ses sous-répertoires.

+ +

Note :

+

Si vous voulez donner un autre nom à votre fichier + .htaccess, vous pouvez le faire en utilisant la + directive AccessFileName. Par + exemple, si vous préférez nommer votre fichier + .config, vous pouvez mettre ceci dans le fichier de + configuration de votre serveur :

+ + 
AccessFileName ".config"
+ +
+ +

En général, les fichiers .htaccess utilisent la même + syntaxe que les fichiers de + configuration principaux. Ce que vous pouvez mettre dans ces + fichier est déterminé par la directive AllowOverride. Cette directive spécifie, + sous forme de catégories, quelles directives seront traitées si + elles se trouvent dans un fichier .htaccess. Si une + directive est permise dans un fichier .htaccess file, + la documentation de cette directive contiendra une section Override, + spécifiant quelle valeur doit prendre AllowOverride pour que cette directive + soit traitée.

+ +

Par exemple, si vous regardez la documentation de la directive + AddDefaultCharset, vous verrez + que cette dernière est permise dans les fichiers + .htaccess (Voir la ligne de contexte dans le résumé de + la directive). La ligne Override indique + FileInfo. Vous devez donc avoir au moins + AllowOverride FileInfo pour que cette directive soit + traitée dans les fichiers .htaccess.

+ +

Exemple :

+ + + + + + + + + +
Contexte :configuration du serveur, serveur virtuel, directory, .htaccess
Override:FileInfo
+ +

Si vous n'êtes pas sûr qu'une directive particulière soit permise + dans un fichier .htaccess, lisez la documentation de + cette directive, et consultez la ligne de contexte pour + ".htaccess".

+
top
+
+

Quand doit-on (ne doit-on pas) utiliser + les fichiers .htaccess ?

+ +

En principe, vous ne devriez utiliser les fichiers + .htaccess que lorsque vous n'avez pas accès au fichier de + configuration du serveur principal. Par exemple, la fausse + idée + selon laquelle l'authentification de l'utilisateur devrait toujours + être faite dans les fichiers .htaccess est très + répandue. Il est aussi souvent avancé, ces dernières + années, que les directives de mod_rewrite doivent + être définies dans les fichiers .htaccess. Ceci est + tout simplement faux. Vous pouvez configurer + l'authentification des utilisateurs au niveau de la configuration du + serveur principal, et c'est en fait cette méthode qui doit être + privilégiée. De même, les directives de + mod_rewrite fonctionneront mieux, à de nombreux égards, + dans le contexte du serveur principal.

+ +

Les fichiers .htaccess ne devraient être utilisés + que dans le cas où les fournisseurs de contenu ont besoin de + modifier la configuration du serveur au niveau d'un répertoire, mais + ne possèdent pas l'accès root sur le système du serveur. Si + l'administrateur du serveur ne souhaite pas effectuer des + modifications de configuration incessantes, il peut être intéressant + de permettre aux utilisateurs isolés d'effectuer eux-mêmes ces + modifications par le biais de fichiers .htaccess. Ceci + est particulièrement vrai dans le cas où le fournisseur d'accès à + Internet héberge de nombreux sites d'utilisateurs sur un seul + serveur, et souhaite que ces utilisateurs puissent modifier + eux-mêmes leurs configurations.

+ +

Cependant et d'une manière générale, il vaut mieux éviter + d'utiliser les fichiers .htaccess. Tout élément de + configuration que vous pourriez vouloir mettre dans un fichier + .htaccess, peut aussi être mis, et avec la même + efficacité, dans une section <Directory> du fichier de configuration de + votre serveur principal.

+ +

Il y a deux raisons principales d'éviter l'utilisation des + fichiers .htaccess.

+ +

La première est liée aux performances. Lorsque la directive + AllowOverride est définie de + façon à autoriser l'utilisation des fichiers .htaccess, + httpd va rechercher leur présence dans chaque répertoire. Ainsi, + permettre l'utilisation des fichiers .htaccess est déjà + en soi une cause de dégradation des performances, que vous utilisiez + effectivement ces fichiers ou non ! De plus, le fichier + .htaccess est chargé en mémoire chaque fois qu'un + document fait l'objet d'une requête.

+ +

Notez aussi que httpd doit rechercher les fichiers + .htaccess dans tous les répertoires de niveau + supérieur, afin de rassembler toutes les directives qui s'appliquent + au répertoire courant (Voir la section comment sont + appliquées les directives). Ainsi, si un fichier fait l'objet + d'une requête à partir d'un répertoire + /www/htdocs/exemple, httpd doit rechercher les + fichiers suivants :

+ +

+ /.htaccess
+ /www/.htaccess
+ /www/htdocs/.htaccess
+ /www/htdocs/exemple/.htaccess +

+ +

En conséquence, chaque accès à un fichier de ce répertoire + nécessite 4 accès au système de fichiers supplémentaires pour + rechercher des fichiers .htaccess, même si + aucun de ces fichiers n'est présent. Notez que cet exemple ne peut + se produire que si les fichiers .htaccess ont été + autorisés pour le répertoire /, ce qui est rarement le + cas.

+ +

La seconde raison d'éviter l'utilisation des fichiers + .htaccess est liée à la sécurité. Si vous permettez aux + utilisateurs de modifier la configuration du serveur, il peut en + résulter des conséquences sur lesquelles vous n'aurez aucun + contrôle. Réfléchissez bien avant de donner ce privilège à vos + utilisateurs. Notez aussi que ne pas donner aux utilisateurs les + privilèges dont ils ont besoin va entraîner une augmentation des + demandes de support technique. Assurez-vous d'avoir informé + clairement vos utilisateurs du niveau de privilèges que vous leur + avez attribué. Indiquer exactement comment vous avez défini la + directive AllowOverride et + diriger les utilisateurs vers la documentation correspondante vous + évitera bien des confusions ultérieures.

+ +

Notez que mettre un fichier .htaccess contenant une + directive dans un répertoire /www/htdocs/exemple + revient exactement au même que mettre la même directive dans une + section Directory <Directory "/www/htdocs/exemple"> + du fichier de configuration de votre serveur principal :

+ +

Fichier .htaccess dans + /www/htdocs/exemple :

+ +

Contenu du fichier .htaccess dans + /www/htdocs/exemple

AddType text/example ".exm"
+
+ +

Section de votre fichier + httpd.conf

<Directory "/www/htdocs/example">
+    AddType text/example .exm
+</Directory>
+
+ +

Cependant, la perte de performances sera moindre si vous + définissez cette directive dans la configuration de + votre serveur principal, car cette dernière ne sera chargée qu'une + seule fois au moment du démarrage du serveur, alors qu'elle le sera + à chaque accès dans le cas d'un fichier .htaccess.

+ +

L'utilisation des fichiers .htaccess peut être + entièrement désactivée en définissant la directive AllowOverride à none :

+ + 
AllowOverride None
+ +
top
+
+

Comment sont appliquées les directives ?

+ +

Les directives de configuration situées dans un fichier + .htaccess s'appliquent au répertoire dans lequel ce + fichier .htaccess se trouve, ainsi qu'à tous ses + sous-répertoires. Cependant, il est important de garder à l'esprit + qu'il peut y avoir des fichiers .htaccess dans les + répertoires de niveau supérieur. Les directives sont appliquées + selon l'ordre dans lequel elles sont rencontrées. Ainsi, les + directives d'un fichier .htaccess situé dans un + répertoire particulier peuvent écraser les directives se trouvant + dans des fichiers .htaccess situés à un niveau + supérieur dans l'arborescence des répertoires. Et ces dernières + peuvent elles-mêmes avoir écrasé des directives d'un fichier + .htaccess situé à un niveau encore plus haut, ou dans + le fichier de configuration du serveur principal.

+ +

Exemple :

+ +

Dans le répertoire /www/htdocs/exemple1 se trouve un + fichier .htaccess contenant ce qui suit :

+ + 
Options +ExecCGI
+ + +

Note : "AllowOverride Options" doit être présent + pour permettre l'utilisation de la directive "Options" dans les fichiers + .htaccess.

+ +

Dans le répertoire /www/htdocs/exemple1/exemple2 se + trouve un fichier .htaccess contenant ce qui suit + :

+ + 
Options Includes
+ + +

Ainsi, à cause de ce second fichier .htaccess du + répertoire /www/htdocs/exemple1/exemple2, l'exécution + des CGI est interdite, car la dernière définition d'options + Options Includes écrase toute autre définition + d'options d'un fichier .htaccess situé dans un + répertoire de niveau supérieur.

+ +

Interactions entre les fichiers .htaccess + et les fichiers de configuration du serveur principal

+ +

Comme indiqué dans la documentation sur les Sections de configuration, les fichiers + .htaccess peuvent écraser les directives des sections + <Directory> pour + le répertoire correspondant, mais peuvent eux-mêmes être écrasés + par d'autres types de sections des fichiers de la + configuration principale. Cette possibilité peut s'avérer utile pour + forcer certaines configurations, même en cas de présence de l'option + libérale AllowOverride. Par + exemple, pour interdire l'exécution de scripts en autorisant la + définition de toute autre option dans les fichiers + .htaccess, vous pouvez utiliser :

+ + 
<Directory "/www/htdocs">
+    AllowOverride All
+</Directory>
+
+<Location "/">
+    Options +IncludesNoExec -ExecCGI
+</Location>
+ + +
Dans cet exemple, on considère que le chemin défini par la + directive DocumentRoot est + /www/htdocs.
+ + +
top
+
+

Exemple d'authentification

+ +

Si vous accédez directement à ce point du document pour apprendre + à effectuer une authentification, il est important de noter ceci. Il + existe une fausse idée selon laquelle il serait nécessaire + d'utiliser les fichiers .htaccess pour implémenter + l'authentification par mot de passe. Ceci est tout simplement faux. + Pour y parvenir, il est préférable de mettre les directives + d'authentification dans une section <Directory> du fichier de configuration de + votre serveur principal, et les fichiers .htaccess ne + devraient être utilisés que dans le cas où vous n'avez pas accès au + fichier de configuration du serveur principal. Voir ci-dessus pour savoir dans quels cas vous devez ou + ne devez pas utiliser les fichiers .htaccess.

+ +

Ceci étant dit, si vous pensez que vous devez quand-même utiliser + un fichier .htaccess, vous pouvez utiliser la + configuration suivante :

+ +

Contenu du fichier .htaccess :

+ + 
AuthType Basic
+AuthName "Password Required"
+AuthUserFile "/www/passwords/password.file"
+AuthGroupFile "/www/passwords/group.file"
+Require group admins
+ + +

Notez que AllowOverride AuthConfig doit être présent + pour que ces directives produisent leur effet.

+ +

Vous pouvez vous référer au tutoriel sur + l'authentification pour une description plus détaillée de + l'authentification et de l'autorisation.

+
top
+
+

Exemple d'Inclusion Côté Serveur (Server Side +Includes - SSI)

+ +

Les fichiers .htaccess sont aussi couramment + utilisés pour activer les SSI pour un répertoire particulier. Pour y + parvenir, on utilise les directives de configuration suivantes, + placées dans un fichier .htaccess enregistré dans le + répertoire considéré :

+ + 
Options +Includes
+AddType text/html shtml
+AddHandler server-parsed shtml
+ + +

Notez que AllowOverride Options et AllowOverride + FileInfo doivent être tous les deux présents pour que ces + directives puissent produire leur effet.

+ +

Vous pouvez vous référer au tutoriel SSI + pour une description plus détaillée des SSI.

+
top
+
+

Les règles de réécriture dans les fichiers .htaccess

+

Sivous utilisez des directives RewriteRule dans un fichier +.htaccess, gardez à l'esprit que les choses sont légèrement +différentes dans un contexte de répertoire. En particulier, les règles +sont relatives au répertoire courant, et non à l'URI original. Considérez +les exemples suivants :

+ +
# Dans httpd.conf
+RewriteRule "^/images/(.+)\.jpg" "/images/$1.png"
+
+# Dans un fichier .htaccess situé dans le répertoire racine de vos
+# documents
+RewriteRule "^images/(.+)\.jpg" "images/$1.png"
+
+# Dans un fichier .htaccess situé dans le répertoire images/
+RewriteRule "^(.+)\.jpg" "$1.png"
+ + +

On voit que si le fichier .htaccess se situe à la racine +de vos documents, le slash de tête est supprimé de la valeur de +remplacement spécifiée pour la règle RewriteRule, et que si le fichier +.htaccess se situe dans le répertoire images, +la chaîne /images/ disparaît de cette même valeur de +remplacement. Il doit donc en être de même dans votre expression +rationnelle.

+ +

Veuillez vous référer à cette documentation +pour une étude détaillée de l'utilisation du module +mod_rewrite.

+ +
top
+
+

Exemple de CGI

+ +

En fin de compte, vous avez décidé d'utiliser un fichier + .htaccess pour permettre l'exécution des programmes CGI + dans un répertoire particulier. Pour y parvenir, vous pouvez + utiliser la configuration suivante :

+ + 
Options +ExecCGI
+AddHandler cgi-script cgi pl
+ + +

Alternativement, si vous souhaitez que tous les fichiers d'un + répertoire donné soient considérés comme des programmes CGI, vous + pouvez utiliser la configuration suivante :

+ + 
Options +ExecCGI
+SetHandler cgi-script
+ + +

Notez que AllowOverride Options et AllowOverride + FileInfo doivent être tous les deux présents pour que ces + directives puissent produire leur effet.

+ +

Vous pouvez vous référer au tutoriel CGI + pour une description plus détaillée de la configuration et de la + proprammation CGI.

+ +
top
+
+

Résolution des problèmes

+ +

De nombreuses raisons peuvent être à l'origine du fait que + les directives que vous avez mises dans un fichier + .htaccess ne produisent pas l'effet désiré.

+ +

Le plus souvent, le problème vient du fait que la définition de + la directive AllowOverride + ne permet pas l'activation des directives de votre fichier + .htaccess. Vérifiez si une directive + AllowOverride None n'affecte pas le répertoire où se + trouve votre fichier. Un bon test consiste à mettre des directives + dont la syntaxe est erronée dans votre ficher .htaccess + et de recharger la page. Si aucune erreur n'est générée par le + serveur, il est pratiquement certain qu'une directive + AllowOverride None affecte votre répertoire.

+ +

Par contre, si vous obtenez des erreurs de serveur lorsque vous + tentez d'accéder à des documents, consultez votre journal des + erreurs de httpd. Il vous indiquera probablement que la directive + utilisée dans votre fichier .htaccess n'est pas + permise.

+ +

+ [Fri Sep 17 18:43:16 2010] [alert] [client 192.168.200.51] /var/www/html/.htaccess: DirectoryIndex not allowed here +

+

Cela signifie soit que vous utilisez une directive qui n'est + jamais permise dans les fichiers .htaccess, soit + que vous n'avez tout simplement pas défini la directive + AllowOverride à un niveau + suffisant pour la directive que vous utilisez. Consultez la + documentation de cette directive pour déterminer quel cas + s'applique.

+ +

Le journal des erreurs peut aussi vous signaler une erreur de + syntaxe dans l'usage de la directive elle-même.

+ +

+ [Sat Aug 09 16:22:34 2008] [alert] [client 192.168.200.51] /var/www/html/.htaccess: RewriteCond: bad flag delimiters +

+ +

Dans ce cas, le message d'erreur sera spécifique à l'erreur + de syntaxe que vous avez commise.

+
+
+

Langues Disponibles:  en  | + es  | + fr  | + ja  | + ko  | + pt-br 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/htaccess.html.ja.utf8 b/docs/manual/howto/htaccess.html.ja.utf8 new file mode 100644 index 0000000..6d42801 --- /dev/null +++ b/docs/manual/howto/htaccess.html.ja.utf8 @@ -0,0 +1,417 @@ + + + + + +Apache チュートリアル: .htaccess ファイル - Apache HTTP サーバ バージョン 2.4 + + + + + + +
+

モジュール | ディレクティブ | FAQ | 用語 | サイトマップ

+

Apache HTTP サーバ バージョン 2.4

+
+
<-
+

Apache チュートリアル: .htaccess ファイル

+
+

翻訳済み言語:  en  | + es  | + fr  | + ja  | + ko  | + pt-br 

+
+
この日本語訳はすでに古くなっている + 可能性があります。 + 最近更新された内容を見るには英語版をご覧下さい。 +
+ +

.htaccess ファイルはディレクトリ毎に設定を変更する方法を +提供します。

+
+ +
top
+
+

.htaccess ファイル

+
関連モジュール関連ディレクティブ
+
top
+
+

.htaccess ファイルとは何か/その使い方

+ + +

.htaccess ファイル (「分散設定ファイル」) は + ディレクトリ毎に設定を変更する方法を提供します。ディレクティブの + 書かれたファイルをディレクトリに置くことで、そのディレクトリとその + サブディレクトリすべてにディレクティブを適用させることができます。

+ +

注:

+

.htaccess ファイルを別の名前にしたい場合は、 + AccessFileName ディレクティブを + 使って変更することができます。例えば、そのファイルを .config + という名前にしたい場合は、以下の設定をサーバ設定ファイルに入れることが + できます:

+ +

+ AccessFileName .config +

+
+ +

一般に、.htaccess ファイルの構文は + 主設定ファイル + と同じです。これらのファイルに書くことのできるディレクティブは AllowOverride ディレクティブにより決まります。 + このディレクティブは、.htaccess ファイルに + 書かれたディレクティブの中で、、 + どのディレクティブが適用されるかをカテゴリー単位で指定します。 + .htaccess に書くことのできるディレクティブであれば、 + 説明文書には「上書き」という項目があり、.htaccess に書くことができるように + なるための AllowOverride の値が指定されています。

+ +

例えば、AddDefaultCharset ディレクティブの説明を + 見ると、.htaccess ファイルでの使用が許可されていることが + わかります。 (ディレクティブの概要の所にある「コンテキスト」と書かれている + 行を見てください。) 上書きと書かれている行には + FileInfo とあります。ですから、.htaccess 中の + このディレクティブが有効になるためには、少なくとも + AllowOverride FileInfo が設定されている必要があります。

+ +

例:

+ + + + + + + + + +
コンテキスト:サーバ設定ファイル,バーチャルホスト,ディレクトリ,.htaccess
上書き:FileInfo
+ +

あるディレクティブを .htaccess ファイルに書くことができるか + どうかわからないときは、そのディレクティブの説明を探して、".htaccess" + のための「コンテキスト」の行を調べてください。

+
top
+
+

いつ .htaccess ファイルを使う(使わない)か。

+ +

一般的に、サーバの主設定ファイルにアクセスできない場合を除いて、 + .htaccess ファイルの使用は極力避けてください。 + 世の中には、例えば、ユーザ認証は常に .htaccess ファイルで + 行なわなければならない、という誤解が広まっていますが、まったくそんなことは + ありません。ユーザ認証の設定はサーバ主設定ファイルに書くことができ、 + 実際、その方がより良い設定方法です。

+ +

.htaccess ファイルはコンテンツ提供者がディレクトリ毎の + 設定を行ないたいけれど、サーバシステムの root アクセス権限を持っていない + という場合にのみ使うべきものです。サーバ管理者が頻繁に設定変更を行ないたくは + ない、というときには個々のユーザが .htaccess ファイルを使って + 自分で設定の変更を行なうことを許可した方が良いときもあるでしょう。 + これは特に、ISP が複数のユーザのサイトを一つのマシンでホストしていて、 + 各ユーザが設定の変更をできるようにしたいようなときにあてはまります。

+ +

しかし、普通は可能であれば .htaccess ファイルの使用は + 避けてください。.htaccess ファイルに書こうと考えるような + すべての設定は、サーバの主設定ファイルの <Directory> セクションで同じように行なうことが + できます。

+ +

.htaccess ファイルの使用を避ける理由は主に二つあります。

+ +

一つ目はサーバの性能の問題です。AllowOverride ディレクティブが + .htaccess ファイルの設定を許可している場合は、Apache は + 各ディレクトリで .htaccess ファイルを探します。 + ですから、.htaccess ファイルを許可すると、実際に使用しているか + どうかに関わらず、性能の低下を招くことになります! また、.htaccess + ファイルは文書がリクエストされる度に読み込まれます。

+ +

さらに、Apache は適用すべきディレクティブを集めるために、すべての + 上位のディレクトリの .htaccess ファイルを探す必要があることにも + 注意してください。(ディレクティブが適用される方法を + 参照してください。)ですから、/www/htdocs/example にある + ファイルがリクエストされたときは、Apache は以下のファイルを調べます。

+ +

+ /.htaccess
+ /www/.htaccess
+ /www/htdocs/.htaccess
+ /www/htdocs/example/.htaccess +

+ +

ですから、そのディレクトリのそれぞれのファイルへのアクセスに対して、 + 上の例のファイルがまったく存在しないときでも、追加のファイルシステムの + アクセスが行なわれることになります。(これは、.htaccess が + / に対して有効になっているときの場合で、普通はそうなって + いないことに注意してください。)

+ +

二つ目はセキュリティです。ユーザにサーバの設定を変更することを + 許可することになりますので、あなた自身が管理できない変更をされる + 恐れがあります。ユーザにこの特権を与えるのが良いのかどうか、十分 + 検討してください。また、ユーザに与える権限が必要なものよりも少なすぎると、 + 余分な技術サポート報告を受け取るようになる可能性が高いことにも + 注意してください。確実に、ユーザにどの程度の権限を与えたか明確に告げるように + してください。AllowOverride に + 何を設定したかということと、関連する文書を示すことで、 + 後々の混乱をぐっと減らすことが + できます。

+ +

ところで、ディレクティブの書かれた .htaccess を + /www/htdocs/example に置くことと、同じディレクティブを + 主サーバ設定の Directory セクション + <Directory /www/htdocs/example> に書くことは + 完全に等価です:

+ +

/www/htdocs/example の .htaccess ファイル:

+ +

/www/htdocs/example の .htaccess ファイルの + 内容

+ AddType text/example .exm +

+ +

httpd.conf のセクション + file

+ <Directory /www/htdocs/example>
+ + AddType text/example .exm
+ + </Directory> +

+ +

しかし、この設定はサーバ設定ファイルに書いた方がパフォーマンスの + 低下が少なくなります。ファイルがリクエストされる度に + 読み込まれる代わりに、Apache の起動時に 1 回だけ読み込めば + よくなるからです。

+ +

AllowOverride ディレクティブの + 値を none に設定することで .htaccess ファイル + の使用を完全に無効にすることができます。

+ +

+ AllowOverride None +

+
top
+
+

ディレクティブの適用のされ方

+ +

.htaccess ファイルの設定ディレクティブは .htaccess + ファイルの存在するディレクトリと、そのサブディレクトリすべてに適用されます。 + しかし、上の階層のディレクトリにも .htaccess ファイルが + 存在するかもしれないことを覚えておくことは大切です。ディレクティブは現れる + 順番に適用されます。ですから、あるディレクトリの .htaccess は + ディレクトリツリーのより上の階層の .htaccess ファイルの + 設定を上書きするかもしれません。そして、その .htaccess も + より上の階層で書かれたディレクティブを上書きしたり、主サーバ設定ファイル + そのものの設定を上書きしたりしているかもしれません。

+ +

例:

+ +

ディレクトリ /www/htdocs/example1 に以下の内容の + .htaccess ファイルがあります:

+ +

+ Options +ExecCGI +

+ +

(注: .htaccess + ファイルで "Options" ディレクティブが有効になるためには、 + "AllowOverride Options" を有効にする必要があります。)

+ +

ディレクトリ /www/htdocs/example1/example2 には + 以下のような .htaccess ファイルがあります:

+ +

+ Options Includes +

+ +

二つめの .htaccess により、ディレクトリ + /www/htdocs/example1/example2 では CGI の実行は + 許可されません。これは、Options Includes のみが + 効力を持ち、それがすべての以前の設定を上書きするからです。

+ +

メイン設定ファイルに対する + .htaccess のマージ

+ +

As discussed in the documentation on Configuration Sections, + .htaccess files can override the <Directory> sections for + the corresponding directory, but will be overriden by other types + of configuration sections from the main configuration files. This + fact can be used to enforce certain configurations, even in the + presence of a liberal AllowOverride setting. For example, to + prevent script execution while allowing anything else to be set in + .htaccess you can use:

+

セクションの設定 + に記載されているように、.htaccess ファイルを使って + <Directory> + セクションの設定をディレクトリ毎に上書きできますが、 + メイン設定ファイル中にある、他の種類の設定セクションによって + さらに上書きされることもあります。 + この特徴を使って、 + AllowOverride + で自由度の高い設定があったとしても、ある特定の設定が確実に + 反映されるようにできます。例えば、CGI スクリプトの実行は + 不許可に、かつ、.htaccess でその他の項目は + 設定できるように、という場合は次のようにできます :

+ +

+<Directory />
+ +Allowoverride All
+ +</Directory>
+
+<Location />
+ +Options +IncludesNoExec -ExecCGI
+ +</Location> +

+ + +
top
+
+

認証の例

+ +

もし認証の方法を知るためにこの部分に直接来たのであれば、次のことを + 知っておくことが重要です。よくある誤解に、パスワード認証を行なうためには + .htaccess ファイルを使う必要がある、というものがあります。 + これは正しくありません。主サーバ設定ファイルの <Directory> セクションに + 認証用のディレクティブを書く方が推奨される方法で、.htaccess + ファイルは主サーバ設定ファイルを変更できないときにのみ使用すべきです。 + いつ .htaccess ファイルを使うべきで、いつ使うべきではないかに + ついては 上を参照してください。

+ +

以上のことをふまえた上で、もし .htaccess の使用が + まだ必要だと思う場合は、次のようなものが望みのことをしてくれるかも + しれません。

+ +

.htaccess ファイルの内容:

+ +

+ AuthType Basic
+ AuthName "Password Required"
+ AuthUserFile /www/passwords/password.file
+ AuthGroupFile /www/passwords/group.file
+ Require Group admins +

+ +

これらのディレクティブが有効になるためには、 + AllowOverride AuthConfig が有効でなくてはならないことに + 注意してください。

+ +

認証と承認については 認証チュートリアルを + 参照してください。

+
top
+
+

SSI の例

+ +

もう一つの .htaccess ファイルのよくある利用法は + 特定のディレクトリで SSI を有効にすることです。これは、望みのディレクトリの + .htaccess ファイルに以下の設定ディレクティブを書くことで + 達成できます:

+ +

+ Options +Includes
+ AddType text/html shtml
+ AddHandler server-parsed shtml +

+ +

これらのディレクティブが有効になるためには、 + AllowOverride Options と AllowOverride + FileInfo が有効になっている必要があることに注意してください。

+ +

よりまとまった SSI の説明は SSI チュートリアルを + 参照してください。

+
top
+
+

CGI の例

+ +

最後に、特定のディレクトリで CGI プログラムの実行を許可したいことが + あるでしょう。これは以下の設定で行なうことができます:

+ +

+ Options +ExecCGI
+ AddHandler cgi-script cgi pl +

+ +

もしくは、あるディレクトリのすべてのファイルが CGI プログラムと + みなされるようにしたいなら、以下の設定で実現することができます:

+ +

+ Options +ExecCGI
+ SetHandler cgi-script +

+ +

これらのディレクティブが有効になるためには、 + AllowOverride Options と AllowOverride + FileInfo が有効である必要があることに注意してください。

+ +

CGI プログラムと設定のよりまとまった説明は CGI チュートリアルを参照してください。

+ +
top
+
+

問題解決

+ +

設定ディレクティブを .htaccess ファイルに書いたけれども、 + 期待した効果が得られないときには、いくつかの原因が考えられます。

+ +

一番よくあることは、設定ディレクティブが考慮されるようには + AllowOverride が設定されていない + というものです。該当のファイルのスコープに AllowOverride None + が設定されていないことを確認してください。これを調べるための良い方法は、 + .htaccess ファイルにごみを書いて、リロードすることです。 + サーバのエラーが生成されないときは、ほぼ確実に AllowOverride + None が設定されている状態になっています。

+ +

そうではなく、文書をアクセスしようとしたときにエラーが発生している + ときは、Apache のエラーログを調べてください。.htaccess ファイルで + 使用されたディレクティブが許可されていない、ということを知らせている + 可能性が高いです。または、構文の間違いがあることを述べているかもしれません。 + その場合にはまずそれを修正する必要があります。

+ +
+
+

翻訳済み言語:  en  | + es  | + fr  | + ja  | + ko  | + pt-br 

+
top

コメント

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/htaccess.html.ko.euc-kr b/docs/manual/howto/htaccess.html.ko.euc-kr new file mode 100644 index 0000000..69d856f --- /dev/null +++ b/docs/manual/howto/htaccess.html.ko.euc-kr @@ -0,0 +1,363 @@ + + + + + +ġ 丮: .htaccess - Apache HTTP Server Version 2.4 + + + + + + +
+

| þ | FAQ | | Ʈ

+

Apache HTTP Server Version 2.4

+
+
<-
+

ġ 丮: .htaccess

+
+

:  en  | + es  | + fr  | + ja  | + ko  | + pt-br 

+
+
ֽ ƴմϴ. + ֱٿ ϼ.
+ +

.htaccess Ͽ 丮 + ִ.

+
+ +
top
+
+

.htaccess

+
õ õ þ
+
top
+
+

̸/ ϴ°

+ + +

.htaccess (Ȥ "л ") + ϸ 丮 ִ. þ + ִ Ư 丮 θ, 丮 + 丮 þ Ѵ.

+ +

:

+

.htaccess ϸ ٸ ϰ ʹٸ, + AccessFileName þ + Ͽ ִ. , .config + ϸ Ϸ Ͽ ߰Ѵ.

+ +

+ AccessFileName .config +

+
+ +

Ϲ .htaccess ּ + . AllowOverride + þ Ͽ ִ Ѵ. þ + .htaccess Ͽ ϴ þ з Ѵ. + þ .htaccess Ͽ ִٸ, + ش þ Override ׸ þ ϱ + AllowOverride + ˷ش.

+ +

, AddDefaultCharset + þ þ .htaccess Ͽ + ִ. (þ ࿡ ׸ .) + Override + ٿ FileInfo ִ. ׷ þ + .htaccess Ͽ ϱؼ ּ + AllowOverride FileInfo ʿϴ.

+ +

:

+ + + + + + + + + +
:ּ, ȣƮ, directory, .htaccess
Override:FileInfo
+ +

Ư þ .htaccess Ͽ + ִ ñϸ þ ׸ ".htaccess" + ִ ȮѴ.

+
top
+
+

.htaccess ϳ + (Ȥ ʳ)

+ +

Ϲ ּϿ 찡 ƴ϶ + .htaccess ϸ ȵȴ. , + ׻ .htaccess Ͽ ־ + Ѵٴ ߸ ˷ ش. ̴ ƴϴ. ּ + ְ, ̷ Ѵ.

+ +

.htaccess ڰ 丮 + ٸϰ ýۿ root + 쿡 Ѵ. ڰ ϰ + Ϲ ڰ .htaccess + ϵ ϴ ٶϴ. , + ǻͿ Ʈ ϴ ISP ڰ + ڽ ϰ 찡 ׷ϴ.

+ +

׷ Ϲ .htaccess + ؾ Ѵ. .htaccess Ͽ ϴ þ + ּ <Directory> ǰ ȿ + ִ.

+ +

ΰ ū .htaccess + ؾ Ѵ.

+ +

ù° ̴. AllowOverride .htaccess + ϵ ϸ, ġ 丮 + .htaccess ã´. ׷ + .htaccess ϸ + ʴ 쿡 ! , .htaccess + ûҶ оδ.

+ +

Դٰ ؾ ϴ ü þ ġ + 丮 .htaccess ã´. + ( þ ϳ .) + ׷ /www/htdocs/example 丮 ִ + ûϸ, ġ ϵ ãƾ Ѵ.

+ +

+ /.htaccess
+ /www/.htaccess
+ /www/htdocs/.htaccess
+ /www/htdocs/example/.htaccess +

+ +

׷ 丮 ִ +  Ͻý 4 ؾ Ѵ. + (/ .htaccess + 츦 Ѵ. ʴ´.)

+ +

ι° ̴. ڿ + ָ ȭ Ͼ ִ. ڿ + ̷ ϶. , ڰ ϴ ͺ + ָ û ´. ڿ + Ȯ ˷. ڿ AllowOverride  Ͽ + Ȯ ˸ ϸ ȥ + ִ.

+ +

þ /www/htdocs/example 丮 + .htaccess δ Ͱ ּ + <Directory /www/htdocs/example> Directory + δ .

+ +

/www/htdocs/example ִ + .htaccess :

+ +

/www/htdocs/example ִ + .htaccess

+ AddType text/example .exm +

+ +

httpd.conf Ͽ ִ

+ <Directory /www/htdocs/example>
+ + AddType text/example .exm
+ + </Directory> +

+ +

׷ û ʰ ġ + Ҷ ѹ б⶧ Ͽ + ϸ .

+ +

AllowOverride þ + none ϸ .htaccess + .

+ +

+ AllowOverride None +

+
top
+
+

 þ ϳ

+ +

.htaccess ߰ 丮 丮 + 丮 .htaccess Ͽ ִ + þ Ѵ. ׷ 丮 .htaccess + ؾ Ѵ. ߰ þ Ѵ. Ư + 丮 ִ .htaccess 丮 + ִ .htaccess þ ȿ + ְ, 丮 ִ þ 丮 Ȥ + ּϿ ִ þ ȿ ִ.

+ +

:

+ +

/www/htdocs/example1 丮 + .htaccess ִ.

+ +

+ Options +ExecCGI +

+ +

(: .htaccess Ͽ "Options" þ Ϸ + "AllowOverride Options" ʿϴ.)

+ +

/www/htdocs/example1/example2 丮 + .htaccess ִ.

+ +

+ Options Includes +

+ +

ι° .htaccess + Options Includes ȿ + ⶧ /www/htdocs/example1/example2 + 丮 CGI ʴ´.

+
top
+
+

+ +

˱ ٷ ̰ д´ٸ + ִ. ȣ Ϸ .htaccess + ʿϴٴ ذ θ ִ. ̴ ƴϴ. + ּ <Directory> ǿ þ + δ ϴ ̰, ּ + 쿡 .htaccess ؾ + Ѵ. .htaccess ؾ ϴ + ƾ ϴ + Ͽ.

+ +

տ .htaccess + ʿϴٰ Ǹ Ʒ ̴.

+ +

.htaccess .

+ +

+ AuthType Basic
+ AuthName "Password Required"
+ AuthUserFile /www/passwords/password.file
+ AuthGroupFile /www/passwords/group.file
+ Require Group admins +

+ +

þ ϱؼ + AllowOverride AuthConfig þ ʿ + ϶.

+ +

Ѻο ڼ + 丮 ٶ.

+
top
+
+

Server Side Includes

+ +

Ǵٸ Ϲ .htaccess 뵵 + Ư 丮 Server Side Includes ϰ + ̴. ϴ 丮 .htaccess Ͽ + þ ϸ ȴ.

+ +

+ Options +Includes
+ AddType text/html shtml
+ AddHandler server-parsed shtml +

+ +

þ Ϸ AllowOverride Options + AllowOverride FileInfo ʿ ϶.

+ +

server-side includes ڼ SSI 丮 ٶ.

+
top
+
+

CGI

+ +

.htaccess Ͽ Ư + 丮 CGI α׷ ϰ ʹٸ, + Ѵ.

+ +

+ Options +ExecCGI
+ AddHandler cgi-script cgi pl +

+ +

Ȥ 丮 ִ CGI α׷ + óϰ ʹٸ ϴ.

+ +

+ Options +ExecCGI
+ SetHandler cgi-script +

+ +

þ Ϸ AllowOverride Options + AllowOverride FileInfo ʿ ϶.

+ +

CGI α׷ְ ڼ CGI 丮 ٶ.

+ +
top
+
+

ذ

+ +

.htaccess Ͽ þ ϴ + ʴ ִ.

+ +

Ϲ þ ϰ AllowOverride + . Ǵ AllowOverride None + ȮѴ. .htaccess ƹԳ + ٽ Ͽ ˻غ ִ. + Ȯ + AllowOverride None .

+ +

ݴ Ҷ ߻ϸ ġ α׸ + . Ƹ .htaccess Ͽ ִ þ + ʴ´ٰ ̴. ƴϰ ִٸ + ģ.

+ +
+
+

:  en  | + es  | + fr  | + ja  | + ko  | + pt-br 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/htaccess.html.pt-br b/docs/manual/howto/htaccess.html.pt-br new file mode 100644 index 0000000..1468957 --- /dev/null +++ b/docs/manual/howto/htaccess.html.pt-br @@ -0,0 +1,407 @@ + + + + + +Tutorial do Apache: arquivos .htaccess - Servidor HTTP Apache Versão 2.4 + + + + + + +
+

Módulos | Diretrizes | FAQ | Glossário | Mapa do site

+

Servidor HTTP Apache Versão 2.4

+
+
<-
+

Tutorial do Apache: arquivos .htaccess

+
+

Línguas Disponíveis:  en  | + es  | + fr  | + ja  | + ko  | + pt-br 

+
+
Esta tradução pode estar desatualizada. + Confira a versão em Inglês para mudanças recentes.
+ +

Arquivos .htaccess oferecem um meio de fazer mudanças + nas configurações por-diretório.

+
+ +
top
+
+

Arquivos .htaccess

+
Módulos RelacionadosDiretrizes Relacionadas
+
top
+
+

O que eles são/Como usá-los

+ + +

Os arquivos .htaccess (ou "arquivos de + configuração distribuída") oferecem um meio de fazer mudanças nas + configurações por-diretório. Um arquivo, contendo uma ou mais + diretrizes de configurações, é colocado em um diretório + em particular, e as diretrizes se aplicam para aquele diretório e todos + os seu subdiretórios subseqüentes.

+ +

Nota:

+

Se você quiser renomear o seu arquivo .htaccess + para outro nome, você deve usar a diretriz AccessFileName. Por exemplo, se você + prefere que o arquivo se chame .config, então você + pode adicionar a seguinte linha ao seu arquivo de configuração + do servidor:

+ +

+ AccessFileName .config +

+
+ +

No geral, arquivos .htaccess usam a mesma sintaxe + que os arquivos de + configuração principal. O que você pode colocar nesses + arquivos é determinado pele diretriz AllowOverride. Essa diretriz especifica, + em categorias, quais diretrizes serão aceitas caso sejam + encontradas em um arquivo .htaccess. Se uma diretriz + for permitida em um arquivo .htaccess, a documentação + para essa diretriz irá conter uma seção Override, + especificando que valor precisa estar em AllowOverride para que esta diretriz + seja permitida.

+ +

Por exemplo, se você procurar na documentação pela diretriz + AddDefaultCharset, você + achará que ela é permitida nos arquivos .htaccess. + (Veja a linha Contexto no sumário das diretivas.) A + linha Override lê + FileInfo. Então, você deve ao menos ter + AllowOverride FileInfo para que essa diretriz seja + aceita nos arquivos .htaccess.

+ +

Exemplo:

+ + + + + + + + + +
Contexto:configuração do servidor, hospedeiros virtuais, diretório, .htaccess
Override:FileInfo
+ +

Se você estiver incerto se uma diretriz em particular é + aceita em um arquivo .htaccess, procure na + documentação por essa diretriz, e verifique a linha de + Contexto por ".htaccess".

top
+
+

Quando (não) usar arquivos .htaccess

+ +

No geral, você nunca deve usar arquivos .htaccess + a não ser que você não tenha acesso ao arquivo de configuração + principal do servidor. Existe, por exemplo, um erro de concepção + que dita que a autenticação de usuários sempre deve + ser feita usando os arquivos .htaccess. Esse + simplesmente não é o caso. Você pode usar as configurações de + autenticação de usuário no arquivo de configuração principal do + servidor, e isso é, de fato, a maneira mais adequada de se fazer + as coisas.

+ +

Arquivos .htaccess devem ser usados em casos onde + os provedores de conteúdo do site precisem fazer mudanças na + configuração do servidor por-diretório, mas não tem + acesso root ao sistema do servidor. Caso o administrador do + servidor não esteja disposto a fazer mudanças freqüentes nas + configurações do servidor, é desejável permitir que os + usuários possam fazer essas mudanças através de arquivos + .htaccess eles mesmos. Isso é particularmente + verdade, por exemplo, em casos onde provedores estão fornecendo + múltiplos sites para usuários em apenas uma máquina, e querem que + seus usuários possam alterar suas configurações.

+ +

No entanto, de modo geral, o uso de arquivos .htaccess + deve ser evitado quando possível. Quaisquer configurações + que você considerar acrescentar em um arquivo .htaccess, podem + ser efetivamente colocadas em uma seção <Directory> no arquivo principal de + configuração de seu servidor.

+ +

Existem duas razões principais para evitar o uso de arquivos + .htaccess.

+ +

A primeira delas é a performance. Quando AllowOverride é configurado para + permitir o uso de arquivos .htaccess, o Apache procura + em todos diretórios por arquivos .htaccess. + Logo, permitir arquivos .htaccess causa um impacto na + performance, mesmo sem você usá-los de fato! Além disso, + o arquivo .htaccess é carregado toda vez que um documento + é requerido.

+ +

Além disso, note que o Apache precisa procurar pelos arquivos + .htaccess em todos os diretórios superiores, para ter + o complemento total de todas as diretivas que devem ser + aplicadas. (Veja a seção como as diretrizes são + aplicadas.) Então, se um arquivo de um diretório + /www/htdocs/example é requerido, o Apache precisa + procurar pelos seguintes arquivos:

+ +

+ /.htaccess
+ /www/.htaccess
+ /www/htdocs/.htaccess
+ /www/htdocs/example/.htaccess +

+ +

Assim, para cada acesso de arquivo fora desse diretório, + existem 4 acessos ao sistema de arquivos adicionais, mesmo + que nenhum desses arquivos estejam presentes. (Note que esse + só será o caso se os arquivos .htaccess + estiverem habilitados para /, o que + normalmente não é o verdade.)

+ +

A segunda consideração é relativa à segurança. + Você está permitindo que os usuários modifiquem as + configurações do servidor, o que pode resultar em mudanças + que podem fugir ao seu controle. Considere com cuidado se você quer + ou não dar aos seus usuários esses privilégios. Note também + que dar aos usuários menos privilégios que eles precisam, acarreta em + pedidos de suporte técnico adicionais. Tenha certeza que você comunicou + aos usuários que nível de privilégios você os deu. + Especificar exatamente o que você configurou na diretriz AllowOverride, e direcioná-los para a + documentação relevante, irá poupá-lo de muita confusão + depois.

+ +

Perceba que é exatamente equivalente colocar o arquivo + .htaccess em um diretório + /www/htdocs/example contendo uma diretriz, e + adicionar a mesma diretriz em uma seção Directory + <Directory /www/htdocs/example> na configuração + principal do seu servidor:

+ +

Arquivo .htaccess em /www/htdocs/example:

+ +

Conteúdo de um arquivo .htaccess em + /www/htdocs/example

+ AddType text/example .exm +

+ +

Seção do seu arquivo httpd.conf

+ <Directory /www/htdocs/example>
+ + AddType text/example .exm
+ + </Directory> +

+ +

No entanto, adicionando isso ao seu arquivo de configuração do + servidor resultará em uma menor perda de performance, na medida que + a configuração é carregada no momento da inicialização do + servidor, ao invés de toda que que um arquivo é requerido.

+ +

O uso de arquivos .htaccess pode ser totalmente + desabilitado, ajustando a diretriz AllowOverride para none:

+ +

+ AllowOverride None +

+
top
+
+

Como as diretrizes são aplicadas

+ +

As diretrizes de configuração que se encontram em um arquivo + .htaccess são aplicadas para o diretório no qual o + arquivo .htaccess se encontra, e para todos os + subdiretórios ali presentes. Mas, é importante lembrar também que + podem existir arquivos .htaccess no diretórios + superiores. As diretrizes são aplicadas na ordem que são + achadas. Logo, um arquivo .htaccess em um diretório + em particular, pode sobrescrever as diretrizes encontradas em um + diretório acima deste em sua respectiva árvore. Estes, por sua vez, + podem ter suas diretrizes sobrescritas por diretrizes ainda mais + acima, ou no próprio arquivo de configuração principal do + servidor.

+ +

Exemplo:

+ +

No diretório /www/htdocs/example1 nós temos + um arquivo .htaccess contendo o seguinte:

+ +

+ Options +ExecCGI +

+ +

(Nota: você deve ter "AllowOverride Options" para + permitir o uso da diretriz "Options" nos arquivos + .htaccess .)

+ +

No diretório /www/htdocs/example1/example2 nós temos + um arquivo .htaccess contendo:

+ +

+ Options Includes +

+ +

Devido a esse segundo arquivo .htaccess, no + diretório /www/htdocs/example1/example2, a execução + de scripts CGI não é permitida, pois somente Options + Includes está em efeito, o que sobrescreve completamente + quaisquer outros ajustes previamente configurados.

+
top
+
+

Exemplo de Autenticação

+ +

Se você veio diretamente à esta parte do documento para + aprender como fazer autenticação, é importante notar uma + coisa. Existe uma concepção errada, mas muito comum, de que é + necessário o uso de arquivos .htaccess para implementar + a autenticação por senha. Este não é o caso. Colocar + diretrizes de senha em uma seção <Directory>, no seu arquivo principal de + configuração do servidor, é a melhor maneira de se implementar + isto, e os arquivos .htaccess devem ser usados apenas + se você não tem acesso ao arquivo principal de configuração do + servidor. Veja acima a discussão sobre quando + você deve e quando não deve usar os arquivos + .htaccess.

+ +

Dito isso, se você ainda acredita que precisa usar um arquivo + .htaccess, a configuração a seguir provavelmente + funcionará para você.

+ +

Conteúdo de um arquivo .htaccess:

+ +

+ AuthType Basic
+ AuthName "Password Required"
+ AuthUserFile /www/passwords/password.file
+ AuthGroupFile /www/passwords/group.file
+ Require Group admins +

+ +

Note que AllowOverride AuthConfig precisa estar + habilitado para que estas diretrizes tenham efeito.

+ +

Por favor veja o tutorial de + autenticação para uma discussão mais completa sobre + autenticação e autorização.

+
top
+
+

Exemplo de Server Side Includes

+ +

Outro uso comum de arquivos .htaccess é ativar o + Server Side Includes para um diretório em particular. Isto pode + ser feito com as seguintes diretrizes de configuração, colocadas em + um arquivo .htaccess no diretório desejado:

+ +

+ Options +Includes
+ AddType text/html shtml
+ AddHandler server-parsed shtml +

+ +

Note que ambos AllowOverride Options e + AllowOverride FileInfo precisam estar habilitados + para essas diretrizes terem efeito.

+ +

Por favor veja o tutorial de SSI para + uma discussão mais completa sobre server-side includes.

+
top
+
+

Exemplo de CGI

+ +

Finalmente, você pode querer que um arquivo + .htaccess permita a execução de programas CGI em um + diretório em particular. Isto pode ser implementado com as + seguintes configurações:

+ +

+ Options +ExecCGI
+ AddHandler cgi-script cgi pl +

+ +

Alternativamente, se você desejar que todos os arquivos de um + dado diretório, sejam considerados programas CGI, isso pode ser + feito com a seguinte configuração:

+ +

+ Options +ExecCGI
+ SetHandler cgi-script +

+ +

Note que ambos AllowOverride Options e + AllowOverride FileInfo precisam estar habilitados + para que essas diretrizes tenham quaisquer efeito.

+ +

Por favor veja o tutorial de CGI + tutorial para uma discussão mais completa sobre programação + e configuração CGI.

+
top
+
+

Resolvendo Problemas

+ +

Quando você adiciona diretrizes de configuração em um arquivo + .htaccess, e não obtém o efeito desejado, existe uma + série de pontos que podem estar errados.

+ +

Mais comumente, o problema é que a diretriz AllowOverride não está habilitada + corretamente para que as suas diretrizes de configurações sejam + honradas. Verifique se você não possui AllowOverride + None ajustado para o escopo do arquivo em questão. Um bom + meio de testar isso é colocar "lixo" em seu arquivo + .htaccess e recarregá-lo. Se não for gerado nenhum + erro do servidor, certamente você tem AllowOverride + None habilitado.

+ +

Se, por outro lado, você está obtendo erros do servidor ao + tentar acessar documentos, verifique o registro de erros do + Apache. Ele provavelmente irá indicar que a diretriz usada em + seu arquivo .htaccess não é permitida. + Alternativamente, ele pode acusar erros de sintaxe que você terá + que corrigir.

+ +
+
+

Línguas Disponíveis:  en  | + es  | + fr  | + ja  | + ko  | + pt-br 

+
top

Comentários

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/http2.html b/docs/manual/howto/http2.html new file mode 100644 index 0000000..7de4a43 --- /dev/null +++ b/docs/manual/howto/http2.html @@ -0,0 +1,13 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: http2.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: http2.html.es +Content-Language: es +Content-type: text/html; charset=ISO-8859-1 + +URI: http2.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/howto/http2.html.en b/docs/manual/howto/http2.html.en new file mode 100644 index 0000000..8e96089 --- /dev/null +++ b/docs/manual/howto/http2.html.en @@ -0,0 +1,346 @@ + + + + + +HTTP/2 guide - Apache HTTP Server Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.4

+
+
<-
+

HTTP/2 guide

+
+

Available Languages:  en  | + es  | + fr 

+
+ +

This is the howto guide for the HTTP/2 implementation in Apache httpd. This + feature is production-ready and you may expect interfaces and directives to + remain consistent releases. +

+
+ +
top
+
+

The HTTP/2 protocol

+ +

HTTP/2 is the evolution of the world's most successful application layer protocol, HTTP. + It focuses on making more efficient use of network resources. It does not change the fundamentals + of HTTP, the semantics. There are still request and responses and headers and all that. So, if + you already know HTTP/1, you know 95% about HTTP/2 as well.

+

There has been a lot written about HTTP/2 and how it works. The most normative is, of course, + its RFC 7540 + (also available in more readable formatting, YMMV). + So, there you'll find the nuts and bolts.

+

But, as RFC do, it's not really a good thing to read first. It's better to first understand + what a thing wants to do and then read the RFC about how it is done. A much + better document to start with is http2 explained + by Daniel Stenberg, the author of curl. It is available in + an ever growing list of languages, too!

+

Too Long, Didn't read: there are some new terms and gotchas that need to be kept in mind while reading this document:

+
    +
  • HTTP/2 is a binary protocol, as opposed to HTTP 1.1 that is plain text. The latter is meant to be human readable (for example sniffing network traffic) meanwhile the former is not. More info in the official FAQ question.
    • +
  • h2 is HTTP/2 over TLS (protocol negotiation via ALPN).
    • +
  • h2c is HTTP/2 over TCP.
    • +
  • A frame is the smallest unit of communication within an HTTP/2 connection, consisting of a header and a variable-length sequence of octets structured according to the frame type. More info in the official documentation section.
    • +
  • A stream is a bidirectional flow of frames within the HTTP/2 connection. The correspondent concept in HTTP 1.1 is a request/response message exchange. More info in the official documentation section.
    • +
  • HTTP/2 is able to run multiple streams of data over the same TCP connection, avoiding the classic HTTP 1.1 head of blocking slow request and avoiding to re-instantiate TCP connections for each request/response (KeepAlive patched the problem in HTTP 1.1 but did not fully solve it).
    • +
+
top
+
+

HTTP/2 in Apache httpd

+ +

The HTTP/2 protocol is implemented by its own httpd module, aptly named + mod_http2. It implements the complete set + of features described by RFC 7540 and supports HTTP/2 over cleartext (http:), as + well as secure (https:) connections. The cleartext variant is named 'h2c', + the secure one 'h2'. For h2c it allows the direct + mode and the Upgrade: via an initial HTTP/1 request.

+

One feature of HTTP/2 that offers new capabilities for web developers is + Server Push. See that section on how your web application + can make use of it.

+
top
+
+

Build httpd with HTTP/2 support

+ +

mod_http2 uses the library of nghttp2 + as its implementation base. In order to build mod_http2 you need at least version 1.2.1 of + libnghttp2 installed on your system.

+

When you ./configure your Apache httpd source tree, you need to give it + '--enable-http2' as additional argument to trigger the build of the module. + Should your libnghttp2 reside in an unusual place (whatever that is on your + operating system), you may announce its location with '--with-nghttp2=<path>' + to configure.

+

While that should do the trick for most, they are people who might prefer a statically + linked nghttp2 in this module. For those, the option --enable-nghttp2-staticlib-deps + exists. It works quite similar to how one statically links openssl to mod_ssl.

+

Speaking of SSL, you need to be aware that most browsers will speak HTTP/2 only on https: + URLs, so you need a server with SSL support. But not only that, you will need a SSL library + that supports the ALPN extension. If OpenSSL is the library you use, you need + at least version 1.0.2.

+
top
+
+

Basic Configuration

+ + +

When you have a httpd built with mod_http2 you need some + basic configuration for it becoming active. The first thing, as with every Apache module, + is that you need to load it:

+ 
LoadModule http2_module modules/mod_http2.so
+ + +

The second directive you need to add to your server configuration is

+ 
Protocols h2 http/1.1
+ +

This allows h2, the secure variant, to be the preferred protocol on your server + connections. When you want to enable all HTTP/2 variants, you simply write:

+ 
Protocols h2 h2c http/1.1
+ +

Depending on where you put this directive, it affects all connections or just + the ones to a certain virtual host. You can nest it, as in:

+ 
Protocols http/1.1
+<VirtualHost ...>
+    ServerName test.example.org
+    Protocols h2 http/1.1
+</VirtualHost>
+ + +

This allows only HTTP/1 on connections, except SSL connections to test.example.org + which offer HTTP/2.

+

Choose a strong SSLCipherSuite

+

The SSLCipherSuite needs to be configured with + a strong TLS cipher suite. The current version of mod_http2 does not enforce any cipher but most + clients do so. Pointing a browser to a h2 enabled server with a inappropriate + cipher suite will force it to simply refuse and fall back to HTTP 1.1. This is a common mistake + that is done while configuring httpd for HTTP/2 the first time, so please keep it in mind to avoid + long debugging sessions! If you want to be sure about the cipher suite to choose please avoid + the ones listed in the HTTP/2 TLS reject list.

+
+

The order of protocols mentioned is also relevant. By default, the first one is the + most preferred protocol. When a client offers multiple choices, the one most to the + left is selected. In

+ 
Protocols http/1.1 h2
+ +

the most preferred protocol is HTTP/1 and it will always be selected unless a + client only supports h2. Since we want to talk HTTP/2 to clients that + support it, the better order is

+ 
Protocols h2 h2c http/1.1
+ + +

There is one more thing to ordering: the client has its own preferences, too. If + you want, you can configure your server to select the protocol most preferred by + the client:

+ 
ProtocolsHonorOrder Off
+ +

makes the order you wrote the Protocols irrelevant and only the client's + ordering will decide.

+

A last thing: the protocols you configure are not checked for correctness + or spelling. You can mention protocols that do not exist, so there is no need + to guard Protocols with any + <IfModule> checks.

+

For more advanced tips on configuration, see the + modules section about dimensioning and + how to manage multiple hosts with the same certificate.

+
top
+
+

MPM Configuration

+ + +

HTTP/2 is supported in all multi-processing modules that come with httpd. However, if + you use the prefork mpm, there will be severe restrictions.

+

In prefork, mod_http2 will only process one request at at time + per connection. But clients, such as browsers, will send many requests at the same time. + If one of these takes long to process (or is a long polling one), the other requests will + stall.

+

mod_http2 will not work around this limit by default. The reason is that + prefork is today only chosen, if you run processing engines that are not + prepared for multi-threading, e.g. will crash with more than one request.

+

If your setup can handle it, configuring event mpm is nowadays + the best one (if supported on your platform).

+

If you are really stuck with prefork and want multiple requests, + you can tweak the H2MinWorkers to make + that possible. If it breaks, however, you own both parts.

+
top
+
+

Clients

+ +

Almost all modern browsers support HTTP/2, but only over SSL connections: Firefox (v43), + Chrome (v45), Safari (since v9), iOS Safari (v9), Opera (v35), Chrome for Android (v49) + and Internet Explorer (v11 on Windows10) (source).

+

Other clients, as well as servers, are listed + on the Implementations wiki, + among them implementations for c, c++, common lisp, dart, erlang, haskell, java, nodejs, php, + python, perl, ruby, rust, scala and swift.

+

Several of the non-browser client implementations support HTTP/2 over cleartext, h2c. The + most versatile being curl.

+
top
+
+

Useful tools to debug HTTP/2

+ +

The first tool to mention is of course curl. Please make sure that + your version supports HTTP/2 checking its Features:

+ 
    $ curl -V
+    curl 7.45.0 (x86_64-apple-darwin15.0.0) libcurl/7.45.0 OpenSSL/1.0.2d zlib/1.2.8 nghttp2/1.3.4
+    Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 [...] 
+    Features: IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP HTTP2
+
+ +

Mac OS homebrew notes

+ brew install curl --with-openssl --with-nghttp2 +
+

And for really deep inspection wireshark.

+

The nghttp2 package also includes clients, such as:

+
    +
  • nghttp - useful to visualize the HTTP/2 frames and get a better idea of the protocol.
    • +
  • h2load - useful to stress-test your server.
    • +
+

Chrome offers detailed HTTP/2 logs on its connections via the + special net-internals page. There is also an + interesting extension for Chrome + and Firefox + to visualize when your browser is using HTTP/2.

+
top
+
+

Server Push

+ +

The HTTP/2 protocol allows the server to PUSH responses to a client it never + asked for. The tone of the conversation is: "here is a request that you + never sent and the response to it will arrive soon..."

+

But there are restrictions: the client can disable this feature and the + server may only ever PUSH on a request that came from the client.

+

The intention is to allow the server to send resources to the client that + it will most likely need: a css or javascript resource that belongs to a html + page the client requested. A set of images that is referenced by a css, etc.

+

The advantage for the client is that it saves the time to send the request which + may range from a few milliseconds to half a second, depending on where on the + globe both are located. The disadvantage is that the client may get sent + things it already has in its cache. Sure, HTTP/2 allows for the early cancellation + of such requests, but still there are resources wasted.

+

To summarize: there is no one good strategy on how to make best use of this + feature of HTTP/2 and everyone is still experimenting. So, how do you experiment + with it in Apache httpd?

+

mod_http2 inspect response header for Link headers + in a certain format:

+ 
Link </xxx.css>;rel=preload, </xxx.js>; rel=preload
+ +

If the connection supports PUSH, these two resources will be sent to the + client. As a web developer, you may set these headers either directly in + your application response or you configure the server via

+ 
<Location /xxx.html>
+    Header add Link "</xxx.css>;rel=preload"
+    Header add Link "</xxx.js>;rel=preload"
+</Location>
+ +

If you want to use preload links without triggering a PUSH, you + can use the nopush parameter, as in

+ 
Link </xxx.css>;rel=preload;nopush
+ +

or you may disable PUSHes for your server entirely with the directive

+ 
H2Push Off
+ +

And there is more:

+

The module will keep a diary of what has been PUSHed for each connection + (hashes of URLs, basically) and will not PUSH the same resource twice. When + the connection closes, this information is discarded.

+

There are people thinking about how a client can tell a server what it + already has, so PUSHes for those things can be avoided, but this is all + highly experimental right now.

+

Another experimental draft that has been implemented in mod_http2 + is the + Accept-Push-Policy Header Field where a client can, for each request, define + what kind of PUSHes it accepts.

+

+ PUSH might not always trigger the request/response/performance that one expects or + hopes for. There are various studies on this topic to be found on the web that explain + benefits and weaknesses and how different features of client and network influence + the outcome. For example: just because the server PUSHes a resource does not mean + a browser will actually use the data.

+

The major thing that influences the response being PUSHed is the request that was + simulated. The request URL for a PUSH is given by the application, but where do the + request headers come from? For example, will the PUSH request a accept-language + header and if yes with what value?

+

Apache will look at the original request (the one that triggered the PUSH) and copy the + following headers over to PUSH requests: user-agent, accept, + accept-encoding, accept-language, cache-control.

+

All other headers are ignored. Cookies will also not be copied over. PUSHing resources + that require a cookie to be present will not work. This can be a matter of debate. But + unless this is more clearly discussed with browser, let's err on the side of caution and + not expose cookie where they might ordinarily not be visible.

+
top
+
+

Early Hints

+ +

An alternative to PUSHing resources is to send Link headers to the + client before the response is even ready. This uses the HTTP feature called "Early Hints" and + is described in RFC 8297.

+

In order to use this, you need to explicitly enable it on the server via

+ 
H2EarlyHints on
+ +

(It is not enabled by default since some older browser tripped on such responses.)

+

If this feature is on, you can use the directive H2PushResource to + trigger early hints and resource PUSHes:

+ 
<Location /xxx.html>
+    H2PushResource /xxx.css
+    H2PushResource /xxx.js
+</Location>
+ +

This will send out a "103 Early Hints" response to a client as soon + as the server starts processing the request. This may be much early than + the time the first response headers have been determined, depending on your web + application.

+

If H2Push is enabled, this will also start the PUSH right after the + 103 response. If H2Push is disabled however, the 103 response will be send + nevertheless to the client.

+
+
+

Available Languages:  en  | + es  | + fr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/http2.html.es b/docs/manual/howto/http2.html.es new file mode 100644 index 0000000..81fd4b3 --- /dev/null +++ b/docs/manual/howto/http2.html.es @@ -0,0 +1,421 @@ + + + + + +Guía HTTP/2 - Servidor HTTP Apache Versión 2.4 + + + + + + +
+

Módulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

+

Versión 2.4 del Servidor HTTP Apache

+
+
<-
+

Guía HTTP/2

+
+

Idiomas disponibles:  en  | + es  | + fr 

+
+
Esta traducción podría estar + obsoleta. Consulte la versión en inglés de la + documentación para comprobar si se han producido cambios + recientemente.
+ +

+ Esta es la guía para configurar HTTP/2 en Apache httpd. Ésta característica + está lista en produción así que es de esperar que las interfaces + y las directivas se mantengan consistentes en cada verión. +

+
+ +
top
+
+

El protocolo HTTP/2

+ + +

HTTP/2 es la evolución del protocolo de la capa de aplicación con más + éxito, HTTP. Se centra en hacer un uso más eficiente de los recursos de red. + No cambia la característica fundamental de HTTP, la semántica. Todavía hay + olicitudes, respuestas, cabeceras y todo los elementos típicos de HTTP/1. Así + que, si ya conoce HTTP/1, también conoce el 95% de HTTP/2.

+ +

Se ha escrito mucho sobre HTTP/2 y de cómo funciona. La norma más + estándar es, por supuesto, su + RFC 7540 + ( también disponible en un + formato más legible, YMMV). Así que, ahí encontrará toda la especificación + del protocolo.

+ +

Pero, como con todos los RFC, no es ideal como primera lectura. Es mejor + entender primero qué se quiere hacer y después leer el RFC sobre + cómo hacerlo. Un documento mucho mejor con el que empezar es + http2 explicado + por Daniel Stenberg, el autor de curl. + ¡También está disponible cada vez en un mayor número lenguajes!

+ +

Si le parece demasiado largo, o no lo ha leido, hay algunos términos + y elementos a tener en cuenta cuando lea este documento:

+
    +
  • HTTP/2 es un protocolo binario, al contrario que + HTTP 1.1 que es texto plano. La intención para HTTP 1.1 es que sea + legible (por ejemplo capturando el tráfico de red) mientras que para + HTTP/2 no. Más información en el FAQ oficial + ¿Por qué es + binario HTTP/2?
    • + +
  • h2 es HTTP/2 sobre TLS (negociación de protocolo a + través de ALPN).
    • + +
  • h2c es HTTP/2 sobre TCP.
    • + +
  • Un frame es la unidad más pequeña de comunicación + dentro de una conexión HTTP/2, que consiste en una cabecera y una secuencia + de octetos de longitud variable estructurada de acuerdo con el tipo de + frame. Más información en la documentación oficial + Sección de + Capa de Frame.
    • + +
  • Un stream es un flujo bidireccional de frames dentro + de una conexión HTTP/2. El concepto correspondiente en HTTP 1.1 es un + intercambio de mensajes de solicitud/respuesta. Más información en la + documentación oficial + Sección Capa + de Stream.
    • + +
  • + HTTP/2 es capaz de llevar múltiples streams de datos + sobre la misma conexión TCP, evitando la clásica solicitud lenta + "head-of-line blocking" de HTTP 1.1 y evitando generar múltiples conexiones + TCP para cada solicitud/respuesta (KeepAlive parcheó el problema en + HTTP 1.1 pero no lo resolvió completamente). +
    • +
+
top
+
+

HTTP/2 en Apache httpd

+ + +

+ El protocolo HTTP/2 se implementa con su propio módulo httpd, llamado + acertadamente mod_http2. Incluye el set completo de + características descritas por el RFC 7540 y soporta HTTP/2 sobre texto + plano (http:), así como conexiones seguras (https:). La variante de texto + plano se llama 'h2c', la segura 'h2'. Para + h2c permite el modo direct + y el Upgrade: a través de una solicitud inicial HTTP/1. +

+ +

+ Una característica de HTTP/2 que ofrece capacidades nuevas para + desarrolladores de web es Server Push. Vea esa sección + para saber como su aplicación web puede hacer uso de ella. +

+
top
+
+

Compilar httpd con soporte HTTP/2

+ + +

+ mod_http2 usa la librería + nghttp2como su implementación base. Para compilar + mod_http2 necesita al menos la versión 1.2.1 de + libnghttp2 instalada en su sistema. +

+ +

+ Cuando usted ejecuta ./configure en el código fuente de + Apache HTTPD, necesita indicarle '--enable-http2' como una + opción adicional para activar la compilación de este módulo. Si su + libnghttp2 está ubicado en una ruta no habitual (cualquiera que + sea en su sistema operativo), puede indicar su ubicación con + '--with-nghttp2=<path>' para ./configure. +

+ +

Aunque puede que eso sirva para la mayoría, habrá quien prefiera un nghttp2 compilado estáticamente para este módulo. Para ellos existe la opción --enable-nghttp2-staticlib-deps. Funciona de manera muy similar a como uno debe enlazar openssl estáticamente para mod_ssl.

+ +

Hablando de SSL, necesita estar al tanto de que la mayoría de los navegadores hablan HTTP/2 solo con URLs https:. Así que necesita un servidor con soporte SSL. Pero no solo eso, necesitará una librería SSL que de soporte a la extensión ALPN. Si usa OpenSSL, necesita al menos la versión 1.0.2.

+
top
+
+

Configuración básica

+ + +

Cuando tiene un httpd compilado con mod_http2 necesita una configuración básica para activarlo. Lo primero, como con cualquier otro módulo de Apache, es que necesita cargarlo:

+ + 
LoadModule http2_module modules/mod_http2.so
+ + +

La segunda directiva que necesita añadir a la configuración de su servidor es:

+ + 
Protocols h2 http/1.1
+ + +

Esto permite h2, la variante segura, para ser el protocolo preferido de las conexiones en su servidor. Cuando quiera habilitar todas las variantes de HTTP/2, entonces simplemente configure:

+ + 
Protocols h2 h2c http/1.1
+ + +

Dependiendo de dónde pone esta directiva, afecta a todas las conexiones o solo a las de ciertos host virtuales. La puede anidar, como en:

+ + 
Protocols http/1.1
+<VirtualHost ...>
+    ServerName test.example.org
+    Protocols h2 http/1.1
+</VirtualHost>
+ + +

Esto solo permite HTTP/1, excepto conexiones SSL hacia test.example.org que ofrecen HTTP/2.

+ +

Escoger un SSLCipherSuite seguro

+

Es necesario configurar SSLCipherSuite con una suite segura de cifrado TLS. La versión actual de mod_http2 no fuerza ningún cifrado pero la mayoría de los clientes si lo hacen. Encaminar un navegador hacia un servidor con h2 activado con una suite inapropiada de cifrados forzará al navegador a rehusar e intentar conectar por HTTP 1.1. Esto es un error común cuando se configura httpd con HTTP/2 por primera vez, ¡así que por favor tenga en cuenta que debe evitar largas sesiones de depuración! Si quiere estar seguro de la suite de cifrados que escoja, por favor evite los listados en la Lista Negra de TLS para HTTP/2.

+
+ +

El orden de los protocolos mencionados también es relevante. Por defecto, el primero es el protocolo preferido. Cuando un cliente ofrece múltiples opciones, la que esté más a la izquierda será la escogida. En

+ 
Protocols http/1.1 h2
+ + +

el protocolo preferido es HTTP/1 y siempre será seleccionado a menos que el cliente sólo soporte h2. Puesto que queremos hablar HTTP/2 con clientes que lo soporten, el orden correcto es:

+ + 
Protocols h2 h2c http/1.1
+ + +

Hay algo más respecto al orden: el cliente también tiene sus propias preferencias. Si quiere, puede configurar su servidor para seleccionar el protocolo preferido por el cliente:

+ + 
ProtocolsHonorOrder Off
+ + +

Hace que el orden en que usted escribió los Protocols sea irrelevante y sólo el orden de preferencia del cliente será decisorio.

+ +

Una última cosa: cuando usted configura los protocolos no se comprueba si son correctos o están bien escritos. Puede mencionar protocolos que no existen, así que no hay necesidad de proteger Protocols con ningún <IfModule> de comprobación.

+ +

Para más consejos avanzados de configuración, vea la + sección de módulos sobre dimensionamiento y + como gestionar multiples hosts con el mismo certificado.

+
top
+
+

Configuración MPM

+ + +

HTTP/2 está soportado en todos los módulos de multi-proceso que se ofrecen con httpd. Aun así, si usa el mpm prefork, habrá restricciones severas.

+ +

En prefork, mod_http2 solo procesará una solicitud cada vez por conexión. Pero los clientes, como los navegadores, enviarán muchas solicitudes al mismo tiempo. Si una de ellas tarda mucho en procesarse (o hace un sondeo que dura más de la cuenta), las otras solicitudes se quedarán atascadas.

+ +

mod_http2 no evitará este límite por defecto. El motivo es que prefork hoy en día solo se escoge si ejecuta motores de proceso que no están preparados para multi-hilo, p.ej. fallará con más de una solicitud.

+ +

Si su configuración lo soporta, hoy en día event es el mejor mpm que puede usar.

+ +

Si realmente está obligado a usar prefork y quiere multiples solicitudes, puede configurar la directiva H2MinWorkers para hacerlo posible. Sin embargo, si esto falla, es bajo su cuenta y riesgo.

+
top
+
+

Clientes

+ + +

Casi todos los navegadores modernos dan soporte a HTTP/2, pero solo en conexiones SSL: Firefox (v43), Chrome (v45), Safari (since v9), iOS Safari (v9), Opera (v35), Chrome para Android (v49) e Internet Explorer (v11 en Windows10) (Fuente).

+ +

Otros clientes, así cómo otros servidores, están listados en la + wiki de Implementaciones, entre ellos, implementaciones para c, c++, common lisp, dart, erlang, haskell, java, nodejs, php, python, perl, ruby, rust, scala y swift.

+ +

Muchos de las implementaciones de clientes que no son navegadores soportan HTTP/2 sobre texto plano, h2c. La más versátil es curl.

+
top
+
+

Herramientas útiles para depurar HTTP/2

+ + +

La primera herramienta a mencionar es por supuesto curl. Por favor asegúrese de que su versión soporta HTTP/2 comprobando sus Características:

+ 
    $ curl -V
+    curl 7.45.0 (x86_64-apple-darwin15.0.0) libcurl/7.45.0 OpenSSL/1.0.2d zlib/1.2.8 nghttp2/1.3.4
+    Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 [...] 
+    Features: IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP HTTP2
+
+ +

Notas sobre Mac OS homebrew

+ brew install curl --with-openssl --with-nghttp2 +
+

Y para una inspección en gran profundidad wireshark.

+

El paquete nghttp2 también incluye clientes, tales como:

+
    +
  • nghttp + - util para visualizar la frames de HTTP/2 y tener una mejor idea de como funciona el protocolo.
    • +
  • h2load - útil para hacer un stress-test de su servidor.
    • +
+ +

Chrome ofrece logs detallados de HTTP/2 en sus conexiones a través de la página especial de net-internals. También hay una extensión interesante para Chrome y Firefox con la que visualizar cuando su navegador usa HTTP/2.

+
top
+
+

Server Push

+ + +

El protocolo HTTP/2 permite al servidor hacer PUSH de respuestas a un cliente que nunca las solicitó. El tono de la conversación es: "Aquí tiene una solicitud que nunca envió y la respuesta llegará pronto..."

+ +

Pero hay restricciones: el cliente puede deshabilitar esta característica y el servidor entonces solo podrá hacer PUSH en una solicitud que hizo previamente del cliente.

+ +

La intención es permitir al servidor enviar recursos que el cliente seguramente vaya a necesitar, p. ej. un recurso css o javascript que pertenece a una página html que el cliente solicitó, un grupo de imágenes a las que se hace referencia en un css, etc.

+ +

La ventaja para el cliente es que ahorra tiempo para solicitudes que pueden tardar desde unos pocos milisegundos a medio segundo, dependiendo de la distancia entre el cliente y el servidor. La desventaja es que el cliente puede recibir cosas que ya tiene en su cache. Por supuesto que HTTP/2 soporta cancelación previa de tales solicitudes, pero aun así se malgastan recursos.

+ +

Resumiendo: no hay una estrategia mejor sobre cómo usar esta característica de HTTP/2 y todo el mundo está experimentando con ella. Así que, ¿cómo experimenta usted con ella en Apache httpd?

+ +

mod_http2 busca e inspecciona las cabeceras de respuesta + Link con cierto formato:

+ + 
Link </xxx.css>;rel=preload, </xxx.js>; rel=preload
+ + +

+ Si la conexión soporta PUSH, estos dos recursos se enviarán al cliente. + Como desarrollador web, puede configurar estas cabeceras o bien + directamente en la respuesta de su aplicación o configurar su servidor con: +

+ + 
<Location /xxx.html>
+    Header add Link "</xxx.css>;rel=preload"
+    Header add Link "</xxx.js>;rel=preload"
+</Location>
+ + +

Si quiere usar enlaces con preload sin activar un PUSH, puede + usar el parámetro nopush, como en:

+ + 
Link </xxx.css>;rel=preload;nopush
+ + +

o puede desactivar PUSH para su servidor por completo con la directiva

+ + 
H2Push Off
+ + +

Y hay más:

+ +

+ El módulo mantiene un registro de lo que se ha enviado con PUSH para cada + conexión (hashes de URLs, básicamente) y no hará PUSH del mismo recurso dos + veces. Cuando la conexión se cierra, la información es descartada. +

+ +

+ Hay gente pensando cómo un cliente puede decirle al servidor lo que ya + tiene, para evitar los PUSH de esos elementos, pero eso algo muy + experimental ahora mismo. +

+ +

Otro borrador experimental que ha sido implementado en + mod_http2 es el Campo de Cabecera + Accept-Push-Policy en la que un cliente puede, para cada solicitud, definir + qué tipo de PUSH acepta.

+ +

+ Puede que PUSH no siempre lance la peticion/respuesta/funcionamiento que + uno espera. Hay varios estudios sobre este tema en internet, que explican + el beneficio y las debilidades de como diferentes funcionalidades del + cliente y de la red influyen en el resultado. + Por Ejemplo, que un servidor haga "PUSH" de recursos, no significa que el + navegador vaya a usar dichos datos. +

+

+ Lo más importante que influye en la respuesta que se envía, es la solicitud + que se simuló. La url de solicitud de un PUSH es dada por la aplicación, + pero ¿de donde vienen las cabeceras de la petición? por ejemplo si el PUSH + pide una cabecera accept-language y si es así, ¿con qué valor? +

+

Httpd mirará la petición original (la que originó el PUSH) y copiará las + siguientes cabeceras a las peticiones PUSH: + user-agent, accept, accept-encoding, + accept-language, cache-control. +

+

+ Todas las otras cabeceras son ignorados. Las cookies tampoco serán copiadas. + Impulsar los recursos que requieren una cookie para estar presente no + funcionará. Esto puede ser una cuestión de debate. Pero a menos que esto se + discuta más claramente con el navegador, evitemos el exceso de precaución y + no expongamos las cookies donde podrían o no ser visibles. +

+ +
top
+
+

"Early Hints"

+ + +

Una alternativa de "Pushear" recursos es mandar una cabecera + Link al cliente antes que la respuesta esté lista. Esto usa + una caracteristica de HTTP que se llama "Early Hints" y está descrita en + la RFC 8297.

+

Para poder usar esto, necesita habilitarlo explicitamente en el servidor + via

+ + 
H2EarlyHints on
+ + +

(No está habilitado por defecto ya q ue algunos navegadores más antiguos + se caen con dichas respuestas.) +

+ +

si esta funcionalidad esta activada, puede usar la directiva + H2PushResource para que lance + "Early hints" y recursos mediante push: +

+ 
<Location /xxx.html>
+    H2PushResource /xxx.css
+    H2PushResource /xxx.js
+</Location>
+ +

+ Esto lanzará una respuesta "103 Early Hints" a un cliente + tan pronto como el servidor comience a procesar la solicitud. + Esto puede ser mucho antes que en el momento en que se determinaron los + primeros encabezados de respuesta, dependiendo de su aplicación web. +

+ +

+ Si la directiva H2Push está + habilitada, esto comenzará el PUSH justo después de la respuesta 103. + Sin embargo, si la directiva H2Push está dehabilitada, la respuesta 103 se le enviará al cliente. +

+
+
+

Idiomas disponibles:  en  | + es  | + fr 

+
top

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/http2.html.fr.utf8 b/docs/manual/howto/http2.html.fr.utf8 new file mode 100644 index 0000000..9694f09 --- /dev/null +++ b/docs/manual/howto/http2.html.fr.utf8 @@ -0,0 +1,429 @@ + + + + + +Guide HTTP/2 - Serveur HTTP Apache Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.4

+
+
<-
+

Guide HTTP/2

+
+

Langues Disponibles:  en  | + es  | + fr 

+
+ +

Ce document est le guide de l'utilisateur de l'implémentation de HTTP/2 + dans Apache httpd. Cette fonctionnalité en est au stade + de production, et les interfaces et directives devraient donc être + dorénavant relativement stables. +

+
+ +
top
+
+

Le protocole HTTP/2

+ +

HTTP/2 est une évolution du protocole de la couche application le plus + utilisé au monde, HTTP. Cette évolution permet en particulier une utilisation + plus efficace des ressources réseau. Il ne modifie pas les aspects + fondamentaux de HTTP (sa sémantique). Entre autres, il y a toujours des + requêtes, des réponses et des en-têtes. Par conséquent, si vous connaissez + HTTP/1, vous connaissez déjà 95% de HTTP/2.

+

Beaucoup a déjà été écrit à propos de HTTP/2 et de son fonctionnement. La + documentation la plus officielle est bien entendu sa RFC 7540 (ou cette version au format plus + lisible). Vous trouverez ici une description des rouages de HTTP/2 dans + leurs moindres détails.

+

Le premier document à lire lorsqu'on ne connaît pas un mécanisme n'est + cependant pas sa RFC. Il est préférable de comprendre tout d'abord ce + que ce mécanisme est censé faire, et seulement ensuite de lire sa RFC + pour comprendre comment il fonctionne. http2 explained de Daniel Stenberg + (l'auteur de curl) + est un bien meilleur document pour démarrer l'étude de HTTP/2. En outre, de + nouveaux langages s'ajoutent régulièrement à sa liste de traductions + disponibles !

+

Si vous n'avez pas envie de le lire parce que vous le trouvez trop long, + voici certains pièges à éviter et nouveaux termes à connaître avant de lire + ce document :

+
    +
  • A la différence de HTTP/1 qui est en texte pur, HTTP/2 est un + protocole binaire, et alors que le premier est lisible par + un humain (par exemple pour sniffer le trafic réseau), le second ne + l'est pas. Voir la FAQ + officielle pour plus de détails.
    • +
  • h2 correspond à HTTP/2 sur TLS (négociation de + protocole via ALPN).
    • +
  • h2c correspond à HTTP/2 sur TCP.
    • +
  • Une frame ou trame est la plus petite unité de + communication au sein d'une connexion HTTP/2 et comporte une en-tête et + une séquence d'octets de longueur variable dont la structure correspond + au type de trame. Voir la section + correspondante de la documentation officielle pour plus de + détails.
    • +
  • Un stream est un flux bidirectionnel de frames au + sein d'une connexion HTTP/2. La notion correspondante dans HTTP/1 est un + échange de messages de type requête et réponse. Voir la section + correspondante de la documentation officielle pour plus de détails.
    • +
  • HTTP/2 peut gérer plusieurs streams de données sur + la même connexion TCP, ce qui permet d'éviter le point de blocage + classique de HTTP/1 pour les requêtes lentes, et de ne pas avoir à + ouvrir de nouvelles connexions TCP pour chaque requête/réponse (les + connexions persistantes ou KeepAlive avaient contourné le problème dans + HTTP/1 mais ne l'avaient pas entièrement résolu)
    • +
+
top
+
+

HTTP/2 dans Apache httpd

+ +

Le protocole HTTP/2 est implémenté dans Apache httpd via un module + propre, pertinemment nommé mod_http2. Ce + module implémente toutes les fonctionnalités décrites par la RFC 7540 et + supporte les connexions en texte pur (http:), ou sécurisées (https:). + La variante texte pur se nomme 'h2c', et la variante sécurisée + 'h2'. h2c peut être en mode direct ou + Upgrade: via une requête initiale en HTTP/1.

+

Server Push est une nouvelle fonctionnalité offerte + aux développeurs web par HTTP/2. La section correspondante de ce document + vous indiquera comment votre application peut en tirer parti.

+
top
+
+

Compilation de httpd avec le support de HTTP/2

+ +

mod_http2 se base sur la bibliothèque + de nghttp2 pour son implémentation. Pour + pouvoir compiler mod_http2, libnghttp2 version + 1.2.1. ou supérieure doit être installée dans votre système.

+

Pour déclencher la compilation de mod_http2, vous devez + ajouter l'argument '--enable-http2' au script + ./configure que vous exécutez à la racine de l'arborescence des + sources de httpd. Si libnghttp2 est installée dans un + répertoire non connu du chemin de vos bibliothèques, vous devez indiquer ce + répertoire au script ./configure via l'argument + '--with-nghttp2=<path>'.

+

Alors que cette méthode de compilation conviendra à la plupart, certains + préféreront lier statiquement nghttp2 à ce module. Pour ce + faire, utilisez l'argument --enable-nghttp2-staticlib-deps. + Cette méthode est pratiquement la même que celle utilisée pour lier + statiquement openssl à mod_ssl.

+

En parlant de SSL, vous devez savoir que la plupart des navigateurs ne + communiqueront en HTTP/2 que sur des URLs sécurisées de type + https: ; votre serveur doit donc supporter SSL. Mais de plus, + votre bibliothèque SSL devra supporter l'extension ALPN. Enfin, + si la bibliothèque que vous utilisez est OpenSSL, sa version devra être + 1.0.2. ou supérieure.

+
top
+
+

Configuration de base

+ + +

Maintenant que vous disposez d'un binaire httpd compilé avec le + module mod_http2, l'activation de ce dernier nécessite un + minimum de configuration supplémentaire. En premier lieu, comme pour tout + module Apache, vous devez le charger :

+ 
LoadModule http2_module modules/mod_http2.so
+ + +

La seconde directive que vous devez ajouter à votre fichier de + configuration est

+ 
Protocols h2 http/1.1
+ +

Ceci permet de définir h2, la variante sécurisée, comme le protocole + préféré pour les connexions à votre serveur. Si vous souhaitez que toutes les + variantes soient disponibles, utilisez la directive suivante :

+ 
Protocols h2 h2c http/1.1
+ +

Selon l'endroit où vous placez cette directive, elle affectera l'ensemble + de votre serveur, ou seulement un ou plusieurs serveurs virtuels. Vous + pouvez aussi l'imbriquer comme dans l'exemple suivant :

+ 
Protocols http/1.1
+<VirtualHost ...>
+    ServerName test.example.org
+    Protocols h2 http/1.1
+</VirtualHost>
+ + +

Seules les connexions en HTTP/1 seront alors permises, sauf pour le serveur + virtuel test.example.org qui acceptera aussi les connexions SSL + en HTTP/2.

+

Utilisez une chaîne d'algorithmes de chiffrement forte

+

La directive SSLCipherSuite doit + être définie avec une chaîne d'algorithmes de chiffrement TLS forte. Même si + la version actuelle de mod_http2 n'impose pas d'algorithmes + de chiffrement particuliers, la plupart des clients le font. Faire pointer + un navigateur vers un serveur où h2 est activé avec une chaîne + d'algorithmes de chiffrement inappropriée entraînera un rejet et une + retrogradation vers HTTP 1.1. C'est une erreur que l'on fait couramment + lorsqu'on configure httpd pour HTTP/2 pour la première fois ; donc gardez la + à l'esprit si vous voulez éviter de longues sessions de débogage ! Si vous + voulez être sûr de définir une chaîne d'algorithmes de chiffrement + appropriée, évitez ceux qui sont listés dans la liste des + algorithmes de chiffrement TLS HTTP/2 à proscrire.

+
+

L'ordre des protocoles indiqués est aussi important. Par défaut, le + premier sera le protocole préféré. Lorsqu'un client offre plusieurs choix, + c'est le plus à gauche qui sera sélectionné. Dans

+ 
Protocols http/1.1 h2
+ +

le protocole préféré sera HTTP/1 et il sera toujours sélectionné sauf si + un client ne supporte que h2. Comme nous souhaitons communiquer en + HTTP/2 avec les clients qui le supportent, la meilleure définition de la + directive est

+ 
Protocols h2 h2c http/1.1
+ + +

Toujours à propos de l'ordre des protocoles, le client a lui aussi ses + propres préférences en la matière. À ce titre, si vous le souhaitez, vous + pouvez configurer votre serveur pour qu'il sélectionne non plus son + protocole préféré, mais au contraire le protocole préféré + du client :

+ 
ProtocolsHonorOrder Off
+ +

Avec cette directive, l'ordre des protocoles que vous avez + défini devient caduque et seul l'ordre défini par le client sera pris en + compte.

+

Une dernière chose : les protocoles que vous définissez ne sont pas + vérifiés quant à leurs validité ou orthographe. Vous pouvez très bien + définir des protocoles qui n'existent pas, et il n'est donc pas nécessaire + de filtrer le contenu de la directive Protocols avec des vérifications de type + <IfModule>.

+

Pour des conseils plus avancés à propos de la configuration, voir la Documentation de mod_http2, et en particulier + la section à propos de la consommation supplémentaire de + ressources, ainsi que la section expliquant comment gérer les serveurs multiples avec certificat + commun.

+
top
+
+

Configuration du MPM

+ + +

Tous les modules multiprocessus (MPM) fournis avec httpd supportent + HTTP/2. Cependant, si vous utilisez le MPM prefork, vous allez + faire face à de sévères restrictions.

+

Avec le MPM prefork, mod_http2 ne traitera + qu'une requête à la fois par connexion alors que les clients tels que les + navigateurs internet envoient de nombreuses requêtes au même moment. Si + l'une d'entre elles est longue à traiter (ou implique une longue + interrogation), les autres requêtes seront mises en attente.

+

Par défaut, mod_http2 ne passe pas outre cette limitation pour + la simple et bonne raison que le MPM prefork n'est aujourd'hui + choisi que si vous exécutez des moteurs de traitement qui ne sont pas préparés + pour le multithreading (par exemple qui se crashent lorsque plusieurs + requêtes arrivent).

+

Si votre plateforme et votre installation de httpd le supportent, la + meilleur solution consiste actuellement à utiliser le MPM + event. +

+

Si vous n'avez pas d'autre choix que d'utiliser le MPM + prefork, mais souhaitez tout de même traiter plusieurs requêtes + simultanément, vous pouvez jouer avec la directive H2MinWorkers, sans garantie que cela + fonctionne.

+
top
+
+

Clients

+ +

La plupart des navigateurs modernes supportent HTTP/2, mais seulement sur + des connexions SSL : Firefox v43, Chrome v45, Safari v9, iOS Safari v9, + Opera v35, Chrome pour Android v49 et + Internet Explorer v11 sous Windows10 (selon cette source).

+

D'autres clients et serveurs sont listés dans le wiki des + implémentations ; entre autres des implémentations pour c, c++, common + lisp, dart, erlang, haskell, java, nodejs, php, python, perl, ruby, rust, + scala et swift.

+

De nombreuses implémentations clientes autres que les navigateurs + supportent HTTP/2 en texte pur, h2c. L'une des plus efficaces d'entre elles + est curl.

+
top
+
+

Outils efficaces pour déboguer HTTP/2

+ +

Le premier d'entre eux est bien entendu curl. Assurez-vous au préalable que votre + version supporte HTTP/2 en vérifiant ses Fonctionnalités :

+ 
    $ curl -V
+    curl 7.45.0 (x86_64-apple-darwin15.0.0) libcurl/7.45.0 OpenSSL/1.0.2d zlib/1.2.8 nghttp2/1.3.4
+    Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 [...]
+    Features: IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP HTTP2
+
+ +

homebrew sous Mac OS :

+ brew install curl --with-openssl --with-nghttp2 +
+

Pour une inspection en profondeur : wireshark.

+

Le paquet nghttp2 inclut aussi des + outils comme :

+
    +
  • nghttp + - permet de visualiser les trames HTTP/2 et ainsi de se faire une meilleure + idée du protocole.
    • +
  • h2load - + permet de tester votre serveur dans des conditions extremes.
    • +
+

Chrome fournit des journaux détaillés des connexions HTTP/2 via la page + special net-internals page. Il y + a aussi cette extension intéressante pour Chrome + et Firefox + qui permet d'indiquer que votre navigateur utilise HTTP/2.

+
top
+
+

Push serveur

+ +

Le protocole HTTP/2 permet au serveur de proposer (PUSH) des réponses + pour lesquelles le client n'a rien demandé. La communication autour de ces + réponses est du style : "voici une requête que vous n'avez jamais + envoyée, et la réponse vous parviendra bientôt tout de même ..."

+

Il y a cependant des conditions : le client peut désactiver cette + fonctionnalité et le serveur ne pourra alors lui proposer des réponses que + pour les requêtes qu'il a effectivement envoyées.

+

Cette fonctionnalité a pour but de permettre au serveur d'envoyer au + client des ressources dont il va probablement avoir besoin : par exemple une + ressource css ou javascript appartenant à une page html que le client a + demandée, un jeu d'images référencé par un css, etc...

+

Cette anticipation a pour avantage de permettre au client d'économiser le + temps qu'il lui aurait fallu pour envoyer une requête, quelques + millisecondes à une demi-seconde en fonction de l'éloignement du serveur. + Elle a cependant pour inconvénient d'imposer au client le téléchargement de + ressources qu'il possède peut-être déjà dans son cache. Bien entendu, HTTP/2 + permet d'annuler prématurément de telles requêtes, mais des ressources sont + tout de même gaspillées.

+

En résumé : il n'existe pas encore de stratégie efficace pour faire le + meilleur usage de cette fonctionnalité de HTTP/2 et tout le monde en est + encore au stade de l'expérimentation. À ce titre, voici des conseils pour + procéder vous-même à ces expérimentations :

+

mod_http2 inspecte l'en-tête de la réponse et recherche les + en-têtes Link sous un certain format :

+ 
Link </xxx.css>;rel=preload, </xxx.js>; rel=preload
+ +

Si la connexion supporte PUSH, ces deux ressources seront envoyées au + client. En tant que développeur web vous pouvez définir ces en-têtes soit + directement au niveau de la réponse de votre application, soit en + configurant votre serveur via

+ 
<Location /xxx.html>
+    Header add Link "</xxx.css>;rel=preload"
+    Header add Link "</xxx.js>;rel=preload"
+</Location>
+ +

Si vous souhaitez utiliser des liens preload sans déclencher + de PUSH, vous pouvez utiliser le paramètre nopush comme suit :

+ 
Link </xxx.css>;rel=preload;nopush
+ +

Vous pouvez aussi désactiver les PUSHes pour l'ensemble de votre + serveur via la directive

+ 
H2Push Off
+ +

À savoir aussi :

+

Le module maintient un journal des ressources ayant fait l'objet d'un + PUSH pour chaque connexion (en général des condensés hash des URLs), et + n'effectuera pas deux fois un PUSH pour la même ressource. Cependant, + lorsque la connexion est fermée, le journal de ses PUSHes est supprimé.

+

Certains développeurs planchent sur la manière de permettre au client + d'informer le serveur des ressources qu'il possède déjà dans son cache afin + d'éviter les PUSHes pour ces dernières, mais ceci n'en est actuellement qu'à + un stade très expérimental.

+

L' + en-tête Accept-Push-Policy est un autre dispositif expérimental + implémenté dans mod_http2 ; il permet au client de définir pour + chaque requête quels genres de PUSHes il accepte.

+ + +

+ La fonctionnalité PUSH n'apportera pas toujours le gain de performances dans + l'obtention de réponses aux requêtes. Vous trouverez plusieurs études sur ce + sujet sur internet qui en expliquent les avantages et inconvénients et + comment les particularités des clients et du réseau en influencent le + fonctionnement. Par exemple, le seul fait que le serveur PUSHes une + ressource n'implique pas forcément que le navigateur l'utilisera.

+

Ce qui influence le plus la réponse PUSHed, c'est la requête qui a été + simulée. En effet, l'URL de la requête pour un PUSH est fournie par + l'application, mais d'où viennent les en-têtes ? Par exemple, La requête + PUSH requiert-elle un en-tête accept-language et si oui, quelle + sera sa valeur ?

+

httpd va consulter la requête originale (celle qui a déclenché le PUSH) + et copier les en-têtes suivants vers la requête PUSH : + user-agent, accept, accept-encoding, + accept-language et cache-control.

+

Tous les autres en-têtes sont ignorés. Les cookies eux non plus ne seront + pas copiés. PUSHer des ressources qui requièrent la présence d'un cookie ne + fonctionnera pas. Ceci peut être sujet à débat, mais tant que ce ne sera pas + clairement discuté avec les navigateurs, restons prudents et évitons + d'exposer les cookies là où ils ne sont pas censés être visibles.

+
top
+
+

Suggestions précoces

+ +

A l'instar des ressources PUSHées, une autre méthode consiste à envoyer + des en-têtes Link au client avant même que la réponse ne soit + prête. Cette méthode utilise la fonctionnalité appelée "Suggestions + précoces" (Early Hints) décrite dans la RFC 8297.

+

Pour utiliser cette fonctionnalité, vous devez l'activer explicitement + sur le serveur via :

+ 
H2EarlyHints on
+ +

Elle n'est en effet pas activée par défaut car certains navigateurs + anciens perdent pied avec de telles réponses.

+

Une fois cette fonctionnalité activée, vous pouvez utiliser la directive + H2PushResource pour déclencher les + suggestions précoces et les PUSHes de ressources :

+ 
<Location /xxx.html>
+    H2PushResource /xxx.css
+    H2PushResource /xxx.js
+</Location>
+ +

Le serveur enverra alors au client une réponse "103 Early + Hints" dès qu'il commencera à traiter la requête. Selon + votre application web, cet envoi peut intervenir beaucoup plus tôt que le + moment où les premiers en-têtes de réponse auront été déterminés.

+

Si H2Push est activé, ceci + déclenchera aussi le PUSH juste après la réponse 103. Mais si H2Push n'est pas activé, la réponse 103 sera + quand-même envoyée au client.

+
+
+

Langues Disponibles:  en  | + es  | + fr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/index.html b/docs/manual/howto/index.html new file mode 100644 index 0000000..9a25dfa --- /dev/null +++ b/docs/manual/howto/index.html @@ -0,0 +1,25 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: index.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: index.html.es +Content-Language: es +Content-type: text/html; charset=ISO-8859-1 + +URI: index.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 + +URI: index.html.ja.utf8 +Content-Language: ja +Content-type: text/html; charset=UTF-8 + +URI: index.html.ko.euc-kr +Content-Language: ko +Content-type: text/html; charset=EUC-KR + +URI: index.html.zh-cn.utf8 +Content-Language: zh-cn +Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/howto/index.html.en b/docs/manual/howto/index.html.en new file mode 100644 index 0000000..a0dc578 --- /dev/null +++ b/docs/manual/howto/index.html.en @@ -0,0 +1,170 @@ + + + + + +How-To / Tutorials - Apache HTTP Server Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.4

+
+
<-
+

How-To / Tutorials

+
+

Available Languages:  en  | + es  | + fr  | + ja  | + ko  | + zh-cn 

+
+
+
top
+
+

How-To / Tutorials

+ + + +
+
Authentication and Authorization
+
+

Authentication is any process by which you verify that + someone is who they claim they are. Authorization is any + process by which someone is allowed to be where they want to + go, or to have information that they want to have.

+ +

See: Authentication, Authorization

+
+
+ +
+
Access Control
+
+

Access control refers to the process of restricting, or + granting access to a resource based on arbitrary criteria. There + are a variety of different ways that this can be + accomplished.

+ +

See: Access Control

+
+
+ +
+
Dynamic Content with CGI
+
+

The CGI (Common Gateway Interface) defines a way for a web + server to interact with external content-generating programs, + which are often referred to as CGI programs or CGI scripts. It + is a simple way to put dynamic content on + your web site. This document will be an introduction to setting + up CGI on your Apache web server, and getting started writing + CGI programs.

+ +

See: CGI: Dynamic Content

+
+
+ +
+
.htaccess files
+
+

.htaccess files provide a way to make configuration + changes on a per-directory basis. A file, containing one or more + configuration directives, is placed in a particular document directory, + and the directives apply to that directory, and all subdirectories thereof.

+ +

See: .htaccess files

+
+
+ +
+
HTTP/2 with httpd
+
+

HTTP/2 is the evolution of the world's most successful application layer protocol, HTTP. + It focuses on making more efficient use of network resources without changing the semantics of HTTP. + This guide explains how HTTP/2 is implemented in httpd, showing basic configurations tips and + best practices. +

+ +

See: HTTP/2 guide

+
+
+ + +
+
Introduction to Server Side Includes
+
+

SSI (Server Side Includes) are directives that are placed in + HTML pages, and evaluated on the server while the pages are + being served. They let you add dynamically generated content to + an existing HTML page, without having to serve the entire page + via a CGI program, or other dynamic technology.

+ +

See: Server Side Includes (SSI)

+
+
+ +
+
Per-user web directories
+
+

On systems with multiple users, each user can be permitted to have a + web site in their home directory using the UserDir directive. Visitors + to a URL http://example.com/~username/ will get content + out of the home directory of the user "username", out of + the subdirectory specified by the UserDir directive.

+ +

See: User web directories (public_html)

+
+
+ +
+
Reverse Proxy guide
+
+

Apache httpd has extensive capabilities as a reverse proxy server using the + ProxyPass directive as well as + BalancerMember to create sophisticated + reverse proxying implementations which provide for high-availability, load + balancing and failover, cloud-based clustering and dynamic on-the-fly reconfiguration.

+ +

See: Reverse proxy guide

+
+
+ +
+
Rewriting URLs with mod_rewrite
+
+

Rewriting URLs with (and without) + mod_rewrite tends to be one of the most + frequently asked topics on our mailing lists and IRC channels. + We have devoted and entire section of our + documentation to howtos and recipes around this topic.

+
+
+ +
+
+

Available Languages:  en  | + es  | + fr  | + ja  | + ko  | + zh-cn 

+
+ \ No newline at end of file diff --git a/docs/manual/howto/index.html.es b/docs/manual/howto/index.html.es new file mode 100644 index 0000000..a089254 --- /dev/null +++ b/docs/manual/howto/index.html.es @@ -0,0 +1,163 @@ + + + + + +How-To / Tutoriales - Servidor HTTP Apache Versión 2.4 + + + + + + +
+

Módulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

+

Versión 2.4 del Servidor HTTP Apache

+
+
<-
+

How-To / Tutoriales

+
+

Idiomas disponibles:  en  | + es  | + fr  | + ja  | + ko  | + zh-cn 

+
+
+
top
+
+

How-To / Tutoriales

+ + + +
+
Autenticación y Autorización
+
+

Autenticación es un proceso en el cual se verifica + que alguien es quien afirma ser. Autorización es cualquier + proceso en el que se permite a alguien acceder donde quiere ir, + o a obtener la información que desea tener.

+ +

Ver: Autenticación, Autorización

+
+
+ +
+
Control de Acceso
+
+

Control de acceso hace referencia al proceso de restringir, o + garantizar el acceso a un recurso en base a un criterio arbitrario. + Esto se puede conseguir de distintas formas.

+ +

Ver: Control de Acceso

+
+
+ +
+
Contenido Dinámico con CGI
+
+

El CGI (Common Gateway Interface) es un método por el cual + un servidor web puede interactuar con programas externos de + generación de contenido, a ellos nos referimos comúnmente como + programas CGI o scripts CGI. Es un método sencillo para mostrar + contenido dinámico en tu sitio web. Este documento es una + introducción para configurar CGI en tu servidor web Apache, y de + inicio para escribir programas CGI.

+ +

Ver: CGI: Contenido Dinámico

+
+
+ +
+
Ficheros .htaccess
+
+

Los ficheros .htaccess facilitan una forma de + hacer configuraciones por-directorio. Un archivo, que + contiene una o más directivas de configuración, se coloca en un + directorio específico y las directivas especificadas solo aplican + sobre ese directorio y los subdirectorios del mismo.

+ +

Ver: .htaccess files

+
+
+ +
+
HTTP/2 con httpd
+
+

HTTP/2 es la evolución del protocolo de capa de aplicación más conocido, HTTP. + Se centra en hacer un uso más eficiente de los recursos de red sin cambiar la + semántica de HTTP. Esta guía explica como se implementa HTTP/2 en httpd, + mostrando buenas prácticas y consejos de configuración básica. +

+ +

Ver: Guía HTTP/2

+
+
+ + +
+
Introducción a los SSI
+
+

Los SSI (Server Side Includes) son directivas que se colocan + en las páginas HTML, y son evaluadas por el servidor mientras + éste las sirve. Le permiten añadir contenido generado + dinámicamente a una página HTML existente, sin tener que servir + la página entera a través de un programa CGI u otro método + dinámico.

+ +

Ver: Server Side Includes (SSI)

+
+
+ +
+
Directorios web Por-usuario
+
+

En sistemas con múltiples usuarios, cada usuario puede tener + su directorio "home" compartido usando la directiva + UserDir. Aquellos + que visiten la URL http://example.com/~username/ + obtendrán contenido del directorio del usuario "username" + que se encuentra en el directorio "home" del sistema.

+ +

Ver: + Directorios Web de Usuario (public_html)

+
+
+ +
+
Guía de Proxy Inverso
+
+

Apache httpd ofrece muchas posibilidades como proxy inverso. Usando la + directiva ProxyPass así como + BalancerMember puede crear + sofisticadas configuraciones de proxy inverso que proveen de alta + disponibilidad, balanceo de carga, clustering basado en la nube y + reconfiguración dinámica en caliente.

+ +

Ver: Guía de Proxy Inverso

+
+
+ +
+
+

Idiomas disponibles:  en  | + es  | + fr  | + ja  | + ko  | + zh-cn 

+
+ \ No newline at end of file diff --git a/docs/manual/howto/index.html.fr.utf8 b/docs/manual/howto/index.html.fr.utf8 new file mode 100644 index 0000000..f38c685 --- /dev/null +++ b/docs/manual/howto/index.html.fr.utf8 @@ -0,0 +1,178 @@ + + + + + +How-To / Tutoriels - Serveur HTTP Apache Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.4

+
+
<-
+

How-To / Tutoriels

+
+

Langues Disponibles:  en  | + es  | + fr  | + ja  | + ko  | + zh-cn 

+
+
+
top
+
+

How-To / Tutoriels

+ + + +
+
Authentification et autorisation
+
+

L'authentification représente tout processus par lequel vous + vérifiez si quelqu'un correspond bien à la personne qu'il + prétend être. L'autorisation représente tout processus + permettant de savoir si une personne est autorisée à aller là où + elle veut aller, ou à obtenir les informations qu'elle demande.

+ +

Voir Authentification, Autorisation

+
+
+ +
+
Contrôle d'accès
+
+

Le contrôle d'accès se réfère au processus permettant + d'interdire ou d'accorder l'accès à une ressource en fonction de + certains critères, et il existe de nombreuses façons d'y + parvenir.

+ +

Voir Contrôle d'accès

+
+
+ +
+
Contenu dynamique avec CGI
+
+

L'interface CGI (Common Gateway Interface) + fournit au serveur web une méthode d'interaction avec des + programmes externes générateurs de contenu, souvent nommés + programmes CGI ou scripts CGI. Il s'agit d'une méthode + simple permettant d'ajouter du contenu + dynamique à votre site web. Ce document se veut une introduction + à la configuration de CGI sur votre serveur web Apache et à + l'écriture de programmes CGI.

+ +

Voir CGI : contenu dynamique

+
+
+ +
+
Fichiers .htaccess
+
+

Les fichiers .htaccess permettent de modifier la + configuration du serveur au niveau de chaque répertoire. À cet + effet, un fichier est placé dans un répertoire particulier du site + web, et les directives de configuration qu'il contient s'appliquent à ce + répertoire et à tous ses sous-répertoires.

+ +

Voir Fichiers .htaccess

+
+
+ +
+
HTTP/2 avec httpd
+
+

HTTP/2 est une évolution du protocole de la couche application le plus + connu au monde, HTTP. Les efforts se sont concentrés sur une amélioration + de l'efficacité de l'utilisation des ressources réseau sans modifier la + sémantique de HTTP. Ce guide explique la manière dont HTTP/2 est + implémenté dans httpd, donne des conseils pour une configuration de base + ainsi qu'une liste de recommandations. +

+ +

Voir le guide HTTP/2

+
+
+ +
+
Introduction au Inclusions côté Serveur (Server Side Includes + ou SSI)
+
+

Les SSI sont des directives que l'on place dans des pages + HTML, et qui sont évaluées par le serveur lorsque ces pages sont + servies. Elles vous permettent d'ajouter du contenu généré + dynamiquement à une page HTML existante, sans avoir à servir + l'intégralité de la page via un programme CGI, ou toute autre + technologie dynamique.

+ +

Voir Server Side Includes (SSI)

+
+
+ +
+
Répertoires web de l'utilisateur
+
+

Sur les systèmes multi-utilisateurs, vous pouvez permettre à + chaque utilisateur d'avoir un site web dans son répertoire home + via la directive UserDir. Les visiteurs de l'URL + http://example.com/~nom-utilisateur/ vont recevoir + du contenu situé dans le répertoire home de l'utilisateur + "nom-utilisateur", et dans le sous-répertoire + spécifié par la directive UserDir.

+ +

Voir Répertoires web des utilisateurs (public_html)

+
+
+
+
Mandataires inverses
+
+

Apache httpd possède des fonctionnalités évoluées de serveur + mandataire inverse via ses directives ProxyPass et BalancerMember qui permettent + d'implémenter un système de mandataire inverse sophistiqué garantissant + une haute disponibilité, une répartition et une réattribution de charge, + un regroupement de serveurs en grappe (clustering) basé sur le cloud et + une reconfiguration dynamique à la volée.

+ +

Voir le Guide de configuration des + mandataires inverses

+
+
+ +
+
Réécriture d'URLs avec mod_rewrite
+
+

La réécriture d'URLs avec (ou sans) mod_rewrite devient + l'une des questions les plus fréquentes posées dans nos listes de + diffusion et nos canaux IRC. C'est pourquoi nous avons dédié une section entière de notre documentation à des + howtos et recettes sur ce sujet.

+
+
+ +
+
+

Langues Disponibles:  en  | + es  | + fr  | + ja  | + ko  | + zh-cn 

+
+ \ No newline at end of file diff --git a/docs/manual/howto/index.html.ja.utf8 b/docs/manual/howto/index.html.ja.utf8 new file mode 100644 index 0000000..59a7627 --- /dev/null +++ b/docs/manual/howto/index.html.ja.utf8 @@ -0,0 +1,132 @@ + + + + + +How-To / チュートリアル - Apache HTTP サーバ バージョン 2.4 + + + + + + +
+

モジュール | ディレクティブ | FAQ | 用語 | サイトマップ

+

Apache HTTP サーバ バージョン 2.4

+
+
<-
+

How-To / チュートリアル

+
+

翻訳済み言語:  en  | + es  | + fr  | + ja  | + ko  | + zh-cn 

+
+
この日本語訳はすでに古くなっている + 可能性があります。 + 最近更新された内容を見るには英語版をご覧下さい。 +
+
+
top
+
+

How-To / チュートリアル

+ + + +
+
認証と承認
+
+

認証とは、誰かが自分は誰であるかを名乗っているものを検証する + 処理のことです。承認とは、誰かが望みの場所に辿り着けたり、 + 望みの情報を手に入れたりすることを許可する処理のことです。

+ +

参照: 認証と承認

+
+
+ +
+
アクセス制御
+
+

アクセス制御は、さまざまな条件でリソースに対するアクセスを + 許可したり制限したりすることを指します。 + 実現方法には様々な異なる手法があります。

+ +

参照: アクセス制御

+
+
+ +
+
CGI による動的コンテンツ
+
+

CGI (Common Gateway Interface) はウェブサーバが外部のコンテンツ + 生成プログラムとどのように相互動作をするかを定義します。 + その外部プログラムは通常 CGI プログラムや CGI スクリプトと呼ばれます。 + CGI はウェブサイトに動的なコンテンツを追加するための、 + 単純な方法です。この文書は Apache ウェブサーバに + CGI を設定し、CGI プログラムを書き始めるためのイントロダクションです。

+ +

参照: CGI: 動的コンテンツ

+
+
+ +
+
.htaccess ファイル
+
+

.htaccess ファイルはディレクトリ毎に設定を変更するための + 方法を提供します。設定ディレクティブが書かれたファイルが、あるドキュメント + ディレクトリに置かれると、ディレクティブはそのディレクトリと + すべてのサブディレクトリに適用されます。

+ +

参照: .htaccess ファイル

+
+
+ +
+
Server Side Includes イントロダクション
+
+

SSI (Server Side Includes) は HTML ページ中に書かれるディレクティブで、 + ページが送られる時にサーバにより評価されます。これにより、ページ全体を + CGI プログラムで生成したり、他の動的な技術を使うことなく、既存の HTML + ページに動的に生成された内容を付加することができます。

+ +

参照: Server Side Includes (SSI)

+
+
+ +
+
ユーザ毎のウェブディレクトリ
+
+

複数ユーザの存在するシステムでは、それぞれのユーザは UserDir ディレクティブを使うことによって + ホームディレクトリ上にウェブサイトを作成することができます。 + URL http://example.com/~username/ を訪れた人は + ユーザ "username" のホームディレクトリの、UserDir ディレクティブで指定された + サブディレクトリからコンテンツを得ることになります。

+ +

参照: ユーザウェブディレクトリ (public_html)

+
+
+ +
+
+

翻訳済み言語:  en  | + es  | + fr  | + ja  | + ko  | + zh-cn 

+
+ \ No newline at end of file diff --git a/docs/manual/howto/index.html.ko.euc-kr b/docs/manual/howto/index.html.ko.euc-kr new file mode 100644 index 0000000..c58e25e --- /dev/null +++ b/docs/manual/howto/index.html.ko.euc-kr @@ -0,0 +1,124 @@ + + + + + +How-To / 丮 - Apache HTTP Server Version 2.4 + + + + + + +
+

| þ | FAQ | | Ʈ

+

Apache HTTP Server Version 2.4

+
+
<-
+

How-To / 丮

+
+

:  en  | + es  | + fr  | + ja  | + ko  | + zh-cn 

+
+
ֽ ƴմϴ. + ֱٿ ϼ.
+
+
top
+
+

How-To / 丮

+ + + +
+
+
+

(authentication) ڽ ϴ + Ȯϴ ̴. Ѻο(authorization) + Ȥ ϴ 򵵷 ϴ ̴.

+ +

: , Ѻο,

+
+
+ +
+
CGI
+
+

CGI (Common Gateway Interface) CGI + α׷ Ȥ CGI ũƮϰ θ, ( + ) ܺ α׷ ȣۿϴ Ѵ. + Ʈ ϰ + ̴. ġ CGI ϴ + Ұϰ, CGI α׷ ۼغ.

+ +

: CGI:

+
+
+ +
+
.htaccess
+
+

.htaccess Ͽ 丮 + ִ. þ ִ + Ư 丮 θ, 丮 丮 + þ Ѵ.

+ +

: .htaccess +

+
+
+ +
+
Server Side Includes Ұ
+
+

SSI (Server Side Includes) HTML ϴ + þ, Ҷ óѴ. SSI + ϸ CGI α׷̳ ٸ + ü  ʰ HTML + ߰ ִ.

+ +

: Server Side Includes (SSI)

+
+
+ +
+
ں 丮
+
+

ڰ ִ ýۿ UserDir þ ϸ + ڴ ڽ Ȩ丮 ȿ Ʈ + ִ. URL http://example.com/~username/ + ϸ "username" Ȩ丮 + UserDir + þ 丮 ִ + ȴ.

+ +

: 丮 + (public_html)

+
+
+ +
+
+

:  en  | + es  | + fr  | + ja  | + ko  | + zh-cn 

+
+ \ No newline at end of file diff --git a/docs/manual/howto/index.html.zh-cn.utf8 b/docs/manual/howto/index.html.zh-cn.utf8 new file mode 100644 index 0000000..754f139 --- /dev/null +++ b/docs/manual/howto/index.html.zh-cn.utf8 @@ -0,0 +1,121 @@ + + + + + +常见操作/教程 - Apache HTTP 服务器 版本 2.4 + + + + + + +
+

模块 | 指令 | 常见问题 | 术语 | 网站导航

+

Apache HTTP 服务器版本 2.4

+
+
<-
+

常见操作/教程

+
+

可用语言:  en  | + es  | + fr  | + ja  | + ko  | + zh-cn 

+
+
此翻译可能过期。要了解最近的更改，请阅读英文版。
+
+
top
+
+

常见操作/教程

+ + + +
+
认证与授权
+
+

认证是你验证某人是所声称的人。 + 授权是允许某人执行他想要的操作，或者获得想要的信息。

+ +

参见: 认证，授权与访问控制

+
+
+ +
+
访问控制
+
+

访问控制是操作限制，或基于任意条件访问资源。这可以通过多种方法完成。

+ + +
+
+ +
+
CGI 与动态内容
+
+

CGI (通用网管接口) 为 web 服务器定义了与外部的内容生成程序的操作接口， + 通常称为 CGI 程序或 CGI 脚本。它是在 web 站点放入动态内容的最简单， + 也最常用的方法。 本文简单介绍了在 Apache 服务器中配置 CGI 的方法， + 以及如何编写 CGI 程序。

+ +

参见: CGI 与动态内容

+
+
+ +
+
.htaccess 文件
+
+

.htaccess files provide a way to make configuration + changes on a per-directory basis. A file, containing one or more + configuration directives, is placed in a particular document directory, + and the directives apply to that directory, and all subdirectories thereof.

+ +

See: .htaccess files

+
+
+ +
+
服务器端插入简介
+
+

SSI (服务器端插入) 是在 HTML 页面中放入的指令，在页面被访问的时候执行。 + 它允许你在现有的 HTML 页面增加动态生成的内容，不需要通过 CGI + 程序或其它动态计数来生成整个页面。

+ +

参见: 服务器端插入 (SSI)

+
+
+ +
+
用户私人网站目录
+
+

在有多个用户的系统中，使用 UserDir 指令，可以允许每个用户在他们的根目录中都有一个 + web 站点。 访问 URL http://example.com/~username/ 会得到位于用户 + "username" 根目录中由 UserDir 指定的子目录中的内容。

+ +

参见: 用户私人网站目录 (public_html)

+
+
+ +
+
+

可用语言:  en  | + es  | + fr  | + ja  | + ko  | + zh-cn 

+
+ \ No newline at end of file diff --git a/docs/manual/howto/public_html.html b/docs/manual/howto/public_html.html new file mode 100644 index 0000000..bd099f3 --- /dev/null +++ b/docs/manual/howto/public_html.html @@ -0,0 +1,25 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: public_html.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: public_html.html.es +Content-Language: es +Content-type: text/html; charset=ISO-8859-1 + +URI: public_html.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 + +URI: public_html.html.ja.utf8 +Content-Language: ja +Content-type: text/html; charset=UTF-8 + +URI: public_html.html.ko.euc-kr +Content-Language: ko +Content-type: text/html; charset=EUC-KR + +URI: public_html.html.tr.utf8 +Content-Language: tr +Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/howto/public_html.html.en b/docs/manual/howto/public_html.html.en new file mode 100644 index 0000000..d0b5162 --- /dev/null +++ b/docs/manual/howto/public_html.html.en @@ -0,0 +1,218 @@ + + + + + +Per-user web directories - Apache HTTP Server Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.4

+
+
<-
+

Per-user web directories

+
+

Available Languages:  en  | + es  | + fr  | + ja  | + ko  | + tr 

+
+ +

On systems with multiple users, each user can be permitted to have a + web site in their home directory using the UserDir directive. Visitors + to a URL http://example.com/~username/ will get content + out of the home directory of the user "username", out of + the subdirectory specified by the UserDir directive.

+

Note that, by default, access to these directories is not + enabled. You can enable access when using UserDir by uncommenting the line:

+ 
#Include conf/extra/httpd-userdir.conf
+ +

in the default config file conf/httpd.conf, and adapting the httpd-userdir.conf + file as necessary, or by including the appropriate directives in a + <Directory> block + within the main config file.

+
+ +
top
+
+

Per-user web directories

+ +
Related ModulesRelated Directives
+
top
+
+

Setting the file path with UserDir

+ + +

The UserDir + directive specifies a directory out of which per-user + content is loaded. This directive may take several different forms.

+ +

If a path is given which does not start with a leading slash, it is + assumed to be a directory path relative to the home directory of the + specified user. Given this configuration:

+ + 
UserDir public_html
+ + +

the URL http://example.com/~rbowen/file.html will be + translated to the file path + /home/rbowen/public_html/file.html

+ +

If a path is given starting with a slash, a directory path will be + constructed using that path, plus the username specified. Given this + configuration:

+ + 
UserDir /var/html
+ + +

the URL http://example.com/~rbowen/file.html will be + translated to the file path /var/html/rbowen/file.html

+ +

If a path is provided which contains an asterisk (*), a path is used + in which the asterisk is replaced with the username. Given this + configuration:

+ + 
UserDir /var/www/*/docs
+ + +

the URL http://example.com/~rbowen/file.html will be + translated to the file path + /var/www/rbowen/docs/file.html

+ +

Multiple directories or directory paths can also be set.

+ + 
UserDir public_html /var/html
+ + +

For the URL http://example.com/~rbowen/file.html, + Apache will search for ~rbowen. If it isn't found, + Apache will search for rbowen in /var/html. If + found, the above URL will then be translated to the file path + /var/html/rbowen/file.html

+ +
top
+
+

Redirecting to external URLs

+ +

The UserDir directive can be + used to redirect user directory requests to external URLs.

+ + 
UserDir http://example.org/users/*/
+ + +

The above example will redirect a request for + http://example.com/~bob/abc.html to + http://example.org/users/bob/abc.html.

+
top
+
+

Restricting what users are permitted to use this + feature

+ + +

Using the syntax shown in the UserDir documentation, you can restrict + what users are permitted to use this functionality:

+ + 
UserDir disabled root jro fish
+ + +

The configuration above will enable the feature for all users + except for those listed in the disabled statement. + You can, likewise, disable the feature for all but a few users by + using a configuration like the following:

+ + 
UserDir disabled
+UserDir enabled rbowen krietz
+ + +

See UserDir + documentation for additional examples.

+ +
top
+
+

Enabling a cgi directory for each user

+ + +

In order to give each user their own cgi-bin directory, you can use + a <Directory> + directive to make a particular subdirectory of a user's home directory + cgi-enabled.

+ + 
<Directory "/home/*/public_html/cgi-bin/">
+    Options ExecCGI
+    SetHandler cgi-script
+</Directory>
+ + +

Then, presuming that UserDir is set to + public_html, a cgi program example.cgi + could be loaded from that directory as:

+ +

+ http://example.com/~rbowen/cgi-bin/example.cgi +

+ +
top
+
+

Allowing users to alter configuration

+ + +

If you want to allows users to modify the server configuration in + their web space, they will need to use .htaccess files to + make these changes. Ensure that you have set AllowOverride to a + value sufficient for the directives that you want to permit the users + to modify. See the .htaccess tutorial for + additional details on how this works.

+ +
+
+

Available Languages:  en  | + es  | + fr  | + ja  | + ko  | + tr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/public_html.html.es b/docs/manual/howto/public_html.html.es new file mode 100644 index 0000000..196f472 --- /dev/null +++ b/docs/manual/howto/public_html.html.es @@ -0,0 +1,216 @@ + + + + + +Directorios web por usuario - Servidor HTTP Apache Versión 2.4 + + + + + + +
+

Módulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

+

Versión 2.4 del Servidor HTTP Apache

+
+
<-
+

Directorios web por usuario

+
+

Idiomas disponibles:  en  | + es  | + fr  | + ja  | + ko  | + tr 

+
+ +

En sistemas con múltiples usuarios, cada usuario puede tener un website + en su directorio home usando la directiva UserDir. Los visitantes de una URL + http://example.com/~username/ recibirán el contenido del + directorio home del usuario "username", en el subdirectorio + especificado por la directiva UserDir.

+ +

Tenga en cuenta que, por defecto, el acceso a estos directorios + NO está activado. Puede permitir acceso cuando usa + UserDir quitando el comentario de la línea:

+ + 
#Include conf/extra/httpd-userdir.conf
+ + +

En el fichero por defecto de configuración conf/httpd.conf, + y adaptando el fichero httpd-userdir.conf según sea necesario, + o incluyendo las directivas apropiadas en un bloque + <Directory> dentro del fichero + principal de configuración.

+
+ +
top
+
+

Directorios web por usuario

+ +
Módulos RelacionadosDirectivas Relacionadas
+
top
+
+

Configurando la ruta del fichero con UserDir

+ + +

La directiva UserDir + especifica un directorio del que cargar contenido por usuario. Esta directiva + puede tener muchas formas distintas.

+ +

Si se especifica una ruta que no empieza con una barra ("/"), se asume que + va a ser una ruta de directorio relativa al directorio home del usuario + especificado. Dada ésta configuración:

+ + 
UserDir public_html
+ + +

La URL http://example.com/~rbowen/file.html se traducirá en + la ruta del fichero /home/rbowen/public_html/file.html

+ +

Si la ruta que se especifica comienza con una barra ("/"), la ruta del + directorio se construirá usando esa ruta, más el usuario especificado en la + configuración:

+ + 
UserDir /var/html
+ + +

La URL http://example.com/~rbowen/file.html se traducirá en + la ruta del fichero /var/html/rbowen/file.html

+ +

Si se especifica una ruta que contiene un asterisco (*), se usará una ruta + en la que el asterisco se reemplaza con el nombre de usuario. Dada ésta configuración:

+ + 
UserDir /var/www/*/docs
+ + +

La URL http://example.com/~rbowen/file.html se traducirá en + la ruta del fichero /var/www/rbowen/docs/file.html

+ +

También se pueden configurar múltiples directorios o rutas de directorios.

+ + 
UserDir public_html /var/html
+ + +

Para la URL http://example.com/~rbowen/file.html, + Apache buscará ~rbowen. Si no lo encuentra, Apache buscará + rbowen en /var/html. Si lo encuentra, la URL de más + arriba se traducirá en la ruta del fichero + /var/html/rbowen/file.html

+ +
top
+
+

Redirigiendo a URLs externas

+ +

La directiva UserDir puede + usarse para redirigir solcitudes de directorios de usuario a URLs externas.

+ + 
UserDir http://example.org/users/*/
+ + +

El ejemplo de aquí arriba redirigirá una solicitud para + http://example.com/~bob/abc.html hacia + http://example.org/users/bob/abc.html.

+
top
+
+

Restringiendo qué usuarios pueden usar esta característica

+ + +

Usando la sintaxis que se muestra en la documentación de UserDir, usted + puede restringir a qué usuarios se les permite usar esta funcionalidad:

+ + 
UserDir disabled root jro fish
+ + +

La configuración de aquí arriba permitirá a todos los usuarios excepto a + los que se listan con la declaración disabled. Usted puede, + del mismo modo, deshabilitar esta característica para todos excepto algunos + usuarios usando una configuración como la siguiente:

+ + 
UserDir disabled
+UserDir enabled rbowen krietz
+ + +

Vea la documentación de UserDir para más + ejemplos.

+ +
top
+
+

Activando un directorio cgi para cada usuario

+ + +

Para dar a cada usuario su propio directorio cgi-bin, puede usar una directiva + <Directory> + para activar cgi en un subdirectorio en particular del directorio home del usuario.

+ + 
<Directory "/home/*/public_html/cgi-bin/">
+    Options ExecCGI
+    SetHandler cgi-script
+</Directory>
+ + +

Entonces, asumiendo que UserDir está configurado con la + declaración public_html, un programa cgi example.cgi + podría cargarse de ese directorio así:

+ +

+ http://example.com/~rbowen/cgi-bin/example.cgi +

+ +
top
+
+

Permitiendo a usuarios cambiar la configuración

+ + +

Si quiere permitir que usuarios modifiquen la configuración del servidor en + su espacio web, necesitarán usar ficheros .htaccess para hacer + estos cambios. Asegúrese de tener configurado AllowOverride con un valor suficiente que permita a + los usuarios modificar las directivas que quiera permitir. + Vea el tutorial de .htaccess para obtener detalles adicionales sobre cómo funciona.

+ +
+
+

Idiomas disponibles:  en  | + es  | + fr  | + ja  | + ko  | + tr 

+
top

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/public_html.html.fr.utf8 b/docs/manual/howto/public_html.html.fr.utf8 new file mode 100644 index 0000000..94844a5 --- /dev/null +++ b/docs/manual/howto/public_html.html.fr.utf8 @@ -0,0 +1,235 @@ + + + + + +Répertoires web utilisateurs - Serveur HTTP Apache Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.4

+
+
<-
+

Répertoires web utilisateurs

+
+

Langues Disponibles:  en  | + es  | + fr  | + ja  | + ko  | + tr 

+
+ +

Sur les systèmes multi-utilisateurs, on peut permettre à chaque +utilisateur d'avoir un site web dans son répertoire home à l'aide de la +directive UserDir. Les +visiteurs de l'URL http://example.com/~nom_utilisateur/ +recevront un contenu situé dans le répertoire home de l'utilisateur +"nom_utilisateur", et dans le sous-répertoire spécifié par +la directive UserDir.

+

Notez que par défaut, l'accès à ces répertoires n'est +pas permis. Vous pouvez en permettre l'accès à l'aide +de la directive UserDir en +décommentant la ligne :

+ 
#Include conf/extra/httpd-userdir.conf
+ +

dans le fichier de configuration par défaut + conf/httpd.conf, et en adaptant le + fichier httpd-userdir.conf selon vos besoins, ou en + incluant les directives appropriées dans une section + <Directory> du fichier de + configuration principal.

+
+ +
top
+
+

Répertoires web utilisateurs

+ +
Modules ApparentésDirectives Apparentées
+
top
+
+

Définition du chemin des fichiers avec UserDir

+ + +

La directive UserDir + permet de spécifier un répertoire à partir duquel le contenu de + l'utilisateur pourra être chargé. Elle peut revêtir plusieurs + formes.

+ +

Si le chemin spécifié ne commence pas par un slash, il sera + interprété comme chemin relatif au répertoire home de l'utilisateur + considéré. Par exemple, avec cette configuration :

+ + 
UserDir public_html
+ + +

l'URL http://example.com/~rbowen/fichier.html + correspondra au chemin fichier + /home/rbowen/public_html/fichier.html

+ +

Si le chemin spécifié commence par un slash, le chemin du fichier + sera construit en utilisant ce chemin, suivi du nom de l'utilisateur + considéré. Par exemple, avec cette configuration :

+ + 
UserDir /var/html
+ + +

l'URL http://example.com/~rbowen/fichier.html + correspondra au chemin fichier + /var/html/rbowen/fichier.html

+ +

Si le chemin spécifié contient un astérisque (*), ce dernier sera + remplacé par le nom de l'utilisateur dans le chemin du fichier + correspondant. Par exemple, avec cette configuration :

+ + 
UserDir /var/www/*/docs
+ + +

l'URL http://example.com/~rbowen/fichier.html + correspondra au chemin fichier + /var/www/rbowen/docs/fichier.html

+ +

On peut aussi définir plusieurs répertoires ou chemins de + répertoires.

+ + 
UserDir public_html /var/html
+ + +

Avec l'URL http://example.com/~rbowen/fichier.html, + Apache va rechercher ~rbowen. S'il ne le trouve pas, + Apache va rechercher rbowen dans + /var/html. S'il le trouve, l'URL ci-dessus correspondra + au chemin fichier /var/html/rbowen/file.html

+ +
top
+
+

Redirection vers des URLs externes

+ +

On peut utiliser la directive UserDir pour rediriger les requêtes + relatives aux répertoires utilisateurs vers des URLs externes.

+ + 
UserDir http://example.org/users/*/
+ + +

L'exemple ci-dessus va rediriger une requête pour + http://example.com/~bob/abc.html vers + http://exemple.org/users/bob/abc.html.

+
top
+
+

Définition de la liste des utilisateurs autorisés à utiliser + cette fonctionnalité

+ + +

En suivant la syntaxe décrite dans la documentation de UserDir, + vous pouvez définir quels utilisateurs sont autorisés à utiliser + cette fonctionnalité :

+ + 
UserDir disabled root jro fish
+ + +

La configuration ci-dessus va autoriser l'utilisation de la + fonctionnalité pour tous les utilisateurs, à l'exception de ceux + listés à la suite de l'argument disabled. De même, vous + pouvez interdire l'utilisation de la fonctionnalité à tous les + utilisateurs sauf certains d'entre eux en utilisant une + configuration du style :

+ + 
UserDir disabled
+UserDir enabled rbowen krietz
+ + +

Vous trouverez d'autres exemples dans la documentation de + UserDir.

+ +
top
+
+

Définition d'un répertoire CGI pour chaque utilisateur

+ + +

Afin de réserver un répertoire cgi-bin pour chaque utilisateur, + vous pouvez utiliser une section <Directory> pour activer CGI dans un + sous-répertoire particulier d'un répertoire home utilisateur.

+ + 
<Directory "/home/*/public_html/cgi-bin/">
+    Options ExecCGI
+    SetHandler cgi-script
+</Directory>
+ + +

Avec la configuration ci-dessus, et en supposant que + UserDir est défini à public_html, un + programme CGI exemple.cgi pourra être chargé depuis ce + répertoire en passant par l'URL :

+ +

+ http://example.com/~rbowen/cgi-bin/exemple.cgi +

+ +
top
+
+

Permettre aux utilisateurs de modifier la + configuration

+ + +

Si vous voulez que vos utilisateurs puissent modifier la + configuration du serveur pour ce qui concerne leur espace web, ils + devront utiliser des fichiers .htaccess pour effectuer + ces modifications. Assurez-vous d'avoir défini la directive + AllowOverride à une valeur + appropriée pour les directives dont vous voulez permettre la + modification aux utilisateurs. Voir le tutoriel .htaccess pour plus de détails sur + la manière dont tout ceci fonctionne.

+ +
+
+

Langues Disponibles:  en  | + es  | + fr  | + ja  | + ko  | + tr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/public_html.html.ja.utf8 b/docs/manual/howto/public_html.html.ja.utf8 new file mode 100644 index 0000000..272e5c1 --- /dev/null +++ b/docs/manual/howto/public_html.html.ja.utf8 @@ -0,0 +1,228 @@ + + + + + +ユーザ毎のウェブディレクトリ - Apache HTTP サーバ バージョン 2.4 + + + + + + +
+

モジュール | ディレクティブ | FAQ | 用語 | サイトマップ

+

Apache HTTP サーバ バージョン 2.4

+
+
<-
+

ユーザ毎のウェブディレクトリ

+
+

翻訳済み言語:  en  | + es  | + fr  | + ja  | + ko  | + tr 

+
+
この日本語訳はすでに古くなっている + 可能性があります。 + 最近更新された内容を見るには英語版をご覧下さい。 +
+ +

複数のユーザのいるシステムでは、UserDir ディレクティブを使って + 各ユーザがホームディレクトリにウェブサイトを構築できるように設定することが + 可能です。URL http://example.com/~username/ を訪れた人は + "username" というユーザの UserDir ディレクティブで指定された + サブディレクトリからコンテンツを得ることになります。

+ +

in the default config file, and adapting the httpd-userdir.conf + file as necessary, or by including the appropriate directives in a + Directory block within the main config file.

+

デフォルトではこれらのディレクトリへのアクセスは許可されていません。 + UserDir を使って有効にできます。 + 有効にするには、デフォルトの設定ファイルで付随する + httpd-userdir.conf ファイルが必要で、 + その中の次の行のコメントアウトを外して有効にするか、 +

+

+ #Include conf/extra/httpd-userdir.conf +

+

あるいは、メインの設定ファイル中の Directory + ブロックの中に適切にディレクティブを記述しておきます。

+
+ +
top
+
+

ユーザ毎のウェブディレクトリ

+ +
関連モジュール関連ディレクティブ
+
top
+
+

UserDir を使ってファイルのパスを設定する

+ + +

UserDir ディレクティブは + ユーザ毎のコンテンツが読み込まれるディレクトリを指定します。 + このディレクティブはいろいろ違った形式を取ることができます。

+ +

スラッシュで始まらないパスが与えられたときは、ユーザのホームディレクトリ + からの相対パスとみなされます。次の設定があったときに:

+ + 
UserDir public_html
+ + +

URL http://example.com/~rbowen/file.html は + パス /home/rbowen/public_html/file.html へ + 変換されます。

+ +

パスがスラッシュで始まるときは、ディレクトリパスはそのパスに + ユーザ名を加えたものからなります。次の設定のとき:

+ + 
UserDir /var/html
+ + +

URL http://example.com/~rbowen/file.html は + パス /var/html/rbowen/file.html へ変換されます。

+ +

アスタリスク (*) を含むパスが指定されたときは、アスタリスクを + ユーザ名で置換したものが使用されます。このような設定だと:

+ + 
UserDir /var/www/*/docs
+ + +

URL http://example.com/~rbowen/file.html は + パス /var/www/rbowen/docs/file.html へ変換されます。

+ +

ディレクトリやディレクトリパスを複数設定することもできます。

+ + 
UserDir public_html /var/html
+ + + +

http://example.com/~rbowen/file.html という + URL に対しては ~rbowen を探します。見つからなければ、 + /var/html の下にある rbowen を探します。 + もし見つかれば上記の URL は /var/html/rbowen/file.html + というファイルパスに変換されます。

+ +
top
+
+

外部 URL にリダイレクトする

+ +

UserDir + ディレクティブを使って外部 URL にリダイレクトすることもできます。

+ + 
UserDir http://example.org/users/*/
+ + + +

上記例では http://example.com/~bob/abc.html + へのリクエストは http://example.org/users/bob/abc.html + にリダイレクトされます。

+
top
+
+

この機能を使用できるユーザを制限する

+ + +

UserDir のドキュメントに示されている構文を使うことで、 + どのユーザがこの機能を使うことができるかを制限することができます:

+ +

+ UserDir enabled
+ UserDir disabled root jro fish +

+ +

上の設定は dissabled 文のユーザ以外のすべてのユーザに + 対して UserDir の機能を有効にします。同様にして、以下のように + 数名のユーザ以外に対してこの機能を無効にすることもできます:

+ + 
      UserDir disabled

+      UserDir enabled rbowen krietz
+ + +

他の例は UserDir + の説明を参照してください。

+ +
top
+
+

ユーザ毎の CGI ディレクトリ

+ + +

それぞれのユーザに専用の cgi-bin ディレクトリを与えるために、 + <Directory> + を使ってユーザのホームディレクトリの指定された領域に対して CGI を有効に + することができます。

+ + 
<Directory /home/*/public_html/cgi-bin/>
+    Options ExecCGI
+    SetHandler cgi-script
+</Directory>
+ + +

そして、UserDir が + public_html に設定されていると仮定すると、 + そのディレクトリの CGI プログラム example.cgi + は以下の様に呼び出されることができます:

+ +

+ http://example.com/~rbowen/cgi-bin/example.cgi +

+ +
top
+
+

ユーザによる設定変更を許可

+ + +

ユーザに彼らのウェブ空間でのサーバの設定の変更を許可する場合、 + ユーザは .htaccess ファイルを使って設定を変更する必要があります。 + AllowOverride の値を + ユーザが変更することを許可したいディレクティブに対して十分なものに + 設定していることを確認してください。この機能がどのようにして動作しているか + の詳細は .htaccess チュートリアル を読んで + ください。

+ +
+
+

翻訳済み言語:  en  | + es  | + fr  | + ja  | + ko  | + tr 

+
top

コメント

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/public_html.html.ko.euc-kr b/docs/manual/howto/public_html.html.ko.euc-kr new file mode 100644 index 0000000..3d2f1f3 --- /dev/null +++ b/docs/manual/howto/public_html.html.ko.euc-kr @@ -0,0 +1,190 @@ + + + + + +ں 丮 - Apache HTTP Server Version 2.4 + + + + + + +
+

| þ | FAQ | | Ʈ

+

Apache HTTP Server Version 2.4

+
+
<-
+

ں 丮

+
+

:  en  | + es  | + fr  | + ja  | + ko  | + tr 

+
+
ֽ ƴմϴ. + ֱٿ ϼ.
+ +

ڰ ִ ýۿ UserDir þ ϸ + ڴ ڽ Ȩ丮 ȿ Ʈ ִ. + URL http://example.com/~username/ ϸ + "username" Ȩ丮 UserDir þ + 丮 ִ ȴ.

+ +
+ +
top
+
+

ں 丮

+ +
õ õ þ
+
top
+
+

UserDir ϰ ϱ

+ + +

UserDir + þ ں 丮 Ѵ. + þ .

+ +

ʴ θ ϸ + Ȩ丮 丮 η óѴ. , + Ʒ :

+ +

+ UserDir public_html +

+ +

URL http://example.com/~rbowen/file.html + /home/rbowen/public_html/file.html + Ѵ.

+ +

ϴ θ ϸ 丮 + ڸ 丮 θ Ѵ. , Ʒ + :

+ +

+ UserDir /var/html +

+ +

URL http://example.com/~rbowen/file.html + /var/html/rbowen/file.html Ѵ.

+ +

ǥ (*) θ ϸ ǥ ڸ + ü θ Ѵ. , Ʒ :

+ +

+ UserDir /var/www/*/docs +

+ +

URL http://example.com/~rbowen/file.html + /var/www/rbowen/docs/file.html + Ѵ.

+ +
top
+
+

̿ ϱ

+ + +

UserDir ִ Ͽ ں 丮 + ̿ ִ ڸ ִ:

+ +

+ UserDir enabled
+ UserDir disabled root jro fish +

+ +

disabled 忡 + ϰ ڿ 丮 Ѵ. , + ڸ ϰ + ִ:

+ +

+ UserDir disabled
+ UserDir enabled rbowen krietz +

+ +

UserDir + ִ ٸ 鵵 ϶.

+ +
top
+
+

ں cgi 丮 ϱ

+ + +

ڸ cgi-bin 丮 οϷ <Directory> þ + Ͽ Ȩ丮 Ư 丮 cgi ϰ + .

+ +

+ <Directory /home/*/public_html/cgi-bin/>
+ Options ExecCGI
+ SetHandler cgi-script
+ </Directory> +

+ +

UserDir public_html̶ + ϸ, ȿ ִ cgi α׷ + example.cgi ִ.

+ +

+ http://example.com/~rbowen/cgi-bin/example.cgi +

+ +
top
+
+

ڰ ֵ

+ + +

ڰ ڽ Ϸ, + .htaccess ־ Ѵ. AllowOverride ڰ + ִ þ ϶.  ϴ + ڼ .htaccess + 丮 ϶.

+ +
+
+

:  en  | + es  | + fr  | + ja  | + ko  | + tr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/public_html.html.tr.utf8 b/docs/manual/howto/public_html.html.tr.utf8 new file mode 100644 index 0000000..7c512a8 --- /dev/null +++ b/docs/manual/howto/public_html.html.tr.utf8 @@ -0,0 +1,229 @@ + + + + + +Kullanıcı Dizinleri (public_html) - Apache HTTP Sunucusu Sürüm 2.4 + + + + + + +
+

Modüller | Yönergeler | SSS | Terimler | Site Haritası

+

Apache HTTP Sunucusu Sürüm 2.4

+
+
<-
+

Kullanıcı Dizinleri (public_html)

+
+

Mevcut Diller:  en  | + es  | + fr  | + ja  | + ko  | + tr 

+
+ +

Çok kullanıcılı sistemlerde, UserDir yönergesi ile her kullanıcının kendi ev dizininde + bir sitesi olması sağlanabilir. + http://example.com/~kullanıcı/ adresinin ziyaretçileri + "kullanıcı" isimli kullanıcının ev dizininin içeriğini değil, UserDir yönergesinde belirtilen alt + dizinin içeriğini görürler.

+ +

Öntanımlı olarak bu dizinlere erişimin etkin olmadığını unutmayınız. + UserDir yönergesini + kullanırken conf/httpd.conf öntanımlı yapılandırma + dosyasındaki

+ + 
#Include conf/extra/httpd-userdir.conf
+ + +

satırını etkin hale getirip, gerekiyorsa httpd-userdir.conf + dosyasını da düzenleyerek veya ana yapılandırma dosyasında bir + <Directory> bloğu içine + uygun yönergeleri yerleştirerek bu dizinlere erişimi etkin hale + getirebilirsiniz.

+
+ +
top
+
+

Kullanıcı sayfaları dizinleri

+ +
İlgili Modüllerİlgili Yönergeler
+
top
+
+

UserDir ile dosya yolunun belirtilmesi

+ + +

UserDir yönergesinde + kullanıcı sayfalarının yükleneceği dizin belirtilir. Bu yönergeye değeri + çeşitli biçimlerde atanabilir.

+ +

Başında bölü çizgisi bulunmayan bir dosya yolu belirtilmişse, + kullanıcının ev dizinine göreli bir dizin belirtildiği varsayılır. + Yapılandırmada şöyle bir satır varsa:

+ + 
UserDir public_html
+ + +

http://example.com/~orhan/dosya.html adresine karşılık + gelen dosya yolu /home/orhan/public_html/dosya.html olarak + çözümlenir.

+ +

Eğer başında bölü çizgisi bulunan bir dosya yolu belirtilirse, + kullanıcı sayfalarının bu dizinin altında kullanıcı ismini taşıyan + dizinlerde bulunacağı varsayılır. Yapılandırmada şöyle bir satır + varsa:

+ + 
UserDir /var/html
+ + +

http://example.com/~orhan/dosya.html adresine karşılık + gelen dosya yolu /var/html/orhan/dosya.html olarak + çözümlenir.

+ +

Eğer belirtilen dosya yolu bir yıldız imi (*) içeriyorsa yıldız iminin + yerine kullanıcı ismi yerleştirilerek elde edilen dosya yolu + kullanılır. Yapılandırmada şöyle bir satır varsa:

+ + 
UserDir /var/html/*/sayfam
+ + +

http://example.com/~orhan/dosya.html adresine karşılık + gelen dosya yolu /var/html/orhan/sayfam/dosya.html + olarak çözümlenir.

+ +

Çok sayıda dizin veya dizin yolu belirtmek de mümkündür.

+ + 
UserDir public_html /var/html
+ + +

http://example.com/~orhan/dosya.html adresini Apache önce + /home/orhan/public_html/dosya.html olarak arayacak, + bulamazsa /var/siteler/orhan/sayfam/dosya.html olarak + arayacak, bulduğunda istenen dosyayı sunacaktır.

+ +
top
+
+

Harici adreslere yönlendirme

+ +

UserDir yönergesi + kullanıcı dizini isteklerini harici adreslere yönlendirmek için de + kullanılabilir.

+ + 
UserDir http://example.org/users/*/
+ + +

Bu yapılandırmaya göre http://example.com/~bob/abc.html + için yapılan bir istek http://example.org/users/bob/abc.html + adresine yönlendirilecektir.

+
top
+
+

Bu özelliği kullanacak kullanıcıların sınırlandırılması

+ + +

UserDir yönergesinin + açıklamasında belirtilen sözdizimini kullanarak bu işlevselliği bazı + kullanıcılara yasaklayabilirsiniz:

+ + 
UserDir disabled root ahmet veli
+ + +

Bu yapılandırma ile disabled deyiminin bulunduğu + satırdaki kullanıcılar dışında kalan bütün kullanıcılar için bu özellik + etkin olacaktır. Benzer şekilde, aşağıdaki yapılandırma ile + işlevselliğin belli kullanıcılar dışında kullanılmamasını da + sağlayabilirsiniz:

+ + 
UserDir disabled
+UserDir enabled orhan yasar
+ + +

Daha fazla örnek için UserDir yönergesinin açıklamasına bakabilirsiniz.

+ +
top
+
+

Her kullanıcıya bir CGI dizini tahsis etmek

+ + +

Her kullanıcıya kendine ait bir CGI dizini vermek isterseniz, bir + <Directory> yönergesi + ile kullanıcının ev dizinindeki belli bir dizini CGI-etkin duruma + getirebilirsiniz.

+ + 
<Directory "/home/*/public_html/cgi-bin/">
+    Options ExecCGI
+    SetHandler cgi-script
+</Directory>
+ + +

UserDir yönergesinde + public_html belirtildiği varsayımıyla + mesela.cgi betiği bu dizinden şöyle bir adresle + yüklenebilir:

+ +

+ http://example.com/~orhan/cgi-bin/mesela.cgi +

+ +
top
+
+

Kullanıcıların yapılandırmayı değiştirmesine izin vermek

+ + +

Kullanıcıların kendilerine ayrılan bölge içinde sunucu + yapılandırmasını değiştirebilmelerine izin vermek isterseniz, + .htaccess dosyalarını kullanmalarına izin vermeniz + gerekir. Kullanıcının değiştirmesine izin vereceğiniz yönerge türlerini + AllowOverride yönergesinde + belirtmeyi ihmal etmeyin. .htaccess dosyalarının kullanımı + ile ilgili daha ayrıntılı bilgi için .htaccess + öğreticisine bakınız.

+ +
+
+

Mevcut Diller:  en  | + es  | + fr  | + ja  | + ko  | + tr 

+
top

Yorumlar

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/reverse_proxy.html b/docs/manual/howto/reverse_proxy.html new file mode 100644 index 0000000..a89178e --- /dev/null +++ b/docs/manual/howto/reverse_proxy.html @@ -0,0 +1,9 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: reverse_proxy.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: reverse_proxy.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/howto/reverse_proxy.html.en b/docs/manual/howto/reverse_proxy.html.en new file mode 100644 index 0000000..27f8788 --- /dev/null +++ b/docs/manual/howto/reverse_proxy.html.en @@ -0,0 +1,360 @@ + + + + + +Reverse Proxy Guide - Apache HTTP Server Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.4

+
+
<-
+

Reverse Proxy Guide

+
+

Available Languages:  en  | + fr 

+
+ +

In addition to being a "basic" web server, and providing static and + dynamic content to end-users, Apache httpd (as well as most other web + servers) can also act as a reverse proxy server, also-known-as a + "gateway" server.

+ +

In such scenarios, httpd itself does not generate or host the data, + but rather the content is obtained by one or several backend servers, + which normally have no direct connection to the external network. As + httpd receives a request from a client, the request itself is proxied + to one of these backend servers, which then handles the request, generates + the content and then sends this content back to httpd, which then + generates the actual HTTP response back to the client.

+ +

There are numerous reasons for such an implementation, but generally + the typical rationales are due to security, high-availability, load-balancing + and centralized authentication/authorization. It is critical in these + implementations that the layout, design and architecture of the backend + infrastructure (those servers which actually handle the requests) are + insulated and protected from the outside; as far as the client is concerned, + the reverse proxy server is the sole source of all content.

+ +

A typical implementation is below:

+

reverse-proxy-arch

+ +
+ +
top
+
+

Reverse Proxy

+ +
Related ModulesRelated Directives
+
top
+
+

Simple reverse proxying

+ + +

+ The ProxyPass + directive specifies the mapping of incoming requests to the backend + server (or a cluster of servers known as a Balancer + group). The simplest example proxies all requests ("/") + to a single backend: +

+ + 
ProxyPass "/"  "http://www.example.com/"
+ + +

+ To ensure that and Location: headers generated from + the backend are modified to point to the reverse proxy, instead of + back to itself, the ProxyPassReverse + directive is most often required: +

+ + 
ProxyPass "/"  "http://www.example.com/"
+ProxyPassReverse "/"  "http://www.example.com/"
+ + +

Only specific URIs can be proxied, as shown in this example:

+ + 
ProxyPass "/images"  "http://www.example.com/"
+ProxyPassReverse "/images"  "http://www.example.com/"
+ + +

In the above, any requests which start with the /images + path with be proxied to the specified backend, otherwise it will be handled + locally. +

+
top
+
+

Clusters and Balancers

+ + +

+ As useful as the above is, it still has the deficiencies that should + the (single) backend node go down, or become heavily loaded, that proxying + those requests provides no real advantage. What is needed is the ability + to define a set or group of backend servers which can handle such + requests and for the reverse proxy to load balance and failover among + them. This group is sometimes called a cluster but Apache httpd's + term is a balancer. One defines a balancer by leveraging the + <Proxy> and + BalancerMember directives as + shown: +

+ + 
<Proxy balancer://myset>
+    BalancerMember http://www2.example.com:8080
+    BalancerMember http://www3.example.com:8080
+    ProxySet lbmethod=bytraffic
+</Proxy>
+
+ProxyPass "/images/"  "balancer://myset/"
+ProxyPassReverse "/images/"  "balancer://myset/"
+ + +

+ The balancer:// scheme is what tells httpd that we are creating + a balancer set, with the name myset. It includes 2 backend servers, + which httpd calls BalancerMembers. In this case, any requests for + /images will be proxied to one of the 2 backends. + The ProxySet directive + specifies that the myset Balancer use a load balancing algorithm + that balances based on I/O bytes. +

+ +

Hint

+

+ BalancerMembers are also sometimes referred to as workers. +

+
+ +
top
+
+

Balancer and BalancerMember configuration

+ + +

+ You can adjust numerous configuration details of the balancers + and the workers via the various parameters defined in + ProxyPass. For example, + assuming we would want http://www3.example.com:8080 to + handle 3x the traffic with a timeout of 1 second, we would adjust the + configuration as follows: +

+ + 
<Proxy balancer://myset>
+    BalancerMember http://www2.example.com:8080
+    BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
+    ProxySet lbmethod=bytraffic
+</Proxy>
+
+ProxyPass "/images"  "balancer://myset/"
+ProxyPassReverse "/images"  "balancer://myset/"
+ + +
top
+
+

Failover

+ + +

+ You can also fine-tune various failover scenarios, detailing which workers + and even which balancers should be accessed in such cases. For example, the + below setup implements three failover cases: +

+
    +
  1. + http://spare1.example.com:8080 and + http://spare2.example.com:8080 are only sent traffic if one + or both of http://www2.example.com:8080 or + http://www3.example.com:8080 is unavailable. (One spare + will be used to replace one unusable member of the same balancer set.) +
    2. +
  2. + http://hstandby.example.com:8080 is only sent traffic if + all other workers in balancer set 0 are not available. +
    3. +
  3. + If all load balancer set 0 workers, spares, and the standby + are unavailable, only then will the + http://bkup1.example.com:8080 and + http://bkup2.example.com:8080 workers from balancer set + 1 be brought into rotation. +
    4. +
+

+ Thus, it is possible to have one or more hot spares and hot standbys for + each load balancer set. +

+ + 
<Proxy balancer://myset>
+    BalancerMember http://www2.example.com:8080
+    BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
+    BalancerMember http://spare1.example.com:8080 status=+R
+    BalancerMember http://spare2.example.com:8080 status=+R
+    BalancerMember http://hstandby.example.com:8080 status=+H
+    BalancerMember http://bkup1.example.com:8080 lbset=1
+    BalancerMember http://bkup2.example.com:8080 lbset=1
+    ProxySet lbmethod=byrequests
+</Proxy>
+
+ProxyPass "/images/"  "balancer://myset/"
+ProxyPassReverse "/images/"  "balancer://myset/"
+ + +

+ For failover, hot spares are used as replacements for unusable workers in + the same load balancer set. A worker is considered unusable if it is + draining, stopped, or otherwise in an error/failed state. Hot standbys are + used if all workers and spares in the load balancer set are + unavailable. Load balancer sets (with their respective hot spares and + standbys) are always tried in order from lowest to highest. +

+ +
top
+
+

Balancer Manager

+ + +

+ One of the most unique and useful features of Apache httpd's reverse proxy is + the embedded balancer-manager application. Similar to + mod_status, balancer-manager displays + the current working configuration and status of the enabled + balancers and workers currently in use. However, not only does it + display these parameters, it also allows for dynamic, runtime, on-the-fly + reconfiguration of almost all of them, including adding new BalancerMembers + (workers) to an existing balancer. To enable these capability, the following + needs to be added to your configuration: +

+ + 
<Location "/balancer-manager">
+    SetHandler balancer-manager
+    Require host localhost
+</Location>
+ + +

Warning

+

Do not enable the balancer-manager until you have secured your server. In + particular, ensure that access to the URL is tightly + restricted.

+
+ +

+ When the reverse proxy server is accessed at that url + (eg: http://rproxy.example.com/balancer-manager/, you will see a + page similar to the below: +

+

balancer-manager page

+ +

+ This form allows the devops admin to adjust various parameters, take + workers offline, change load balancing methods and add new works. For + example, clicking on the balancer itself, you will get the following page: +

+

balancer-manager page

+ +

+ Whereas clicking on a worker, displays this page: +

+

balancer-manager page

+ +

+ To have these changes persist restarts of the reverse proxy, ensure that + BalancerPersist is enabled. +

+ +
top
+
+

Dynamic Health Checks

+ + +

+ Before httpd proxies a request to a worker, it can "test" if that worker + is available via setting the ping parameter for that worker using + ProxyPass. Oftentimes it is + more useful to check the health of the workers out of band, in a + dynamic fashion. This is achieved in Apache httpd by the + mod_proxy_hcheck module. +

+ +
top
+
+

BalancerMember status flags

+ + +

+ In the balancer-manager the current state, or status, of a worker + is displayed and can be set/reset. The meanings of these statuses are as follows: +

+ + + + + + + + + + + + +
FlagStringDescription
 OkWorker is available
 InitWorker has been initialized
DDisWorker is disabled and will not accept any requests; will be + automatically retried.
SStopWorker is administratively stopped; will not accept requests + and will not be automatically retried
IIgnWorker is in ignore-errors mode and will always be considered available.
RSparWorker is a hot spare. For each worker in a given lbset that is unusable + (draining, stopped, in error, etc.), a usable hot spare with the same lbset will be used in + its place. Hot spares can help ensure that a specific number of workers are always available + for use by a balancer.
HStbyWorker is in hot-standby mode and will only be used if no other + viable workers or spares are available in the balancer set.
EErrWorker is in an error state, usually due to failing pre-request check; + requests will not be proxied to this worker, but it will be retried depending on + the retry setting of the worker.
NDrnWorker is in drain mode and will only accept existing sticky sessions + destined for itself and ignore all other requests.
CHcFlWorker has failed dynamic health check and will not be used until it + passes subsequent health checks.
+
+
+

Available Languages:  en  | + fr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/reverse_proxy.html.fr.utf8 b/docs/manual/howto/reverse_proxy.html.fr.utf8 new file mode 100644 index 0000000..d9d634e --- /dev/null +++ b/docs/manual/howto/reverse_proxy.html.fr.utf8 @@ -0,0 +1,381 @@ + + + + + +Guide de configuration d'un mandataire inverse - Serveur HTTP Apache Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.4

+
+
<-
+

Guide de configuration d'un mandataire inverse

+
+

Langues Disponibles:  en  | + fr 

+
+ +

En plus de ses fonctions de serveur web "basique", à savoir fournir du + contenu statique et dynamique à l'utilisateur, Apache httpd (comme la + plupart des autres serveurs web) peut aussi assurer les fonctions de serveur + mandataire inverse, connu aussi sous le nom de serveur "passerelle".

+ +

Dans un tel scénario, httpd ne génère et n'héberge pas lui-même les + données, le contenu étant en général obtenu à partir d'un ou plusieurs serveurs + d'arrière-plan qui n'ont normalement aucune connexion directe avec le réseau + externe. Lorsque httpd reçoit une requête en provenance d'un client, la + requête proprement dite est mandatée vers un de ces serveurs + d'arrière-plan qui traite la requête, génère le contenu et l'envoie à httpd, + ce dernier générant la véritable réponse HTTP à destination du client.

+ +

De nombreuses raisons peuvent vous motiver à utiliser cette + fonctionnalité, mais elles sont souvent du domaine de la sécurité, de + la haute disponibilité, de la répartition de charge et de + l'authentification/autorisation centralisée. Il est alors indispensable que + l'organisation, la conception et l'architecture de l'infrastructure + d'arrière-plan (les serveurs qui traitent au sens propre les requêtes) soient + isolées et protégées de l'extérieur ; vu du client, le serveur mandataire + inverse est le seul serveur accessible pouvant lui fournir du + contenu.

+ +

Voici un exemple typique d'implémentation de cette fonctionnalité :

+

reverse-proxy-arch

+ +
+ +
top
+
+

Mandataire inverse

+ +
Modules ApparentésDirectives Apparentées
+
top
+
+

Mandatement inverse simple

+ + +

+ La directive ProxyPass permet de + rediriger les requêtes entrantes vers un serveur d'arrière-plan (ou un + cluster de serveurs plus connu sous le nom de groupe + Balancer). Dans cet exemple le plus simple, toutes les + requêtes ("/") sont redirigées vers un serveur d'arrière-plan + unique : +

+ + 
ProxyPass "/"  "http://www.example.com/"
+ + +

+ Pour être sur que cette redirection soit effectuée et que les en-têtes + Location: générés par le serveur d'arrière-plan soient + modifiés pour pointer vers le mandataire inverse, et non vers le serveur + d'arrière-plan, la directive ProxyPassReverse est souvent requise : +

+ + 
ProxyPass "/"  "http://www.example.com/"
+ProxyPassReverse "/"  "http://www.example.com/"
+ + +

Seules des URIs spécifiques peuvent être mandatées, comme le montre + l'exemple suivant :

+ + 
ProxyPass "/images"  "http://www.example.com/"
+ProxyPassReverse "/images"  "http://www.example.com/"
+ + +

Dans l'exemple précédent, si le chemin d'une requête commence par + /images, elle sera redirigée vers le serveur d'arrière-plan + spécifié ; dans le cas contraire, elle sera traitée localement. +

+
top
+
+

Clusters et Balancers

+ + +

+ Utiliser un serveur d'arrière-plan unique n'est cependant pas une solution + idéale car ce dernier peut devenir indisponible ou surchargé, et le + mandatement inverse vers ce serveur ne présente alors plus aucun avantage. + La solution réside dans la définition d'un groupe de serveurs + d'arrière-plan qui vont se partager le traitement des requêtes via un + mécanisme de répartition de charge et de gestion des indisponibilités pris + en charge par le mandataire. Ce groupe de répartition est plus connu sous le nom de + cluster, mais dans la terminologie d'Apache httpd, on utilise + plutôt le terme de balancer. Un balancer se définit en + utilisant les directives <Proxy> et BalancerMember comme suit : +

+ + 
<Proxy balancer://myset>
+    BalancerMember http://www2.example.com:8080
+    BalancerMember http://www3.example.com:8080
+    ProxySet lbmethod=bytraffic
+</Proxy>
+
+ProxyPass "/images/"  "balancer://myset/"
+ProxyPassReverse "/images/"  "balancer://myset/"
+ + +

+ Le protocole balancer:// indique à httpd que l'on souhaite + créer un balancer nommé myset. Ce balancer comporte deux serveurs + d'arrière-plan référencés dans la terminologie httpd sous le nom de + BalancerMembers. Avec cet exemple, toute requête dont le chemin + commence par /images sera mandatée vers un des deux + serveurs d'arrière-plan. La directive ProxySet définit ici pour le balancer + myset un algorithme de + répartition de charge basé sur le trafic entrées/sorties. +

+ +

Remarque

+

+ Les BalancerMembers sont aussi souvent référencés sous le terme + workers. +

+
+ +
top
+
+

Configuration du Balancer et des BalancerMembers

+ + +

+ Vous pouvez configurer de manière détaillée les balancers et + workers via les nombreux paramètres de la directive ProxyPass. Par exemple, si vous souhaitez + que http://www3.example.com:8080 traite avec un facteur 3 le + trafic avec un timeout d'une seconde, utilisez la configuration suivante : +

+ + 
<Proxy balancer://myset>
+    BalancerMember http://www2.example.com:8080
+    BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
+    ProxySet lbmethod=bytraffic
+</Proxy>
+
+ProxyPass "/images"  "balancer://myset/"
+ProxyPassReverse "/images"  "balancer://myset/"
+ + +
top
+
+

Gestion des indisponibilités (Failover)

+ + +

+ Vous pouvez aussi définir finement des scénarios pour les cas + d'indisponibilité d'un ou plusieurs serveurs d'arrière-plan en spécifiant + quels serveurs doivent alors prendre le relai. Dans l'exemple suivant, + trois scénarios sont envisagés : +

+
    +
  1. + http://spare1.example.com:8080 et + http://spare2.example.com:8080 ne sont sollicités que si + http://www2.example.com:8080 ou + http://www3.example.com:8080 est indisponible (un serveur + de remplacement sera utilisé à la place d'un membre indisponible du même + jeu de serveurs cibles). +
    2. +
  2. + http://hstandby.example.com:8080 n'est sollicité que si + tous les autres serveurs cibles du jeu de serveurs 0 sont + indisponibles. +
    3. +
  3. + Les serveurs http://bkup1.example.com:8080 et + http://bkup2.example.com:8080 du jeu 1 ne seront sollicités que si + tous les serveurs du jeu 0, tous les serveurs de + remplacement et tous les serveurs de standby sont indisponibles. +
    4. +
+

+ Il est ainsi possible de définir un ou plusieurs serveurs de remplacement + ou de standby pour chaque jeu de serveurs du répartiteur de charge. +

+ + 
<Proxy balancer://myset>
+    BalancerMember http://www2.example.com:8080
+    BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
+    BalancerMember http://spare1.example.com:8080 status=+R
+    BalancerMember http://spare2.example.com:8080 status=+R
+    BalancerMember http://hstandby.example.com:8080 status=+H
+    BalancerMember http://bkup1.example.com:8080 lbset=1
+    BalancerMember http://bkup2.example.com:8080 lbset=1
+    ProxySet lbmethod=byrequests
+</Proxy>
+
+ProxyPass "/images/"  "balancer://myset/"
+ProxyPassReverse "/images/"  "balancer://myset/"
+ + +

+ Les serveurs de remplacement à chaud remplacent les serveurs indisponibles + du même jeu de serveurs du répartiteur de charge. Un serveur est + considéré comme indisponible s'il est en maintenance, arrêté ou en erreur. + Les serveurs de standby à chaud sont utilisés si tous les serveurs et + serveurs de remplacement du jeu de serveurs du répartiteur de charge sont + indisponibles. Les jeux de serveurs du répartiteur de charge (avec leurs + serveurs de standby et de remplacement à chaud respectifs) sont toujours + sollicités dans l'ordre du plus bas lbset vers le plus haut. +

+ +
top
+
+

Gestion du répartiteur de charge

+ + +

+ L'application balancer-manager fournie avec le mandataire inverse + d'Apache httpd en est un des outils les plus utiles. Comme + mod_status, balancer-manager affiche la + configuration et l'activité actuelles des balancers actifs. L'affichage de + ces informations n'est cependant pas sa seule fonction ; il permet aussi de + modifier la plupart d'entre elles et même d'ajouter des membres au groupe + de répartition de charge en temps réel. Pour activer ces fonctionnalités, + vous devez ajouter les lignes suivantes à votre fichier de configuration : +

+ + 
<Location "/balancer-manager">
+    SetHandler balancer-manager
+    Require host localhost
+</Location>
+ + +

Avertissement

+

N'activez le balancer-manager que si vous avez déjà sécurisé votre serveur. + Assurez-vous en particulier que l'accès à l'URL soit fortement restreint.

+
+ +

+ Lorsque vous accédez au serveur mandataire avec une adresse du style + http://rproxy.example.com/balancer-manager/, la page suivante + s'affiche : +

+

balancer-manager page

+ +

+ Ce formulaire permet à l'administrateur de modifier certains paramètres, + de désactiver ou d'ajouter certains serveurs d'arrière-plan, et de + modifier les règles de répartition de charge. Par exemple, si on clique + sur le répartiteur, la page suivante s'affiche : +

+

balancer-manager page

+ +

+ Si on clique sur un membre du groupe de répartition de charge, la page + suivante s'affiche : +

+

balancer-manager page

+ +

+ Si vous souhaitez que ces modifications soient conservées après un + redémarrage du serveur, assurez-vous que la directive BalancerPersist soit définie à On. +

+ +
top
+
+

Vérification dynamique du bon fonctionnement d'un serveur + d'arrière-plan

+ + +

+ Avant que le mandataire httpd ne fasse appel à un serveur d'arrière-plan, il + peut "tester" si ce dernier est disponible en définissant le + paramètre ping de ce serveur via la directive ProxyPass. Cependant, il est souvent plus + judicieux de vérifier le bon fonctionnement d'un serveur hors + bande et de manière dynamique via le module + mod_proxy_hcheck d'Apache httpd. +

+ +
top
+
+

Drapeaux d'état d'un membre du groupe de répartition de charge

+ + +

+ balancer-manager permet d'afficher et de modifier l'état d'un + membre du groupe de répartition de charge. Les différents états et leurs + significations sont les suivants : +

+ + + + + + + + + + + + +
DrapeauSigleDescription
 OkLe serveur est disponible
 InitLe serveur a été initialisé
DDisLe serveur est + désactivé et n'accepte aucune requête ; il sera retesté automatiquement.
SStopLe serveur a été + arrêté par l'administrateur ; il n'accepte aucune requête et il ne sera + pas retesté automatiquement.
IIgnLes erreurs + concernant ce serveur sont ignorées et il sera donc toujours considéré + comme disponible.
RSparLe serveur cible sert de remplaçant à + chaud. Lorsqu'un serveur cible avec un lbset donné est inutilisable + (maintenance, arrêt, en erreur, etc...), un serveur de remplacement à + chaud libre de même lbset sera utilisé à sa place. Les remplaçants à + chaud permettent de s'assurer qu'un nombre déterminé de serveurs cibles + sera toujours disponible pour un répartiteur de charge.
HStbyLe serveur est en + mode hot-standby et ne sera donc utilisé que si aucun autre serveur ou + serveur de remplacement n'est disponible dans le jeu de serveurs du + répartiteur de charge.
EErrLe serveur est en + erreur, en général suite à un test préalable à une requête ; aucune + requête ne lui sera soumise, mais il sera retesté en fonction de la + valeur de son paramètre retry.
NDrnLe serveur est en + mode drain ; il n'acceptera de requêtes que dans le cadre des sessions + persistantes qui lui sont réservées et ignorera toutes les autres.
CHcFlLe serveur a échoué + au test dynamique de bon fonctionnement et ne sera utilisé que lorsqu'il + aura réussi un test ultérieur.
+
+
+

Langues Disponibles:  en  | + fr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/ssi.html b/docs/manual/howto/ssi.html new file mode 100644 index 0000000..e3d279f --- /dev/null +++ b/docs/manual/howto/ssi.html @@ -0,0 +1,21 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: ssi.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: ssi.html.es +Content-Language: es +Content-type: text/html; charset=ISO-8859-1 + +URI: ssi.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 + +URI: ssi.html.ja.utf8 +Content-Language: ja +Content-type: text/html; charset=UTF-8 + +URI: ssi.html.ko.euc-kr +Content-Language: ko +Content-type: text/html; charset=EUC-KR diff --git a/docs/manual/howto/ssi.html.en b/docs/manual/howto/ssi.html.en new file mode 100644 index 0000000..53ea265 --- /dev/null +++ b/docs/manual/howto/ssi.html.en @@ -0,0 +1,503 @@ + + + + + +Apache httpd Tutorial: Introduction to Server Side Includes - Apache HTTP Server Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.4

+
+
<-
+

Apache httpd Tutorial: Introduction to Server Side Includes

+
+

Available Languages:  en  | + es  | + fr  | + ja  | + ko 

+
+ +

Server-side includes provide a means to add dynamic content to +existing HTML documents.

+
+ +
top
+
+

Introduction

+
Related ModulesRelated Directives
+ +

This article deals with Server Side Includes, usually called + simply SSI. In this article, I'll talk about configuring your + server to permit SSI, and introduce some basic SSI techniques + for adding dynamic content to your existing HTML pages.

+ +

In the latter part of the article, we'll talk about some of + the somewhat more advanced things that can be done with SSI, + such as conditional statements in your SSI directives.

+ +
top
+
+

What are SSI?

+ +

SSI (Server Side Includes) are directives that are placed in + HTML pages, and evaluated on the server while the pages are + being served. They let you add dynamically generated content to + an existing HTML page, without having to serve the entire page + via a CGI program, or other dynamic technology.

+ +

For example, you might place a directive into an existing HTML + page, such as:

+ +

+ <!--#echo var="DATE_LOCAL" --> +

+ +

And, when the page is served, this fragment will be evaluated and replaced with its value:

+ +

+ Tuesday, 15-Jan-2013 19:28:54 EST +

+ +

The decision of when to use SSI, and when to have your page + entirely generated by some program, is usually a matter of how + much of the page is static, and how much needs to be + recalculated every time the page is served. SSI is a great way + to add small pieces of information, such as the current time - shown + above. But if a majority of your page is being generated at the time + that it is served, you need to look for some other solution.

+
top
+
+

Configuring your server to permit SSI

+ + +

To permit SSI on your server, you must have the following + directive either in your httpd.conf file, or in a + .htaccess file:

+
Options +Includes
+ + +

This tells Apache that you want to permit files to be parsed + for SSI directives. Note that most configurations contain + multiple Options directives + that can override each other. You will probably need to apply the + Options to the specific directory where you want SSI + enabled in order to assure that it gets evaluated last.

+ +

Not just any file is parsed for SSI directives. You have to + tell Apache which files should be parsed. There are two ways to + do this. You can tell Apache to parse any file with a + particular file extension, such as .shtml, with + the following directives:

+
AddType text/html .shtml
+AddOutputFilter INCLUDES .shtml
+ + +

One disadvantage to this approach is that if you wanted to + add SSI directives to an existing page, you would have to + change the name of that page, and all links to that page, in + order to give it a .shtml extension, so that those + directives would be executed.

+ +

The other method is to use the XBitHack directive:

+
XBitHack on
+ + +

XBitHack + tells Apache to parse files for SSI + directives if they have the execute bit set. So, to add SSI + directives to an existing page, rather than having to change + the file name, you would just need to make the file executable + using chmod.

+

+ chmod +x pagename.html +

+ +

A brief comment about what not to do. You'll occasionally + see people recommending that you just tell Apache to parse all + .html files for SSI, so that you don't have to + mess with .shtml file names. These folks have + perhaps not heard about XBitHack. The thing to + keep in mind is that, by doing this, you're requiring that + Apache read through every single file that it sends out to + clients, even if they don't contain any SSI directives. This + can slow things down quite a bit, and is not a good idea.

+ +

Of course, on Windows, there is no such thing as an execute + bit to set, so that limits your options a little.

+ +

In its default configuration, Apache does not send the last + modified date or content length HTTP headers on SSI pages, + because these values are difficult to calculate for dynamic + content. This can prevent your document from being cached, and + result in slower perceived client performance. There are two + ways to solve this:

+ +
    +
  1. Use the XBitHack Full configuration. This + tells Apache to determine the last modified date by looking + only at the date of the originally requested file, ignoring + the modification date of any included files.
    2. + +
  2. Use the directives provided by + mod_expires to set an explicit expiration + time on your files, thereby letting browsers and proxies + know that it is acceptable to cache them.
    3. +
+
top
+
+

Basic SSI directives

+ +

SSI directives have the following syntax:

+

+ <!--#function attribute=value attribute=value ... --> +

+ +

It is formatted like an HTML comment, so if you don't have + SSI correctly enabled, the browser will ignore it, but it will + still be visible in the HTML source. If you have SSI correctly + configured, the directive will be replaced with its + results.

+ +

The function can be one of a number of things, and we'll talk + some more about most of these in the next installment of this + series. For now, here are some examples of what you can do with + SSI

+ +

Today's date

+ +

+ <!--#echo var="DATE_LOCAL" --> +

+ +

The echo function just spits out the value of a + variable. There are a number of standard variables, which + include the whole set of environment variables that are + available to CGI programs. Also, you can define your own + variables with the set function.

+ +

If you don't like the format in which the date gets printed, + you can use the config function, with a + timefmt attribute, to modify that formatting.

+ +

+ <!--#config timefmt="%A %B %d, %Y" -->
+ Today is <!--#echo var="DATE_LOCAL" --> +

+ + +

Modification date of the file

+ +

+ This document last modified <!--#flastmod file="index.html" --> +

+ +

This function is also subject to timefmt format + configurations.

+ + +

Including the results of a CGI program

+ +

This is one of the more common uses of SSI - to output the + results of a CGI program, such as everybody's favorite, a ``hit + counter.''

+ +

+ <!--#include virtual="/cgi-bin/counter.pl" --> +

+ + +
top
+
+

Additional examples

+ + +

Following are some specific examples of things you can do in + your HTML documents with SSI.

+ +

When was this document +modified?

+ +

Earlier, we mentioned that you could use SSI to inform the + user when the document was most recently modified. However, the + actual method for doing that was left somewhat in question. The + following code, placed in your HTML document, will put such a + time stamp on your page. Of course, you will have to have SSI + correctly enabled, as discussed above.

+

+ <!--#config timefmt="%A %B %d, %Y" -->
+ This file last modified <!--#flastmod file="ssi.shtml" --> +

+ +

Of course, you will need to replace the + ssi.shtml with the actual name of the file that + you're referring to. This can be inconvenient if you're just + looking for a generic piece of code that you can paste into any + file, so you probably want to use the + LAST_MODIFIED variable instead:

+

+ <!--#config timefmt="%D" -->
+ This file last modified <!--#echo var="LAST_MODIFIED" --> +

+ +

For more details on the timefmt format, go to + your favorite search site and look for strftime. The + syntax is the same.

+ + +

Including a standard footer

+ + +

If you are managing any site that is more than a few pages, + you may find that making changes to all those pages can be a + real pain, particularly if you are trying to maintain some kind + of standard look across all those pages.

+ +

Using an include file for a header and/or a footer can + reduce the burden of these updates. You just have to make one + footer file, and then include it into each page with the + include SSI command. The include + function can determine what file to include with either the + file attribute, or the virtual + attribute. The file attribute is a file path, + relative to the current directory. That means that it + cannot be an absolute file path (starting with /), nor can it + contain ../ as part of that path. The virtual + attribute is probably more useful, and should specify a URL + relative to the document being served. It can start with a /, + but must be on the same server as the file being served.

+

+ <!--#include virtual="/footer.html" --> +

+ +

I'll frequently combine the last two things, putting a + LAST_MODIFIED directive inside a footer file to be + included. SSI directives can be contained in the included file, + and includes can be nested - that is, the included file can + include another file, and so on.

+ + +
top
+
+

What else can I config?

+ + +

In addition to being able to config the time + format, you can also config two other things.

+ +

Usually, when something goes wrong with your SSI directive, + you get the message

+

+ [an error occurred while processing this directive] +

+ +

If you want to change that message to something else, you + can do so with the errmsg attribute to the + config function:

+

+ <!--#config errmsg="[It appears that you don't know how to use SSI]" --> +

+ +

Hopefully, end users will never see this message, because + you will have resolved all the problems with your SSI + directives before your site goes live. (Right?)

+ +

And you can config the format in which file + sizes are returned with the sizefmt attribute. You + can specify bytes for a full count in bytes, or + abbrev for an abbreviated number in Kb or Mb, as + appropriate.

+
top
+
+

Executing commands

+ + +

Here's something else that you can do with the exec + function. You can actually have SSI execute a command using the + shell (/bin/sh, to be precise - or the DOS shell, + if you're on Win32). The following, for example, will give you + a directory listing.

+

+ <pre>
+ <!--#exec cmd="ls" -->
+ </pre> +

+ +

or, on Windows

+

+ <pre>
+ <!--#exec cmd="dir" -->
+ </pre> +

+ +

You might notice some strange formatting with this directive + on Windows, because the output from dir contains + the string ``<dir>'' in it, which confuses + browsers.

+ +

Note that this feature is exceedingly dangerous, as it will + execute whatever code happens to be embedded in the + exec tag. If you have any situation where users + can edit content on your web pages, such as with a + ``guestbook'', for example, make sure that you have this + feature disabled. You can allow SSI, but not the + exec feature, with the IncludesNOEXEC + argument to the Options directive.

+
top
+
+

Advanced SSI techniques

+ + +

In addition to spitting out content, Apache SSI gives you + the option of setting variables, and using those variables in + comparisons and conditionals.

+ +

Setting variables

+ +

Using the set directive, you can set variables + for later use. We'll need this later in the discussion, so + we'll talk about it here. The syntax of this is as follows:

+

+ <!--#set var="name" value="Rich" --> +

+ +

In addition to merely setting values literally like that, you + can use any other variable, including environment variables or the variables + discussed above (like LAST_MODIFIED, for example) to + give values to your variables. You will specify that something is + a variable, rather than a literal string, by using the dollar sign + ($) before the name of the variable.

+ +

<!--#set var="modified" value="$LAST_MODIFIED" --> +

+ +

To put a literal dollar sign into the value of your + variable, you need to escape the dollar sign with a + backslash.

+

+ <!--#set var="cost" value="\$100" --> +

+ +

Finally, if you want to put a variable in the midst of a + longer string, and there's a chance that the name of the + variable will run up against some other characters, and thus be + confused with those characters, you can place the name of the + variable in braces, to remove this confusion. (It's hard to + come up with a really good example of this, but hopefully + you'll get the point.)

+

+ <!--#set var="date" value="${DATE_LOCAL}_${DATE_GMT}" --> +

+ + +

Conditional expressions

+ + +

Now that we have variables, and are able to set and compare + their values, we can use them to express conditionals. This + lets SSI be a tiny programming language of sorts. + mod_include provides an if, + elif, else, endif + structure for building conditional statements. This allows you + to effectively generate multiple logical pages out of one + actual page.

+ +

The structure of this conditional construct is:

+

+ <!--#if expr="test_condition" -->
+ <!--#elif expr="test_condition" -->
+ <!--#else -->
+ <!--#endif --> +

+ +

A test_condition can be any sort of logical + comparison - either comparing values to one another, or testing + the ``truth'' of a particular value. (A given string is true if + it is nonempty.) For a full list of the comparison operators + available to you, see the mod_include + documentation.

+ +

For example, if you wish to customize the text on your web page + based on the time of day, you could use the following recipe, placed + in the HTML page:

+ +

+ Good + <!--#if expr="%{TIME_HOUR} <12" -->
+ morning!
+ <!--#else -->
+ afternoon!
+ <!--#endif -->
+

+ +

Any other variable (either ones that you define, or normal + environment variables) can be used in conditional statements. + See Expressions in Apache HTTP Server for + more information on the expression evaluation engine.

+ +

With Apache's ability to set environment variables with the + SetEnvIf directives, and other related directives, + this functionality can let you do a wide variety of dynamic content + on the server side without resorting a full web application.

+ +
top
+
+

Conclusion

+ +

SSI is certainly not a replacement for CGI, or other + technologies used for generating dynamic web pages. But it is a + great way to add small amounts of dynamic content to pages, + without doing a lot of extra work.

+
+
+

Available Languages:  en  | + es  | + fr  | + ja  | + ko 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/ssi.html.es b/docs/manual/howto/ssi.html.es new file mode 100644 index 0000000..1b5eebf --- /dev/null +++ b/docs/manual/howto/ssi.html.es @@ -0,0 +1,361 @@ + + + + + +Tutorial de Apache httpd: Introducción a los Server Side Includes + - Servidor HTTP Apache Versión 2.4 + + + + + + +
+

Módulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

+

Versión 2.4 del Servidor HTTP Apache

+
+
<-
+

Tutorial de Apache httpd: Introducción a los Server Side Includes +

+
+

Idiomas disponibles:  en  | + es  | + fr  | + ja  | + ko 

+
+ +

Los Server Side Includes (Inclusiones en la parte Servidor) facilitan un método para añadir contenido dinámico a documentos HTML existentes.

+
+ +
top
+
+

Introducción

+
Módulos RelacionadosDirectivas Relacionadas
+ +

Este artículo trata sobre los Server Side Includes, generalmente llamados SSI. + En este artículo, hablaremos sobre cómo configurar su servidor para permitir SSI, + y de técnicas básicas de SSI para añadir contenido dinámico a sus páginas + HTML existentes.

+ +

Más adelante también hablaremos de algunas técnicas más avanzadas que + pueden usarse con SSI, tales como declaraciones condicionales en sus directivas SSI.

+ +
top
+
+

¿Qué son los SSI?

+ +

SSI (Server Side Includes) son directivas que se introducen en páginas HTML y son + evaluadas por el servidor mientras éste las sirve. Le permiten añadir + contenido generado de manera dinámica a sus páginas HTML existentes sin tener + que servir una página entera a través de un programa CGI, u otra tecnología + para generar contenido dinámico.

+ +

Por ejemplo, podría colocar una directiva en una página existente de HTML + de esta manera:

+ +

+ <!--#echo var="DATE_LOCAL" --> +

+ +

Y, cuando se sirve la página, este fragmento será evaluado y sustituido con su resultado:

+ +

+ Tuesday, 15-Jan-2013 19:28:54 EST +

+ +

La decisión sobre cuándo usar SSI, o de cuándo generar una página al completo con algún programa, suele depender generalmente de la cantidad de contenido estático que contiene, y cuánto de esa página tiene que ser recalculado cada vez que ésta se sirve. SSI es un buen método para añadir pequeñas partes de información, tales como la hora actual - como se ha mostrado más arriba. Pero si la mayoría de su página se tiene que generar en el momento en el que se está sirviendo, necesita buscar otra opción más adecuada que no sea SSI.

+
top
+
+

Configurar su servidor para permitir SSI

+ + +

Para permitir SSI en su servidor, debe tener la siguiente directiva en su fichero httpd.conf , o en un fichero + .htaccess:

+
Options +Includes
+ + +

Esto le dice a Apache que quiere permitir que se examinen los ficheros buscando directivas SSI. Tenga en cuenta que la mayoría de las configuraciones contienen múltiples directivas Options que pueden sobreescribirse las unas a las otras. Probablemente necesitará aplicar Options al directorio específico donde quiere SSI activado para asegurarse de que se evalúa en último lugar y por tanto se acabará aplicando.

+ +

No todos los ficheros se examinan buscando directivas SSI. Usted Le tiene que indicar a Apache qué ficheros se tienen que examinar. Hay dos formas de hacer esto. Puede decirle a Apache que examine cualquier fichero con una extensión determinada, como por ejemplo .shtml, con las siguientes directivas:

+
AddType text/html .shtml
+AddOutputFilter INCLUDES .shtml
+ + +

Una desventaja de este método es que si quisiera añadir directivas SSI a una página ya existente, tendría que cambiar el nombre de la página, y todos los enlaces que apuntasen a esa página, todo para poder darle la extensión .shtml y que esas directivas sean interpretadas.

+ +

El otro método es usar la directiva XBitHack :

+
XBitHack on
+ + +

XBitHack le dice a Apache que examine ficheros buscando directivas SSI si los ficheros tienen el bit de ejecución configurado. Asi que para añadir directivas SSI a una página existente, en lugar de tener que cambiarle el nombre, solo tendría que convertirla en ejecutable usando chmod.

+

+ chmod +x pagename.html +

+ +

Una breve recomendación de qué no hay que hacer. Ocasionalmente vemos gente recomendar que le diga a Apache que examine todos los ficheros + .html para activar SSI, para no tener que lidiar renombrando los ficheros a .shtml. Quizás estas personas no hayan oido hablar de XBitHack. Lo que hay que tener en cuenta, es que haciendo eso, está pidiendo al Apache que lea cada uno de los ficheros que manda al cliente, incluso si no contenien directivas SSI. Esto puede ralentizar bastante el servidor, y no es una buena idea.

+ +

Por supuesto, en Windows, no hay tal cosa como la configuración del bit de ejecución, así que esto limita las opciones un poco.

+ +

En su configuración por defecto, Apache no envía la fecha de última modificación o la longitud de contenido de páginas SSI porque es dificil calcular estos valores para contenido dinámico. Esto puede impedir que se cachee un documento, y dar como resultado en apareciencia un rendimiento más lento del cliente. Hay dos maneras de solucionar esto:

+ +
    +
  1. Usando la configuración XBitHack Full. Esto le indica a apache que determine la fecha de última modificación mirando sólo la fecha del fichero que se ha solicitado originalmente, obviando la modificación de cualquier otro fichero al que se hace referencia mediante SSI.
    2. + +
  2. Use las directivas facilitadas por mod_expires para configurar una expiración específica de tiempo en sus ficheros, y así hacer saber a proxies o navegadores web que es aceptable cachearlos.
    3. +
+
top
+
+

Directivas SSI básicas

+ +

Las directivas SSI tienen la sintaxis siguiente:

+

+ <!--#function attribute=value attribute=value ... --> +

+ +

Se formatean como comentarios HTML, así si no tiene SSI habilitado correctamente, el navegador las obviará, pero todavía serán visibles en el fichero HTML. Si tiene SSI configurado correctamente, la directiva será reemplazada con su propio resultado.

+ +

Esta función es una de tantas, y hablaremos de algunas de ellas más adelante. Por ahora, aquí mostramos unos ejemplos de lo que puede hacer con SSI.

+ +

La fecha de hoy

+ +

+ <!--#echo var="DATE_LOCAL" --> +

+ +

La función echo sencillamente muestra el valor de una variable. Hay muchas variables estándar que incluyen un conjunto de variables de entorno disponibles para programas CGI. También puede definir sus propias variables con la función set.

+ +

Si no le gusta el formato en el que se imprime la fecha, puede usar la función config, con un atributo + timefmt para modificar ese formato.

+ +

+ <!--#config timefmt="%A %B %d, %Y" -->
+ Today is <!--#echo var="DATE_LOCAL" --> +

+ + +

Fecha de modificación del fichero

+ +

+ La última modificación de este documento <!--#flastmod file="index.html" --> +

+ +

Esta función también está sujeta a configuraciones de formato de + timefmt.

+ + +

Incluyendo los resultados de un programa CGI

+ +

Este es uno de los usos más comunes de SSI - para sacar el resultado de un programa CGI, tal y como ocurre con el que fuera el programa favorito de todos, un ``contador de visitas.''

+ +

+ <!--#include virtual="/cgi-bin/counter.pl" --> +

+ + +
top
+
+

Más ejemplos

+ + +

A continuación hay algunos ejemplos específicos de cosas que puede hacer con SSI en sus documentos HTML.

+ +

¿Cuándo fue modificado este documento?

+ +

Antes mencionamos que puede usar SSI para informar al usuario cuando el documento ha sido modificado por última vez. Aun así, el método actual para hacerlo se dejó en cuestión. El código que se muestra a continuación, puesto en un documento HTML, pondrá ese sello de tiempo en su página. Por descontado, tendrá que tener SSI habilitado correctamente, como se indicó más arriba.

+

+ <!--#config timefmt="%A %B %d, %Y" -->
+ Ultima modificación de este fichero <!--#flastmod file="ssi.shtml" --> +

+ +

Obviamente, necesitará sustituir el nombre de fichero + ssi.shtml con el nombre real del fichero al que usted hace referencia. Esto puede ser inconveniente si solo está buscando un trozo genérico de código que pueda copiar y pegar en cualquier fichero, asi que probablemente necesite usar la variable LAST_MODIFIED en su lugar:

+

+ <!--#config timefmt="%D" -->
+ Última modificación de este fichero <!--#echo var="LAST_MODIFIED" --> +

+ +

Para más detalles sobre el formato timefmt, vaya a su buscador favorito y busque strftime. La sintaxis es la misma.

+ + +

Incluyendo un pie de página estándar

+ + +

Si gestiona un sitio que tiene más de unas cuantas páginas, probablemente se de cuenta de que modificar todas esa páginas es un auténtico engorro, especialmente si trata de mantener una apareciencia homogénea en todas ellas.

+ +

Si usa un Include de fichero para la cabecera y/o pie de página puede reducir la carga de trabajo de estas actualizaciones. Solo tiene que hacer un sólo pie de página, y después incluirlo en cada página con el comando SSI include. La función include + puede determinar qué fichero incluir cuando usa el atributo + file, o el atributo virtual. El atributo file es una ruta de fichero, relativa al directorio actual. Eso significa que no puede ser una ruta de fichero absoluta (que comienza con /), ni tampoco puede contener ../ como parte de la ruta. El atributo virtual es probablemente más útil, y debería especificar una URL relativa al documento que se está sirviendo. Puede empezar con una /, pero debe estar en el mismo servidor que el fichero que se está sirviendo.

+

+ <!--#include virtual="/footer.html" --> +

+ +

Frecuentemente combinaremos las dos últimas, poniendo una directiva + LAST_MODIFIED dentro de un fichero de pie de página que va a ser incluido. Se pueden encontrar directivas SSI en el fichero que se incluye, las inclusiones pueden anidarse - lo que quiere decir, que el fichero incluido puede incluir otro fichero, y así sucesivamente.

+ + +
top
+
+

¿Qué más puedo configurar?

+ + +

Además de poder configurar el formato de la hora, también puede configurar dos cosas más.

+ +

Generalmente, cuando algo sale mal con sus directivas SSI, obtiene el mensaje (ha ocurrido un error procesando esta directiva)

+

+ [an error occurred while processing this directive] +

+ +

Si quiere cambiar ese mensaje por otra cosa, puede hacerlo con el atributo errmsg para la función + config:

+

+ <!--#config errmsg="[Parece que no sabe cómo usar SSI]" --> +

+ +

Afortunadamente, los usuarios finales nunca verán este mensaje, porque habrá resuelto todos los problemas con sus directivas SSI antes de publicar su página web. (¿Verdad?)

+ +

Y puede configurar el formato en el que los tamaños de fichero se muestran con el formato sizefmt. Puede especificar + bytes para un recuento total en bytes, o + abbrev para un número abreviado en Kb o Mb, según sea necesario.

+
top
+
+

Ejecutando comandos

+ + +

Puede usar la función exec para ejecutar comandos. Y SSI puede ejecutar un comando usando la shell (/bin/sh, para ser más precisos - o la shell de DOS , si está en Win32). Lo siguiente, por ejemplo, le dará un listado de ficheros en un directorio.

+

+ <pre>
+ <!--#exec cmd="ls" -->
+ </pre> +

+ +

o, en Windows

+

+ <pre>
+ <!--#exec cmd="dir" -->
+ </pre> +

+ +

Notará un formato estraño con esta directiva en Windows, porque el resultado de dir contiene la cadena de caracterers ``<dir>'' ,que confunde a los navegadores.

+ +

Tenga en cuenta de que esta característica es muy peligrosa, puesto que ejecutará cualquier código que esté especificado con la etiqueta + exec. Si tiene una situación en la que los usuarios pueden editar contenido en sus páginas web, tales como por ejemplo un ``registro de visitas'', asegúrese de tener esta característica deshabilitada. Puede permitir SSI, pero no la característica exec, con el argumento IncludesNOEXEC en la directiva Options.

+
top
+
+

Técnicas avanzadas de SSI

+ + +

Además de mostrar contenido, SSI en Apache da la opción de configurar variables y usar esas variables en comparaciones y condicionales.

+ +

Configurando Variables

+ +

Usando la directiva set, puede configurar variables para su uso posterior. La sintaxis es como sigue:

+

+ <!--#set var="name" value="Rich" --> +

+ +

Además de configurar valores literales como esto, puede usar cualquier otra variable, incluyendo variables de entorno o las variables que se han mencionado antes (como por ejemplo LAST_MODIFIED) para dar valores a sus variables. Podrá especificar que algo es una vaiable, en lugar de una cadena de caracters literal, usando el símbolo del dolar ($) antes del nombre de la variable.

+ +

<!--#set var="modified" value="$LAST_MODIFIED" --> +

+ +

Para poner el símbolo del dolar de manera literal en un valor de su variable tendrá que escapar el símbolo del dolar con una barra "\".

+

+ <!--#set var="cost" value="\$100" --> +

+ +

Por último, si quiere poner una variable entre medias de una cadena de caracteres más larga, y se da la coincidencia de que el nombre de la variable se encontrará con otros caracteres, y de esta manera se confundirá con otros caracteres, puedes poner el nombre de la variable entre llaves, y así eliminar la confusión. (Es dificil encontrar un buen ejemplo para esto, pero con éste a lo mejor entiende lo que tratamos de transmitir.)

+

+ <!--#set var="date" value="${DATE_LOCAL}_${DATE_GMT}" --> +

+ + +

Expresiones condicionales

+ + +

Ahora que tenemos variables, y somos capaces de comparar sus valores, podemos usarlas para expresar condicionales. Esto permite a SSI ser un cierto tipo de lenguaje de programación diminuto. + mod_include provee una estrucura if, + elif, else, endif + para construir declaraciones condicionales. Esto le permite generar de manera efectiva multitud de páginas lógicas desde tan solo una página.

+ +

La estructura de este sistema condicional es:

+

+ <!--#if expr="test_condition" -->
+ <!--#elif expr="test_condition" -->
+ <!--#else -->
+ <!--#endif --> +

+ +

Una test_condition puede ser cualquier tipo de comparación lógica - o bien comparando valores entre ellos, o probando la ``verdad'' (o falsedad) de un valor en particular. (Una cadena de caracteres cualquiera es verdadera si no está vacía.) Para una lista completa de operadores de comparación, vea la documentación de mod_include.

+ +

Por ejemplo, si quiere personalizar el texto en su página web basado en la hora actual, puede usar la siguiente receta, colocada en su página HTML:

+ +

+ Good + <!--#if expr="%{TIME_HOUR} <12" -->
+ morning!
+ <!--#else -->
+ afternoon!
+ <!--#endif -->
+

+ +

Cualquier otra variable (o bien las que defina usted, o variables de entorno normales) puede usarse en declaraciones condicionales. + Vea Expresiones en el Servidor Apache HTTP para más información sobre el motor de evaluación de expresiones.

+ +

Con la habilidad de Apache de configurar variables de entorno con directivas SetEnvIf, y otras directivas relacionadas, + esta funcionalidad puede llevarle a hacer una gran variedad de contenido dinámico en la parte de servidor sin tener que depender de una aplicación web al completo.

+ +
top
+
+

Conclusión

+ +

Desde luego SSI no es un reemplazo para CGI u otras tecnologías que se usen para generar páginas web dinámicas. Pero es un gran método para añadir pequeñas cantidaddes de contenido dinámico a páginas web, sin hacer mucho más trabajo extra.

+
+
+

Idiomas disponibles:  en  | + es  | + fr  | + ja  | + ko 

+
top

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/ssi.html.fr.utf8 b/docs/manual/howto/ssi.html.fr.utf8 new file mode 100644 index 0000000..a5bfcf6 --- /dev/null +++ b/docs/manual/howto/ssi.html.fr.utf8 @@ -0,0 +1,518 @@ + + + + + +Tutoriel Apache httpd : Introduction aux "Inclusions Côté Serveur" +(Server Side Includes - SSI) - Serveur HTTP Apache Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.4

+
+
<-
+

Tutoriel Apache httpd : Introduction aux "Inclusions Côté Serveur" +(Server Side Includes - SSI)

+
+

Langues Disponibles:  en  | + es  | + fr  | + ja  | + ko 

+
+ +

Les SSI permettent d'ajouter du contenu dynamique à des documents +HTML préexistants.

+
+ +
top
+
+

Introduction

+
Modules ApparentésDirectives Apparentées
+ +

Cet article traite des Inclusions Côté Serveur (Server Side + Includes), plus communément appelés SSI. Vous trouverez ici la + manière de configurer votre serveur pour permettre les SSI, ainsi + qu'une introduction à quelques techniques SSI de base permettant + d'ajouter du contenu dynamique à vos pages HTML préexistantes.

+ +

La dernière partie de cet article sera consacrée aux + configurations SSI plus avancées, telles que les expressions + conditionnelles dans les directives SSI.

+ +
top
+
+

Qu'est-ce que SSI ?

+ +

SSI (Server Side Includes) est constitué de directives placées dans + des pages HTML, et évaluées par le serveur au moment où les pages + sont servies. Elles vous permettent d'ajouter du contenu généré + dynamiquement à une page HTML préexistante, sans avoir à servir la + page entière via un programme CGI, ou toute autre technologie de + contenu dynamique.

+ +

Par exemple, vous pouvez insérer la directive suivante dans une + page HTML existante :

+ +

+ <!--#echo var="DATE_LOCAL" --> +

+ +

Ainsi, lorsque la page sera servie, la directive sera évaluée et + remplacée par sa valeur :

+ +

+ Tuesday, 15-Jan-2013 19:28:54 EST +

+ +

Le choix entre l'utilisation des SSI et la génération entière de + la page par un programme quelconque, est en général dicté par la + proportion de contenu statique et de contenu devant être généré + chaque fois que la page est servie. SSI est idéal pour ajouter de + petites quantités d'information, comme l'heure courante dans + l'exemple précédent. Mais si la + plus grande partie de votre page est générée au moment où elle est + servie, vous devez vous tourner vers une autre solution.

+
top
+
+

Configurer votre serveur pour permettre les SSI

+ + +

Pour permettre l'utilisation des SSI sur votre serveur, vous + devez ajouter la directive suivante dans votre fichier + httpd.conf, ou dans un fichier .htaccess + :

+
Options +Includes
+ + +

Cette directive indique à Apache que vous désirez permettre la + recherche de directives SSI lors de l'interprétation des fichiers. + Notez cependant que la plupart des configurations contiennent de + nombreuses directives Options + qui peuvent s'écraser les unes les autres. Vous devrez probablement + appliquer ces directives Options au répertoire + spécifique pour lequel vous voulez activer les SSI, afin d'être sûr + qu'elles y seront bien activées.

+ +

Tout fichier ne fera cependant pas l'objet de recherche de + directives SSI. Vous devez indiquer à Apache quels fichiers seront + concernés. Vous pouvez y parvenir en indiquant une extension, comme + .shtml, à l'aide des directives suivantes :

+
AddType text/html .shtml
+AddOutputFilter INCLUDES .shtml
+ + +

Un des désavantages de cette approche réside dans le fait que si + vous voulez ajouter des directives SSI à une page préexistante, vous + devrez changer le nom de cette page, et donc tout lien qui la + contient, de façon à ce qu'elle possède l'extension + .shtml, condition nécessaire pour que les directives + SSI qu'elle contient soient traitées.

+ +

Une autre méthode consiste à utiliser la directive XBitHack :

+
XBitHack on
+ + +

La directive XBitHack + indique à Apache qu'il doit rechercher des directivves SSI dans les + fichiers si leur bit d'exécution est positionné. Il n'est ainsi plus + nécessaire de changer le nom du fichier pour ajouter des directives + SSI à une page préexistante ; vous devez simplement attribuer les + droits d'exécution au fichier à l'aide de chmod.

+

+ chmod +x pagename.html +

+ +

Un bref commentaire sur ce qu'il ne faut pas faire. Certaines + personnes peuvent vous conseiller de tout simplement indiquer à + Apache de rechercher des directives SSI dans tous les fichiers + .html, ce qui vous évite d'avoir à gérer les noms de + fichiers avec extension .shtml. Ils n'ont probablement + pas entendu parler de la directive XBitHack. En effet, vous devez + garder à l'esprit qu'en faisant ceci, Apache va devoir rechercher + des directives SSI dans chaque fichier qu'il sert, même s'il n'en + contient aucune. Ce n'est donc pas une bonne idée car les + performances peuvent en être sensiblement affectées.

+ +

Bien entendu, sous Windows, il n'y a pas de bit d'exécution à + positionner, ce qui limite un peu vos choix.

+ +

Dans sa configuration par défaut, Apache n'envoie pas la date de + dernière modification ou les en-têtes HTTP relatifs à la taille des + contenus dans les pages SSI, car ses valeurs sont difficiles à + calculer pour les contenus dynamiques. Ceci peut induire une + impression de diminution des performances côté client, en empêchant + la mise en cache de votre document. Il existe deux méthodes pour + résoudre ce problème :

+ +
    +
  1. Utilisez la configuration XBitHack Full. Elle + indique à Apache de déterminer la date de dernière modification en + ne regardant que la date du fichier à l'origine de la requête, + tout en ignorant la date de modification de tout fichier inclus.
    2. + +
  2. Utilisez les directives fournies par le module + mod_expires pour définir de manière explicite la + date d'expiration de vos fichiers, laissant par la-même + aux navigateurs et aux mandataires le soin de déterminer s'il est + opportun ou non de les mettre en cache.
    3. +
+
top
+
+

Directives SSI de base

+ +

Les directives SSI adoptent la syntaxe suivante :

+

+ <!--#fonction attribut=valeur attribut=valeur ... --> +

+ +

Le format d'une directive SSI étant similaire à celui d'un + commentaire HTML, si vous n'avez pas activé correctement SSI, le + navigateur l'ignorera, mais elle sera encore visible dans le source + HTML. Si SSI est correctement configuré, la directive sera remplacée + par ses résultats.

+ +

"fonction" peut prendre de nombreuses formes, et nous décrirons + plus précisément la plupart d'entre eux dans la prochaine version de + ce document. Pour le moment, voici quelques exemples de ce que vous + pouvez faire avec SSI.

+ +

La date courante

+ +

+ <!--#echo var="DATE_LOCAL" --> +

+ +

La fonction echo permet d'afficher la valeur d'une + variable. Il existe un grand nombre de variables standards, y + compris l'ensemble des variables d'environnement disponibles pour + les programmes CGI. De plus, vous pouvez définir vos propres + variables à l'aide de la fonction set.

+ +

Si vous n'aimez pas le format sous lequel la date s'affiche, vous + pouvez utiliser la fonction config avec un attribut + timefmt, pour le modifier.

+ +

+ <!--#config timefmt="%A %B %d, %Y" -->
+ Today is <!--#echo var="DATE_LOCAL" --> +

+ + +

Date de modification du fichier

+ +

+ Dernière modification du document <!--#flastmod file="index.html" --> +

+ +

Le format peut là aussi être modifié à l'aide de l'attribut + timefmt.

+ + +

Inclusion des résultats d'un programme CGI

+ +

C'est le cas le plus courant d'utilisation des SSI - afficher les + résultats d'un programme CGI, comme l'universellement adoré + "compteur d'accès".

+ +

+ <!--#include virtual="/cgi-bin/counter.pl" --> +

+ + +
top
+
+

Exemples additionnels

+ + +

Vous trouverez dans ce qui suit quelques exemples spécifiques de + ce que vous pouvez faire de vos documents HTML avec SSI.

+ +

Quand ce document a-t-il été modifié ?

+ +

Nous avons mentionné plus haut que vous pouviez utiliser SSI pour + informer l'utilisateur de la date de dernière modification du + document. Cependant, la méthode pour y parvenir n'a pas été vraiment + abordée. Placé dans votre document HTML, le code suivant va insérer + un repère de temps dans votre page. Bien entendu, SSI devra avoir + été correctement activé, comme décrit plus haut.

+

+ <!--#config timefmt="%A %B %d, %Y" -->
+ Dernière modification du fichier <!--#flastmod file="ssi.shtml" --> +

+ +

Bien entendu, vous devez remplacer ssi.shtml par le + nom du fichier auquel vous faites référence. Ceci ne conviendra pas + si vous recherchez un morceau de code générique que vous pourrez + insérer dans tout fichier ; dans ce cas, il est préférable + d'utiliser la variable LAST_MODIFIED :

+

+ <!--#config timefmt="%D" -->
+ This file last modified <!--#echo var="LAST_MODIFIED" --> +

+ +

Pour plus de détails sur le format timefmt, tapez + strftime dans votre moteur de recherche préferé. La + syntaxe est identique.

+ + +

Inclusion d'un pied de page standard

+ + +

Si le site que vous gérez comporte plus que quelques pages, vous + allez vite vous apercevoir qu'effectuer des modifications sur toutes + ces pages peut devenir très contraignant, en particulier si vous + voulez qu'elles conservent un aspect homogène.

+ +

Inclure un fichier pour un en-tête et/ou un pied de page peut + simplifier cette corvée de mises à jour. Il vous suffit de + confectionner un fichier de pied de page, et de l'inclure dans + chaque page à l'aide de l'élément SSI include. Pour + définir le fichier à inclure, la fonction include peut + utiliser soit l'attribut file, soit l'attribut + virtual. L'attribut file est un chemin de + fichier relatif au répertoire courant. C'est à dire qu'il + ne peut ni avoir pour valeur un chemin absolu (commençant par /), ni + comporter "../" dans son chemin. L'attribut virtual est + probablement plus commode, et peut spécifier une URL relative au + document servi. Elle peut commencer par un /, mais le fichier inclus + et le fichier servi doivent résider sur le même serveur.

+

+ <!--#include virtual="/footer.html" --> +

+ +

Je combinerai souvent ces deux derniers points, en ajoutant une + directive LAST_MODIFIED dans un fichier de pied de page + destiné à être inclus. Le fichier inclus peut contenir des + directives SSI, et les inclusions peuvent être imbriquées - à + savoir, le fichier inclus peut inclure un autre fichier, etc...

+ + +
top
+
+

Que puis-je configurer d'autre ?

+ + +

En plus du format de date, vous pouvez utiliser l'élément + config pour configurer deux autres choses.

+ +

En général, lorsque quelque chose se passe mal avec votre + directive SSI, vous recevez le message :

+

+ [an error occurred while processing this directive] +

+ +

Pour modifier ce message, vous pouvez utiliser l'attribut + errmsg avec la fonction config :

+

+ <!--#config errmsg="[Il semblerait que vous ne sachiez pas + utiliser les SSI]" --> +

+ +

Il est cependant probable que les utilisateurs finaux ne voient + jamais ce message, car vous aurez résolu tous les problèmes issus de + vos directives SSI avant que votre site ne soit mis en production. + (N'est-ce pas ?)

+ +

Vous pouvez aussi modifier le format sous lequel les tailles de + fichiers sont affichées à l'aide de l'attribut sizefmt. + Vous pouvez spécifier bytes pour un affichage en + octets, ou abbrev pour un affichage plus concis en Ko + ou Mo, selon le cas.

+
top
+
+

Exécution de commandes

+ + +

Voici autre chose que vous pouvez faire avec la fonction + exec. Vous pouvez vraiment faire exécuter une commande + par SSI en utilisant le shell (/bin/sh, pour être plus + précis - ou le shell DOS, si vous êtes sous Win32). Par exemple, ce + qui suit vous permet d'afficher le contenu d'un répertoire.

+

+ <pre>
+ <!--#exec cmd="ls" -->
+ </pre> +

+ +

ou, sous Windows

+

+ <pre>
+ <!--#exec cmd="dir" -->
+ </pre> +

+ +

Vous noterez probablement l'étrange formatage provoqué par cette + directive sous Windows, car la sortie de dir contient + la chaîne de caractères "<dir>", ce qui trompe le + navigateur.

+ +

Notez que cette fonctionnalité est très dangereuse, car elle va + permettre d'exécuter tout code associé à l'élément + exec. Si vous êtes dans la situation où les + utilisateurs peuvent éditer le contenu de vos pages web, dans le cas + d'un "livre d'or" par exemple, assurez-vous de désactiver cette + fonctionnalité. Vous pouvez, tout en permettant les SSI, désactiver + la fonctionnalité exec à l'aide de l'argument + IncludesNOEXEC de la directive + Options.

+
top
+
+

Techniques SSI avancées

+ + +

Outre l'affichage de contenu, les SSI d'Apache vous permettent de + définir des variables, et de les utiliser dans des comparaisons et + des conditions.

+ +

Définition de variables

+ +

Avec l'élément set, vous pouvez définir des + variables pour un usage ultérieur. Comme nous en aurons besoin plus + loin, nous allons en parler tout de suite. La syntaxe se présente + comme suit :

+

+ <!--#set var="name" value="Rich" --> +

+ +

Pour affecter une valeur à vos variables, en plus de la + définition littérale de l'exemple ci-dessus, vous pouvez utiliser + une autre variable, y compris les variables d'environnement, ou les variables + décrites plus haut (comme LAST_MODIFIED par exemple). + Pour indiquer qu'il s'agit d'une variable et non d'une chaîne, vous + devez utiliser le symbole dollar ($) devant le nom de la + variable.

+ +

<!--#set var="modified" value="$LAST_MODIFIED" --> +

+ +

Pour insérer un caractère $ dans la valeur de votre variable, + vous devez l'échapper à l'aide d'un backslash.

+

+ <!--#set var="cost" value="\$100" --> +

+ +

Enfin, si vous voulez insérer une variable dans une chaîne, et + s'il y a une chance pour que le nom de la variable se confonde avec + le reste de la chaîne, vous pouvez l'entourer d'accolades pour + eviter toute confusion (Il est difficile de trouver un bon exemple + pour illustrer ceci, mais j'espère que vous comprendrez).

+

+ <!--#set var="date" value="${DATE_LOCAL}_${DATE_GMT}" --> +

+ + +

Expressions conditionnelles

+ + +

Maintenent que nous avons des variables, et que nous pouvons + définir et comparer leurs valeurs, nous sommes à même de les + utiliser dans des expressions conditionnelles. Ceci confère à SSI le + statut de petit langage de programmation. + mod_include fournit une structure if, + elif, else, endif pour la + construction d'expressions conditionnelles, ce qui vous permet de + générer plusieurs pages logiques à partir d'une seule vraie + page.

+ +

La structure de l'expression conditionnelle est :

+

+ <!--#if expr="condition" -->
+ <!--#elif expr="condition" -->
+ <!--#else -->
+ <!--#endif --> +

+ +

Une condition peut revêtir la forme de toute comparaison + logique - soit une comparaison de valeurs avec une autre, soit une + vérification de la "vérité" d'une valeur particulière (Une chaîne + donnée est vraie si elle n'est pas vide). Pour une liste exhaustive + des opérateurs de comparaison disponibles, voir la documentation du + module mod_include.

+ +

Par exemple, spour insérer l'heure du jour dans votre page web, + vous pouvez ajouter ces lignes dans la page HTML :

+ +

+ Good + <!--#if expr="%{TIME_HOUR} <12" -->
+ morning!
+ <!--#else -->
+ afternoon!
+ <!--#endif -->
+

+ +

Toute autre variable (que vous avez définie, ou une variable + d'environnement normale) peut être utilisée dans les expressions + conditionnelles. Voir le document Expressions + rationnelles dans le serveur HTTP Apache pour plus de détails à + propos du fonctionnement du moteur d'évaluation des expressions + rationnelles.

+ +

Associée à la possibilité avec Apache de définir + des variables d'environnement à l'aide de directives + SetEnvIf, ainsi que d'autres directives en rapport, + cette fonctionnalité vous permet d'ajouter une grande variété + de contenus dynamiques côté serveur sans avoir à concevoir une + application web de A à Z.

+ +
top
+
+

Conclusion

+ +

SSI ne remplace certainement pas CGI, ou d'autres technologies + utilisées pour la génération de pages web dynamiques. Mais c'est une + bonne méthode pour ajouter des petits contenus dynamiques à vos + pages, sans devoir fournir un gros effort supplémentaire.

+
+
+

Langues Disponibles:  en  | + es  | + fr  | + ja  | + ko 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/ssi.html.ja.utf8 b/docs/manual/howto/ssi.html.ja.utf8 new file mode 100644 index 0000000..269df5a --- /dev/null +++ b/docs/manual/howto/ssi.html.ja.utf8 @@ -0,0 +1,515 @@ + + + + + +Apache チュートリアル: Server Side Includes 入門 - Apache HTTP サーバ バージョン 2.4 + + + + + + +
+

モジュール | ディレクティブ | FAQ | 用語 | サイトマップ

+

Apache HTTP サーバ バージョン 2.4

+
+
<-
+

Apache チュートリアル: Server Side Includes 入門

+
+

翻訳済み言語:  en  | + es  | + fr  | + ja  | + ko 

+
+
この日本語訳はすでに古くなっている + 可能性があります。 + 最近更新された内容を見るには英語版をご覧下さい。 +
+ +

サーバサイドインクルードによって、既存の HTML +ドキュメントに動的なコンテンツを追加することができます。

+
+ +
top
+
+

はじめに

+
関連モジュール関連ディレクティブ
+ +

この記事は、通常は単に SSI と呼ばれる Server Side Includes + を扱います。この記事においては、サーバでの SSI を許可するための設定と、 + 現在の HTML ページに動的なコンテンツを加えるためのいくつかの基本的な + SSI 技術を紹介します。

+ +

記事の後半では、SSI ディレクティブで SSI + と共に実行することができる条件文のような + 幾分高度な事柄について述べています。

+ +
top
+
+

SSI とは ?

+ +

SSI (Server Side Includes) は、HTML + ページ中に配置されるディレクティブであり、 + サーバでページを提供する時に評価されます。SSI は、CGI + プログラムやその他の動的な技術で全てのページを提供せずに、 + 動的に生成されたコンテンツを現在の HTML ページに加えます。

+ +

どういう場合に SSI を使い、どういう場合にプログラムで + ページを完全に生成するかは、ページのうちどの程度が静的であり、 + ページが提供されるたびに再計算する必要がどの程度あるかで通常は決定します。 + SSI は現在時刻のような小さい情報を加えるにはうってつけの方法です。 + しかし、そのページのほとんどの部分が提供時に生成される場合は、 + 他の方法を探す必要があります。

+
top
+
+

SSI を許可するためのサーバの設定

+ + +

サーバで SSI を許可するには、httpd.conf + ファイルまたは .htaccess + ファイルに次のディレクティブを指定する必要があります:

+

+ Options +Includes +

+ +

この指定は、ファイルを SSI + ディレクティブで解析させることを許可するということを Apache + に伝えます。ほとんどの設定ではお互いを上書きできる、複数の + Options があることに + 注意してください。おそらく、設定が最後に評価されることを + 保証されるために、SSI を使用したいディレクトリに Options + ディレクティブを適用する必要があるでしょう。

+ +

全てのファイルが SSI + ディレクティブで解析されるというわけではありません。 + どのファイルが解析されるかを Apache に伝える必要があります。 + これを行なうには二つ方法があります。 + 次のディレクティブを使うことで、例えば .shtml + のような特別なファイル拡張子を持つファイルを解析するよう + Apache に伝えることができます:

+

+ AddType text/html .shtml
+ AddOutputFilter INCLUDES .shtml +

+ +

この方法の欠点は、もし現在のページに SSI ディレクティブを加えたい場合、 + それらのディレクティブが実行されるように + .shtml 拡張子にするため、そのページの名前と、 + そのページへの全てのリンクを変更しなければならないことです。

+ +

もう一つの方法は、XBitHack + ディレクティブを使用することです:

+

+ XBitHack on +

+ +

XBitHack + は、ファイルの実行ビットが立っている場合、 + SSI ディレクティブにより解析することを Apache に伝えます。 + 従って、SSI ディレクティブを現在のページに加えるためには、 + ファイル名を変更しなくてもよく、単に chmod + を使用してファイルを実行可能にするだけで済みます。

+

+ chmod +x pagename.html +

+ +

行なうべきではないことに関する短いコメント。時々誰かが、全ての + .html ファイルを SSI で解析するよう Apache に伝えれば、 + わざわざ .shtml というファイル名にする必要がないといって + 薦めるのを見ることでしょう。こういう人たちは、おそらく + XBitHack + について聞いたことがないのでしょう。 + この方法について注意することは、たとえ SSI + ディレクティブを全く含まない場合でも、Apache がクライアントに + 送る全てのファイルを最後まで読み込ませることになります。 + この方法はかなり処理を遅くするものであり、良くないアイデアです。

+ +

もちろん、Windows ではそのような実行ビットをセット + するようなものはありませんのでオプションが少し制限されています。

+ +

デフォルトの設定では、Apache は SSI ページについて最終変更時刻や + コンテンツの長さを HTTP ヘッダに送りません。 + 動的なコンテンツであるため、それらの値を計算するのが難しいからです。 + このためドキュメントがキャッシュされなくなり、 + 結果としてクライアントの性能が遅くなったように感じさせることになります。 + これを解決する方法が二つあります:

+ +
    +
  1. XBitHack Full 設定を使用する。 + この設定により、もともと要求されたファイルの時刻を参照し、 + 読み込まれるファイルの変更時刻を無視して最終変更時刻を決定するよう + Apache に伝えます。
    2. + +
  2. mod_expires + で提供されているディレクティブを使用して、 + ファイルが無効になる時刻を明示します。これにより、 + ブラウザとプロキシにキャッシュが有効であることを通知します。
    3. +
+
top
+
+

基本的な SSI ディレクティブ

+ +

SSI ディレクティブは以下の文法で記述します:

+

+ <!--#element attribute=value attribute=value ... --> +

+ +

HTML のコメントのような書式をしているので、もし SSI + を正しく動作可能にしなければ、ブラウザはそれを無視するでしょう。 + しかし、HTML ソース中では見えます。もし SSI を正しく設定したなら、 + ディレクティブはその結果と置き換えられます。

+ +

element はたくさんあるものから一つ指定することができます。 + 指定できるものの大多数については、次回もう少し詳しく説明します。 + ここでは、SSI で行なうことができる例をいくつか示します。

+ +

今日の日付

+ +

+ <!--#echo var="DATE_LOCAL" --> +

+ +

echo 要素は単に変数の値を出力します。 + CGI プログラムに利用可能な環境変数の全ての + セットを含む多くの標準変数があります。また、set + 要素を用いることで、独自の変数を定義することができます。 +

+ +

出力される日付の書式が好きではない場合、その書式を修正するために、 + config 要素に timefmt + 属性を使用することができます。

+ +

+ <!--#config timefmt="%A %B %d, %Y" -->
+ Today is <!--#echo var="DATE_LOCAL" --> +

+ + +

ファイルの変更日

+ +

+ This document last modified <!--#flastmod file="index.html" --> +

+ +

この要素も timefmt + フォーマットの設定に従います。

+ + +

CGI プログラムの結果を取り込む

+ +

これは、全ての人のお気に入りである ``ヒットカウンタ'' のような + CGI プログラムの結果を出力する SSI + のより一般的な使用のうちの一つです。

+ +

+ <!--#include virtual="/cgi-bin/counter.pl" --> +

+ + +
top
+
+

追加の例

+ + +

以下は、SSI を使用して HTML + ドキュメントにおいてできることのいくつかの特別な例です。

+ +

いつこのドキュメントは修正されたのか +?

+ +

先に、ドキュメントが最後に変更されたのはいつかを + ユーザに通知するために SSI を使用することができることを述べました。 + しかしながら、実際の方法は、いくぶん問題のままにしておきました。 + HTML ドキュメントに配置された次のコードは、ページにそのような + タイムスタンプを入れるでしょう。もちろん、上述のように、 + SSI を正しく動作可能にしておく必要があります。

+

+ <!--#config timefmt="%A %B %d, %Y" -->
+ This file last modified <!--#flastmod file="ssi.shtml" --> +

+ +

もちろん、ssi.shtml + の部分を実際の当該ファイル名と置き換える必要があります。 + もし、あらゆるファイルに張ることができる一般的なコードを探しているなら、 + これは不便であるかもしれません。おそらくその場合は、 + そうする代わりに変数 LAST_MODIFIED + を使用したいと考えるでしょう:

+

+ <!--#config timefmt="%D" -->
+ This file last modified <!--#echo var="LAST_MODIFIED" --> +

+ +

timefmt + 書式についてのより詳細については、お好みの検索サイトに行き、 + strftime で検索してみてください。文法は同じです。

+ + +

標準のフッタを挿入する

+ + +

もし数ページを超えるページを持つサイトを管理しているならば、 + 全ページに対して変項を行なうことが本当に苦痛となり得ることが + 分かるでしょう。全てのページに渡ってある種の標準的な外観を + 維持しようとしているならば特にそうでしょう。

+ +

ヘッダやフッタ用の挿入用ファイルを使用することで、 + このような更新にかかる負担を減らすことができます。 + 一つのフッタファイルを作成し、それを include + SSI コマンドで各ページに入れるだけで済みます。include + 要素は、file 属性または virtual + 属性のいずれかを使用してどのファイルを挿入するかを決めることができます。 + file 属性は、カレントディレクトリからの相対パスで示された + ファイルパスです。 + それは / で始まる絶対ファイルパスにはできず、また、そのパスの一部に ../ + を含むことができないことを意味します。virtual + 属性は、おそらくより便利だと思いますが、提供するドキュメントからの相対 + URL で指定すべきです。それは / で始めることができますが、 + 提供するファイルと同じサーバ上に存在しなくてはなりません。

+

+ <!--#include virtual="/footer.html" --> +

+ +

私は最後の二つを組み合わせて、LAST_MODIFIED + ディレクティブをフッタファイルの中に置くことがよくあります。 + SSI ディレクティブは、挿入用のファイルに含ませたり、 + 挿入ファイルのネストをしたりすることができます。すなわち、 + 挿入用のファイルは他のファイルを再帰的に挿入することができます。

+ + +
top
+
+

他に何が設定できるのか ?

+ + +

時刻書式を config で設定できることに加えて、 + 更に二つ config で設定することができます。

+ +

通常、SSI ディレクティブで何かがうまくいかないときは、 + 次のメッセージが出力されます。

+

+ [an error occurred while processing this directive] +

+ +

このメッセージを他のものにしたい場合、config + 要素の errmsg 属性で変更することができます:

+

+ <!--#config errmsg="[It appears that you don't know how to use SSI]" --> +

+ +

おそらく、エンドユーザはこのメッセージを決して見ることはありません。 + なぜなら、そのサイトが生きた状態になる前に SSI ディレクティブに関する + 全ての問題を解決しているはずだからです。(そうですよね?)

+ +

そして、config において sizefmt + 属性を使用することで、 + 返されるファイルサイズの書式を設定することができます。 + バイト数には bytes を、適当に Kb や Mb + に短縮させるには abbrev を指定することができます。

+
top
+
+

コマンドの実行

+ + +

今後数ヶ月のうちに、小さな CGI プログラムと SSI + を使用する記事を出したいと考えています。ここではそれとは別に、 + exec 要素によって行なうことができることを示します。 + SSI にシェル (正確には /bin/sh。Win32 ならば DOS シェル) + を使用してコマンドを実行させることができます。 + 下記の例では、ディレクトリリスト出力を行ないます。

+

+ <pre>
+ <!--#exec cmd="ls" -->
+ </pre> +

+ +

Windows 上では、

+

+ <pre>
+ <!--#exec cmd="dir" -->
+ </pre> +

+ +

Windows 上では、このディレクティブによっていくつかの奇妙な + 書式に気づくでしょう。なぜなら dir の出力が文字列 + ``<dir>'' を含み、ブラウザを混乱させるからです。

+ +

この機能は非常に危険であり、どんなコードでも exec + タグに埋め込まれてしまえば実行することに注意してください。例えば + `` ゲストブック '' のように、もし、 + ユーザがページの内容を編集できる状況にあるならば、 + この機能を確実に抑制してください。Options + ディレクティブの IncludesNOEXEC 引数を指定することで、 + SSI は許可するけれど exec + 機能は許可しないようにすることができます。

+
top
+
+

高度な SSI テクニック

+ + +

コンテンツを出力することに加え、Apache SSI は変数を設定し、 + そして比較と条件分岐にその変数を使用できる機能を提供しています。 +

+ +

警告

+ +

この記事で述べた大部分の機能は、Apache 1.2 + 以降を使用している場合のみ利用可能です。もちろん、もし Apache 1.2 + 以降を使用してない場合、直ちにアップグレードする必要があります。 + さぁ、今それを行ないなさい。それまで待っています。

+ + +

変数を設定する

+ +

set ディレクティブを使用して、 + 後で使用するために変数を設定することができます。 + これは後の説明で必要になるので、ここでそれについて述べています。 + 文法は以下のとおりです:

+

+ <!--#set var="name" value="Rich" --> +

+ +

このように単純に文字どおりに設定することに加え、 + 環境変数や上記の変数 + (例えば LAST_MODIFIED のような) + を含む他のあらゆる変数を値を設定するのに使用することができます。 + 変数名の前にドル記号 ($) を使用することで、 + それがリテラル文字列ではなくて変数であることを示します。

+

+ <!--#set var="modified" value="$LAST_MODIFIED" --> +

+ +

ドル記号 ($) を文字として変数の値に入れるには、 + バックスラッシュによってドル記号をエスケープする必要があります。

+

+ <!--#set var="cost" value="\$100" --> +

+ +

最後になりますが、長い文字列の中に変数を置きたい場合で、 + 変数名が他の文字とぶつかる可能性があり、 + それらの文字について混乱してしまう場合、この混乱を取り除くため、 + 変数名を中括弧で囲むことができます + (これについての良い例を示すのは難しいのですが、 + おそらく分かっていただけるでしょう)。 +

+

+ <!--#set var="date" value="${DATE_LOCAL}_${DATE_GMT}" --> +

+ + +

条件式

+ + +

さて、変数を持っていて、 + それらの値を設定して比較することができるのですから、 + 条件を表すためにそれらを使用することができます。これにより + SSI はある種の小さなプログラミング言語になっています。 + mod_include は条件を表現するために if, + elif, else, endif + 構造を提供しています。これによって、 + 一つの実際のページから複数の論理ページを効果的に生成することができます。

+ +

条件構造は以下のとおりです:

+

+ <!--#if expr="test_condition" -->
+ <!--#elif expr="test_condition" -->
+ <!--#else -->
+ <!--#endif --> +

+ +

test_condition + はあらゆる種類の論理的比較をすることができます。 + 値を比較したり、その値が ``真'' かどうかを評価します + (空でないなら与えられた文字列は真です)。 + 利用可能な比較演算子の全てのリストについては、 + mod_include ドキュメンテーションを参照してください。 + ここでは、この構造をどう使用するかの例をいくつか示します。

+ +

設定ファイルで次の行を記述します:

+

+ BrowserMatchNoCase macintosh Mac
+ BrowserMatchNoCase MSIE InternetExplorer +

+ +

これはクライアントが Macintosh + 上でインターネットエクスプローラが動いている場合、環境変数 + ``Mac'' と ``InternetExplorer'' を真と設定します。

+ +

次に、SSI が可能になったドキュメントで以下を行ないます: +

+

+ <!--#if expr="${Mac} && ${InternetExplorer}" -->
+ Apologetic text goes here
+ <!--#else -->
+ Cool JavaScript code goes here
+ <!--#endif --> +

+ +

Mac 上の IE に対して何か思うところがあるわけでありません。 + 他では実行できているいくつかの JavaScript を Mac 上の IE + で実行させるのに、先週数時間苦労したというだけのことです。 + 上の例はその暫定的な対処方法です。

+ +

他のどんな変数 (あなたが定義するもの、 + または普通の環境変数のいずれか) も、条件文に使用することができます。 + Apache は SetEnvIf ディレクティブや他の関連 + ディレクティブを使用して環境変数を設定することができます。 + この機能により、CGI + に頼ることなくかなり複雑な動的なことをさせることができます。

+ +
top
+
+

終わりに

+ +

SSI は確かに CGI + や動的なウェブページを生成する他の技術に代わるものではありません。 + しかし、たくさんの余分な作業をせずに、 + 少量の動的なコンテンツを加えるにはすぐれた方法です。

+
+
+

翻訳済み言語:  en  | + es  | + fr  | + ja  | + ko 

+
top

コメント

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/ssi.html.ko.euc-kr b/docs/manual/howto/ssi.html.ko.euc-kr new file mode 100644 index 0000000..01ebf3c --- /dev/null +++ b/docs/manual/howto/ssi.html.ko.euc-kr @@ -0,0 +1,458 @@ + + + + + +ġ 丮: Server Side Includes Ұ - Apache HTTP Server Version 2.4 + + + + + + +
+

| þ | FAQ | | Ʈ

+

Apache HTTP Server Version 2.4

+
+
<-
+

ġ 丮: Server Side Includes Ұ

+
+

:  en  | + es  | + fr  | + ja  | + ko 

+
+
ֽ ƴմϴ. + ֱٿ ϼ.
+ +

Server-side includes Ͽ HTML +߰ ִ.

+
+ +
top
+
+

Ұ

+
õ õ þ
+ +

SSI θ Server Side Includes Ѵ. + SSI ϵ ϴ HTML + ߰ϴ ⺻ SSI ҰѴ.

+ +

޺κ SSI þ ǹ ޱ + Ѵ.

+ +
top
+
+

SSI ΰ?

+ +

SSI (Server Side Includes) HTML ϴ þ, + Ҷ óѴ. SSI ϸ CGI + α׷̳ ٸ ü  + ʰ HTML ߰ + ִ.

+ +

SSI ƴϸ α׷ ü + κ + ٽ ؾ ޷ȴ. SSI + ð ߰ϴµ . ׷ + Ҷ κ ؾ Ѵٸ ٸ + ãƺ Ѵ.

+
top
+
+

SSI ϵ ϱ

+ + +

SSI óϷ httpd.conf ̳ + .htaccess Ͽ þ ؾ Ѵ.

+

+ Options +Includes +

+ +

׷ ġ Ͽ SSI þ óѴ. + Options þ + ְ, þ Ἥ ȿ . ׷ + þ Ǹ óϱ SSI ϴ Ư + 丮 Options Ѵ.

+ +

Ͽ SSI þ óϴ ƴϴ. ġ +  ó ˷ Ѵ. ΰ ִ. + ϳ þ .shtml Ư + Ȯڸ óϴ ̴.

+

+ AddType text/html .shtml
+ AddOutputFilter INCLUDES .shtml +

+ +

̹ ִ SSI þ ߰ϴ + SSI þ óϱ .shtml Ȯڸ + οϱ⶧ ϸ ũ ؾ + ϴ ̴.

+ +

ٸ XBitHack + þ ϴ ̴.

+

+ XBitHack on +

+ +

XBitHack + ִ Ͽ SSI þ óѴ. ׷ ̹ + ִ SSI þ ߰Ѵٸ ϸ + ʰ chmod Ͽ ָ ȴ.

+

+ chmod +x pagename.html +

+ +

ƾ ϳ. .shtml ϸ + ġ .html SSI ó϶ + ϴ ִ. Ƹ XBitHack 𸣴 + . ̷ ϸ ġ Ͽ SSI þ + Ŭ̾Ʈ Ѵٴ + ̴. ſ , ƴϴ.

+ +

 ̶ ⶧ ڸ + .

+ +

̿ ϱ Ʊ⶧ ġ ⺻ + SSI ֱټϰ content length HTTP + ʴ´. ׷ ij ϰ Ŭ̾Ʈ + . ΰ ذ ִ.

+ +
    +
  1. XBitHack Full Ѵ. ׷ + ġ ϴ(include) ϵ ü + û ¥ ֱټ ˾Ƴ.
    2. + +
  2. mod_expires ִ þ Ͽ + Ͽ ϸ Ͻð + ij ִ.
    3. +
+
top
+
+

⺻ SSI þ

+ +

SSI þ .

+

+ <!--#element attribute=value attribute=value ... --> +

+ +

HTML ּ ⶧ SSI ʾƵ + HTML ҽ Ѵ. SSI ùٷ + ϸ þ ٲ۴.

+ +

element ϳ. ȸ ڼ ̴. + SSI ִ  δ

+ +

¥

+ +

+ <!--#echo var="DATE_LOCAL" --> +

+ +

echo element ״ Ѵ. + CGI α׷ ϴ ȯ溯 ܿ ǥ + ִ. , set element Ͽ + ִ.

+ +

¥ ʴ´ٸ, + config element timefmt attribute + Ѵ.

+ +

+ <!--#config timefmt="%A %B %d, %Y" -->
+ Today is <!--#echo var="DATE_LOCAL" --> +

+ + +

+ +

+ <!--#flastmod file="index.html" --> Ǿ +

+ +

element timefmt ޷ȴ.

+ + +

CGI α׷ ϱ

+ +

Ϲ SSI ϳ, ̵ ֿϴ ``湮 + ī'' CGI α׷ Ѵ.

+ +

+ <!--#include virtual="/cgi-bin/counter.pl" --> +

+ + +
top
+
+

߰

+ + +

HTML ִ  SSI .

+ +

+Ǿ?

+ +

տ SSI Ͽ ڿ ֱټ + ˸ ִٰ ߴ. ׷ ˷ ʾҴ. + ڵ带 HTML ϸ ð . + Ѵ SSI ùٷ ۵ؾ Ѵ.

+

+ <!--#config timefmt="%A %B %d, %Y" -->
+ <!--#flastmod file="ssi.shtml" --> Ǿ; +

+ +

ssi.shtml ϴ ϸ + Ѵ. ƹ ٿ ִ ڵ带 + Ѵٸ, ϸ LAST_MODIFIED + Ѵ.

+

+ <!--#config timefmt="%D" -->
+ This file last modified <!--#echo var="LAST_MODIFIED" --> +

+ +

timefmt Ŀ ڼ ˻ + strftime ãƺ. .

+ + +

ǥ ϴ ϱ

+ + +

ִ Ʈ Ѵٸ ü + ϴ , Ư ǥ ܰ ϴ + Ӵ.

+ +

(header) ϴ(footer) Ϸ Ͽ + ̷ δ ִ. + include SSI ɾ Ͽ ϴ + ϳ ϸ ȴ. include element + file attribute virtual attribute + Ѵ. file attribute + 丮 ϰδ. , (/ ϴ) + ϰγ ȿ ../ . Ƹ ϴ + URL ִ virtual attribute + ̴. θ / , Ϸ + ϴ ϰ ־ Ѵ.

+

+ <!--#include virtual="/footer.html" --> +

+ +

ΰ ļ ϴ Ͽ + LAST_MODIFIED þ ִ´. Ϸ Ͽ + SSI þ , ̷ ٸ + ϴ ִ.

+ + +
top
+
+

̿ܿ ִ ?

+ + +

ð config() ܿ ΰ + config() ִ.

+ +

SSI þ ߸Ǹ ´

+

+ [an error occurred while processing this directive] +

+ +

ϰ ʹٸ config element + errmsg attribute Ͽ Ѵ.

+

+ <!--#config errmsg="[It appears that you don't know how to use SSI]" --> +

+ +

Ʈ ϱ SSI þ ذϿ + ڰ ̷ ʱ ٶ. (׷?)

+ +

׸ sizefmt attribute ȯϴ ũ + config() ִ. Ʈ ũ⸦ + ַ bytes, Kb Mb ũ⸦ + ַ abbrev Ѵ.

+
top
+
+

ɾ ϱ

+ + +

޿ CGI α׷ SSI ϴ + ̴. exec element + ִ ٸ ͵ ̴. SSI (Ȯ + /bin/sh Win32 Ѵٸ DOS ) Ͽ + ɾ Ѵ. , 丮 ش.

+

+ <pre>
+ <!--#exec cmd="ls" -->
+ </pre> +

+ +

or, on Windows

+

+ <pre>
+ <!--#exec cmd="dir" -->
+ </pre> +

+ +

dir ¿ ȥ + ``<dir>'' ڿ Եֱ⶧, +  þ ϸ ̻ ̴.

+ +

exec ±׿  ɾ + ֱ⶧ ſ ϴ. ``'' ڰ + ִ ȯ̶, + ؼ ȵȴ. Options þ + IncludesNOEXEC ƱԸƮ Ͽ SSI + exec ִ.

+
top
+
+

SSI

+ + +

ϴ ܿ ġ SSI ϰ, + 񱳹 ǹ ִ.

+ +

+ +

ۿ ϴ κ ġ 1.2 ĺ + ִ. , ġ 1.2 ̻ ʴ´ٸ + Ƹ ׷̵ؾ Ѵ. ض. ض. ٸ + ̴.

+ + +

+ +

set þ Ͽ ߿ + ִ. ʿϱ⶧ Ѵ. + .

+

+ <!--#set var="name" value="Rich" --> +

+ +

ڱ״ ʰ ȯ溯 ( + , LAST_MODIFIED) ٸ Ͽ + ִ. ̶ տ ޷ ǥ($) + ٿ ڿ ƴ ǥѴ.

+ +

<!--#set var="modified" value="$LAST_MODIFIED" --> +

+ +

޷ ڸ ״ ԷϷ ޷ ǥ տ + 齽 Ѵ.

+

+ <!--#set var="cost" value="\$100" --> +

+ +

ڿ ߰ ϴµ ڿ ִ + ڵ Ͽ ȥǴ , ȣ +  Ȯ Ѵ. ( ã , + ϱ ٶ.)

+

+ <!--#set var="date" value="${DATE_LOCAL}_${DATE_GMT}" --> +

+ + +

ǥ

+ + +

ϰ ǹ ϴ. + SSI α׷־ ȴ. + mod_include ǹ if, + elif, else, endif + Ѵ. + ִ.

+ +

ǹ .

+

+ <!--#if expr="test_condition" -->
+ <!--#elif expr="test_condition" -->
+ <!--#else -->
+ <!--#endif --> +

+ +

test_condition  񱳶 + ִ. ٸ ϰų, Ư ``'' + ˻Ѵ. (ڿ ̴.) 밡 + ڸ , mod_include + ϶. ǹ  .

+ +

Ͽ ߰Ѵ.

+

+ BrowserMatchNoCase macintosh Mac
+ BrowserMatchNoCase MSIE InternetExplorer +

+ +

Ŭ̾Ʈ Ųÿ ϴ Internet Explorer + ȯ溯 ``Mac'' ``InternetExplorer'' Ѵ.

+ +

׸ SSI ´.

+

+ <!--#if expr="${Mac} && ${InternetExplorer}" -->
+ ⿡ ´
+ <!--#else -->
+ ⿡ JavaScript ڵ尡 ´
+ <!--#endif --> +

+ +

Ų IE ݰ ִ ƴϴ. + ֿ ٸ JavaScript ڵ尡 Ų + IE ʾƼ ð ߴ. ӽ + ذå̴.

+ +

( Ͽ Ϲ ȯ溯̰)  ǹ + ִ. ƶġ SetEnvIf ٸ + þ ȯ溯 ֱ⶧ CGI ̵ + ִ.

+ +
top
+
+

+ +

SSI Ȯ CGI ϴ ٸ + ü . ׷ ߰ ۾ + ߰ϱ⿡ Ǹ ̴.

+
+
+

:  en  | + es  | + fr  | + ja  | + ko 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file -- cgit v1.2.3