From cc40af334e619bb549038238507407866f774f8f Mon Sep 17 00:00:00 2001 From: hongbotian Date: Mon, 30 Nov 2015 01:35:09 -0500 Subject: upload apache JIRA: BOTTLENECK-10 Change-Id: I67eae31de6dc824097dfa56ab454ba36fdd23a2c Signed-off-by: hongbotian --- rubbos/app/apache2/manual/howto/auth.html | 17 + rubbos/app/apache2/manual/howto/auth.html.en | 355 +++++++++++++ rubbos/app/apache2/manual/howto/auth.html.es | 374 ++++++++++++++ rubbos/app/apache2/manual/howto/auth.html.ja.utf8 | 388 ++++++++++++++ .../app/apache2/manual/howto/auth.html.ko.euc-kr | 325 ++++++++++++ rubbos/app/apache2/manual/howto/cgi.html | 13 + rubbos/app/apache2/manual/howto/cgi.html.en | 555 +++++++++++++++++++++ rubbos/app/apache2/manual/howto/cgi.html.ja.utf8 | 546 ++++++++++++++++++++ rubbos/app/apache2/manual/howto/cgi.html.ko.euc-kr | 503 +++++++++++++++++++ rubbos/app/apache2/manual/howto/htaccess.html | 13 + rubbos/app/apache2/manual/howto/htaccess.html.en | 386 ++++++++++++++ .../app/apache2/manual/howto/htaccess.html.ja.utf8 | 347 +++++++++++++ .../apache2/manual/howto/htaccess.html.ko.euc-kr | 334 +++++++++++++ rubbos/app/apache2/manual/howto/index.html | 13 + rubbos/app/apache2/manual/howto/index.html.en | 105 ++++ rubbos/app/apache2/manual/howto/index.html.ja.utf8 | 102 ++++ .../app/apache2/manual/howto/index.html.ko.euc-kr | 107 ++++ rubbos/app/apache2/manual/howto/public_html.html | 17 + .../app/apache2/manual/howto/public_html.html.en | 163 ++++++ .../apache2/manual/howto/public_html.html.ja.utf8 | 157 ++++++ .../manual/howto/public_html.html.ko.euc-kr | 158 ++++++ .../apache2/manual/howto/public_html.html.tr.utf8 | 167 +++++++ rubbos/app/apache2/manual/howto/ssi.html | 13 + rubbos/app/apache2/manual/howto/ssi.html.en | 486 ++++++++++++++++++ rubbos/app/apache2/manual/howto/ssi.html.ja.utf8 | 481 ++++++++++++++++++ rubbos/app/apache2/manual/howto/ssi.html.ko.euc-kr | 426 ++++++++++++++++ 26 files changed, 6551 insertions(+) create mode 100644 rubbos/app/apache2/manual/howto/auth.html create mode 100644 rubbos/app/apache2/manual/howto/auth.html.en create mode 100644 rubbos/app/apache2/manual/howto/auth.html.es create mode 100644 rubbos/app/apache2/manual/howto/auth.html.ja.utf8 create mode 100644 rubbos/app/apache2/manual/howto/auth.html.ko.euc-kr create mode 100644 rubbos/app/apache2/manual/howto/cgi.html create mode 100644 rubbos/app/apache2/manual/howto/cgi.html.en create mode 100644 rubbos/app/apache2/manual/howto/cgi.html.ja.utf8 create mode 100644 rubbos/app/apache2/manual/howto/cgi.html.ko.euc-kr create mode 100644 rubbos/app/apache2/manual/howto/htaccess.html create mode 100644 rubbos/app/apache2/manual/howto/htaccess.html.en create mode 100644 rubbos/app/apache2/manual/howto/htaccess.html.ja.utf8 create mode 100644 rubbos/app/apache2/manual/howto/htaccess.html.ko.euc-kr create mode 100644 rubbos/app/apache2/manual/howto/index.html create mode 100644 rubbos/app/apache2/manual/howto/index.html.en create mode 100644 rubbos/app/apache2/manual/howto/index.html.ja.utf8 create mode 100644 rubbos/app/apache2/manual/howto/index.html.ko.euc-kr create mode 100644 rubbos/app/apache2/manual/howto/public_html.html create mode 100644 rubbos/app/apache2/manual/howto/public_html.html.en create mode 100644 rubbos/app/apache2/manual/howto/public_html.html.ja.utf8 create mode 100644 rubbos/app/apache2/manual/howto/public_html.html.ko.euc-kr create mode 100644 rubbos/app/apache2/manual/howto/public_html.html.tr.utf8 create mode 100644 rubbos/app/apache2/manual/howto/ssi.html create mode 100644 rubbos/app/apache2/manual/howto/ssi.html.en create mode 100644 rubbos/app/apache2/manual/howto/ssi.html.ja.utf8 create mode 100644 rubbos/app/apache2/manual/howto/ssi.html.ko.euc-kr (limited to 'rubbos/app/apache2/manual/howto') diff --git a/rubbos/app/apache2/manual/howto/auth.html b/rubbos/app/apache2/manual/howto/auth.html new file mode 100644 index 00000000..c485dfb9 --- /dev/null +++ b/rubbos/app/apache2/manual/howto/auth.html @@ -0,0 +1,17 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: auth.html.en +Content-Language: en +Content-type: text/html; charset=ISO-8859-1 + +URI: auth.html.es +Content-Language: es +Content-type: text/html; charset=ISO-8859-1 + +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 diff --git a/rubbos/app/apache2/manual/howto/auth.html.en b/rubbos/app/apache2/manual/howto/auth.html.en new file mode 100644 index 00000000..f410577f --- /dev/null +++ b/rubbos/app/apache2/manual/howto/auth.html.en @@ -0,0 +1,355 @@ + + + +Authentication, Authorization and Access Control - Apache HTTP Server + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.0

