From: Rich Bowen Date: Fri, 19 Jun 2026 14:27:29 +0000 (+0000) Subject: Rebuild html, meta files X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=b53c1f558b95a48048d3cabbcda14b6e4cf88891;p=thirdparty%2Fapache%2Fhttpd.git Rebuild html, meta files git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1935524 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/howto/access.html.en b/docs/manual/howto/access.html.en index 0864d3f281..4b8bbcf2f0 100644 --- a/docs/manual/howto/access.html.en +++ b/docs/manual/howto/access.html.en @@ -51,7 +51,7 @@

Access control by host

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

@@ -72,9 +72,10 @@

The usage of these directives is:

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

In the first form, address is a fully qualified domain name (or a partial domain name); you may provide multiple @@ -84,12 +85,26 @@ Require ip ip.address partial IP address, a network/netmask pair, or a network/nnn CIDR specification. Either IPv4 or IPv6 addresses may be used.

+

Examples of IP address formats

# Full IP address
+Require ip 10.2.3.4
+# Partial IP address (matches any host in the 172.20.0.0/16 range)
+Require ip 172.20
+# Network/netmask pair
+Require ip 192.168.1.0/255.255.255.0
+# Network/CIDR specification
+Require ip 192.168.1.0/24
+# IPv6 address
+Require ip 2001:db8::a00:20ff:fea7:ccea
+# IPv6 with CIDR
+Require ip 2001:db8:1::/48
+
+

See the mod_authz_host documentation for further examples of this syntax.

You can insert not to negate a particular requirement. - Note, that since a not is a negation of a value, it cannot + Since a not is a negation of a value, it cannot be used by itself to allow or deny a request, as not true does not constitute false. Thus, to deny a visit using a negation, the block must have one element that evaluates as true or false. @@ -97,28 +112,28 @@ Require ip ip.address board, and you want to keep them out, you could do the following:

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

-
+

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

 
-    
Require not host host.example.com
-    

-
+
Require not host host.example.com
+

+

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

+    you can specify part of an address or domain name:

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

-
+

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

@@ -133,17 +148,17 @@ Require not host gov

     based on user-agent (the browser type) you might do the
     following:

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

-
+

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

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

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

+

 
     
Warning:

     
Access control by User-Agent is an unreliable technique,
@@ -166,11 +181,11 @@ Require not host gov

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

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

-
+RewriteRule "^/fridge"     "-"       [F]

+
 
     
This will return a 403 Forbidden response for any request after 8pm
     or before 7am. This technique can be used for any criteria that you wish
diff --git a/docs/manual/howto/access.html.fr.utf8 b/docs/manual/howto/access.html.fr.utf8
index 9acb7cd2c9..1b7e2649e7 100644
--- a/docs/manual/howto/access.html.fr.utf8
+++ b/docs/manual/howto/access.html.fr.utf8
@@ -27,6 +27,8 @@
  es  |
  fr 

 
+
Cette traduction peut être périmée. Vérifiez la version
+            anglaise pour les changements récents.

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

diff --git a/docs/manual/howto/access.xml.es b/docs/manual/howto/access.xml.es
index e2b3d63f0a..4fffdea4d7 100644
--- a/docs/manual/howto/access.xml.es
+++ b/docs/manual/howto/access.xml.es
@@ -1,7 +1,7 @@
 
 
 
-
+
 
 
 
+
 
 
 
diff --git a/docs/manual/howto/access.xml.meta b/docs/manual/howto/access.xml.meta
index 39cc277557..ee45dee0b6 100644
--- a/docs/manual/howto/access.xml.meta
+++ b/docs/manual/howto/access.xml.meta
@@ -9,6 +9,6 @@
   
     en
     es
-    fr
+    fr
   
 
diff --git a/docs/manual/howto/auth.html.en b/docs/manual/howto/auth.html.en
index 5ec9d76b6c..6d9f0cdde5 100644
--- a/docs/manual/howto/auth.html.en
+++ b/docs/manual/howto/auth.html.en
@@ -145,8 +145,8 @@ module from each group.

     an AllowOverride directive like the
     following:

 