+
+
<-
+

Authentication, Authorization and Access Control

+
+

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

+
+ +

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.

+
+ +
top
+
+

Related Modules and Directives

+
Related ModulesRelated Directives
+
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.

+
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.

+
top
+
+

Getting it working

+

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

+ +

You'll need to create a 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. 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. + On my server, it's located at + /usr/local/apache/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/apache/htdocs/secret> section.

+ +

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

+ +

Let's examine each of those directives individually. The AuthType directive selects + that method that is used to authenticate the user. The most + common method is Basic, and this is the method + implemented by mod_auth. It is important to be aware, + however, that Basic authentication sends the password from the client to + the browser unencrypted. This method should therefore not be used for + highly sensitive data. Apache supports one other authentication method: + AuthType Digest. This method is implemented by mod_auth_digest and is much more secure. Only the most recent + versions of clients are known to support Digest authentication.

+ +

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 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_auth_dbm module provides the AuthDBMUserFile directive. These + files can be created and manipulated with the dbmmanage program. Many + other types of authentication options are available from third + party modules in the Apache Modules + Database.

+ +

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 to + look like the following:

+ +

+ AuthType Basic
+ AuthName "By Invitation Only"
+ 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. You can even emulate + the group behavior here, by just keeping a separate password + file for each group. The advantage of this approach is that + Apache only has to check one file, rather than two. The + disadvantage is that you have to maintain a bunch of password + files, and remember to reference the right one in the + AuthUserFile directive.

+
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
+
+

What other neat stuff can I +do?

+

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 Allow and + Deny directives let + you allow and deny access based on the host name, or host + address, of the machine requesting a document. The + Order directive goes + hand-in-hand with these two, and tells Apache in which order to + apply the filters.

+ +

The usage of these directives is:

+ +

+ Allow from address +

+ +

where address is an IP address (or a partial IP + address) or 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:

+ +

+ Deny from 10.252.46.165 +

+ +

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.

+ +

+ Deny from 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:

+ +

+ Deny from 192.168.205
+ Deny from phishers.example.com moreidiots.example
+ Deny from ke +

+ +

Using Order will let you be + sure that you are actually restricting things to the group that you want + to let in, by combining a Deny + and an Allow directive:

+ +

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

+ +

Listing just the Allow + directive would not do what you want, because it will let folks from that + host in, in addition to letting everyone in. What you want is to let + only those folks in.

+
top
+
+

More information

+

You should also read the documentation for mod_auth + and mod_access which contain some more information + about how this all works.

+
+
+

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

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/howto/auth.html.es b/rubbos/app/apache2/manual/howto/auth.html.es new file mode 100644 index 00000000..f2839d77 --- /dev/null +++ b/rubbos/app/apache2/manual/howto/auth.html.es @@ -0,0 +1,374 @@ + + + +Autentificacin, Autorizacin y Control de Acceso - Servidor HTTP Apache + + + + +
+

Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa de este sitio web

+

Versin 2.0 del Servidor HTTP Apache

+
+
<-
+

Autentificacin, Autorizacin y Control de Acceso

+
+

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

+
+
Esta traduccin podra estar + obsoleta. Consulte la versin en ingls de la + documentacin para comprobar si se han producido cambios + recientemente.
+ +

La autentificacin es cualquier proceso mediante el cual se + verifica que alguien es quien dice ser. La autorizacin es + cualquier proceso por el cual a alguien se le permite estar donde + quiere ir, o tener la informacin que quiere tener.

+
+ +
top
+
+

Mdulos y Directivas relacionadas

+
Mdulos RelacionadosDirectivas Relacionadas
+
top
+
+

Introduccin

+

Si en su sitio web tiene informacin sensible o dirigida + slo a un pequeo grupo de personas, las tcnicas + explicadas en ste artculo le ayudarn a + asegurarse de que las personas que ven esas pginas son las + personas que usted quiere que las vean.

+ +

Este artculo cubre la manera "estndar" de proteger + partes de su sitio web que la mayora de ustedes van a usar.

+
top
+
+

Los Prerrequisitos

+

Las directivas tratadas en ste artculo necesitarn + ir en el archivo de configuracin principal de su servidor + (tpicamente en una seccin del tipo + <Directory>), + o en archivos de configuracin por directorios (archivos + .htaccess).

+ +

Si planea usar archivos .htaccess, necesitar + tener una configuracin en el servidor que permita poner directivas + de autentificacin en estos archivos. Esto se logra con la + directiva AllowOverride, + la cual especifica cules directivas, en caso de existir, pueden + ser colocadas en los archivos de configuracin por directorios.

+ +

Ya que se est hablando de autentificacin, necesitar + una directiva AllowOverride como + la siguiente:

+ +

+ AllowOverride AuthConfig +

+ +

O, si slo va a colocar directivas directamente en el principal + archivo de configuracin del servidor, por supuesto necesitar + tener permiso de escritura a ese archivo.

+ +

Y necesitar saber un poco acerca de la estructura de + directorios de su servidor, con la finalidad de que sepa dnde + estn algunos archivos. Esto no debera ser muy + difcil, y tratar de hacerlo sencillo cuando lleguemos a + ese punto.

+
top
+
+

Puesta en funcionamiento

+

Aqu est lo esencial en cuanto a proteger con + contrasea un directorio de su servidor.

+ +

Necesitar crear un archivo de contraseas. ste + archivo debera colocarlo en algn sitio no accesible + mediante la Web. Por ejemplo, si sus documentos son servidos desde + /usr/local/apache/htdocs usted podra querer colocar + el(los) archivo(s) de contraseas en + /usr/local/apache/passwd.

+ +

Para crear un archivo de contraseas, use la utilidad + htpasswd que viene con Apache. + sta utilidad puede encontrarla en el directorio bin + de cualquier sitio en que haya instalado Apache. Para crear el + archivo, escriba:

+ +

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

+ +

htpasswd le pedir la contrasea, y luego se + la volver a pedir 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 su ruta, por supuesto + tendr que escribir la ruta completa al archivo para ejecutarlo. + En mi servidor, ste archivo est en + /usr/local/apache/bin/htpasswd

+ +

El siguiente paso es configurar el servidor para que solicite una + contrasea y decirle al servidor a qu usuarios se les + permite el acceso. Puede hacer esto editando el archivo + httpd.conf o usando un archivo .htaccess. + Por ejemplo, si desea proteger el directorio + /usr/local/apache/htdocs/secret, puede usar las siguientes + directivas, ya sea colocndolas en el archivo + /usr/local/apache/htdocs/secret/.htaccess, + o en httpd.conf dentro de una seccin <Directory + /usr/local/apache/apache/htdocs/secret>.

+ +

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

+ +

Vamos a examinar cada una de estas directivas por separado. La + directiva AuthType selecciona + el mtodo que se va a usar para autentificar al usuario. El + mtodo ms comn es Basic, y ste + mtodo est implementado en mod_auth. Es importante + ser consciente, sin embargo, de que la autentificacin Bsica + enva la contrasea desde el cliente hasta el navegador sin + encriptar. Por lo tanto, este mtodo no debera ser usado + para informacin altamente sensible. Apache soporta otro mtodo + de autentificacin: AuthType Digest. Este mtodo + est implementado en mod_auth_digest y es mucho ms + seguro. Slo las versiones ms recientes de clientes soportan + la autentificacin del tipo Digest.

+ +

La directiva AuthName establece + el Dominio (Realm) a usar en la + autentificacin. El dominio (realm) cumple + dos funciones importantes. Primero, el cliente frecuentemente presenta + esta informacin al usuario como parte del cuatro de dilogo + para la contrasea. Segundo, es usado por el cliente para determinar + qu contrasea enviar para un rea autentificada dada.

+ +

As, por ejemplo, una vez que el cliente se haya autentificado en + el rea "Restricted Files", + automticamente se volver a tratar de usar la misma + contrasea en cualquier rea del mismo servidor que est + marcado con el Dominio (Realm) "Restricted Files". Por lo tanto, + puede evitar que se le pida al usuario la contrasea + ms de una vez permitiendo compartir el mismo dominio (realm) + para mltiples reas restringidas. Por supuesto, por + razones de seguridad, el cliente siempre necesitar pedir de + nuevo la contrasea cuando cambie el nombre de la + mquina del servidor.

+ +

La directiva AuthUserFile + establece la ruta al archivo de contrasea que acabamos de crear + con htpasswd. Si tiene un gran nmero de usuarios, + sera bastante lento buscar por medio de un archivo en texto plano + para autentificar al usuario en cada solicitud. Apache tambin tiene + la capacidad de almacenar la informacin del usuario en + archivos rpidos de bases de datos. El mdulo mod_auth_dbm + proporciona la directiva AuthDBMUserFile. Estos archivos pueden + ser creados y manipulados con el programa + dbmmanage. Muchos otros tipos + de opciones de autentificacin estn disponibles en mdulos + de terceras partes en la Base de + datos de Mdulos de Apache.

+ +

Finalmente, la directiva Require + proporciona la parte de la autorizacin del proceso estableciendo + el usuario al que se le permite acceder a ese rea del servidor. + En la prxima seccin, discutimos varias formas de usar la + directiva Require.

+
top
+
+

Permitir el acceso a ms +de una persona

+

Las directivas anteriores slo permiten que una persona + (especficamente alguien con un nombre de usuario de + rbowen) acceda al directorio. En la mayora de los + casos, usted querr permitir el acceso a ms de una persona. + Aqu es donde entra la directiva AuthGroupFile.

+ +

Si desea permitir la entrada a ms de una persona, necesitar + crear un archivo de grupo que asocie nombres de grupo con una lista + de usuarios perteneciente a ese grupo. El formato de este archivo es muy sencillo, + y puede crearlo con su editor favorito. El contenido del archivo + ser parecido a este:

+ +

+ GroupName: rbowen dpitts sungo rshersey +

+ +

Esto es solo una lista de miembros del grupo escritos en una + lnea separados por espacios.

+ +

Para agregar un usuario a un archivo de contraseas ya existente, + escriba:

+ +

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

+ +

Obtendr la misma respuesta que antes, pero el nuevo usuario ser agregado + al archivo existente, en lugar de crear un nuevo archivo. + (Es la opcin -c la que se cree un nuevo archivo + de contraseas).

+ +

Ahora, necesita modificar su archivo .htaccess para que + sea como el siguiente:

+ +

+ AuthType Basic
+ AuthName "By Invitation Only"
+ 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 figure en el archivo password, se le permitir + el acceso, si escribe la contrasea correcta.

+ +

Existe otra manera de permitir entrar a mltiples usuarios que + es menos especfica. En lugar de crear un archivo de grupo, puede + usar slo la siguiente directiva:

+ +

+ Require valid-user +

+ +

Usando eso en vez de la lnea Require user rbowen, + le permitir el acceso a cualquiera que est listado en el + archivo de contraseas y que haya introducido correctamente su + contrasea. Incluso puede emular el comportamiento del grupo + aqu, slo manteniendo un archivo de contrasea para + cada grupo. La ventaja de esta tcnica es que Apache slo + tiene que verificar un archivo, en vez de dos. La desventaja es que + usted tiene que mantener un grupo de archivos de contrasea, y + recordar referirse al correcto en la directiva AuthUserFile.

+
top
+
+

Posibles Problemas

+

Por la manera en la que la autentificacin bsica est + especificada, su nombre de usuario y contrasea debe ser verificado + cada vez que se solicita un documento del servidor. Incluso si est + recargando la misma pgina, y por cada imagen de la pgina + (si vienen de un directorio protegido). Como se puede imaginar, esto + retrasa un poco las cosas. El retraso es proporcional al + tamao del archivo de contrasea, porque se tiene que abrir ese + archivo, y recorrer la lista de usuarios hasta que encuentre su nombre. + Y eso se tiene que hacer cada vez que se cargue la pgina.

+ +

Una consecuencia de esto es que hay un lmite prctico + de cuntos usuarios puede colocar en un archivo de contraseas. + Este lmite variar dependiendo del rendimiento de su equipo + servidor en particular, pero puede esperar observar una disminucin + una vez que inserte unos cientos de entradas, y puede que entonces considere + un mtodo distinto de autentificacin.

+
top
+
+

Qu otra cosa +sencilla y efectiva puedo hacer?

+

La autentificacin por nombre de usuario y contrasea es + slo parte del cuento. Frecuentemente se desea permitir el acceso + a los usuarios basandose en algo ms que quines son. Algo como de + dnde vienen.

+ +

Las directivas Allow y + Deny posibilitan permitir + y rechazar el acceso dependiendo del nombre o la direccin de la + mquina que solicita un documento. La directiva Order va de la mano con estas dos, y le + dice a Apache en qu orden aplicar los filtros.

+ +

El uso de estas directivas es:

+ +

+ Allow from address +

+ +

donde address es una direccin IP (o una + direccin IP parcial) o un nombre de dominio completamente + cualificado (o un nombre de dominio parcial); puede proporcionar + mltiples direcciones o nombres de dominio, si lo desea.

+ +

Por ejemplo, si usted tiene a alguien que manda mensajes no deseados + a su foro, y quiere que no vuelva a acceder, podra hacer lo + siguiente:

+ +

+ Deny from 205.252.46.165 +

+ +

Los visitantes que vengan de esa direccin no podrn + ver el contenido afectado por esta directiva. Si, por el + contrario, usted tiene un nombre de mquina pero no una + direccin IP, tambin puede usarlo.

+ +

+ Deny from host.example.com +

+ +

Y, si le gustara bloquear el acceso de un dominio entero, + puede especificar slo parte de una direccin o nombre de + dominio:

+ +

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

+ +

Usar Order le permitir + estar seguro de que efectivamente est restringiendo el acceso + al grupo al que quiere permitir el acceso, combinando una directiva + Deny y una Allow:

+ +

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

+ +

Usando slo la directiva Allow no hara lo que desea, porque + le permitira entrar a la gente proveniente de esa mquina, y + adicionalmente a cualquier persona. Lo que usted quiere es dejar entrar + slo aquellos.

+
top
+
+

Ms informacin

+

Tambin debera leer la documentacin de + mod_auth y mod_access que + contiene ms informacin acerca de cmo funciona todo esto.

+
+
+

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

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/howto/auth.html.ja.utf8 b/rubbos/app/apache2/manual/howto/auth.html.ja.utf8 new file mode 100644 index 00000000..bcbfd650 --- /dev/null +++ b/rubbos/app/apache2/manual/howto/auth.html.ja.utf8 @@ -0,0 +1,388 @@ + + + +認証、承認、アクセス制御 - Apache HTTP サーバ + + + + +
+

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

+

Apache HTTP サーバ バージョン 2.0

+
+
<-
+

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

+
+

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

+
+
This translation may be out of date. Check the + English version for recent changes.
+ +

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

+
+ +
top
+
+

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

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