-    
AllowOverride AuthConfig

-
+
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
@@ -218,13 +218,13 @@ module from each group.

     placed in httpd.conf inside a <Directory
     "/usr/local/apache/htdocs/secret"> section.

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

-
+

 
     
Let's examine each of those directives individually. The AuthType directive selects
     the method that is used to authenticate the user. The most
@@ -310,18 +310,17 @@ person in <Directory> block
-    to look like the following:

+    
Now, you need to modify your .htaccess file to
+    look like the following:

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

-
+

 
     
Now, anyone that is listed in the group GroupName,
     and has an entry in the password file, will be let in, if
@@ -331,12 +330,18 @@ Require group GroupName

     specific. Rather than creating a group file, you can just use
     the following directive:

 
-    
Require valid-user

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

+    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 

@@ -372,14 +377,14 @@ Require group GroupName

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

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

-
+

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

@@ -394,15 +399,15 @@ Require group GroupName

     scheme that meets your needs. In the following example, both the
     file and LDAP based authentication providers are being used.

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

-
+

 
     
In this example the file provider will attempt to authenticate
     the user first. If it is unable to authenticate the user, the LDAP
@@ -417,17 +422,17 @@ Require group GroupName

     authorization methods can also be used. In this example both file group
     authorization as well as LDAP group authorization is being used.

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

-
+

 
     
To take authorization a little further, authorization container
     directives such as
@@ -490,73 +495,15 @@ Require group GroupName

 
     
Using authorization providers for access control

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

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

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

-
-        
Require ip address
-        

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

-
-        
Require host domain_name
-        

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

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

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

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

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

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

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

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

+        story. You can also allow or deny access based on other
+        criteria, such as the client's IP address or hostname, using
+        the authorization providers all, env,
+        host, and ip with the
+        Require
+        directive.

 
+        
For full details and examples, see the
+        Access Control howto.

     
 
     
Access Control backwards compatibility

@@ -587,9 +534,8 @@ Require group GroupName

Authentication Caching

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

This may offer a substantial performance boost to some users.

top
diff --git a/docs/manual/howto/auth.html.fr.utf8 b/docs/manual/howto/auth.html.fr.utf8 index 30001d8721..022647719e 100644 --- a/docs/manual/howto/auth.html.fr.utf8 +++ b/docs/manual/howto/auth.html.fr.utf8 @@ -30,6 +30,8 @@  ko  |  tr 

+
Cette traduction peut être périmée. Vérifiez la version + anglaise pour les changements récents.

L'authentification est un processus qui vous permet de vérifier qu'une personne est bien celle qu'elle prétend être. L'autorisation diff --git a/docs/manual/howto/auth.xml.es b/docs/manual/howto/auth.xml.es index b783d7fd37..2994b1f9fc 100644 --- a/docs/manual/howto/auth.xml.es +++ b/docs/manual/howto/auth.xml.es @@ -1,7 +1,7 @@ - + + diff --git a/docs/manual/howto/auth.xml.ja b/docs/manual/howto/auth.xml.ja index 0b40e32dc8..96b7ddd3c5 100644 --- a/docs/manual/howto/auth.xml.ja +++ b/docs/manual/howto/auth.xml.ja @@ -1,7 +1,7 @@ - + + + + diff --git a/docs/manual/howto/cgi.xml.fr b/docs/manual/howto/cgi.xml.fr index 07317f2763..ffb9d0ea5a 100644 --- a/docs/manual/howto/cgi.xml.fr +++ b/docs/manual/howto/cgi.xml.fr @@ -1,7 +1,7 @@ - + diff --git a/docs/manual/howto/cgi.xml.ja b/docs/manual/howto/cgi.xml.ja index a9d52aaa41..bc3dc4dd69 100644 --- a/docs/manual/howto/cgi.xml.ja +++ b/docs/manual/howto/cgi.xml.ja @@ -1,7 +1,7 @@ - + + + + diff --git a/docs/manual/howto/htaccess.xml.ja b/docs/manual/howto/htaccess.xml.ja index 2ef4aa5ae4..d2c01bc540 100644 --- a/docs/manual/howto/htaccess.xml.ja +++ b/docs/manual/howto/htaccess.xml.ja @@ -1,7 +1,7 @@ - + + + + diff --git a/docs/manual/howto/http2.xml.fr b/docs/manual/howto/http2.xml.fr index 1ce2141026..a3694c804f 100644 --- a/docs/manual/howto/http2.xml.fr +++ b/docs/manual/howto/http2.xml.fr @@ -1,7 +1,7 @@ - + diff --git a/docs/manual/howto/http2.xml.meta b/docs/manual/howto/http2.xml.meta index cd0a8de064..9b93a6fba0 100644 --- a/docs/manual/howto/http2.xml.meta +++ b/docs/manual/howto/http2.xml.meta @@ -9,6 +9,6 @@ en es - fr + fr diff --git a/docs/manual/howto/public_html.html.en b/docs/manual/howto/public_html.html.en index b0bf3c0fe7..c371e61c07 100644 --- a/docs/manual/howto/public_html.html.en +++ b/docs/manual/howto/public_html.html.en @@ -36,14 +36,20 @@ to a URL http://example.com/~username/ will get content out of the home directory of the user "username", out of the subdirectory specified by the UserDir directive.

-

Note that, by default, access to these directories is not +

By default, access to these directories is not enabled. You can enable access when using UserDir by uncommenting the line:

- 
#Include conf/extra/httpd-userdir.conf
- +
#Include conf/extra/httpd-userdir.conf
+

in the default config file conf/httpd.conf, and adapting the httpd-userdir.conf file as necessary, or by including the appropriate directives in a <Directory> block within the main config file.

+ +
Third-party distributions of httpd (from your OS vendor or + package manager) often place the mod_userdir + configuration in a separate file, and may enable it by default. + Check your distribution's documentation for specifics. The examples + in this document assume a default source build of httpd.
top
@@ -117,8 +123,8 @@

The UserDir directive can be used to redirect user directory requests to external URLs.

- 
UserDir http://example.org/users/*/
- +
UserDir http://example.org/users/*/
+

The above example will redirect a request for http://example.com/~bob/abc.html to @@ -132,17 +138,17 @@

Using the syntax shown in the UserDir documentation, you can restrict what users are permitted to use this functionality:

- 
UserDir disabled root jro fish
- +
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 disabled
 UserDir enabled rbowen krietz

-
+

 
     
See UserDir
     documentation for additional examples.

@@ -152,16 +158,16 @@ UserDir enabled rbowen krietz

Enabling a cgi directory for each user

-

In order to give each user their own cgi-bin directory, you can use +

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 "/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
@@ -176,7 +182,7 @@ UserDir enabled rbowen krietz

Allowing users to alter configuration

-

If you want to allows users to modify the server configuration in +

If you want to allow users to modify the server configuration in their web space, they will need to use .htaccess files to make these changes. Ensure that you have set AllowOverride to a value sufficient for the directives that you want to permit the users diff --git a/docs/manual/howto/public_html.html.es b/docs/manual/howto/public_html.html.es index f2c701a757..c25f0800bc 100644 --- a/docs/manual/howto/public_html.html.es +++ b/docs/manual/howto/public_html.html.es @@ -30,6 +30,10 @@  ko  |  tr 

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

En sistemas con múltiples usuarios, cada usuario puede tener un website en su directorio home usando la directiva UserDir. Los visitantes de una URL diff --git a/docs/manual/howto/public_html.html.fr.utf8 b/docs/manual/howto/public_html.html.fr.utf8 index 6d104843c3..28436b8c77 100644 --- a/docs/manual/howto/public_html.html.fr.utf8 +++ b/docs/manual/howto/public_html.html.fr.utf8 @@ -30,6 +30,8 @@  ko  |  tr 