はじめに

+

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

+ +

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

+
top
+
+

準備

+

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

+ +

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

+ +

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

+ +

+ AllowOverride AuthConfig +

+ +

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

+ +

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

+
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/apache/htdocs/secret> セクションに + 配置して、次のディレクティブを使うことができます。

+ +

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

+ +

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

+ +

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

+ +

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

+ +

AuthUserFile + ディレクティブは htpasswd で作った + パスワードファイルへのパスを設定します。 + ユーザ数が多い場合は、リクエスト毎のユーザの認証のための + プレーンテキストの探索が非常に遅くなることがあります。 + Apache ではユーザ情報を高速なデータベースファイルに + 保管することもできます。 + mod_auth_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"
+ 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
+
+

もっと巧みに制御できない +?

+

ユーザ名とパスワードによる認証は認証の一つの方法に過ぎません。 + しばしば誰であるかということとは違う何かに基づいて、 + 入れるようにしたくなることもあるでしょう。 + 例えばその人がどこから来ているかといったことです。

+ +

Allow と + Deny + ディレクティブを使って、ドキュメントを要求してきたマシンの + ホスト名やホストアドレスに基づいて許可不許可を制御できます。 + Order + ディレクティブはこの二つと連携して動作し、Apache + にどの順番でフィルタを適用するかを知らせます。

+ +

これらのディレクティブの使い方は次のようになります。

+ +

+ 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 と + mod_access + の文書も読むとよいでしょう。

+
+
+

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

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/howto/auth.html.ko.euc-kr b/rubbos/app/apache2/manual/howto/auth.html.ko.euc-kr new file mode 100644 index 00000000..f79cc967 --- /dev/null +++ b/rubbos/app/apache2/manual/howto/auth.html.ko.euc-kr @@ -0,0 +1,325 @@ + + + +(Authentication), Ѻο(Authorization), +(Access Control) - Apache HTTP Server + + + + +
+

| þ | FAQ | | Ʈ

+

Apache HTTP Server Version 2.0

+
+
<-
+

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

+
+

:  en  | + es  | + ja  | + ko 

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

(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 + ȣ ȣȭ ʰ . + ׷Ƿ ڷḦ ȣϱ ϸ ȵȴ. + ġ AuthType Digest Ѵ. + mod_auth_digest ϸ, ſ + ϴ. ֱ Ŭ̾Ʈ鸸 Digest Ѵٰ + Ѵ.

+ +

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

+ +

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

+ +

AuthUserFile + þ 츮 htpasswd ȣ + θ Ѵ. ڰ ٸ û Ź ڸ + ϱ Ϲ ˻ϴµ ð + ɸ ִ. ġ Ÿ̽ Ͽ + ִ. mod_auth_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 + mod_access  ϴ + ִ.

+
+
+

:  en  | + es  | + ja  | + ko 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/howto/cgi.html b/rubbos/app/apache2/manual/howto/cgi.html new file mode 100644 index 00000000..61f160a2 --- /dev/null +++ b/rubbos/app/apache2/manual/howto/cgi.html @@ -0,0 +1,13 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: cgi.html.en +Content-Language: en +Content-type: text/html; charset=ISO-8859-1 + +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/rubbos/app/apache2/manual/howto/cgi.html.en b/rubbos/app/apache2/manual/howto/cgi.html.en new file mode 100644 index 00000000..c3299f6c --- /dev/null +++ b/rubbos/app/apache2/manual/howto/cgi.html.en @@ -0,0 +1,555 @@ + + + +Apache Tutorial: Dynamic Content with CGI - Apache HTTP Server + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.0

+
+
<-
+

Apache Tutorial: Dynamic Content with CGI

+
+

Available Languages:  en  | + 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 the simplest, and most common, 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.

+
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.

+ +

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.

+ +

In addition, if your CGI program depends on other environment variables, you will need to + assure that those variables are passed by Apache.

+ + + +

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 + http://hoohoo.ncsa.uiuc.edu/cgi/env.html.

+ +

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
+ print "Content-type: text/html\n\n";
+ foreach $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 + http://www.boutell.com/cgic/.

+
top
+
+

For more information

+ + +

There are a large number of CGI resources on the web. You + can discuss CGI problems with other users on the Usenet group + comp.infosystems.www.authoring.cgi. And the -servers mailing + list from the HTML Writers Guild is a great source of answers + to your questions. You can find out more at + http://www.hwg.org/lists/hwg-servers/.

+ +

And, of course, you should probably read the CGI + specification, which has all the details on the operation of + CGI programs. You can find the original version at the + NCSA and there is an updated draft at the + Common Gateway + Interface RFC project.

+ +

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  | + ja  | + ko 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/howto/cgi.html.ja.utf8 b/rubbos/app/apache2/manual/howto/cgi.html.ja.utf8 new file mode 100644 index 00000000..51168ac5 --- /dev/null +++ b/rubbos/app/apache2/manual/howto/cgi.html.ja.utf8 @@ -0,0 +1,546 @@ + + + +Apache Tutorial: CGI による動的コンテンツ - Apache HTTP サーバ + + + + +
+

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

+

Apache HTTP サーバ バージョン 2.0

+
+
<-
+

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

+
+

Available Languages:  en  | + ja  | + ko 

+
+
This translation may be out of date. Check the + English version for recent changes.
+
+ +
top
+
+

はじめに

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

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

+
top
+
+

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

+ + +

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

+ +

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://dev.rcbowen.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 files

+ + +

.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-type + ヘッダを付けなければなりません。 + これはどのような種類のコンテンツを受け取っているかをクライアントに示す + 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 + プログラムが失敗するのは大抵、プログラム自身に問題がある場合です。 + 一度 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 + バグデータベースに送るべきでない + ことに注目してください。

+
+
+

Available Languages:  en  | + ja  | + ko 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/howto/cgi.html.ko.euc-kr b/rubbos/app/apache2/manual/howto/cgi.html.ko.euc-kr new file mode 100644 index 00000000..0486a222 --- /dev/null +++ b/rubbos/app/apache2/manual/howto/cgi.html.ko.euc-kr @@ -0,0 +1,503 @@ + + + +ġ 丮: CGI - Apache HTTP Server + + + + +
+

| þ | FAQ | | Ʈ

+

Apache HTTP Server Version 2.0

+
+
<-
+

ġ 丮: CGI

+
+

:  en  | + 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  | + ja  | + ko 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/howto/htaccess.html b/rubbos/app/apache2/manual/howto/htaccess.html new file mode 100644 index 00000000..9c5991ce --- /dev/null +++ b/rubbos/app/apache2/manual/howto/htaccess.html @@ -0,0 +1,13 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: htaccess.html.en +Content-Language: en +Content-type: text/html; charset=ISO-8859-1 + +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 diff --git a/rubbos/app/apache2/manual/howto/htaccess.html.en b/rubbos/app/apache2/manual/howto/htaccess.html.en new file mode 100644 index 00000000..f9d6614f --- /dev/null +++ b/rubbos/app/apache2/manual/howto/htaccess.html.en @@ -0,0 +1,386 @@ + + + +Apache Tutorial: .htaccess files - Apache HTTP Server + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.0

+
+
<-
+

Apache Tutorial: .htaccess files

+
+

Available Languages:  en  | + ja  | + ko 

+
+ +

.htaccess files provide a way to make configuration +changes on a per-directory basis.

+
+ +
top
+
+

.htaccess files

+
Related ModulesRelated Directives
+
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 never use .htaccess files unless + you don't have access to the main server configuration file. There is, + for example, a prevailing misconception that user authentication should + always be done 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.

+ +

.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, Apache 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 Apache 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, Apache 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.)