+
Cette traduction peut être périmée. Vérifiez la version + anglaise pour les changements récents.

Sur les systèmes multi-utilisateurs, on peut permettre à chaque utilisateur d'avoir un site web dans son répertoire home à l'aide de la diff --git a/docs/manual/howto/public_html.html.tr.utf8 b/docs/manual/howto/public_html.html.tr.utf8 index cc563e5d71..139ff8d493 100644 --- a/docs/manual/howto/public_html.html.tr.utf8 +++ b/docs/manual/howto/public_html.html.tr.utf8 @@ -30,6 +30,7 @@  ko  |  tr 

+
Bu çeviri güncel olmayabilir. Son değişiklikler için Ä°ngilizce sürüm geçerlidir.

Çok kullanıcılı sistemlerde, UserDir yönergesi ile her kullanıcının kendi ev dizininde bir sitesi olması sağlanabilir. diff --git a/docs/manual/howto/public_html.xml.es b/docs/manual/howto/public_html.xml.es index 05e72e8789..aff5f09ba4 100644 --- a/docs/manual/howto/public_html.xml.es +++ b/docs/manual/howto/public_html.xml.es @@ -1,7 +1,7 @@ - + diff --git a/docs/manual/howto/public_html.xml.fr b/docs/manual/howto/public_html.xml.fr index ee0df0f02e..33a2f31692 100644 --- a/docs/manual/howto/public_html.xml.fr +++ b/docs/manual/howto/public_html.xml.fr @@ -1,7 +1,7 @@ - + diff --git a/docs/manual/howto/public_html.xml.ja b/docs/manual/howto/public_html.xml.ja index 1c5d7d2005..4573b49d8f 100644 --- a/docs/manual/howto/public_html.xml.ja +++ b/docs/manual/howto/public_html.xml.ja @@ -1,7 +1,7 @@ - + + + + diff --git a/docs/manual/howto/reverse_proxy.xml.meta b/docs/manual/howto/reverse_proxy.xml.meta index 8cb8970fff..655c8823e7 100644 --- a/docs/manual/howto/reverse_proxy.xml.meta +++ b/docs/manual/howto/reverse_proxy.xml.meta @@ -8,6 +8,6 @@ en - fr + fr diff --git a/docs/manual/howto/ssi.html.en b/docs/manual/howto/ssi.html.en index 1f6de502ae..b09470439d 100644 --- a/docs/manual/howto/ssi.html.en +++ b/docs/manual/howto/ssi.html.en @@ -30,15 +30,17 @@  ko 

-

Server-side includes provide a means to add dynamic content to -existing HTML documents.

+

Server Side Includes (SSI) provide a way to add dynamic content to +existing HTML documents without requiring a full application framework. +They are particularly useful for inserting common elements — headers, +footers, navigation, timestamps — into otherwise static pages.

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.

+

SSI directives are HTML comments with a specific syntax that + mod_include recognizes and evaluates before the + page is sent to the client. They look like this:

-

For example, you might place a directive into an existing HTML - page, such as:

- -

- <!--#echo var="DATE_LOCAL" --> -

+
<!--#echo var="DATE_LOCAL" -->
+
-

And, when the page is served, this fragment will be evaluated and replaced with its value:

+

When the page is served, this fragment is replaced with its + value:

- Tuesday, 15-Jan-2013 19:28:54 EST + Thursday, 18-Jun-2026 14:22:07 EDT

-

The decision of when to use SSI, and when to have your page - entirely generated by some program, is usually a matter of how - much of the page is static, and how much needs to be - recalculated every time the page is served. SSI is a great way - to add small pieces of information, such as the current time - shown - above. But if a majority of your page is being generated at the time - that it is served, you need to look for some other solution.

+

Because the directives are embedded in HTML comments, if SSI + is not enabled, browsers ignore them (though they remain + visible in the page source).

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
+

To enable SSI processing, add the following directive to your + httpd.conf file or to a .htaccess + file:

+ +
Options +Includes
+
+ +

This tells httpd to parse files for SSI directives. Since most + configurations contain multiple Options directives that can override each other, apply + this to the specific directory where you want SSI enabled.

+

You also need to tell httpd which files to parse. There are + two common approaches.

-

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.

+

The first is to designate a file extension (typically + .shtml) for SSI-enabled pages:

-

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
+
AddType text/html .shtml
 AddOutputFilter INCLUDES .shtml

+

 
+    
The disadvantage here is that adding SSI to an existing page
+    requires renaming the file (and updating all links to it) to use
+    the .shtml extension.

 
-    
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 second approach uses the XBitHack directive:

 
-    
The other method is to use the XBitHack directive:

-
XBitHack on

+
XBitHack on

+

 
+    
XBitHack tells
+    httpd to parse any file that has its execute bit set. To enable
+    SSI on an existing page, make the file executable:

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

+
chmod +x pagename.html

+

+
+    

+    Avoid configuring httpd to parse all .html
+    files for SSI directives. This forces the server to read through
+    every HTML file it serves, even those without any SSI content,
+    which adds unnecessary overhead.
+    

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

+    
On Windows, there is no execute bit, so the
+    XBitHack approach is
+    not available. Use the file-extension method instead.

+
+    
By default, httpd does not send the last-modified date or
+    content-length headers on SSI pages, since these values are
+    difficult to calculate for dynamic content. This can prevent
+    caching and result in slower perceived performance. Two
+    approaches can help:

 
     
    
-      
  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. 
+      
  3. Use XBitHack Full, which tells httpd to
+      determine the last-modified date from the originally requested
+      file, ignoring the modification dates of included files.
    4. 
+
+      
  4. Use mod_expires to set an explicit
+      expiration time, letting browsers and proxies know the content
+      is safe to cache.
    5.
top

Basic SSI directives

-

SSI directives have the following syntax:

-

- <!--#function attribute=value attribute=value ... --> -

- -

It is formatted like an HTML comment, so if you don't have - SSI correctly enabled, the browser will ignore it, but it will - still be visible in the HTML source. If you have SSI correctly - configured, the directive will be replaced with its - results.

+

SSI directives use the following syntax:

+
<!--#function attribute=value attribute=value ... -->
+
-

The function can be one of a number of things, and we'll talk - some more about most of these in the next installment of this - series. For now, here are some examples of what you can do with - SSI

+

If SSI is correctly configured, the directive is replaced with + its output. If not, it remains as an HTML comment — invisible to + the end user but present in the source.

Today's date

-

- <!--#echo var="DATE_LOCAL" --> -

+
<!--#echo var="DATE_LOCAL" -->
+
-

The echo function just spits out the value of a - variable. There are a number of standard variables, which - include the whole set of environment variables that are - available to CGI programs. Also, you can define your own - variables with the set function.

+

The echo function outputs the value of a variable. + Standard variables include the full set of environment variables + available to CGI programs, plus variables you define with + set.

-

If you don't like the format in which the date gets printed, - you can use the config function, with a - timefmt attribute, to modify that formatting.

+

To customize the date format, use the config + function with the timefmt attribute:

-

- <!--#config timefmt="%A %B %d, %Y" -->
- Today is <!--#echo var="DATE_LOCAL" --> -

+
<!--#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 document last modified <!--#flastmod file="index.html" -->
+
-

This function is also subject to timefmt format - configurations.

+

This function is also subject to timefmt + configuration.

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

+

SSI can include the output of a CGI program directly in the + page:

-

- <!--#include virtual="/cgi-bin/counter.pl" --> -

+
<!--#include virtual="/cgi-bin/counter.pl" -->
+
top
@@ -233,242 +202,182 @@ AddOutputFilter INCLUDES .shtml