+ +

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 Apache 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 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:

+ +

+<Directory />
+ +Allowoverride All
+ +</Directory>
+
+<Location />
+ +Options +IncludesNoExec -ExecCGI
+ +</Location> +

+ + +
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.

+ +

You must have "AllowOverride AuthConfig" in effect for + these directives to be honored.

+ +

.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
+
+

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. 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 Apache error log. It will likely tell you + that the directive used in your .htaccess file is not + permitted. Alternately, it may tell you that you had a syntax error, + which you will then need to fix.

+ +
+
+

Available Languages:  en  | + ja  | + ko 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/howto/htaccess.html.ja.utf8 b/rubbos/app/apache2/manual/howto/htaccess.html.ja.utf8 new file mode 100644 index 00000000..bafb8b7c --- /dev/null +++ b/rubbos/app/apache2/manual/howto/htaccess.html.ja.utf8 @@ -0,0 +1,347 @@ + + + +Apache チュートリアル: .htaccess ファイル - Apache HTTP サーバ + + + + +
+

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

+

Apache HTTP サーバ バージョン 2.0

+
+
<-
+

Apache チュートリアル: .htaccess ファイル

+
+

Available Languages:  en  | + ja  | + ko 

+
+
This translation may be out of date. Check the + English version for recent changes.
+ +

.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 のみが + 効力を持ち、それがすべての以前の設定を上書きするからです。

+
top
+
+

認証の例

+ +

もし認証の方法を知るためにこの部分に直接来たのであれば、次のことを + 知っておくことが重要です。よくある誤解に、パスワード認証を行なうためには + .htaccess ファイルを使う必要がある、というものがあります。 + これは正しくありません。主サーバ設定ファイルの <Directory> セクションに + 認証用のディレクティブを書く方が推奨される方法で、.htaccess + ファイルは主サーバ設定ファイルを変更できないときにのみ使用すべきです。 + いつ .htaccess ファイルを使うべきで、いつ使うべきではないかに + ついては 上を参照してください。

+ +

以上のことをふまえた上で、もし .htaccess の使用が + まだ必要だと思う場合は、次のようなものが望みのことをしてくれるかも + しれません。

+ +

ディレクティブが適用されるためには、 + "AllowOverride AuthConfig" の設定がなされている + 必要があります。

+ +

.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 ファイルで + 使用されたディレクティブが許可されていない、ということを知らせている + 可能性が高いです。または、構文の間違いがあることを述べているかもしれません。 + その場合にはまずそれを修正する必要があります。

+ +
+
+

Available Languages:  en  | + ja  | + ko 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/howto/htaccess.html.ko.euc-kr b/rubbos/app/apache2/manual/howto/htaccess.html.ko.euc-kr new file mode 100644 index 00000000..7fcb2b92 --- /dev/null +++ b/rubbos/app/apache2/manual/howto/htaccess.html.ko.euc-kr @@ -0,0 +1,334 @@ + + + +ġ 丮: .htaccess - Apache HTTP Server + + + + +
+