Additional examples

-

Following are some specific examples of things you can do in - your HTML documents with SSI.

+

The following are practical examples of common SSI use + cases.

-

When was this document -modified?

+

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

+

A common use of SSI is to display a "last modified" timestamp + on each page. The following code uses the + LAST_MODIFIED variable so you can paste the same + snippet into any file without changing the filename:

-

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

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

+

For details on timefmt format strings, see the + documentation for strftime in your system's C + library reference.

-

If you are managing any site that is more than a few pages, - you may find that making changes to all those pages can be a - real pain, particularly if you are trying to maintain some kind - of standard look across all those pages.

- -

Using an include file for a header and/or a footer can - reduce the burden of these updates. You just have to make one - footer file, and then include it into each page with the - include SSI command. The include - function can determine what file to include with either the - file attribute, or the virtual - attribute. The file attribute is a file path, - relative to the current directory. That means that it - cannot be an absolute file path (starting with /), nor can it - contain ../ as part of that path. The virtual - attribute is probably more useful, and should specify a URL - relative to the document being served. It can start with a /, - but must be on the same server as the file being served.

-

- <!--#include virtual="/footer.html" --> -

+

On a site with more than a few pages, maintaining a + consistent header or footer across all pages can be tedious. + SSI solves this by letting you keep shared content in a single + file and include it everywhere:

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

+

The include function accepts two attributes: + file specifies a path relative to the current + directory (it cannot be an absolute path or contain + ../), while virtual specifies a URL + relative to the document being served (it can start with + / but must be on the same server).

+ +

SSI directives inside included files are evaluated normally, + and includes can be nested. This means you can put a + LAST_MODIFIED timestamp in your footer file, and + it will be evaluated in the context of each page that includes + it.

top
-

What else can I config?

- +

Other config options

-

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

+

In addition to timefmt, the config + function supports two other attributes.

-

If you want to change that message to something else, you - can do so with the errmsg attribute to the - config function:

+

The errmsg attribute changes the error message + displayed when an SSI directive fails. The default is:

- <!--#config errmsg="[It appears that you don't know how to use SSI]" --> +[an error occurred while processing this directive]

-

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

+

You can replace it with something more appropriate for your + site:

+
<!--#config errmsg="[Content unavailable]" -->
+
-

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
+

The sizefmt attribute controls how file sizes + are formatted: bytes for a full byte count, or + abbrev for an abbreviated form in KB or MB.

+
top

Executing commands

-

Here's something else that you can do with the exec - function. You can actually have SSI execute a command using the - shell (/bin/sh, to be precise - or the DOS shell, - if you're on Win32). The following, for example, will give you - a directory listing.

-

- <pre>
- <!--#exec cmd="ls" -->
- </pre> -

+

The exec function can run a shell command and + include its output in the page. On Unix-like systems, the + command is executed via /bin/sh; on Windows, via + the command shell.

-

or, on Windows

-

- <pre>
- <!--#exec cmd="dir" -->
- </pre> -

+
<pre>
+<!--#exec cmd="ls" -->
+</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
+

+ The exec feature is a significant security risk. It + executes arbitrary commands with the permissions of the web + server process. If users can edit content on your site, ensure + this feature is disabled by using IncludesNOEXEC + instead of Includes in 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.

+

Beyond simple content inclusion, SSI supports variables and + conditional expressions, making it possible to generate + different content based on the request context.

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

+

The set directive defines variables for use later + in the page:

-

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="name" value="Rich" -->
+
-

<!--#set var="modified" value="$LAST_MODIFIED" --> -

+

Variables can reference other variables (including + environment variables) using the dollar + sign ($) prefix:

-

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

+
<!--#set var="modified" value="$LAST_MODIFIED" -->
+
-

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}" --> -

+

To include a literal dollar sign, escape it with a + backslash:

+ +
<!--#set var="cost" value="\$100" -->
+
+ +

When a variable name might be ambiguous within a longer + string, use braces to delimit it:

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

+

mod_include provides if, + elif, else, and endif + constructs for building conditional logic. This lets you + generate different output from a single physical page.

-

The structure of this conditional construct is:

-

- <!--#if expr="test_condition" -->
- <!--#elif expr="test_condition" -->
- <!--#else -->
- <!--#endif --> -

+

The structure is:

-

A test_condition can be any sort of logical - comparison - either comparing values to one another, or testing - the ``truth'' of a particular value. (A given string is true if - it is nonempty.) For a full list of the comparison operators - available to you, see the mod_include - documentation.

- -

For example, if you wish to customize the text on your web page - based on the time of day, you could use the following recipe, placed - in the HTML page:

+
<!--#if expr="test_condition" -->

+<!--#elif expr="test_condition" -->

+<!--#else -->

+<!--#endif -->
+
-

- Good - <!--#if expr="%{TIME_HOUR} <12" -->
- morning!
- <!--#else -->
- afternoon!
- <!--#endif -->
-

+

A test_condition can compare values or test whether a + variable is non-empty. See the mod_include + documentation for the full list of comparison operators.

+ +

For example, to display different greetings based on the time + of day:

+ +
Good
+<!--#if expr="%{TIME_HOUR} <12" -->

+morning!

+<!--#else -->

+afternoon!

+<!--#endif -->

+
+
-

Any other variable (either ones that you define, or normal - environment variables) can be used in conditional statements. - See Expressions in Apache HTTP Server for - more information on the expression evaluation engine.

+

Any variable — user-defined or from the environment — can be + used in conditional expressions. See + Expressions in Apache HTTP Server for + full details on the expression evaluation engine.

-

With Apache's ability to set environment variables with the - SetEnvIf directives, and other related directives, - this functionality can let you do a wide variety of dynamic content - on the server side without resorting a full web application.

+

Combined with httpd's ability to set environment variables + using SetEnvIf and + related directives, conditional SSI can handle a wide variety of + dynamic content scenarios without a full application + framework.

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.

+

For sites that are mostly static but need a few dynamic + touches, SSI avoids the overhead of setting up a full + application stack. It requires only mod_include + and a few lines of configuration to get started.

Available Languages:  en  | diff --git a/docs/manual/howto/ssi.html.es b/docs/manual/howto/ssi.html.es index 74ba830711..0fc74195c7 100644 --- a/docs/manual/howto/ssi.html.es +++ b/docs/manual/howto/ssi.html.es @@ -31,6 +31,10 @@  ja  |  ko 

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

Los Server Side Includes (Inclusiones en la parte Servidor) facilitan un método para añadir contenido dinámico a documentos HTML existentes.

diff --git a/docs/manual/howto/ssi.html.fr.utf8 b/docs/manual/howto/ssi.html.fr.utf8 index 5a341cbd31..9612ead939 100644 --- a/docs/manual/howto/ssi.html.fr.utf8 +++ b/docs/manual/howto/ssi.html.fr.utf8 @@ -31,6 +31,8 @@  ja  |  ko 

+
Cette traduction peut être périmée. Vérifiez la version + anglaise pour les changements récents.

Les SSI permettent d'ajouter du contenu dynamique à des documents HTML préexistants.

diff --git a/docs/manual/howto/ssi.xml.es b/docs/manual/howto/ssi.xml.es index 90d12e888c..d305b108aa 100644 --- a/docs/manual/howto/ssi.xml.es +++ b/docs/manual/howto/ssi.xml.es @@ -1,7 +1,7 @@ - + + diff --git a/docs/manual/howto/ssi.xml.ja b/docs/manual/howto/ssi.xml.ja index eed30e9845..ed4d2d759b 100644 --- a/docs/manual/howto/ssi.xml.ja +++ b/docs/manual/howto/ssi.xml.ja @@ -1,7 +1,7 @@ - + +