| þ | FAQ | | Ʈ

+

Apache HTTP Server Version 2.0

+
+
<-
+

ġ 丮: .htaccess

+
+

:  en  | + ja  | + ko 

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

.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 + ʿϴٰ Ǹ Ʒ ̴.

+ +

þ Ϸ "AllowOverride AuthConfig" + ־ Ѵ.

+ +

.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  | + ja  | + ko 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/howto/index.html b/rubbos/app/apache2/manual/howto/index.html new file mode 100644 index 00000000..4f3357b3 --- /dev/null +++ b/rubbos/app/apache2/manual/howto/index.html @@ -0,0 +1,13 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: index.html.en +Content-Language: en +Content-type: text/html; charset=ISO-8859-1 + +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 diff --git a/rubbos/app/apache2/manual/howto/index.html.en b/rubbos/app/apache2/manual/howto/index.html.en new file mode 100644 index 00000000..5ef8dc03 --- /dev/null +++ b/rubbos/app/apache2/manual/howto/index.html.en @@ -0,0 +1,105 @@ + + + +How-To / Tutorials - Apache HTTP Server + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.0

+
+
<-
+

How-To / Tutorials

+
+

Available Languages:  en  | + ja  | + ko 

+
+
+
top
+
+

How-To / Tutorials

+ + + +
+
Authentication
+
+

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, and 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 the simplest, and most common, 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

+
+
+ +
+
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)

+
+
+ +
+
+

Available Languages:  en  | + ja  | + ko 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/howto/index.html.ja.utf8 b/rubbos/app/apache2/manual/howto/index.html.ja.utf8 new file mode 100644 index 00000000..cd111ec5 --- /dev/null +++ b/rubbos/app/apache2/manual/howto/index.html.ja.utf8 @@ -0,0 +1,102 @@ + + + +How-To / チュートリアル - Apache HTTP サーバ + + + + +
+

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

+

Apache HTTP サーバ バージョン 2.0

+
+
<-
+

How-To / チュートリアル

+
+

Available Languages:  en  | + ja  | + ko 

+
+
+
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)

+
+
+ +
+
+

Available Languages:  en  | + ja  | + ko 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/howto/index.html.ko.euc-kr b/rubbos/app/apache2/manual/howto/index.html.ko.euc-kr new file mode 100644 index 00000000..14434cc7 --- /dev/null +++ b/rubbos/app/apache2/manual/howto/index.html.ko.euc-kr @@ -0,0 +1,107 @@ + + + +How-To / 丮 - Apache HTTP Server + + + + +
+

| þ | FAQ | | Ʈ

+

Apache HTTP Server Version 2.0

+
+
<-
+

How-To / 丮

+
+

:  en  | + ja  | + ko 

+
+
+
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  | + ja  | + ko 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/howto/public_html.html b/rubbos/app/apache2/manual/howto/public_html.html new file mode 100644 index 00000000..f67a8c66 --- /dev/null +++ b/rubbos/app/apache2/manual/howto/public_html.html @@ -0,0 +1,17 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: public_html.html.en +Content-Language: en +Content-type: text/html; charset=ISO-8859-1 + +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/rubbos/app/apache2/manual/howto/public_html.html.en b/rubbos/app/apache2/manual/howto/public_html.html.en new file mode 100644 index 00000000..df6751db --- /dev/null +++ b/rubbos/app/apache2/manual/howto/public_html.html.en @@ -0,0 +1,163 @@ + + + +Per-user web directories - Apache HTTP Server + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.0

+
+
<-
+

Per-user web directories

+
+

Available Languages:  en  | + 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.

+ +
+ +
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

+ +
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 enabled
+ 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 changed. 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  | + ja  | + ko  | + tr 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/howto/public_html.html.ja.utf8 b/rubbos/app/apache2/manual/howto/public_html.html.ja.utf8 new file mode 100644 index 00000000..1fc52c9f --- /dev/null +++ b/rubbos/app/apache2/manual/howto/public_html.html.ja.utf8 @@ -0,0 +1,157 @@ + + + +ユーザ毎のウェブディレクトリ - Apache HTTP サーバ + + + + +
+

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

+

Apache HTTP サーバ バージョン 2.0

+
+
<-
+

ユーザ毎のウェブディレクトリ

+
+

Available Languages:  en  | + 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 +

+ +

上の設定は 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 チュートリアル を読んで + ください。

+ +
+
+

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

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/howto/public_html.html.ko.euc-kr b/rubbos/app/apache2/manual/howto/public_html.html.ko.euc-kr new file mode 100644 index 00000000..782bd448 --- /dev/null +++ b/rubbos/app/apache2/manual/howto/public_html.html.ko.euc-kr @@ -0,0 +1,158 @@ + + + +ں 丮 - Apache HTTP Server + + + + +
+

| þ | FAQ | | Ʈ

+

Apache HTTP Server Version 2.0

+
+
<-
+

ں 丮

+
+

:  en  | + 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  | + ja  | + ko  | + tr 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/howto/public_html.html.tr.utf8 b/rubbos/app/apache2/manual/howto/public_html.html.tr.utf8 new file mode 100644 index 00000000..0788ed25 --- /dev/null +++ b/rubbos/app/apache2/manual/howto/public_html.html.tr.utf8 @@ -0,0 +1,167 @@ + + + +Kullanıcı Dizinleri (public_html) - Apache HTTP Sunucusu + + + + +
+

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

+

Apache HTTP Sunucusu Sürüm 2.0

+
+
<-
+

Kullanıcı Dizinleri (public_html)

+
+

Mevcut Diller:  en  | + 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.

+
+ +
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/siteler/*/sayfam +

+ +

http://example.com/~orhan/dosya.html adresine karşılık + gelen dosya yolu /var/siteler/orhan/sayfam/dosya.html + olarak çözümlenir.

+ +
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 enabled
+ UserDir disabled root ahmet mustafa +

+ +

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  | + ja  | + ko  | + tr 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/howto/ssi.html b/rubbos/app/apache2/manual/howto/ssi.html new file mode 100644 index 00000000..477d79ca --- /dev/null +++ b/rubbos/app/apache2/manual/howto/ssi.html @@ -0,0 +1,13 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: ssi.html.en +Content-Language: en +Content-type: text/html; charset=ISO-8859-1 + +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/rubbos/app/apache2/manual/howto/ssi.html.en b/rubbos/app/apache2/manual/howto/ssi.html.en new file mode 100644 index 00000000..f03a467d --- /dev/null +++ b/rubbos/app/apache2/manual/howto/ssi.html.en @@ -0,0 +1,486 @@ + + + +Apache Tutorial: Introduction to Server Side Includes - Apache HTTP Server + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.0

+
+
<-
+

Apache Tutorial: Introduction to Server Side Includes

+
+

Available Languages:  en  | + 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.

+ +

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. + 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:

+

+ <!--#element 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 element 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 element 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 element.

+ +

If you don't like the format in which the date gets printed, + you can use the config element, 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 element 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 + element 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 element:

+

+ <!--#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

+ + +

I expect that I'll have an article some time in the coming + months about using SSI with small CGI programs. For now, here's + something else that you can do with the exec + element. 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.

+ +

Caveat

+ +

Most of the features discussed in this article are only + available to you if you are running Apache 1.2 or later. Of + course, if you are not running Apache 1.2 or later, you need to + upgrade immediately, if not sooner. Go on. Do it now. We'll + wait.

+ + +

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. Here are some examples of how one might use this + construct.

+ +

In your configuration file, you could put the following + line:

+

+ BrowserMatchNoCase macintosh Mac
+ BrowserMatchNoCase MSIE InternetExplorer +

+ +

This will set environment variables ``Mac'' and + ``InternetExplorer'' to true, if the client is running Internet + Explorer on a Macintosh.

+ +

Then, in your SSI-enabled document, you might do the + following:

+

+ <!--#if expr="${Mac} && ${InternetExplorer}" -->
+ Apologetic text goes here
+ <!--#else -->
+ Cool JavaScript code goes here
+ <!--#endif --> +

+ +

Not that I have anything against IE on Macs - I just + struggled for a few hours last week trying to get some + JavaScript working on IE on a Mac, when it was working + everywhere else. The above was the interim workaround.

+ +

Any other variable (either ones that you define, or normal + environment variables) can be used in conditional statements. + With Apache's ability to set environment variables with the + SetEnvIf directives, and other related directives, + this functionality can let you do some pretty involved dynamic + stuff without ever resorting to CGI.

+ +
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  | + ja  | + ko 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/howto/ssi.html.ja.utf8 b/rubbos/app/apache2/manual/howto/ssi.html.ja.utf8 new file mode 100644 index 00000000..4e83b0fd --- /dev/null +++ b/rubbos/app/apache2/manual/howto/ssi.html.ja.utf8 @@ -0,0 +1,481 @@ + + + +Apache チュートリアル: Server Side Includes 入門 - Apache HTTP サーバ + + + + +
+

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

+

Apache HTTP サーバ バージョン 2.0

+
+
<-
+

Apache チュートリアル: Server Side Includes 入門

+
+

Available Languages:  en  | + 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 + や動的なウェブページを生成する他の技術に代わるものではありません。 + しかし、たくさんの余分な作業をせずに、 + 少量の動的なコンテンツを加えるにはすぐれた方法です。

+
+
+

Available Languages:  en  | + ja  | + ko 

+
+ \ No newline at end of file diff --git a/rubbos/app/apache2/manual/howto/ssi.html.ko.euc-kr b/rubbos/app/apache2/manual/howto/ssi.html.ko.euc-kr new file mode 100644 index 00000000..f849bd67 --- /dev/null +++ b/rubbos/app/apache2/manual/howto/ssi.html.ko.euc-kr @@ -0,0 +1,426 @@ + + + +ġ 丮: Server Side Includes Ұ - Apache HTTP Server + + + + +
+

| þ | FAQ | | Ʈ

+

Apache HTTP Server Version 2.0

+
+
<-
+

ġ 丮: Server Side Includes Ұ

+
+

:  en  | + 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  | + ja  | + ko 

+
+ \ No newline at end of file -- cgit 1.2.3-korg