From f2b5ac922ba7aaa91f2ae2381c4dabfe47c4ee40 Mon Sep 17 00:00:00 2001 From: André Malo Date: Mon, 8 Oct 2018 20:59:30 +0000 Subject: move es and fr targets to *.utf8 extension. Update transformation git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1843201 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/bind.html | 2 +- docs/manual/bind.html.en | 12 +- docs/manual/bind.html.es | 226 - docs/manual/bind.html.es.utf8 | 226 + docs/manual/bind.html.fr | 259 - docs/manual/bind.html.fr.utf8 | 259 + docs/manual/caching.html.en | 8 +- docs/manual/caching.html.fr | 1003 ---- docs/manual/caching.html.fr.utf8 | 1003 ++++ docs/manual/compliance.html.en | 4 +- docs/manual/compliance.html.fr | 520 -- docs/manual/compliance.html.fr.utf8 | 520 ++ docs/manual/configuring.html.en | 8 +- docs/manual/configuring.html.fr | 253 - docs/manual/configuring.html.fr.utf8 | 253 + docs/manual/content-negotiation.html.en | 8 +- docs/manual/content-negotiation.html.fr | 742 --- docs/manual/content-negotiation.html.fr.utf8 | 742 +++ docs/manual/convenience.map | 1 + docs/manual/custom-error.html | 2 +- docs/manual/custom-error.html.en | 12 +- docs/manual/custom-error.html.es | 233 - docs/manual/custom-error.html.es.utf8 | 233 + docs/manual/custom-error.html.fr | 250 - docs/manual/custom-error.html.fr.utf8 | 250 + docs/manual/dns-caveats.html.en | 8 +- docs/manual/dns-caveats.html.fr | 226 - docs/manual/dns-caveats.html.fr.utf8 | 226 + docs/manual/dso.html.en | 8 +- docs/manual/dso.html.fr | 356 -- docs/manual/dso.html.fr.utf8 | 356 ++ docs/manual/env.html.en | 8 +- docs/manual/env.html.fr | 560 -- docs/manual/env.html.fr.utf8 | 560 ++ docs/manual/expr.html.en | 4 +- docs/manual/expr.html.fr | 787 --- docs/manual/expr.html.fr.utf8 | 787 +++ docs/manual/faq/index.html | 2 +- docs/manual/faq/index.html.en | 12 +- docs/manual/faq/index.html.es | 52 - docs/manual/faq/index.html.es.utf8 | 52 + docs/manual/faq/index.html.fr | 52 - docs/manual/faq/index.html.fr.utf8 | 52 + docs/manual/filter.html | 2 +- docs/manual/filter.html.en | 12 +- docs/manual/filter.html.es | 200 - docs/manual/filter.html.es.utf8 | 200 + docs/manual/filter.html.fr | 202 - docs/manual/filter.html.fr.utf8 | 202 + docs/manual/getting-started.html.en | 4 +- docs/manual/getting-started.html.fr | 276 - docs/manual/getting-started.html.fr.utf8 | 276 + docs/manual/glossary.html | 2 +- docs/manual/glossary.html.en | 12 +- docs/manual/glossary.html.es | 556 -- docs/manual/glossary.html.es.utf8 | 556 ++ docs/manual/glossary.html.fr | 619 --- docs/manual/glossary.html.fr.utf8 | 619 +++ docs/manual/handler.html | 2 +- docs/manual/handler.html.en | 12 +- docs/manual/handler.html.es | 195 - docs/manual/handler.html.es.utf8 | 195 + docs/manual/handler.html.fr | 188 - docs/manual/handler.html.fr.utf8 | 188 + docs/manual/howto/access.html | 2 +- docs/manual/howto/access.html.en | 8 +- docs/manual/howto/access.html.es | 236 - docs/manual/howto/access.html.es.utf8 | 236 + docs/manual/howto/access.html.fr | 243 - docs/manual/howto/access.html.fr.utf8 | 243 + docs/manual/howto/auth.html | 2 +- docs/manual/howto/auth.html.en | 12 +- docs/manual/howto/auth.html.es | 713 --- docs/manual/howto/auth.html.es.utf8 | 713 +++ docs/manual/howto/auth.html.fr | 684 --- docs/manual/howto/auth.html.fr.utf8 | 684 +++ docs/manual/howto/cgi.html | 2 +- docs/manual/howto/cgi.html.en | 8 +- docs/manual/howto/cgi.html.es | 615 --- docs/manual/howto/cgi.html.es.utf8 | 615 +++ docs/manual/howto/cgi.html.fr | 644 --- docs/manual/howto/cgi.html.fr.utf8 | 644 +++ docs/manual/howto/encrypt.html | 2 +- docs/manual/howto/encrypt.html.en | 4 +- docs/manual/howto/encrypt.html.es | 168 - docs/manual/howto/encrypt.html.es.utf8 | 168 + docs/manual/howto/htaccess.html | 2 +- docs/manual/howto/htaccess.html.en | 12 +- docs/manual/howto/htaccess.html.es | 464 -- docs/manual/howto/htaccess.html.es.utf8 | 464 ++ docs/manual/howto/htaccess.html.fr | 512 -- docs/manual/howto/htaccess.html.fr.utf8 | 512 ++ docs/manual/howto/http2.html | 2 +- docs/manual/howto/http2.html.en | 8 +- docs/manual/howto/http2.html.es | 417 -- docs/manual/howto/http2.html.es.utf8 | 417 ++ docs/manual/howto/http2.html.fr | 429 -- docs/manual/howto/http2.html.fr.utf8 | 429 ++ docs/manual/howto/index.html | 2 +- docs/manual/howto/index.html.en | 8 +- docs/manual/howto/index.html.es | 174 - docs/manual/howto/index.html.es.utf8 | 174 + docs/manual/howto/index.html.fr | 180 - docs/manual/howto/index.html.fr.utf8 | 180 + docs/manual/howto/public_html.html | 2 +- docs/manual/howto/public_html.html.en | 12 +- docs/manual/howto/public_html.html.es | 216 - docs/manual/howto/public_html.html.es.utf8 | 216 + docs/manual/howto/public_html.html.fr | 235 - docs/manual/howto/public_html.html.fr.utf8 | 235 + docs/manual/howto/reverse_proxy.html | 2 +- docs/manual/howto/reverse_proxy.html.en | 8 +- docs/manual/howto/reverse_proxy.html.es | 339 -- docs/manual/howto/reverse_proxy.html.es.utf8 | 339 ++ docs/manual/howto/reverse_proxy.html.fr | 383 -- docs/manual/howto/reverse_proxy.html.fr.utf8 | 383 ++ docs/manual/howto/ssi.html | 2 +- docs/manual/howto/ssi.html.en | 8 +- docs/manual/howto/ssi.html.es | 356 -- docs/manual/howto/ssi.html.es.utf8 | 356 ++ docs/manual/howto/ssi.html.fr | 518 -- docs/manual/howto/ssi.html.fr.utf8 | 518 ++ docs/manual/index.html | 2 +- docs/manual/index.html.en | 16 +- docs/manual/index.html.es | 127 - docs/manual/index.html.es.utf8 | 127 + docs/manual/index.html.fr | 129 - docs/manual/index.html.fr.utf8 | 129 + docs/manual/install.html | 2 +- docs/manual/install.html.en | 12 +- docs/manual/install.html.es | 510 -- docs/manual/install.html.es.utf8 | 510 ++ docs/manual/install.html.fr | 529 -- docs/manual/install.html.fr.utf8 | 529 ++ docs/manual/invoking.html | 2 +- docs/manual/invoking.html.en | 12 +- docs/manual/invoking.html.es | 190 - docs/manual/invoking.html.es.utf8 | 190 + docs/manual/invoking.html.fr | 188 - docs/manual/invoking.html.fr.utf8 | 188 + docs/manual/logs.html.en | 8 +- docs/manual/logs.html.fr | 764 --- docs/manual/logs.html.fr.utf8 | 764 +++ docs/manual/misc/index.html | 2 +- docs/manual/misc/index.html.en | 12 +- docs/manual/misc/index.html.es | 89 - docs/manual/misc/index.html.es.utf8 | 89 + docs/manual/misc/index.html.fr | 106 - docs/manual/misc/index.html.fr.utf8 | 106 + docs/manual/misc/password_encryptions.html | 2 +- docs/manual/misc/password_encryptions.html.en | 8 +- docs/manual/misc/password_encryptions.html.es | 240 - docs/manual/misc/password_encryptions.html.es.utf8 | 240 + docs/manual/misc/password_encryptions.html.fr | 276 - docs/manual/misc/password_encryptions.html.fr.utf8 | 276 + docs/manual/misc/perf-scaling.html | 2 +- docs/manual/misc/perf-scaling.html.en | 8 +- docs/manual/misc/perf-scaling.html.es | 735 --- docs/manual/misc/perf-scaling.html.es.utf8 | 735 +++ docs/manual/misc/perf-scaling.html.fr | 1649 ------ docs/manual/misc/perf-scaling.html.fr.utf8 | 1649 ++++++ docs/manual/misc/perf-tuning.html.en | 8 +- docs/manual/misc/perf-tuning.html.fr | 1018 ---- docs/manual/misc/perf-tuning.html.fr.utf8 | 1018 ++++ docs/manual/misc/relevant_standards.html.en | 4 +- docs/manual/misc/relevant_standards.html.fr | 253 - docs/manual/misc/relevant_standards.html.fr.utf8 | 253 + docs/manual/misc/security_tips.html | 2 +- docs/manual/misc/security_tips.html.en | 12 +- docs/manual/misc/security_tips.html.es | 334 -- docs/manual/misc/security_tips.html.es.utf8 | 334 ++ docs/manual/misc/security_tips.html.fr | 515 -- docs/manual/misc/security_tips.html.fr.utf8 | 515 ++ docs/manual/mod/core.html | 2 +- docs/manual/mod/core.html.de | 20 + docs/manual/mod/core.html.en | 68 +- docs/manual/mod/core.html.es | 4584 ---------------- docs/manual/mod/core.html.es.utf8 | 4584 ++++++++++++++++ docs/manual/mod/core.html.fr | 5654 -------------------- docs/manual/mod/core.html.fr.utf8 | 5654 ++++++++++++++++++++ docs/manual/mod/core.html.ja.utf8 | 20 + docs/manual/mod/core.html.tr.utf8 | 19 + docs/manual/mod/core.xml.de | 2 +- docs/manual/mod/core.xml.es | 2 +- docs/manual/mod/core.xml.fr | 2 +- docs/manual/mod/core.xml.ja | 2 +- docs/manual/mod/core.xml.meta | 2 +- docs/manual/mod/core.xml.tr | 2 +- docs/manual/mod/directive-dict.html | 2 +- docs/manual/mod/directive-dict.html.en | 12 +- docs/manual/mod/directive-dict.html.es | 318 -- docs/manual/mod/directive-dict.html.es.utf8 | 318 ++ docs/manual/mod/directive-dict.html.fr | 332 -- docs/manual/mod/directive-dict.html.fr.utf8 | 332 ++ docs/manual/mod/directives.html | 2 +- docs/manual/mod/directives.html.de | 1 + docs/manual/mod/directives.html.en | 13 +- docs/manual/mod/directives.html.es | 819 --- docs/manual/mod/directives.html.es.utf8 | 819 +++ docs/manual/mod/directives.html.fr | 818 --- docs/manual/mod/directives.html.fr.utf8 | 818 +++ docs/manual/mod/directives.html.ja.utf8 | 1 + docs/manual/mod/directives.html.ko.euc-kr | 1 + docs/manual/mod/directives.html.tr.utf8 | 1 + docs/manual/mod/directives.html.zh-cn.utf8 | 1 + docs/manual/mod/event.html | 2 +- docs/manual/mod/event.html.en | 12 +- docs/manual/mod/event.html.es | 340 -- docs/manual/mod/event.html.es.utf8 | 340 ++ docs/manual/mod/event.html.fr | 519 -- docs/manual/mod/event.html.fr.utf8 | 519 ++ docs/manual/mod/index.html | 2 +- docs/manual/mod/index.html.en | 12 +- docs/manual/mod/index.html.es | 286 - docs/manual/mod/index.html.es.utf8 | 286 + docs/manual/mod/index.html.fr | 331 -- docs/manual/mod/index.html.fr.utf8 | 331 ++ docs/manual/mod/mod_access_compat.html | 2 +- docs/manual/mod/mod_access_compat.html.en | 12 +- docs/manual/mod/mod_access_compat.html.es | 378 -- docs/manual/mod/mod_access_compat.html.es.utf8 | 378 ++ docs/manual/mod/mod_access_compat.html.fr | 524 -- docs/manual/mod/mod_access_compat.html.fr.utf8 | 524 ++ docs/manual/mod/mod_actions.html | 2 +- docs/manual/mod/mod_actions.html.en | 12 +- docs/manual/mod/mod_actions.html.es | 156 - docs/manual/mod/mod_actions.html.es.utf8 | 156 + docs/manual/mod/mod_actions.html.fr | 196 - docs/manual/mod/mod_actions.html.fr.utf8 | 196 + docs/manual/mod/mod_alias.html | 2 +- docs/manual/mod/mod_alias.html.en | 16 +- docs/manual/mod/mod_alias.html.es | 552 -- docs/manual/mod/mod_alias.html.es.utf8 | 552 ++ docs/manual/mod/mod_alias.html.fr | 649 --- docs/manual/mod/mod_alias.html.fr.utf8 | 649 +++ docs/manual/mod/mod_allowhandlers.html | 2 +- docs/manual/mod/mod_allowhandlers.html.en | 12 +- docs/manual/mod/mod_allowhandlers.html.es | 112 - docs/manual/mod/mod_allowhandlers.html.es.utf8 | 112 + docs/manual/mod/mod_allowhandlers.html.fr | 120 - docs/manual/mod/mod_allowhandlers.html.fr.utf8 | 120 + docs/manual/mod/mod_allowmethods.html | 2 +- docs/manual/mod/mod_allowmethods.html.en | 12 +- docs/manual/mod/mod_allowmethods.html.es | 119 - docs/manual/mod/mod_allowmethods.html.es.utf8 | 119 + docs/manual/mod/mod_allowmethods.html.fr | 120 - docs/manual/mod/mod_allowmethods.html.fr.utf8 | 120 + docs/manual/mod/mod_asis.html | 2 +- docs/manual/mod/mod_asis.html.en | 12 +- docs/manual/mod/mod_asis.html.es | 144 - docs/manual/mod/mod_asis.html.es.utf8 | 144 + docs/manual/mod/mod_asis.html.fr | 145 - docs/manual/mod/mod_asis.html.fr.utf8 | 145 + docs/manual/mod/mod_auth_basic.html | 2 +- docs/manual/mod/mod_auth_basic.html.en | 12 +- docs/manual/mod/mod_auth_basic.html.es | 243 - docs/manual/mod/mod_auth_basic.html.es.utf8 | 243 + docs/manual/mod/mod_auth_basic.html.fr | 316 -- docs/manual/mod/mod_auth_basic.html.fr.utf8 | 316 ++ docs/manual/mod/mod_auth_digest.html.en | 8 +- docs/manual/mod/mod_auth_digest.html.fr | 353 -- docs/manual/mod/mod_auth_digest.html.fr.utf8 | 353 ++ docs/manual/mod/mod_auth_form.html.en | 8 +- docs/manual/mod/mod_auth_form.html.fr | 833 --- docs/manual/mod/mod_auth_form.html.fr.utf8 | 833 +++ docs/manual/mod/mod_authn_anon.html.en | 8 +- docs/manual/mod/mod_authn_anon.html.fr | 261 - docs/manual/mod/mod_authn_anon.html.fr.utf8 | 261 + docs/manual/mod/mod_authn_core.html.en | 8 +- docs/manual/mod/mod_authn_core.html.fr | 297 - docs/manual/mod/mod_authn_core.html.fr.utf8 | 297 + docs/manual/mod/mod_authn_dbd.html.en | 8 +- docs/manual/mod/mod_authn_dbd.html.fr | 266 - docs/manual/mod/mod_authn_dbd.html.fr.utf8 | 266 + docs/manual/mod/mod_authn_dbm.html.en | 8 +- docs/manual/mod/mod_authn_dbm.html.fr | 186 - docs/manual/mod/mod_authn_dbm.html.fr.utf8 | 186 + docs/manual/mod/mod_authn_file.html.en | 8 +- docs/manual/mod/mod_authn_file.html.fr | 171 - docs/manual/mod/mod_authn_file.html.fr.utf8 | 171 + docs/manual/mod/mod_authn_socache.html.en | 8 +- docs/manual/mod/mod_authn_socache.html.fr | 284 - docs/manual/mod/mod_authn_socache.html.fr.utf8 | 284 + docs/manual/mod/mod_authnz_fcgi.html.en | 8 +- docs/manual/mod/mod_authnz_fcgi.html.fr | 589 -- docs/manual/mod/mod_authnz_fcgi.html.fr.utf8 | 589 ++ docs/manual/mod/mod_authnz_ldap.html.en | 8 +- docs/manual/mod/mod_authnz_ldap.html.fr | 1635 ------ docs/manual/mod/mod_authnz_ldap.html.fr.utf8 | 1635 ++++++ docs/manual/mod/mod_authz_core.html.en | 12 +- docs/manual/mod/mod_authz_core.html.fr | 692 --- docs/manual/mod/mod_authz_core.html.fr.utf8 | 692 +++ docs/manual/mod/mod_authz_dbd.html.en | 8 +- docs/manual/mod/mod_authz_dbd.html.fr | 349 -- docs/manual/mod/mod_authz_dbd.html.fr.utf8 | 349 ++ docs/manual/mod/mod_authz_dbm.html.en | 8 +- docs/manual/mod/mod_authz_dbm.html.fr | 218 - docs/manual/mod/mod_authz_dbm.html.fr.utf8 | 218 + docs/manual/mod/mod_authz_groupfile.html.en | 8 +- docs/manual/mod/mod_authz_groupfile.html.fr | 162 - docs/manual/mod/mod_authz_groupfile.html.fr.utf8 | 162 + docs/manual/mod/mod_authz_host.html.en | 8 +- docs/manual/mod/mod_authz_host.html.fr | 255 - docs/manual/mod/mod_authz_host.html.fr.utf8 | 255 + docs/manual/mod/mod_authz_owner.html.en | 8 +- docs/manual/mod/mod_authz_owner.html.fr | 180 - docs/manual/mod/mod_authz_owner.html.fr.utf8 | 180 + docs/manual/mod/mod_authz_user.html.en | 8 +- docs/manual/mod/mod_authz_user.html.fr | 122 - docs/manual/mod/mod_authz_user.html.fr.utf8 | 122 + docs/manual/mod/mod_autoindex.html.en | 12 +- docs/manual/mod/mod_autoindex.html.fr | 1169 ---- docs/manual/mod/mod_autoindex.html.fr.utf8 | 1169 ++++ docs/manual/mod/mod_brotli.html.en | 8 +- docs/manual/mod/mod_brotli.html.fr | 353 -- docs/manual/mod/mod_brotli.html.fr.utf8 | 353 ++ docs/manual/mod/mod_buffer.html.en | 8 +- docs/manual/mod/mod_buffer.html.fr | 131 - docs/manual/mod/mod_buffer.html.fr.utf8 | 131 + docs/manual/mod/mod_cache.html.en | 8 +- docs/manual/mod/mod_cache.html.fr | 1192 ----- docs/manual/mod/mod_cache.html.fr.utf8 | 1192 +++++ docs/manual/mod/mod_cache_disk.html.en | 8 +- docs/manual/mod/mod_cache_disk.html.fr | 310 -- docs/manual/mod/mod_cache_disk.html.fr.utf8 | 310 ++ docs/manual/mod/mod_cache_socache.html.en | 8 +- docs/manual/mod/mod_cache_socache.html.fr | 279 - docs/manual/mod/mod_cache_socache.html.fr.utf8 | 279 + docs/manual/mod/mod_cern_meta.html.en | 8 +- docs/manual/mod/mod_cern_meta.html.fr | 162 - docs/manual/mod/mod_cern_meta.html.fr.utf8 | 162 + docs/manual/mod/mod_cgi.html.en | 8 +- docs/manual/mod/mod_cgi.html.fr | 333 -- docs/manual/mod/mod_cgi.html.fr.utf8 | 333 ++ docs/manual/mod/mod_cgid.html.en | 8 +- docs/manual/mod/mod_cgid.html.fr | 165 - docs/manual/mod/mod_cgid.html.fr.utf8 | 165 + docs/manual/mod/mod_charset_lite.html.en | 8 +- docs/manual/mod/mod_charset_lite.html.fr | 252 - docs/manual/mod/mod_charset_lite.html.fr.utf8 | 252 + docs/manual/mod/mod_crypto.html.en | 8 +- docs/manual/mod/mod_crypto.html.fr | 319 -- docs/manual/mod/mod_crypto.html.fr.utf8 | 319 ++ docs/manual/mod/mod_data.html.en | 8 +- docs/manual/mod/mod_data.html.fr | 105 - docs/manual/mod/mod_data.html.fr.utf8 | 105 + docs/manual/mod/mod_dav.html.en | 8 +- docs/manual/mod/mod_dav.html.fr | 302 -- docs/manual/mod/mod_dav.html.fr.utf8 | 302 ++ docs/manual/mod/mod_dav_fs.html.en | 15 +- docs/manual/mod/mod_dav_fs.html.fr | 129 - docs/manual/mod/mod_dav_fs.html.fr.utf8 | 129 + docs/manual/mod/mod_dav_fs.xml.fr | 2 +- docs/manual/mod/mod_dav_fs.xml.ja | 2 +- docs/manual/mod/mod_dav_fs.xml.ko | 2 +- docs/manual/mod/mod_dav_fs.xml.meta | 2 +- docs/manual/mod/mod_dav_lock.html.en | 8 +- docs/manual/mod/mod_dav_lock.html.fr | 136 - docs/manual/mod/mod_dav_lock.html.fr.utf8 | 136 + docs/manual/mod/mod_dbd.html.en | 8 +- docs/manual/mod/mod_dbd.html.fr | 420 -- docs/manual/mod/mod_dbd.html.fr.utf8 | 420 ++ docs/manual/mod/mod_deflate.html.en | 8 +- docs/manual/mod/mod_deflate.html.fr | 515 -- docs/manual/mod/mod_deflate.html.fr.utf8 | 515 ++ docs/manual/mod/mod_dialup.html.en | 8 +- docs/manual/mod/mod_dialup.html.fr | 113 - docs/manual/mod/mod_dialup.html.fr.utf8 | 113 + docs/manual/mod/mod_dir.html.en | 12 +- docs/manual/mod/mod_dir.html.fr | 380 -- docs/manual/mod/mod_dir.html.fr.utf8 | 380 ++ docs/manual/mod/mod_dumpio.html.en | 8 +- docs/manual/mod/mod_dumpio.html.fr | 139 - docs/manual/mod/mod_dumpio.html.fr.utf8 | 139 + docs/manual/mod/mod_echo.html.en | 8 +- docs/manual/mod/mod_echo.html.fr | 100 - docs/manual/mod/mod_echo.html.fr.utf8 | 100 + docs/manual/mod/mod_env.html.en | 12 +- docs/manual/mod/mod_env.html.fr | 172 - docs/manual/mod/mod_env.html.fr.utf8 | 172 + docs/manual/mod/mod_example_hooks.html.en | 8 +- docs/manual/mod/mod_example_hooks.html.fr | 198 - docs/manual/mod/mod_example_hooks.html.fr.utf8 | 198 + docs/manual/mod/mod_expires.html.en | 8 +- docs/manual/mod/mod_expires.html.fr | 280 - docs/manual/mod/mod_expires.html.fr.utf8 | 280 + docs/manual/mod/mod_ext_filter.html.en | 8 +- docs/manual/mod/mod_ext_filter.html.fr | 383 -- docs/manual/mod/mod_ext_filter.html.fr.utf8 | 383 ++ docs/manual/mod/mod_file_cache.html.en | 8 +- docs/manual/mod/mod_file_cache.html.fr | 270 - docs/manual/mod/mod_file_cache.html.fr.utf8 | 270 + docs/manual/mod/mod_filter.html.en | 8 +- docs/manual/mod/mod_filter.html.fr | 574 -- docs/manual/mod/mod_filter.html.fr.utf8 | 574 ++ docs/manual/mod/mod_firehose.html.en | 8 +- docs/manual/mod/mod_firehose.html.fr | 316 -- docs/manual/mod/mod_firehose.html.fr.utf8 | 316 ++ docs/manual/mod/mod_headers.html.en | 8 +- docs/manual/mod/mod_headers.html.fr | 654 --- docs/manual/mod/mod_headers.html.fr.utf8 | 654 +++ docs/manual/mod/mod_heartbeat.html.en | 8 +- docs/manual/mod/mod_heartbeat.html.fr | 142 - docs/manual/mod/mod_heartbeat.html.fr.utf8 | 142 + docs/manual/mod/mod_heartmonitor.html.en | 8 +- docs/manual/mod/mod_heartmonitor.html.fr | 158 - docs/manual/mod/mod_heartmonitor.html.fr.utf8 | 158 + docs/manual/mod/mod_http2.html.en | 8 +- docs/manual/mod/mod_http2.html.fr | 1034 ---- docs/manual/mod/mod_http2.html.fr.utf8 | 1034 ++++ docs/manual/mod/mod_ident.html.en | 8 +- docs/manual/mod/mod_ident.html.fr | 137 - docs/manual/mod/mod_ident.html.fr.utf8 | 137 + docs/manual/mod/mod_imagemap.html.en | 8 +- docs/manual/mod/mod_imagemap.html.fr | 440 -- docs/manual/mod/mod_imagemap.html.fr.utf8 | 440 ++ docs/manual/mod/mod_include.html.en | 8 +- docs/manual/mod/mod_include.html.fr | 1231 ----- docs/manual/mod/mod_include.html.fr.utf8 | 1231 +++++ docs/manual/mod/mod_info.html.en | 8 +- docs/manual/mod/mod_info.html.fr | 240 - docs/manual/mod/mod_info.html.fr.utf8 | 240 + docs/manual/mod/mod_isapi.html.en | 8 +- docs/manual/mod/mod_isapi.html.fr | 393 -- docs/manual/mod/mod_isapi.html.fr.utf8 | 393 ++ docs/manual/mod/mod_journald.html.en | 8 +- docs/manual/mod/mod_journald.html.fr | 148 - docs/manual/mod/mod_journald.html.fr.utf8 | 148 + docs/manual/mod/mod_lbmethod_bybusyness.html.en | 8 +- docs/manual/mod/mod_lbmethod_bybusyness.html.fr | 109 - .../mod/mod_lbmethod_bybusyness.html.fr.utf8 | 109 + docs/manual/mod/mod_lbmethod_byrequests.html.en | 8 +- docs/manual/mod/mod_lbmethod_byrequests.html.fr | 264 - .../mod/mod_lbmethod_byrequests.html.fr.utf8 | 264 + docs/manual/mod/mod_lbmethod_bytraffic.html.en | 8 +- docs/manual/mod/mod_lbmethod_bytraffic.html.fr | 125 - .../manual/mod/mod_lbmethod_bytraffic.html.fr.utf8 | 125 + docs/manual/mod/mod_lbmethod_heartbeat.html.en | 8 +- docs/manual/mod/mod_lbmethod_heartbeat.html.fr | 109 - .../manual/mod/mod_lbmethod_heartbeat.html.fr.utf8 | 109 + docs/manual/mod/mod_ldap.html.en | 8 +- docs/manual/mod/mod_ldap.html.fr | 966 ---- docs/manual/mod/mod_ldap.html.fr.utf8 | 966 ++++ docs/manual/mod/mod_log_config.html.en | 12 +- docs/manual/mod/mod_log_config.html.fr | 690 --- docs/manual/mod/mod_log_config.html.fr.utf8 | 690 +++ docs/manual/mod/mod_log_debug.html.en | 14 +- docs/manual/mod/mod_log_debug.html.fr | 183 - docs/manual/mod/mod_log_debug.html.fr.utf8 | 183 + docs/manual/mod/mod_log_forensic.html.en | 12 +- docs/manual/mod/mod_log_forensic.html.fr | 230 - docs/manual/mod/mod_log_forensic.html.fr.utf8 | 230 + docs/manual/mod/mod_logio.html.en | 12 +- docs/manual/mod/mod_logio.html.fr | 190 - docs/manual/mod/mod_logio.html.fr.utf8 | 190 + docs/manual/mod/mod_lua.html.en | 8 +- docs/manual/mod/mod_lua.html.fr | 2061 ------- docs/manual/mod/mod_lua.html.fr.utf8 | 2061 +++++++ docs/manual/mod/mod_macro.html.en | 8 +- docs/manual/mod/mod_macro.html.fr | 338 -- docs/manual/mod/mod_macro.html.fr.utf8 | 338 ++ docs/manual/mod/mod_md.html.en | 4 +- docs/manual/mod/mod_mime.html.en | 8 +- docs/manual/mod/mod_mime.html.fr | 1131 ---- docs/manual/mod/mod_mime.html.fr.utf8 | 1131 ++++ docs/manual/mod/mod_mime_magic.html.en | 8 +- docs/manual/mod/mod_mime_magic.html.fr | 312 -- docs/manual/mod/mod_mime_magic.html.fr.utf8 | 312 ++ docs/manual/mod/mod_negotiation.html.en | 8 +- docs/manual/mod/mod_negotiation.html.fr | 388 -- docs/manual/mod/mod_negotiation.html.fr.utf8 | 388 ++ docs/manual/mod/mod_nw_ssl.html.en | 8 +- docs/manual/mod/mod_nw_ssl.html.fr | 131 - docs/manual/mod/mod_nw_ssl.html.fr.utf8 | 131 + docs/manual/mod/mod_policy.html.en | 8 +- docs/manual/mod/mod_policy.html.fr | 742 --- docs/manual/mod/mod_policy.html.fr.utf8 | 742 +++ docs/manual/mod/mod_privileges.html.en | 8 +- docs/manual/mod/mod_privileges.html.fr | 480 -- docs/manual/mod/mod_privileges.html.fr.utf8 | 480 ++ docs/manual/mod/mod_proxy.html.en | 8 +- docs/manual/mod/mod_proxy.html.fr | 2408 --------- docs/manual/mod/mod_proxy.html.fr.utf8 | 2408 +++++++++ docs/manual/mod/mod_proxy_ajp.html.en | 8 +- docs/manual/mod/mod_proxy_ajp.html.fr | 684 --- docs/manual/mod/mod_proxy_ajp.html.fr.utf8 | 684 +++ docs/manual/mod/mod_proxy_balancer.html.en | 8 +- docs/manual/mod/mod_proxy_balancer.html.fr | 407 -- docs/manual/mod/mod_proxy_balancer.html.fr.utf8 | 407 ++ docs/manual/mod/mod_proxy_connect.html.en | 8 +- docs/manual/mod/mod_proxy_connect.html.fr | 155 - docs/manual/mod/mod_proxy_connect.html.fr.utf8 | 155 + docs/manual/mod/mod_proxy_express.html.en | 8 +- docs/manual/mod/mod_proxy_express.html.fr | 215 - docs/manual/mod/mod_proxy_express.html.fr.utf8 | 215 + docs/manual/mod/mod_proxy_fcgi.html.en | 8 +- docs/manual/mod/mod_proxy_fcgi.html.fr | 403 -- docs/manual/mod/mod_proxy_fcgi.html.fr.utf8 | 403 ++ docs/manual/mod/mod_proxy_fdpass.html.en | 8 +- docs/manual/mod/mod_proxy_fdpass.html.fr | 104 - docs/manual/mod/mod_proxy_fdpass.html.fr.utf8 | 104 + docs/manual/mod/mod_proxy_ftp.html.en | 8 +- docs/manual/mod/mod_proxy_ftp.html.fr | 296 - docs/manual/mod/mod_proxy_ftp.html.fr.utf8 | 296 + docs/manual/mod/mod_proxy_hcheck.html.en | 8 +- docs/manual/mod/mod_proxy_hcheck.html.fr | 299 -- docs/manual/mod/mod_proxy_hcheck.html.fr.utf8 | 299 ++ docs/manual/mod/mod_proxy_html.html.en | 8 +- docs/manual/mod/mod_proxy_html.html.fr | 634 --- docs/manual/mod/mod_proxy_html.html.fr.utf8 | 634 +++ docs/manual/mod/mod_proxy_http.html.en | 8 +- docs/manual/mod/mod_proxy_http.html.fr | 193 - docs/manual/mod/mod_proxy_http.html.fr.utf8 | 193 + docs/manual/mod/mod_proxy_http2.html.en | 8 +- docs/manual/mod/mod_proxy_http2.html.fr | 167 - docs/manual/mod/mod_proxy_http2.html.fr.utf8 | 167 + docs/manual/mod/mod_proxy_scgi.html.en | 8 +- docs/manual/mod/mod_proxy_scgi.html.fr | 229 - docs/manual/mod/mod_proxy_scgi.html.fr.utf8 | 229 + docs/manual/mod/mod_proxy_uwsgi.html.en | 4 +- docs/manual/mod/mod_proxy_wstunnel.html.en | 8 +- docs/manual/mod/mod_proxy_wstunnel.html.fr | 157 - docs/manual/mod/mod_proxy_wstunnel.html.fr.utf8 | 157 + docs/manual/mod/mod_ratelimit.html.en | 8 +- docs/manual/mod/mod_ratelimit.html.fr | 104 - docs/manual/mod/mod_ratelimit.html.fr.utf8 | 104 + docs/manual/mod/mod_reflector.html.en | 8 +- docs/manual/mod/mod_reflector.html.fr | 129 - docs/manual/mod/mod_reflector.html.fr.utf8 | 129 + docs/manual/mod/mod_remoteip.html.en | 8 +- docs/manual/mod/mod_remoteip.html.fr | 428 -- docs/manual/mod/mod_remoteip.html.fr.utf8 | 428 ++ docs/manual/mod/mod_reqtimeout.html.en | 8 +- docs/manual/mod/mod_reqtimeout.html.fr | 226 - docs/manual/mod/mod_reqtimeout.html.fr.utf8 | 226 + docs/manual/mod/mod_request.html.en | 12 +- docs/manual/mod/mod_request.html.fr | 138 - docs/manual/mod/mod_request.html.fr.utf8 | 138 + docs/manual/mod/mod_rewrite.html.en | 8 +- docs/manual/mod/mod_rewrite.html.fr | 1681 ------ docs/manual/mod/mod_rewrite.html.fr.utf8 | 1681 ++++++ docs/manual/mod/mod_sed.html.en | 8 +- docs/manual/mod/mod_sed.html.fr | 189 - docs/manual/mod/mod_sed.html.fr.utf8 | 189 + docs/manual/mod/mod_session.html.en | 8 +- docs/manual/mod/mod_session.html.fr | 620 --- docs/manual/mod/mod_session.html.fr.utf8 | 620 +++ docs/manual/mod/mod_session_cookie.html.en | 8 +- docs/manual/mod/mod_session_cookie.html.fr | 220 - docs/manual/mod/mod_session_cookie.html.fr.utf8 | 220 + docs/manual/mod/mod_session_crypto.html.en | 8 +- docs/manual/mod/mod_session_crypto.html.fr | 294 - docs/manual/mod/mod_session_crypto.html.fr.utf8 | 294 + docs/manual/mod/mod_session_dbd.html.en | 8 +- docs/manual/mod/mod_session_dbd.html.fr | 415 -- docs/manual/mod/mod_session_dbd.html.fr.utf8 | 415 ++ docs/manual/mod/mod_setenvif.html.en | 12 +- docs/manual/mod/mod_setenvif.html.fr | 373 -- docs/manual/mod/mod_setenvif.html.fr.utf8 | 373 ++ docs/manual/mod/mod_slotmem_plain.html.en | 8 +- docs/manual/mod/mod_slotmem_plain.html.fr | 123 - docs/manual/mod/mod_slotmem_plain.html.fr.utf8 | 123 + docs/manual/mod/mod_slotmem_shm.html.en | 8 +- docs/manual/mod/mod_slotmem_shm.html.fr | 138 - docs/manual/mod/mod_slotmem_shm.html.fr.utf8 | 138 + docs/manual/mod/mod_so.html.en | 12 +- docs/manual/mod/mod_so.html.fr | 244 - docs/manual/mod/mod_so.html.fr.utf8 | 244 + docs/manual/mod/mod_socache_dbm.html.en | 8 +- docs/manual/mod/mod_socache_dbm.html.fr | 89 - docs/manual/mod/mod_socache_dbm.html.fr.utf8 | 89 + docs/manual/mod/mod_socache_dc.html.en | 8 +- docs/manual/mod/mod_socache_dc.html.fr | 83 - docs/manual/mod/mod_socache_dc.html.fr.utf8 | 83 + docs/manual/mod/mod_socache_memcache.html.en | 8 +- docs/manual/mod/mod_socache_memcache.html.fr | 135 - docs/manual/mod/mod_socache_memcache.html.fr.utf8 | 135 + docs/manual/mod/mod_socache_redis.html.en | 4 +- docs/manual/mod/mod_socache_shmcb.html.en | 8 +- docs/manual/mod/mod_socache_shmcb.html.fr | 90 - docs/manual/mod/mod_socache_shmcb.html.fr.utf8 | 90 + docs/manual/mod/mod_speling.html.en | 8 +- docs/manual/mod/mod_speling.html.fr | 195 - docs/manual/mod/mod_speling.html.fr.utf8 | 195 + docs/manual/mod/mod_ssl.html | 2 +- docs/manual/mod/mod_ssl.html.en | 14 +- docs/manual/mod/mod_ssl.html.es | 3018 ----------- docs/manual/mod/mod_ssl.html.es.utf8 | 3018 +++++++++++ docs/manual/mod/mod_ssl.html.fr | 3177 ----------- docs/manual/mod/mod_ssl.html.fr.utf8 | 3177 +++++++++++ docs/manual/mod/mod_ssl.xml.es | 2 +- docs/manual/mod/mod_ssl.xml.fr | 2 +- docs/manual/mod/mod_ssl.xml.meta | 2 +- docs/manual/mod/mod_ssl_ct.html.en | 8 +- docs/manual/mod/mod_ssl_ct.html.fr | 672 --- docs/manual/mod/mod_ssl_ct.html.fr.utf8 | 672 +++ docs/manual/mod/mod_status.html | 2 +- docs/manual/mod/mod_status.html.en | 16 +- docs/manual/mod/mod_status.html.es | 204 - docs/manual/mod/mod_status.html.es.utf8 | 204 + docs/manual/mod/mod_status.html.fr | 211 - docs/manual/mod/mod_status.html.fr.utf8 | 211 + docs/manual/mod/mod_substitute.html.en | 8 +- docs/manual/mod/mod_substitute.html.fr | 266 - docs/manual/mod/mod_substitute.html.fr.utf8 | 266 + docs/manual/mod/mod_suexec.html.en | 12 +- docs/manual/mod/mod_suexec.html.fr | 114 - docs/manual/mod/mod_suexec.html.fr.utf8 | 114 + docs/manual/mod/mod_syslog.html.en | 8 +- docs/manual/mod/mod_syslog.html.fr | 99 - docs/manual/mod/mod_syslog.html.fr.utf8 | 99 + docs/manual/mod/mod_systemd.html.en | 8 +- docs/manual/mod/mod_systemd.html.fr | 118 - docs/manual/mod/mod_systemd.html.fr.utf8 | 118 + docs/manual/mod/mod_unique_id.html.en | 8 +- docs/manual/mod/mod_unique_id.html.fr | 272 - docs/manual/mod/mod_unique_id.html.fr.utf8 | 272 + docs/manual/mod/mod_unixd.html.en | 12 +- docs/manual/mod/mod_unixd.html.fr | 226 - docs/manual/mod/mod_unixd.html.fr.utf8 | 226 + docs/manual/mod/mod_userdir.html.en | 12 +- docs/manual/mod/mod_userdir.html.fr | 226 - docs/manual/mod/mod_userdir.html.fr.utf8 | 226 + docs/manual/mod/mod_usertrack.html.en | 8 +- docs/manual/mod/mod_usertrack.html.fr | 251 - docs/manual/mod/mod_usertrack.html.fr.utf8 | 251 + docs/manual/mod/mod_version.html.en | 8 +- docs/manual/mod/mod_version.html.fr | 176 - docs/manual/mod/mod_version.html.fr.utf8 | 176 + docs/manual/mod/mod_vhost_alias.html.en | 12 +- docs/manual/mod/mod_vhost_alias.html.fr | 385 -- docs/manual/mod/mod_vhost_alias.html.fr.utf8 | 385 ++ docs/manual/mod/mod_watchdog.html.en | 8 +- docs/manual/mod/mod_watchdog.html.fr | 110 - docs/manual/mod/mod_watchdog.html.fr.utf8 | 110 + docs/manual/mod/mod_xml2enc.html.en | 8 +- docs/manual/mod/mod_xml2enc.html.fr | 243 - docs/manual/mod/mod_xml2enc.html.fr.utf8 | 243 + docs/manual/mod/module-dict.html.en | 8 +- docs/manual/mod/module-dict.html.fr | 147 - docs/manual/mod/module-dict.html.fr.utf8 | 147 + docs/manual/mod/mpm_common.html.en | 8 +- docs/manual/mod/mpm_common.html.fr | 999 ---- docs/manual/mod/mpm_common.html.fr.utf8 | 999 ++++ docs/manual/mod/mpm_netware.html.en | 8 +- docs/manual/mod/mpm_netware.html.fr | 140 - docs/manual/mod/mpm_netware.html.fr.utf8 | 140 + docs/manual/mod/mpm_winnt.html.en | 8 +- docs/manual/mod/mpm_winnt.html.fr | 163 - docs/manual/mod/mpm_winnt.html.fr.utf8 | 163 + docs/manual/mod/mpmt_os2.html.en | 8 +- docs/manual/mod/mpmt_os2.html.fr | 102 - docs/manual/mod/mpmt_os2.html.fr.utf8 | 102 + docs/manual/mod/prefork.html.en | 12 +- docs/manual/mod/prefork.html.fr | 233 - docs/manual/mod/prefork.html.fr.utf8 | 233 + docs/manual/mod/quickreference.html | 2 +- docs/manual/mod/quickreference.html.de | 1179 ++-- docs/manual/mod/quickreference.html.en | 1191 +++-- docs/manual/mod/quickreference.html.es | 1284 ----- docs/manual/mod/quickreference.html.es.utf8 | 1284 +++++ docs/manual/mod/quickreference.html.fr | 1603 ------ docs/manual/mod/quickreference.html.fr.utf8 | 1603 ++++++ docs/manual/mod/quickreference.html.ja.utf8 | 1161 ++-- docs/manual/mod/quickreference.html.ko.euc-kr | 1173 ++-- docs/manual/mod/quickreference.html.tr.utf8 | 1191 +++-- docs/manual/mod/quickreference.html.zh-cn.utf8 | 1179 ++-- docs/manual/mod/worker.html.en | 12 +- docs/manual/mod/worker.html.fr | 212 - docs/manual/mod/worker.html.fr.utf8 | 212 + docs/manual/mpm.html | 2 +- docs/manual/mpm.html.en | 12 +- docs/manual/mpm.html.es | 169 - docs/manual/mpm.html.es.utf8 | 169 + docs/manual/mpm.html.fr | 227 - docs/manual/mpm.html.fr.utf8 | 227 + docs/manual/new_features_2_0.html.en | 12 +- docs/manual/new_features_2_0.html.fr | 286 - docs/manual/new_features_2_0.html.fr.utf8 | 286 + docs/manual/new_features_2_2.html | 2 +- docs/manual/new_features_2_2.html.en | 16 +- docs/manual/new_features_2_2.html.es | 327 -- docs/manual/new_features_2_2.html.es.utf8 | 327 ++ docs/manual/new_features_2_2.html.fr | 333 -- docs/manual/new_features_2_2.html.fr.utf8 | 333 ++ docs/manual/new_features_2_4.html | 2 +- docs/manual/new_features_2_4.html.en | 12 +- docs/manual/new_features_2_4.html.es | 452 -- docs/manual/new_features_2_4.html.es.utf8 | 452 ++ docs/manual/new_features_2_4.html.fr | 507 -- docs/manual/new_features_2_4.html.fr.utf8 | 507 ++ docs/manual/platform/index.html.en | 4 +- docs/manual/platform/index.html.fr | 111 - docs/manual/platform/index.html.fr.utf8 | 111 + docs/manual/platform/netware.html.en | 4 +- docs/manual/platform/netware.html.fr | 763 --- docs/manual/platform/netware.html.fr.utf8 | 763 +++ docs/manual/platform/perf-hp.html.en | 4 +- docs/manual/platform/perf-hp.html.fr | 143 - docs/manual/platform/perf-hp.html.fr.utf8 | 143 + docs/manual/platform/rpm.html.en | 4 +- docs/manual/platform/rpm.html.fr | 264 - docs/manual/platform/rpm.html.fr.utf8 | 264 + docs/manual/platform/win_compiling.html.en | 4 +- docs/manual/platform/win_compiling.html.fr | 594 -- docs/manual/platform/win_compiling.html.fr.utf8 | 594 ++ docs/manual/platform/windows.html.en | 4 +- docs/manual/platform/windows.html.fr | 718 --- docs/manual/platform/windows.html.fr.utf8 | 718 +++ docs/manual/programs/ab.html.en | 8 +- docs/manual/programs/ab.html.fr | 404 -- docs/manual/programs/ab.html.fr.utf8 | 404 ++ docs/manual/programs/apachectl.html.en | 8 +- docs/manual/programs/apachectl.html.fr | 202 - docs/manual/programs/apachectl.html.fr.utf8 | 202 + docs/manual/programs/apxs.html.en | 8 +- docs/manual/programs/apxs.html.fr | 395 -- docs/manual/programs/apxs.html.fr.utf8 | 395 ++ docs/manual/programs/configure.html.en | 8 +- docs/manual/programs/configure.html.fr | 790 --- docs/manual/programs/configure.html.fr.utf8 | 790 +++ docs/manual/programs/ctlogconfig.html.en | 4 +- docs/manual/programs/ctlogconfig.html.fr | 259 - docs/manual/programs/ctlogconfig.html.fr.utf8 | 259 + docs/manual/programs/dbmmanage.html.en | 8 +- docs/manual/programs/dbmmanage.html.fr | 247 - docs/manual/programs/dbmmanage.html.fr.utf8 | 247 + docs/manual/programs/fcgistarter.html.en | 8 +- docs/manual/programs/fcgistarter.html.fr | 96 - docs/manual/programs/fcgistarter.html.fr.utf8 | 96 + docs/manual/programs/firehose.html.en | 4 +- docs/manual/programs/firehose.html.fr | 110 - docs/manual/programs/firehose.html.fr.utf8 | 110 + docs/manual/programs/htcacheclean.html.en | 8 +- docs/manual/programs/htcacheclean.html.fr | 262 - docs/manual/programs/htcacheclean.html.fr.utf8 | 262 + docs/manual/programs/htdbm.html.en | 8 +- docs/manual/programs/htdbm.html.fr | 398 -- docs/manual/programs/htdbm.html.fr.utf8 | 398 ++ docs/manual/programs/htdigest.html.en | 8 +- docs/manual/programs/htdigest.html.fr | 119 - docs/manual/programs/htdigest.html.fr.utf8 | 119 + docs/manual/programs/htpasswd.html.en | 8 +- docs/manual/programs/htpasswd.html.fr | 338 -- docs/manual/programs/htpasswd.html.fr.utf8 | 338 ++ docs/manual/programs/httpd.html.en | 8 +- docs/manual/programs/httpd.html.fr | 244 - docs/manual/programs/httpd.html.fr.utf8 | 244 + docs/manual/programs/httxt2dbm.html.en | 8 +- docs/manual/programs/httxt2dbm.html.fr | 122 - docs/manual/programs/httxt2dbm.html.fr.utf8 | 122 + docs/manual/programs/index.html | 2 +- docs/manual/programs/index.html.en | 12 +- docs/manual/programs/index.html.es | 136 - docs/manual/programs/index.html.es.utf8 | 136 + docs/manual/programs/index.html.fr | 137 - docs/manual/programs/index.html.fr.utf8 | 137 + docs/manual/programs/log_server_status.html.en | 4 +- docs/manual/programs/log_server_status.html.fr | 89 - .../manual/programs/log_server_status.html.fr.utf8 | 89 + docs/manual/programs/logresolve.html.en | 8 +- docs/manual/programs/logresolve.html.fr | 106 - docs/manual/programs/logresolve.html.fr.utf8 | 106 + docs/manual/programs/other.html.en | 8 +- docs/manual/programs/other.html.fr | 70 - docs/manual/programs/other.html.fr.utf8 | 70 + docs/manual/programs/rotatelogs.html.en | 8 +- docs/manual/programs/rotatelogs.html.fr | 307 -- docs/manual/programs/rotatelogs.html.fr.utf8 | 307 ++ docs/manual/programs/split-logfile.html.en | 4 +- docs/manual/programs/split-logfile.html.fr | 92 - docs/manual/programs/split-logfile.html.fr.utf8 | 92 + docs/manual/programs/suexec.html.en | 8 +- docs/manual/programs/suexec.html.fr | 96 - docs/manual/programs/suexec.html.fr.utf8 | 96 + docs/manual/rewrite/access.html.en | 4 +- docs/manual/rewrite/access.html.fr | 331 -- docs/manual/rewrite/access.html.fr.utf8 | 331 ++ docs/manual/rewrite/advanced.html.en | 4 +- docs/manual/rewrite/advanced.html.fr | 385 -- docs/manual/rewrite/advanced.html.fr.utf8 | 385 ++ docs/manual/rewrite/avoid.html.en | 4 +- docs/manual/rewrite/avoid.html.fr | 271 - docs/manual/rewrite/avoid.html.fr.utf8 | 271 + docs/manual/rewrite/flags.html.en | 4 +- docs/manual/rewrite/flags.html.fr | 853 --- docs/manual/rewrite/flags.html.fr.utf8 | 853 +++ docs/manual/rewrite/htaccess.html.en | 4 +- docs/manual/rewrite/htaccess.html.fr | 67 - docs/manual/rewrite/htaccess.html.fr.utf8 | 67 + docs/manual/rewrite/index.html.en | 8 +- docs/manual/rewrite/index.html.fr | 110 - docs/manual/rewrite/index.html.fr.utf8 | 110 + docs/manual/rewrite/intro.html.en | 4 +- docs/manual/rewrite/intro.html.fr | 389 -- docs/manual/rewrite/intro.html.fr.utf8 | 389 ++ docs/manual/rewrite/proxy.html.en | 4 +- docs/manual/rewrite/proxy.html.fr | 124 - docs/manual/rewrite/proxy.html.fr.utf8 | 124 + docs/manual/rewrite/remapping.html.en | 4 +- docs/manual/rewrite/remapping.html.fr | 677 --- docs/manual/rewrite/remapping.html.fr.utf8 | 677 +++ docs/manual/rewrite/rewritemap.html.en | 4 +- docs/manual/rewrite/rewritemap.html.fr | 512 -- docs/manual/rewrite/rewritemap.html.fr.utf8 | 512 ++ docs/manual/rewrite/tech.html.en | 4 +- docs/manual/rewrite/tech.html.fr | 223 - docs/manual/rewrite/tech.html.fr.utf8 | 223 + docs/manual/rewrite/vhosts.html.en | 4 +- docs/manual/rewrite/vhosts.html.fr | 244 - docs/manual/rewrite/vhosts.html.fr.utf8 | 244 + docs/manual/sections.html.en | 8 +- docs/manual/sections.html.fr | 676 --- docs/manual/sections.html.fr.utf8 | 676 +++ docs/manual/server-wide.html.en | 8 +- docs/manual/server-wide.html.fr | 144 - docs/manual/server-wide.html.fr.utf8 | 144 + docs/manual/sitemap.html | 2 +- docs/manual/sitemap.html.en | 12 +- docs/manual/sitemap.html.es | 391 -- docs/manual/sitemap.html.es.utf8 | 391 ++ docs/manual/sitemap.html.fr | 406 -- docs/manual/sitemap.html.fr.utf8 | 406 ++ docs/manual/socache.html.en | 4 +- docs/manual/socache.html.fr | 152 - docs/manual/socache.html.fr.utf8 | 152 + docs/manual/ssl/index.html | 2 +- docs/manual/ssl/index.html.en | 12 +- docs/manual/ssl/index.html.es | 74 - docs/manual/ssl/index.html.es.utf8 | 74 + docs/manual/ssl/index.html.fr | 75 - docs/manual/ssl/index.html.fr.utf8 | 75 + docs/manual/ssl/ssl_compat.html | 2 +- docs/manual/ssl/ssl_compat.html.en | 8 +- docs/manual/ssl/ssl_compat.html.es | 258 - docs/manual/ssl/ssl_compat.html.es.utf8 | 258 + docs/manual/ssl/ssl_compat.html.fr | 259 - docs/manual/ssl/ssl_compat.html.fr.utf8 | 259 + docs/manual/ssl/ssl_faq.html.en | 4 +- docs/manual/ssl/ssl_faq.html.fr | 1035 ---- docs/manual/ssl/ssl_faq.html.fr.utf8 | 1035 ++++ docs/manual/ssl/ssl_howto.html.en | 4 +- docs/manual/ssl/ssl_howto.html.fr | 540 -- docs/manual/ssl/ssl_howto.html.fr.utf8 | 540 ++ docs/manual/ssl/ssl_intro.html.en | 4 +- docs/manual/ssl/ssl_intro.html.fr | 727 --- docs/manual/ssl/ssl_intro.html.fr.utf8 | 727 +++ docs/manual/stopping.html | 2 +- docs/manual/stopping.html.en | 12 +- docs/manual/stopping.html.es | 299 -- docs/manual/stopping.html.es.utf8 | 299 ++ docs/manual/stopping.html.fr | 305 -- docs/manual/stopping.html.fr.utf8 | 305 ++ docs/manual/style/lang/es.xml | 2 +- docs/manual/style/lang/fr.xml | 2 +- docs/manual/suexec.html.en | 8 +- docs/manual/suexec.html.fr | 716 --- docs/manual/suexec.html.fr.utf8 | 716 +++ docs/manual/upgrading.html.en | 4 +- docs/manual/upgrading.html.fr | 591 -- docs/manual/upgrading.html.fr.utf8 | 591 ++ docs/manual/urlmapping.html.en | 8 +- docs/manual/urlmapping.html.fr | 402 -- docs/manual/urlmapping.html.fr.utf8 | 402 ++ docs/manual/vhosts/details.html.en | 8 +- docs/manual/vhosts/details.html.fr | 369 -- docs/manual/vhosts/details.html.fr.utf8 | 369 ++ docs/manual/vhosts/examples.html.en | 8 +- docs/manual/vhosts/examples.html.fr | 600 --- docs/manual/vhosts/examples.html.fr.utf8 | 600 +++ docs/manual/vhosts/fd-limits.html.en | 8 +- docs/manual/vhosts/fd-limits.html.fr | 167 - docs/manual/vhosts/fd-limits.html.fr.utf8 | 167 + docs/manual/vhosts/index.html.en | 8 +- docs/manual/vhosts/index.html.fr | 127 - docs/manual/vhosts/index.html.fr.utf8 | 127 + docs/manual/vhosts/ip-based.html.en | 8 +- docs/manual/vhosts/ip-based.html.fr | 213 - docs/manual/vhosts/ip-based.html.fr.utf8 | 213 + docs/manual/vhosts/mass.html.en | 8 +- docs/manual/vhosts/mass.html.fr | 364 -- docs/manual/vhosts/mass.html.fr.utf8 | 364 ++ docs/manual/vhosts/name-based.html.en | 8 +- docs/manual/vhosts/name-based.html.fr | 267 - docs/manual/vhosts/name-based.html.fr.utf8 | 267 + 885 files changed, 124689 insertions(+), 124572 deletions(-) delete mode 100644 docs/manual/bind.html.es create mode 100644 docs/manual/bind.html.es.utf8 delete mode 100644 docs/manual/bind.html.fr create mode 100644 docs/manual/bind.html.fr.utf8 delete mode 100644 docs/manual/caching.html.fr create mode 100644 docs/manual/caching.html.fr.utf8 delete mode 100644 docs/manual/compliance.html.fr create mode 100644 docs/manual/compliance.html.fr.utf8 delete mode 100644 docs/manual/configuring.html.fr create mode 100644 docs/manual/configuring.html.fr.utf8 delete mode 100644 docs/manual/content-negotiation.html.fr create mode 100644 docs/manual/content-negotiation.html.fr.utf8 delete mode 100644 docs/manual/custom-error.html.es create mode 100644 docs/manual/custom-error.html.es.utf8 delete mode 100644 docs/manual/custom-error.html.fr create mode 100644 docs/manual/custom-error.html.fr.utf8 delete mode 100644 docs/manual/dns-caveats.html.fr create mode 100644 docs/manual/dns-caveats.html.fr.utf8 delete mode 100644 docs/manual/dso.html.fr create mode 100644 docs/manual/dso.html.fr.utf8 delete mode 100644 docs/manual/env.html.fr create mode 100644 docs/manual/env.html.fr.utf8 delete mode 100644 docs/manual/expr.html.fr create mode 100644 docs/manual/expr.html.fr.utf8 delete mode 100644 docs/manual/faq/index.html.es create mode 100644 docs/manual/faq/index.html.es.utf8 delete mode 100644 docs/manual/faq/index.html.fr create mode 100644 docs/manual/faq/index.html.fr.utf8 delete mode 100644 docs/manual/filter.html.es create mode 100644 docs/manual/filter.html.es.utf8 delete mode 100644 docs/manual/filter.html.fr create mode 100644 docs/manual/filter.html.fr.utf8 delete mode 100644 docs/manual/getting-started.html.fr create mode 100644 docs/manual/getting-started.html.fr.utf8 delete mode 100644 docs/manual/glossary.html.es create mode 100644 docs/manual/glossary.html.es.utf8 delete mode 100644 docs/manual/glossary.html.fr create mode 100644 docs/manual/glossary.html.fr.utf8 delete mode 100644 docs/manual/handler.html.es create mode 100644 docs/manual/handler.html.es.utf8 delete mode 100644 docs/manual/handler.html.fr create mode 100644 docs/manual/handler.html.fr.utf8 delete mode 100644 docs/manual/howto/access.html.es create mode 100644 docs/manual/howto/access.html.es.utf8 delete mode 100644 docs/manual/howto/access.html.fr create mode 100644 docs/manual/howto/access.html.fr.utf8 delete mode 100644 docs/manual/howto/auth.html.es create mode 100644 docs/manual/howto/auth.html.es.utf8 delete mode 100644 docs/manual/howto/auth.html.fr create mode 100644 docs/manual/howto/auth.html.fr.utf8 delete mode 100644 docs/manual/howto/cgi.html.es create mode 100644 docs/manual/howto/cgi.html.es.utf8 delete mode 100644 docs/manual/howto/cgi.html.fr create mode 100644 docs/manual/howto/cgi.html.fr.utf8 delete mode 100644 docs/manual/howto/encrypt.html.es create mode 100644 docs/manual/howto/encrypt.html.es.utf8 delete mode 100644 docs/manual/howto/htaccess.html.es create mode 100644 docs/manual/howto/htaccess.html.es.utf8 delete mode 100644 docs/manual/howto/htaccess.html.fr create mode 100644 docs/manual/howto/htaccess.html.fr.utf8 delete mode 100644 docs/manual/howto/http2.html.es create mode 100644 docs/manual/howto/http2.html.es.utf8 delete mode 100644 docs/manual/howto/http2.html.fr create mode 100644 docs/manual/howto/http2.html.fr.utf8 delete mode 100644 docs/manual/howto/index.html.es create mode 100644 docs/manual/howto/index.html.es.utf8 delete mode 100644 docs/manual/howto/index.html.fr create mode 100644 docs/manual/howto/index.html.fr.utf8 delete mode 100644 docs/manual/howto/public_html.html.es create mode 100644 docs/manual/howto/public_html.html.es.utf8 delete mode 100644 docs/manual/howto/public_html.html.fr create mode 100644 docs/manual/howto/public_html.html.fr.utf8 delete mode 100644 docs/manual/howto/reverse_proxy.html.es create mode 100644 docs/manual/howto/reverse_proxy.html.es.utf8 delete mode 100644 docs/manual/howto/reverse_proxy.html.fr create mode 100644 docs/manual/howto/reverse_proxy.html.fr.utf8 delete mode 100644 docs/manual/howto/ssi.html.es create mode 100644 docs/manual/howto/ssi.html.es.utf8 delete mode 100644 docs/manual/howto/ssi.html.fr create mode 100644 docs/manual/howto/ssi.html.fr.utf8 delete mode 100644 docs/manual/index.html.es create mode 100644 docs/manual/index.html.es.utf8 delete mode 100644 docs/manual/index.html.fr create mode 100644 docs/manual/index.html.fr.utf8 delete mode 100644 docs/manual/install.html.es create mode 100644 docs/manual/install.html.es.utf8 delete mode 100644 docs/manual/install.html.fr create mode 100644 docs/manual/install.html.fr.utf8 delete mode 100644 docs/manual/invoking.html.es create mode 100644 docs/manual/invoking.html.es.utf8 delete mode 100644 docs/manual/invoking.html.fr create mode 100644 docs/manual/invoking.html.fr.utf8 delete mode 100644 docs/manual/logs.html.fr create mode 100644 docs/manual/logs.html.fr.utf8 delete mode 100644 docs/manual/misc/index.html.es create mode 100644 docs/manual/misc/index.html.es.utf8 delete mode 100644 docs/manual/misc/index.html.fr create mode 100644 docs/manual/misc/index.html.fr.utf8 delete mode 100644 docs/manual/misc/password_encryptions.html.es create mode 100644 docs/manual/misc/password_encryptions.html.es.utf8 delete mode 100644 docs/manual/misc/password_encryptions.html.fr create mode 100644 docs/manual/misc/password_encryptions.html.fr.utf8 delete mode 100644 docs/manual/misc/perf-scaling.html.es create mode 100644 docs/manual/misc/perf-scaling.html.es.utf8 delete mode 100644 docs/manual/misc/perf-scaling.html.fr create mode 100644 docs/manual/misc/perf-scaling.html.fr.utf8 delete mode 100644 docs/manual/misc/perf-tuning.html.fr create mode 100644 docs/manual/misc/perf-tuning.html.fr.utf8 delete mode 100644 docs/manual/misc/relevant_standards.html.fr create mode 100644 docs/manual/misc/relevant_standards.html.fr.utf8 delete mode 100644 docs/manual/misc/security_tips.html.es create mode 100644 docs/manual/misc/security_tips.html.es.utf8 delete mode 100644 docs/manual/misc/security_tips.html.fr create mode 100644 docs/manual/misc/security_tips.html.fr.utf8 delete mode 100644 docs/manual/mod/core.html.es create mode 100644 docs/manual/mod/core.html.es.utf8 delete mode 100644 docs/manual/mod/core.html.fr create mode 100644 docs/manual/mod/core.html.fr.utf8 delete mode 100644 docs/manual/mod/directive-dict.html.es create mode 100644 docs/manual/mod/directive-dict.html.es.utf8 delete mode 100644 docs/manual/mod/directive-dict.html.fr create mode 100644 docs/manual/mod/directive-dict.html.fr.utf8 delete mode 100644 docs/manual/mod/directives.html.es create mode 100644 docs/manual/mod/directives.html.es.utf8 delete mode 100644 docs/manual/mod/directives.html.fr create mode 100644 docs/manual/mod/directives.html.fr.utf8 delete mode 100644 docs/manual/mod/event.html.es create mode 100644 docs/manual/mod/event.html.es.utf8 delete mode 100644 docs/manual/mod/event.html.fr create mode 100644 docs/manual/mod/event.html.fr.utf8 delete mode 100644 docs/manual/mod/index.html.es create mode 100644 docs/manual/mod/index.html.es.utf8 delete mode 100644 docs/manual/mod/index.html.fr create mode 100644 docs/manual/mod/index.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_access_compat.html.es create mode 100644 docs/manual/mod/mod_access_compat.html.es.utf8 delete mode 100644 docs/manual/mod/mod_access_compat.html.fr create mode 100644 docs/manual/mod/mod_access_compat.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_actions.html.es create mode 100644 docs/manual/mod/mod_actions.html.es.utf8 delete mode 100644 docs/manual/mod/mod_actions.html.fr create mode 100644 docs/manual/mod/mod_actions.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_alias.html.es create mode 100644 docs/manual/mod/mod_alias.html.es.utf8 delete mode 100644 docs/manual/mod/mod_alias.html.fr create mode 100644 docs/manual/mod/mod_alias.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_allowhandlers.html.es create mode 100644 docs/manual/mod/mod_allowhandlers.html.es.utf8 delete mode 100644 docs/manual/mod/mod_allowhandlers.html.fr create mode 100644 docs/manual/mod/mod_allowhandlers.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_allowmethods.html.es create mode 100644 docs/manual/mod/mod_allowmethods.html.es.utf8 delete mode 100644 docs/manual/mod/mod_allowmethods.html.fr create mode 100644 docs/manual/mod/mod_allowmethods.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_asis.html.es create mode 100644 docs/manual/mod/mod_asis.html.es.utf8 delete mode 100644 docs/manual/mod/mod_asis.html.fr create mode 100644 docs/manual/mod/mod_asis.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_auth_basic.html.es create mode 100644 docs/manual/mod/mod_auth_basic.html.es.utf8 delete mode 100644 docs/manual/mod/mod_auth_basic.html.fr create mode 100644 docs/manual/mod/mod_auth_basic.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_auth_digest.html.fr create mode 100644 docs/manual/mod/mod_auth_digest.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_auth_form.html.fr create mode 100644 docs/manual/mod/mod_auth_form.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_authn_anon.html.fr create mode 100644 docs/manual/mod/mod_authn_anon.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_authn_core.html.fr create mode 100644 docs/manual/mod/mod_authn_core.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_authn_dbd.html.fr create mode 100644 docs/manual/mod/mod_authn_dbd.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_authn_dbm.html.fr create mode 100644 docs/manual/mod/mod_authn_dbm.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_authn_file.html.fr create mode 100644 docs/manual/mod/mod_authn_file.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_authn_socache.html.fr create mode 100644 docs/manual/mod/mod_authn_socache.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_authnz_fcgi.html.fr create mode 100644 docs/manual/mod/mod_authnz_fcgi.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_authnz_ldap.html.fr create mode 100644 docs/manual/mod/mod_authnz_ldap.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_authz_core.html.fr create mode 100644 docs/manual/mod/mod_authz_core.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_authz_dbd.html.fr create mode 100644 docs/manual/mod/mod_authz_dbd.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_authz_dbm.html.fr create mode 100644 docs/manual/mod/mod_authz_dbm.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_authz_groupfile.html.fr create mode 100644 docs/manual/mod/mod_authz_groupfile.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_authz_host.html.fr create mode 100644 docs/manual/mod/mod_authz_host.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_authz_owner.html.fr create mode 100644 docs/manual/mod/mod_authz_owner.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_authz_user.html.fr create mode 100644 docs/manual/mod/mod_authz_user.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_autoindex.html.fr create mode 100644 docs/manual/mod/mod_autoindex.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_brotli.html.fr create mode 100644 docs/manual/mod/mod_brotli.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_buffer.html.fr create mode 100644 docs/manual/mod/mod_buffer.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_cache.html.fr create mode 100644 docs/manual/mod/mod_cache.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_cache_disk.html.fr create mode 100644 docs/manual/mod/mod_cache_disk.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_cache_socache.html.fr create mode 100644 docs/manual/mod/mod_cache_socache.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_cern_meta.html.fr create mode 100644 docs/manual/mod/mod_cern_meta.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_cgi.html.fr create mode 100644 docs/manual/mod/mod_cgi.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_cgid.html.fr create mode 100644 docs/manual/mod/mod_cgid.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_charset_lite.html.fr create mode 100644 docs/manual/mod/mod_charset_lite.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_crypto.html.fr create mode 100644 docs/manual/mod/mod_crypto.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_data.html.fr create mode 100644 docs/manual/mod/mod_data.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_dav.html.fr create mode 100644 docs/manual/mod/mod_dav.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_dav_fs.html.fr create mode 100644 docs/manual/mod/mod_dav_fs.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_dav_lock.html.fr create mode 100644 docs/manual/mod/mod_dav_lock.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_dbd.html.fr create mode 100644 docs/manual/mod/mod_dbd.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_deflate.html.fr create mode 100644 docs/manual/mod/mod_deflate.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_dialup.html.fr create mode 100644 docs/manual/mod/mod_dialup.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_dir.html.fr create mode 100644 docs/manual/mod/mod_dir.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_dumpio.html.fr create mode 100644 docs/manual/mod/mod_dumpio.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_echo.html.fr create mode 100644 docs/manual/mod/mod_echo.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_env.html.fr create mode 100644 docs/manual/mod/mod_env.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_example_hooks.html.fr create mode 100644 docs/manual/mod/mod_example_hooks.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_expires.html.fr create mode 100644 docs/manual/mod/mod_expires.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_ext_filter.html.fr create mode 100644 docs/manual/mod/mod_ext_filter.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_file_cache.html.fr create mode 100644 docs/manual/mod/mod_file_cache.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_filter.html.fr create mode 100644 docs/manual/mod/mod_filter.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_firehose.html.fr create mode 100644 docs/manual/mod/mod_firehose.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_headers.html.fr create mode 100644 docs/manual/mod/mod_headers.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_heartbeat.html.fr create mode 100644 docs/manual/mod/mod_heartbeat.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_heartmonitor.html.fr create mode 100644 docs/manual/mod/mod_heartmonitor.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_http2.html.fr create mode 100644 docs/manual/mod/mod_http2.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_ident.html.fr create mode 100644 docs/manual/mod/mod_ident.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_imagemap.html.fr create mode 100644 docs/manual/mod/mod_imagemap.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_include.html.fr create mode 100644 docs/manual/mod/mod_include.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_info.html.fr create mode 100644 docs/manual/mod/mod_info.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_isapi.html.fr create mode 100644 docs/manual/mod/mod_isapi.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_journald.html.fr create mode 100644 docs/manual/mod/mod_journald.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_lbmethod_bybusyness.html.fr create mode 100644 docs/manual/mod/mod_lbmethod_bybusyness.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_lbmethod_byrequests.html.fr create mode 100644 docs/manual/mod/mod_lbmethod_byrequests.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_lbmethod_bytraffic.html.fr create mode 100644 docs/manual/mod/mod_lbmethod_bytraffic.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_lbmethod_heartbeat.html.fr create mode 100644 docs/manual/mod/mod_lbmethod_heartbeat.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_ldap.html.fr create mode 100644 docs/manual/mod/mod_ldap.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_log_config.html.fr create mode 100644 docs/manual/mod/mod_log_config.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_log_debug.html.fr create mode 100644 docs/manual/mod/mod_log_debug.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_log_forensic.html.fr create mode 100644 docs/manual/mod/mod_log_forensic.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_logio.html.fr create mode 100644 docs/manual/mod/mod_logio.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_lua.html.fr create mode 100644 docs/manual/mod/mod_lua.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_macro.html.fr create mode 100644 docs/manual/mod/mod_macro.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_mime.html.fr create mode 100644 docs/manual/mod/mod_mime.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_mime_magic.html.fr create mode 100644 docs/manual/mod/mod_mime_magic.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_negotiation.html.fr create mode 100644 docs/manual/mod/mod_negotiation.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_nw_ssl.html.fr create mode 100644 docs/manual/mod/mod_nw_ssl.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_policy.html.fr create mode 100644 docs/manual/mod/mod_policy.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_privileges.html.fr create mode 100644 docs/manual/mod/mod_privileges.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_proxy.html.fr create mode 100644 docs/manual/mod/mod_proxy.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_proxy_ajp.html.fr create mode 100644 docs/manual/mod/mod_proxy_ajp.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_proxy_balancer.html.fr create mode 100644 docs/manual/mod/mod_proxy_balancer.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_proxy_connect.html.fr create mode 100644 docs/manual/mod/mod_proxy_connect.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_proxy_express.html.fr create mode 100644 docs/manual/mod/mod_proxy_express.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_proxy_fcgi.html.fr create mode 100644 docs/manual/mod/mod_proxy_fcgi.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_proxy_fdpass.html.fr create mode 100644 docs/manual/mod/mod_proxy_fdpass.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_proxy_ftp.html.fr create mode 100644 docs/manual/mod/mod_proxy_ftp.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_proxy_hcheck.html.fr create mode 100644 docs/manual/mod/mod_proxy_hcheck.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_proxy_html.html.fr create mode 100644 docs/manual/mod/mod_proxy_html.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_proxy_http.html.fr create mode 100644 docs/manual/mod/mod_proxy_http.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_proxy_http2.html.fr create mode 100644 docs/manual/mod/mod_proxy_http2.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_proxy_scgi.html.fr create mode 100644 docs/manual/mod/mod_proxy_scgi.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_proxy_wstunnel.html.fr create mode 100644 docs/manual/mod/mod_proxy_wstunnel.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_ratelimit.html.fr create mode 100644 docs/manual/mod/mod_ratelimit.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_reflector.html.fr create mode 100644 docs/manual/mod/mod_reflector.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_remoteip.html.fr create mode 100644 docs/manual/mod/mod_remoteip.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_reqtimeout.html.fr create mode 100644 docs/manual/mod/mod_reqtimeout.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_request.html.fr create mode 100644 docs/manual/mod/mod_request.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_rewrite.html.fr create mode 100644 docs/manual/mod/mod_rewrite.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_sed.html.fr create mode 100644 docs/manual/mod/mod_sed.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_session.html.fr create mode 100644 docs/manual/mod/mod_session.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_session_cookie.html.fr create mode 100644 docs/manual/mod/mod_session_cookie.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_session_crypto.html.fr create mode 100644 docs/manual/mod/mod_session_crypto.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_session_dbd.html.fr create mode 100644 docs/manual/mod/mod_session_dbd.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_setenvif.html.fr create mode 100644 docs/manual/mod/mod_setenvif.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_slotmem_plain.html.fr create mode 100644 docs/manual/mod/mod_slotmem_plain.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_slotmem_shm.html.fr create mode 100644 docs/manual/mod/mod_slotmem_shm.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_so.html.fr create mode 100644 docs/manual/mod/mod_so.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_socache_dbm.html.fr create mode 100644 docs/manual/mod/mod_socache_dbm.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_socache_dc.html.fr create mode 100644 docs/manual/mod/mod_socache_dc.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_socache_memcache.html.fr create mode 100644 docs/manual/mod/mod_socache_memcache.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_socache_shmcb.html.fr create mode 100644 docs/manual/mod/mod_socache_shmcb.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_speling.html.fr create mode 100644 docs/manual/mod/mod_speling.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_ssl.html.es create mode 100644 docs/manual/mod/mod_ssl.html.es.utf8 delete mode 100644 docs/manual/mod/mod_ssl.html.fr create mode 100644 docs/manual/mod/mod_ssl.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_ssl_ct.html.fr create mode 100644 docs/manual/mod/mod_ssl_ct.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_status.html.es create mode 100644 docs/manual/mod/mod_status.html.es.utf8 delete mode 100644 docs/manual/mod/mod_status.html.fr create mode 100644 docs/manual/mod/mod_status.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_substitute.html.fr create mode 100644 docs/manual/mod/mod_substitute.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_suexec.html.fr create mode 100644 docs/manual/mod/mod_suexec.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_syslog.html.fr create mode 100644 docs/manual/mod/mod_syslog.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_systemd.html.fr create mode 100644 docs/manual/mod/mod_systemd.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_unique_id.html.fr create mode 100644 docs/manual/mod/mod_unique_id.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_unixd.html.fr create mode 100644 docs/manual/mod/mod_unixd.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_userdir.html.fr create mode 100644 docs/manual/mod/mod_userdir.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_usertrack.html.fr create mode 100644 docs/manual/mod/mod_usertrack.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_version.html.fr create mode 100644 docs/manual/mod/mod_version.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_vhost_alias.html.fr create mode 100644 docs/manual/mod/mod_vhost_alias.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_watchdog.html.fr create mode 100644 docs/manual/mod/mod_watchdog.html.fr.utf8 delete mode 100644 docs/manual/mod/mod_xml2enc.html.fr create mode 100644 docs/manual/mod/mod_xml2enc.html.fr.utf8 delete mode 100644 docs/manual/mod/module-dict.html.fr create mode 100644 docs/manual/mod/module-dict.html.fr.utf8 delete mode 100644 docs/manual/mod/mpm_common.html.fr create mode 100644 docs/manual/mod/mpm_common.html.fr.utf8 delete mode 100644 docs/manual/mod/mpm_netware.html.fr create mode 100644 docs/manual/mod/mpm_netware.html.fr.utf8 delete mode 100644 docs/manual/mod/mpm_winnt.html.fr create mode 100644 docs/manual/mod/mpm_winnt.html.fr.utf8 delete mode 100644 docs/manual/mod/mpmt_os2.html.fr create mode 100644 docs/manual/mod/mpmt_os2.html.fr.utf8 delete mode 100644 docs/manual/mod/prefork.html.fr create mode 100644 docs/manual/mod/prefork.html.fr.utf8 delete mode 100644 docs/manual/mod/quickreference.html.es create mode 100644 docs/manual/mod/quickreference.html.es.utf8 delete mode 100644 docs/manual/mod/quickreference.html.fr create mode 100644 docs/manual/mod/quickreference.html.fr.utf8 delete mode 100644 docs/manual/mod/worker.html.fr create mode 100644 docs/manual/mod/worker.html.fr.utf8 delete mode 100644 docs/manual/mpm.html.es create mode 100644 docs/manual/mpm.html.es.utf8 delete mode 100644 docs/manual/mpm.html.fr create mode 100644 docs/manual/mpm.html.fr.utf8 delete mode 100644 docs/manual/new_features_2_0.html.fr create mode 100644 docs/manual/new_features_2_0.html.fr.utf8 delete mode 100644 docs/manual/new_features_2_2.html.es create mode 100644 docs/manual/new_features_2_2.html.es.utf8 delete mode 100644 docs/manual/new_features_2_2.html.fr create mode 100644 docs/manual/new_features_2_2.html.fr.utf8 delete mode 100644 docs/manual/new_features_2_4.html.es create mode 100644 docs/manual/new_features_2_4.html.es.utf8 delete mode 100644 docs/manual/new_features_2_4.html.fr create mode 100644 docs/manual/new_features_2_4.html.fr.utf8 delete mode 100644 docs/manual/platform/index.html.fr create mode 100644 docs/manual/platform/index.html.fr.utf8 delete mode 100644 docs/manual/platform/netware.html.fr create mode 100644 docs/manual/platform/netware.html.fr.utf8 delete mode 100644 docs/manual/platform/perf-hp.html.fr create mode 100644 docs/manual/platform/perf-hp.html.fr.utf8 delete mode 100644 docs/manual/platform/rpm.html.fr create mode 100644 docs/manual/platform/rpm.html.fr.utf8 delete mode 100644 docs/manual/platform/win_compiling.html.fr create mode 100644 docs/manual/platform/win_compiling.html.fr.utf8 delete mode 100644 docs/manual/platform/windows.html.fr create mode 100644 docs/manual/platform/windows.html.fr.utf8 delete mode 100644 docs/manual/programs/ab.html.fr create mode 100644 docs/manual/programs/ab.html.fr.utf8 delete mode 100644 docs/manual/programs/apachectl.html.fr create mode 100644 docs/manual/programs/apachectl.html.fr.utf8 delete mode 100644 docs/manual/programs/apxs.html.fr create mode 100644 docs/manual/programs/apxs.html.fr.utf8 delete mode 100644 docs/manual/programs/configure.html.fr create mode 100644 docs/manual/programs/configure.html.fr.utf8 delete mode 100644 docs/manual/programs/ctlogconfig.html.fr create mode 100644 docs/manual/programs/ctlogconfig.html.fr.utf8 delete mode 100644 docs/manual/programs/dbmmanage.html.fr create mode 100644 docs/manual/programs/dbmmanage.html.fr.utf8 delete mode 100644 docs/manual/programs/fcgistarter.html.fr create mode 100644 docs/manual/programs/fcgistarter.html.fr.utf8 delete mode 100644 docs/manual/programs/firehose.html.fr create mode 100644 docs/manual/programs/firehose.html.fr.utf8 delete mode 100644 docs/manual/programs/htcacheclean.html.fr create mode 100644 docs/manual/programs/htcacheclean.html.fr.utf8 delete mode 100644 docs/manual/programs/htdbm.html.fr create mode 100644 docs/manual/programs/htdbm.html.fr.utf8 delete mode 100644 docs/manual/programs/htdigest.html.fr create mode 100644 docs/manual/programs/htdigest.html.fr.utf8 delete mode 100644 docs/manual/programs/htpasswd.html.fr create mode 100644 docs/manual/programs/htpasswd.html.fr.utf8 delete mode 100644 docs/manual/programs/httpd.html.fr create mode 100644 docs/manual/programs/httpd.html.fr.utf8 delete mode 100644 docs/manual/programs/httxt2dbm.html.fr create mode 100644 docs/manual/programs/httxt2dbm.html.fr.utf8 delete mode 100644 docs/manual/programs/index.html.es create mode 100644 docs/manual/programs/index.html.es.utf8 delete mode 100644 docs/manual/programs/index.html.fr create mode 100644 docs/manual/programs/index.html.fr.utf8 delete mode 100644 docs/manual/programs/log_server_status.html.fr create mode 100644 docs/manual/programs/log_server_status.html.fr.utf8 delete mode 100644 docs/manual/programs/logresolve.html.fr create mode 100644 docs/manual/programs/logresolve.html.fr.utf8 delete mode 100644 docs/manual/programs/other.html.fr create mode 100644 docs/manual/programs/other.html.fr.utf8 delete mode 100644 docs/manual/programs/rotatelogs.html.fr create mode 100644 docs/manual/programs/rotatelogs.html.fr.utf8 delete mode 100644 docs/manual/programs/split-logfile.html.fr create mode 100644 docs/manual/programs/split-logfile.html.fr.utf8 delete mode 100644 docs/manual/programs/suexec.html.fr create mode 100644 docs/manual/programs/suexec.html.fr.utf8 delete mode 100644 docs/manual/rewrite/access.html.fr create mode 100644 docs/manual/rewrite/access.html.fr.utf8 delete mode 100644 docs/manual/rewrite/advanced.html.fr create mode 100644 docs/manual/rewrite/advanced.html.fr.utf8 delete mode 100644 docs/manual/rewrite/avoid.html.fr create mode 100644 docs/manual/rewrite/avoid.html.fr.utf8 delete mode 100644 docs/manual/rewrite/flags.html.fr create mode 100644 docs/manual/rewrite/flags.html.fr.utf8 delete mode 100644 docs/manual/rewrite/htaccess.html.fr create mode 100644 docs/manual/rewrite/htaccess.html.fr.utf8 delete mode 100644 docs/manual/rewrite/index.html.fr create mode 100644 docs/manual/rewrite/index.html.fr.utf8 delete mode 100644 docs/manual/rewrite/intro.html.fr create mode 100644 docs/manual/rewrite/intro.html.fr.utf8 delete mode 100644 docs/manual/rewrite/proxy.html.fr create mode 100644 docs/manual/rewrite/proxy.html.fr.utf8 delete mode 100644 docs/manual/rewrite/remapping.html.fr create mode 100644 docs/manual/rewrite/remapping.html.fr.utf8 delete mode 100644 docs/manual/rewrite/rewritemap.html.fr create mode 100644 docs/manual/rewrite/rewritemap.html.fr.utf8 delete mode 100644 docs/manual/rewrite/tech.html.fr create mode 100644 docs/manual/rewrite/tech.html.fr.utf8 delete mode 100644 docs/manual/rewrite/vhosts.html.fr create mode 100644 docs/manual/rewrite/vhosts.html.fr.utf8 delete mode 100644 docs/manual/sections.html.fr create mode 100644 docs/manual/sections.html.fr.utf8 delete mode 100644 docs/manual/server-wide.html.fr create mode 100644 docs/manual/server-wide.html.fr.utf8 delete mode 100644 docs/manual/sitemap.html.es create mode 100644 docs/manual/sitemap.html.es.utf8 delete mode 100644 docs/manual/sitemap.html.fr create mode 100644 docs/manual/sitemap.html.fr.utf8 delete mode 100644 docs/manual/socache.html.fr create mode 100644 docs/manual/socache.html.fr.utf8 delete mode 100644 docs/manual/ssl/index.html.es create mode 100644 docs/manual/ssl/index.html.es.utf8 delete mode 100644 docs/manual/ssl/index.html.fr create mode 100644 docs/manual/ssl/index.html.fr.utf8 delete mode 100644 docs/manual/ssl/ssl_compat.html.es create mode 100644 docs/manual/ssl/ssl_compat.html.es.utf8 delete mode 100644 docs/manual/ssl/ssl_compat.html.fr create mode 100644 docs/manual/ssl/ssl_compat.html.fr.utf8 delete mode 100644 docs/manual/ssl/ssl_faq.html.fr create mode 100644 docs/manual/ssl/ssl_faq.html.fr.utf8 delete mode 100644 docs/manual/ssl/ssl_howto.html.fr create mode 100644 docs/manual/ssl/ssl_howto.html.fr.utf8 delete mode 100644 docs/manual/ssl/ssl_intro.html.fr create mode 100644 docs/manual/ssl/ssl_intro.html.fr.utf8 delete mode 100644 docs/manual/stopping.html.es create mode 100644 docs/manual/stopping.html.es.utf8 delete mode 100644 docs/manual/stopping.html.fr create mode 100644 docs/manual/stopping.html.fr.utf8 delete mode 100644 docs/manual/suexec.html.fr create mode 100644 docs/manual/suexec.html.fr.utf8 delete mode 100644 docs/manual/upgrading.html.fr create mode 100644 docs/manual/upgrading.html.fr.utf8 delete mode 100644 docs/manual/urlmapping.html.fr create mode 100644 docs/manual/urlmapping.html.fr.utf8 delete mode 100644 docs/manual/vhosts/details.html.fr create mode 100644 docs/manual/vhosts/details.html.fr.utf8 delete mode 100644 docs/manual/vhosts/examples.html.fr create mode 100644 docs/manual/vhosts/examples.html.fr.utf8 delete mode 100644 docs/manual/vhosts/fd-limits.html.fr create mode 100644 docs/manual/vhosts/fd-limits.html.fr.utf8 delete mode 100644 docs/manual/vhosts/index.html.fr create mode 100644 docs/manual/vhosts/index.html.fr.utf8 delete mode 100644 docs/manual/vhosts/ip-based.html.fr create mode 100644 docs/manual/vhosts/ip-based.html.fr.utf8 delete mode 100644 docs/manual/vhosts/mass.html.fr create mode 100644 docs/manual/vhosts/mass.html.fr.utf8 delete mode 100644 docs/manual/vhosts/name-based.html.fr create mode 100644 docs/manual/vhosts/name-based.html.fr.utf8 diff --git a/docs/manual/bind.html b/docs/manual/bind.html index 73982d6aee..7984501abf 100644 --- a/docs/manual/bind.html +++ b/docs/manual/bind.html @@ -10,7 +10,7 @@ Content-type: text/html; charset=ISO-8859-1 URI: bind.html.es Content-Language: es -Content-type: text/html; charset=ISO-8859-1 +Content-type: text/html; charset=UTF-8 URI: bind.html.fr Content-Language: fr diff --git a/docs/manual/bind.html.en b/docs/manual/bind.html.en index c4fd943c72..33630f43b8 100644 --- a/docs/manual/bind.html.en +++ b/docs/manual/bind.html.en @@ -25,11 +25,11 @@

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

+ tr 

Configuring Apache HTTP Server to listen on specific addresses and ports.

@@ -216,11 +216,11 @@ Listen 192.0.2.1:80

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

+ tr 

top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
- - -
-

Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

-

Versin 2.5 del Servidor HTTP Apache

-
-
<-
-

Mapeo de Direcciones y Puertos.

-
-

Idiomas disponibles:  de  | - en  | - es  | - fr  | - ja  | - ko  | - tr 

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

Configurando Apache HTTP Server para que escuche en una direccin y puertos especficos.

-
- -
top
-
-

Visin General

- - -
Mdulos RelacionadosDirectivas Relacionadas
- - -

Cuando httpd se ejecuta, se mapea a una direccin y un puerto en la - mquina local, y espera a recibir peticiones. Por defecto, escucha en - todas las direcciones de la mquina. Ahora bien, se le puede especificar - que escuche en un determinado puerto, o en una sola direccin IP especifica, - o una combinacin de ambos. A menudo esto se combina con la caracterstica - de los Hosts virtuales, que determina como responde el - httpd a diferentes direcciones IP, nombres de mquinas y puertos.

- -

La directiva Listen - le dice al servidor que acepte peticiones en el puerto o puertos que - se le especifiquen al servidor, o a combinaciones de direcciones y - puertos. Si slo se especifica el nmero del puerto en la directiva - Listen, el servidor escuchar en - ese puerto pero en todas las interfaces de red. - Si adems del puerto se le especifica una direccin IP, el servidor escuchar - en el puerto y en la interfaz de red asociado a la direccin IP - que se le ha especificado en la directiva. Se pueden especificar - mltiples directivas Listen para - especificar un determinado nmero de IPs y puertos por donde el servidor escuchar. - El servidor por tanto, responder a las peticiones en cualquiera de las IPs y puertos - listados en la directiva.

- -

Por ejemplo, para hacer que el servidor escuche en ambos puertos 80 y 8080 en todas - sus interfaces de red, se usa lo siguiente:

- - 
Listen 80
-Listen 8000
-
- -

Para hacer que el servidor acepte peticiones en el puerto 80 en una sola interfaz de red, usaremos:

- - 
Listen 192.0.2.1:80
-Listen 192.0.2.5:8000
-
- -

Las direcciones IPv6 debrn ir entre '[ ]' corchetes como en el siguiente ejemplo:

- - 
Listen [2001:db8::a00:20ff:fea7:ccea]:80
-
- -

Si se superponen directivas de tipo Listen, dar como resultado un error fatal - que impedir que se inicie el servidor.

- -

- (48)Address already in use: make_sock: could not bind to address [::]:80 -

- -

Puede mirar el articulo de la wiki - de consejos para solucionar problemas relacionados.

- -
- -
top
-
-

Consideraciones especiales con IPv6

- - -

Un creciente nmero de plataformas implementan ya IPv6, y - APR soporta IPv6 en la mayora de estas plataformas, - permitiendo as a httpd asignar sockets IPv6, y manejar las respuestas - enviadas a travs de IPv6.

- -

Un factor bastante complejo para un administrador del httpd - es si un socket IPv6 puede o no manejar tanto conexiones IPv6 - como IPv4. El manejo por httpd de conexiones IPv4 con socket IPv6 - se debe al mapeo de direcciones IPv4 sobre IPv6, que - est permitido por defecto en muchas plataformas, pero no lo est - en sistemas FreeBSD, NetBSD y Open BSD, con el fin de que en estas - plataformas, cumpla con la poltica del sistema. - En los sistemas que no est permitido el mapeo por defecto, - existe un parmetro de configure especial - para cambiar ste comportamiento para httpd.

- -

Por otro lado, en algunas plataformas, como Linux y True64, la - nica forma para el manejo de IPv4 e IPv6 al mismo - tiempo es mediante direcciones mapeadas. - Si quieres que httpd maneje amos tipos de conexiones IPv4 e IPv6 - con el mnimo de sockets, hay que especificar la opcin - --enable-v4-mapped al configure.

- -

--enable-v4-mapped es la opcin que est estipulada por defecto - en todos los sistemas menos en FreeBSD, NetBSD y Open BSD, por - lo que es probablemente como se compil su httpd.

- -

Si lo que quiere es manejar slo conexiones IPv4, independientemente de - lo que soporten APR y su plataforma, especifique - una direccin IPv4 por cada directiva - Listen, como en el siguiente - ejemplo:

- - 
Listen 0.0.0.0:80
-Listen 192.0.2.1:80
-
- -

Si en cambio, su plataforma lo soporta, y lo que quiere es que su httpd - soporte tanto conexiones IPv4 como IPv6 en diferentes sockets (ejemplo.: para - deshabilitar mapeo de direcciones IPv4), especifique la opcin - --disable-v4-mapped al configure. --disable-v4-mapped es la opcin por defecto - en FreeBSD, NetBSD y OpenBSD.

-
top
-
-

Especificar el Protocolo en el Listen

- -

El segundo argumento en la directiva Listen - el protocolo que es opcional no es algo que se requiera en las configuraciones. - Si ste argumento no se especifica, https es el protocolo - usado por defecto en el puerto 443 y http para el resto. - El protocolo se utiliza para determinar que mdulo deber manejar la peticin, - y se le aplicarn optimizaciones especficas del protocolo con la directiva - AcceptFilter.

- -

Slo necesitar especificar el protocolo si no est escuchando en un puerto - de los que son estndares, por ejemplo si ejecuta un sitio web https en el puerto 8443:

- - 
Listen 192.170.2.1:8443 https
-
-
top
-
-

Como Funciona en los Hosts Virtuales

- - -

La directiva Listen no implementa los - Hosts Virtuales - solo le dice al servidor en que direcciones - y puertos debe escuchar. Si no hay directiva - <VirtualHost> - en uso, el servidor se comportar de la misma manera para todas las - peticiones aceptadas. Ahora bien, - <VirtualHost> - puede ser usado para especificar un comportamiento diferente en una o - varias direcciones o puertos. - Para implementar los Hosts Virtuales, antes se le tiene que decir al servidor - que direcciones y puertos van a ser usados. - Despus de esto, se deber especificar una seccin de la directiva - <VirtualHost> - especificando direcciones y puertos que se van a usar en el Host Virtual - Note que si se configura un - <VirtualHost> - para una direccin y puerto en el que el servidor no est escuchando, - no se podr acceder al Host Virtual.

-
-
-

Idiomas disponibles:  de  | - en  | - es  | - fr  | - ja  | - ko  | - tr 

-
top

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
-
- \ No newline at end of file diff --git a/docs/manual/bind.html.es.utf8 b/docs/manual/bind.html.es.utf8 new file mode 100644 index 0000000000..eb9045844e --- /dev/null +++ b/docs/manual/bind.html.es.utf8 @@ -0,0 +1,226 @@ + + + + + +Mapeo de Direcciones y Puertos. - Servidor HTTP Apache Versin 2.5 + + + + + + +
+

Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

+

Versin 2.5 del Servidor HTTP Apache

+
+
<-
+

Mapeo de Direcciones y Puertos.

+
+

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

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

Configurando Apache HTTP Server para que escuche en una direccin y puertos especficos.

+
+ +
top
+
+

Visin General

+ + +
Mdulos RelacionadosDirectivas Relacionadas
+ + +

Cuando httpd se ejecuta, se mapea a una direccin y un puerto en la + mquina local, y espera a recibir peticiones. Por defecto, escucha en + todas las direcciones de la mquina. Ahora bien, se le puede especificar + que escuche en un determinado puerto, o en una sola direccin IP especifica, + o una combinacin de ambos. A menudo esto se combina con la caracterstica + de los Hosts virtuales, que determina como responde el + httpd a diferentes direcciones IP, nombres de mquinas y puertos.

+ +

La directiva Listen + le dice al servidor que acepte peticiones en el puerto o puertos que + se le especifiquen al servidor, o a combinaciones de direcciones y + puertos. Si slo se especifica el nmero del puerto en la directiva + Listen, el servidor escuchar en + ese puerto pero en todas las interfaces de red. + Si adems del puerto se le especifica una direccin IP, el servidor escuchar + en el puerto y en la interfaz de red asociado a la direccin IP + que se le ha especificado en la directiva. Se pueden especificar + mltiples directivas Listen para + especificar un determinado nmero de IPs y puertos por donde el servidor escuchar. + El servidor por tanto, responder a las peticiones en cualquiera de las IPs y puertos + listados en la directiva.

+ +

Por ejemplo, para hacer que el servidor escuche en ambos puertos 80 y 8080 en todas + sus interfaces de red, se usa lo siguiente:

+ + 
Listen 80
+Listen 8000
+
+ +

Para hacer que el servidor acepte peticiones en el puerto 80 en una sola interfaz de red, usaremos:

+ + 
Listen 192.0.2.1:80
+Listen 192.0.2.5:8000
+
+ +

Las direcciones IPv6 debrn ir entre '[ ]' corchetes como en el siguiente ejemplo:

+ + 
Listen [2001:db8::a00:20ff:fea7:ccea]:80
+
+ +

Si se superponen directivas de tipo Listen, dar como resultado un error fatal + que impedir que se inicie el servidor.

+ +

+ (48)Address already in use: make_sock: could not bind to address [::]:80 +

+ +

Puede mirar el articulo de la wiki + de consejos para solucionar problemas relacionados.

+ +
+ +
top
+
+

Consideraciones especiales con IPv6

+ + +

Un creciente nmero de plataformas implementan ya IPv6, y + APR soporta IPv6 en la mayora de estas plataformas, + permitiendo as a httpd asignar sockets IPv6, y manejar las respuestas + enviadas a travs de IPv6.

+ +

Un factor bastante complejo para un administrador del httpd + es si un socket IPv6 puede o no manejar tanto conexiones IPv6 + como IPv4. El manejo por httpd de conexiones IPv4 con socket IPv6 + se debe al mapeo de direcciones IPv4 sobre IPv6, que + est permitido por defecto en muchas plataformas, pero no lo est + en sistemas FreeBSD, NetBSD y Open BSD, con el fin de que en estas + plataformas, cumpla con la poltica del sistema. + En los sistemas que no est permitido el mapeo por defecto, + existe un parmetro de configure especial + para cambiar ste comportamiento para httpd.

+ +

Por otro lado, en algunas plataformas, como Linux y True64, la + nica forma para el manejo de IPv4 e IPv6 al mismo + tiempo es mediante direcciones mapeadas. + Si quieres que httpd maneje amos tipos de conexiones IPv4 e IPv6 + con el mnimo de sockets, hay que especificar la opcin + --enable-v4-mapped al configure.

+ +

--enable-v4-mapped es la opcin que est estipulada por defecto + en todos los sistemas menos en FreeBSD, NetBSD y Open BSD, por + lo que es probablemente como se compil su httpd.

+ +

Si lo que quiere es manejar slo conexiones IPv4, independientemente de + lo que soporten APR y su plataforma, especifique + una direccin IPv4 por cada directiva + Listen, como en el siguiente + ejemplo:

+ + 
Listen 0.0.0.0:80
+Listen 192.0.2.1:80
+
+ +

Si en cambio, su plataforma lo soporta, y lo que quiere es que su httpd + soporte tanto conexiones IPv4 como IPv6 en diferentes sockets (ejemplo.: para + deshabilitar mapeo de direcciones IPv4), especifique la opcin + --disable-v4-mapped al configure. --disable-v4-mapped es la opcin por defecto + en FreeBSD, NetBSD y OpenBSD.

+
top
+
+

Especificar el Protocolo en el Listen

+ +

El segundo argumento en la directiva Listen + el protocolo que es opcional no es algo que se requiera en las configuraciones. + Si ste argumento no se especifica, https es el protocolo + usado por defecto en el puerto 443 y http para el resto. + El protocolo se utiliza para determinar que mdulo deber manejar la peticin, + y se le aplicarn optimizaciones especficas del protocolo con la directiva + AcceptFilter.

+ +

Slo necesitar especificar el protocolo si no est escuchando en un puerto + de los que son estndares, por ejemplo si ejecuta un sitio web https en el puerto 8443:

+ + 
Listen 192.170.2.1:8443 https
+
+
top
+
+

Como Funciona en los Hosts Virtuales

+ + +

La directiva Listen no implementa los + Hosts Virtuales - solo le dice al servidor en que direcciones + y puertos debe escuchar. Si no hay directiva + <VirtualHost> + en uso, el servidor se comportar de la misma manera para todas las + peticiones aceptadas. Ahora bien, + <VirtualHost> + puede ser usado para especificar un comportamiento diferente en una o + varias direcciones o puertos. + Para implementar los Hosts Virtuales, antes se le tiene que decir al servidor + que direcciones y puertos van a ser usados. + Despus de esto, se deber especificar una seccin de la directiva + <VirtualHost> + especificando direcciones y puertos que se van a usar en el Host Virtual + Note que si se configura un + <VirtualHost> + para una direccin y puerto en el que el servidor no est escuchando, + no se podr acceder al Host Virtual.

+
+
+

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

+
top

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/bind.html.fr b/docs/manual/bind.html.fr deleted file mode 100644 index a76d6e5012..0000000000 --- a/docs/manual/bind.html.fr +++ /dev/null @@ -1,259 +0,0 @@ - - - - - -Ecoute sélective - Serveur HTTP Apache Version 2.5 - - - - - - -
-

Modules | Directives | FAQ | Glossaire | Plan du site

-

Serveur HTTP Apache Version 2.5

-
-
<-
-

Ecoute sélective

-
-

Langues Disponibles:  de  | - en  | - es  | - fr  | - ja  | - ko  | - tr 

-
- -

Configuration du serveur HTTP Apache pour l'écoute - sur un port et une adresse IP spécifiques.

-
- -
top
-
-

Vue d'ensemble

- - -
Modules ApparentésDirectives Apparentées
- - -

Au démarrage de httpd, un port et une adresse lui sont associés sur - l'hôte local et le serveur se met en attente de l'arrivée d'une requête. - Par défaut, le serveur écoute toutes les adresses de l'hôte local. - Cependant, on peut lui préciser des ports et des adresses spécifiques à écouter, - ou une combinaison des deux. - Tout ceci est souvent associé avec la fonctionnalité - des hôtes virtuels - qui détermine la manière dont httpd répond aux différents ports, - noms d'hôtes et adresses IP.

- -

La directive Listen - enjoint le serveur de n'accepter des requêtes que sur le(s) - port(s) spécifiés ou - une combinaison adresse/port. Si seul un numéro de port est spécifié - dans la directive Listen, - le serveur se met à l'écoute sur ce port, sur toutes les interfaces réseau. - Si une adresse IP est spécifiée en plus du port, le serveur va écouter - sur ce port, uniquement sur l'interface réseau correspondante. On peut utiliser - de multiples directives - Listen pour - spécifier plusieurs adresses et ports à écouter. Le serveur répondra alors - aux requêtes sur ces ports et adresses spécifiés.

- -

Par exemple, pour faire en sorte que le serveur accepte des connexions - sur les ports 80 et 8000, sur toutes les interfaces, utilisez :

- - 
Listen 80
-Listen 8000
-
- -

Pour faire en sorte que le serveur accepte des connexions sur le port 80 - pour une interface, et sur le port 8000 pour une - autre interface, utilisez :

- - 
Listen 192.0.2.1:80
-Listen 192.0.2.5:8000
-
- -

Les adresses IPv6 doivent être mises entre crochets, comme dans - l'exemple suivant :

- - 
Listen [2001:db8::a00:20ff:fea7:ccea]:80
-
- -

Des directives Listen - imbriquées provoqueront une erreur fatale qui - empêchera le serveur de démarrer.

- -

- (48)Address already in use: make_sock: could not bind to address [::]:80 -

- -

Voir cette - discussion dans le wiki pour plus de conseils pour résoudre ce - problème.

- -
- -
top
-
-

Changer la configuration de l'écoute au redémarrage

- - -

Lorsque httpd est redémarré, certaines remarques sont à prendre en compte - quant aux modifications apportées aux directives Listen. Au cours du redémarrage, httpd - conserve la liaison avec les ports de la configuration précédente afin - d'éviter l'obtention d'un message d'erreur "Connection refused" lors d'une - tentative ultérieure de connexion au serveur. Si les modifications apportées au jeu de - directives Listen utilisé entrent - en conflit avec ce dernier, le serveur refusera de redémarrer.

- -

Par exemple, modifier la configuration suivante :

- - 
Listen 127.0.0.1:80
-
- -

pour utiliser la suivante pourra échouer car écouter le port 80 sur - toutes les adresses IP entre en conflit avec une écoute sélective du port 80 - sur la seule adresse IP 127.0.0.1.

- - 
Listen 80
-
- -

Pour qu'une telle modification de configuration soit prise en compte avec - succès, il est nécessaire d'arrêter, puis de démarrer le serveur.

- -
top
-
-

Remarques spécifiques à IPv6

- - -

Un nombre croissant de plateformes implémentent IPv6, et - APR supporte IPv6 sur la plupart d'entre elles, - ce qui permet à httpd d'allouer des points de connexion (sockets) IPv6 - et de traiter des requêtes envoyées sur IPv6.

- -

Les administrateurs de httpd doivent se préoccuper de la possibilité - pour un point de connexion IPv6 de traiter à la fois des connexions IPv4 - et des connexions IPv6. - Le traitement de connexions IPv4 avec un point de connexion IPv6 utilise - des adresses IPv6 traduites en IPv4, qui sont autorisées par défaut sur la - plupart des plateformes, mais sont interdites par défaut sous FreeBSD, NetBSD, - et OpenBSD, afin de respecter la politique de sécurité du système sur ces plateformes. - Sur les systèmes où ces adresses sont interdites par défaut, un - paramètre spécial du script configure permet de modifier - ce comportement pour httpd.

- -

En revanche, sur certaines plateformes comme Linux et Tru64, la - seule manière de gérer à la fois IPv6 et IPv4 passe - par l'utilisation d'adresses traduites. Si vous voulez que httpd gère - des connexions IPv4 et IPv6 avec un minimum de points de connexion, - ce qui nécessite l'utilisation d'adresses IPv6 traduites en IPv4, - utilisez l'option --enable-v4-mapped du script configure.

- -

L'option --enable-v4-mapped est utilisée par défaut sur - toutes les plateformes sauf FreeBSD, NetBSD, et OpenBSD; - votre httpd a donc probablement été construit avec cette option.

- -

Si vous souhaitez que httpd ne gère que des connexions IPv4, sans se - soucier de ce que vos plateforme et APR supportent, spécifiez une adresse - IPv4 dans toutes les directives - Listen, comme dans l'exemple - suivant :

- - 
Listen 0.0.0.0:80
-Listen 192.0.2.1:80
-
- -

Si votre plateforme le supporte et si vous souhaitez que httpd gère - des connexions IPv4 et IPv6 sur des points de connexion séparés - (c'est à dire désactiver la traduction des adresses IPv6 au format IPv4), - utilisez l'option --disable-v4-mapped du script - configure. --disable-v4-mapped est - utilisé par défaut sur FreeBSD, NetBSD, et OpenBSD.

-
top
-
-

Spécification du protocole avec Listen

- -

Dans la plupart des configurations, le second paramètre optionnel - protocol de la directive Listen n'est pas obligatoire. S'il - n'est pas spécifié, les protocoles par défaut - sont https pour le port 443, et http pour - tous les autres ports. Le protocole sert à déterminer quel module - doit traiter une requête, et à appliquer les optimisations - spécifiques au protocole via la directive AcceptFilter.

- -

Vous ne devez définir le protocole que si vous travaillez avec - des ports non standards. Par exemple, pour travailler en - https sur le port 8443 :

- - 
Listen 192.170.2.1:8443 https
-
-
top
-
-

Comment tout ceci fonctionne-t-il avec les hôtes virtuels

- - -

La directive Listen n'implémente pas les hôtes virtuels. - Elle indique simplement au serveur principal sur quels adresses et ports - il doit écouter. Si aucune directive - <VirtualHost> - n'est présente, le serveur se comportera de la même façon pour toutes - les requêtes acceptées. En revanche, la directive - <VirtualHost> - peut être utilisée pour provoquer une réaction différente du serveur - pour un ou plusieurs adresses ou ports. Pour implémenter un hôte virtuel, - on doit d'abord indiquer au serveur sur quels adresses et ports il doit écouter. - Ensuite, une section - <VirtualHost> - doit être créée pour le couple adresse+port spécifié afin de définir le - comportement de cet hôte virtuel. Notez que si la directive - <VirtualHost> - est définie pour une adresse et un port sur lesquels le serveur n'est pas censé - écouter, cet hôte virtuel ne sera pas accessible.

-
-
-

Langues Disponibles:  de  | - en  | - es  | - fr  | - ja  | - ko  | - tr 

-
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
-
- \ No newline at end of file diff --git a/docs/manual/bind.html.fr.utf8 b/docs/manual/bind.html.fr.utf8 new file mode 100644 index 0000000000..a76d6e5012 --- /dev/null +++ b/docs/manual/bind.html.fr.utf8 @@ -0,0 +1,259 @@ + + + + + +Ecoute sélective - Serveur HTTP Apache Version 2.5 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.5

+
+
<-
+

Ecoute sélective

+
+

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

+
+ +

Configuration du serveur HTTP Apache pour l'écoute + sur un port et une adresse IP spécifiques.

+
+ +
top
+
+

Vue d'ensemble

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

Au démarrage de httpd, un port et une adresse lui sont associés sur + l'hôte local et le serveur se met en attente de l'arrivée d'une requête. + Par défaut, le serveur écoute toutes les adresses de l'hôte local. + Cependant, on peut lui préciser des ports et des adresses spécifiques à écouter, + ou une combinaison des deux. + Tout ceci est souvent associé avec la fonctionnalité + des hôtes virtuels + qui détermine la manière dont httpd répond aux différents ports, + noms d'hôtes et adresses IP.

+ +

La directive Listen + enjoint le serveur de n'accepter des requêtes que sur le(s) + port(s) spécifiés ou + une combinaison adresse/port. Si seul un numéro de port est spécifié + dans la directive Listen, + le serveur se met à l'écoute sur ce port, sur toutes les interfaces réseau. + Si une adresse IP est spécifiée en plus du port, le serveur va écouter + sur ce port, uniquement sur l'interface réseau correspondante. On peut utiliser + de multiples directives + Listen pour + spécifier plusieurs adresses et ports à écouter. Le serveur répondra alors + aux requêtes sur ces ports et adresses spécifiés.

+ +

Par exemple, pour faire en sorte que le serveur accepte des connexions + sur les ports 80 et 8000, sur toutes les interfaces, utilisez :

+ + 
Listen 80
+Listen 8000
+
+ +

Pour faire en sorte que le serveur accepte des connexions sur le port 80 + pour une interface, et sur le port 8000 pour une + autre interface, utilisez :

+ + 
Listen 192.0.2.1:80
+Listen 192.0.2.5:8000
+
+ +

Les adresses IPv6 doivent être mises entre crochets, comme dans + l'exemple suivant :

+ + 
Listen [2001:db8::a00:20ff:fea7:ccea]:80
+
+ +

Des directives Listen + imbriquées provoqueront une erreur fatale qui + empêchera le serveur de démarrer.

+ +

+ (48)Address already in use: make_sock: could not bind to address [::]:80 +

+ +

Voir cette + discussion dans le wiki pour plus de conseils pour résoudre ce + problème.

+ +
+ +
top
+
+

Changer la configuration de l'écoute au redémarrage

+ + +

Lorsque httpd est redémarré, certaines remarques sont à prendre en compte + quant aux modifications apportées aux directives Listen. Au cours du redémarrage, httpd + conserve la liaison avec les ports de la configuration précédente afin + d'éviter l'obtention d'un message d'erreur "Connection refused" lors d'une + tentative ultérieure de connexion au serveur. Si les modifications apportées au jeu de + directives Listen utilisé entrent + en conflit avec ce dernier, le serveur refusera de redémarrer.

+ +

Par exemple, modifier la configuration suivante :

+ + 
Listen 127.0.0.1:80
+
+ +

pour utiliser la suivante pourra échouer car écouter le port 80 sur + toutes les adresses IP entre en conflit avec une écoute sélective du port 80 + sur la seule adresse IP 127.0.0.1.

+ + 
Listen 80
+
+ +

Pour qu'une telle modification de configuration soit prise en compte avec + succès, il est nécessaire d'arrêter, puis de démarrer le serveur.

+ +
top
+
+

Remarques spécifiques à IPv6

+ + +

Un nombre croissant de plateformes implémentent IPv6, et + APR supporte IPv6 sur la plupart d'entre elles, + ce qui permet à httpd d'allouer des points de connexion (sockets) IPv6 + et de traiter des requêtes envoyées sur IPv6.

+ +

Les administrateurs de httpd doivent se préoccuper de la possibilité + pour un point de connexion IPv6 de traiter à la fois des connexions IPv4 + et des connexions IPv6. + Le traitement de connexions IPv4 avec un point de connexion IPv6 utilise + des adresses IPv6 traduites en IPv4, qui sont autorisées par défaut sur la + plupart des plateformes, mais sont interdites par défaut sous FreeBSD, NetBSD, + et OpenBSD, afin de respecter la politique de sécurité du système sur ces plateformes. + Sur les systèmes où ces adresses sont interdites par défaut, un + paramètre spécial du script configure permet de modifier + ce comportement pour httpd.

+ +

En revanche, sur certaines plateformes comme Linux et Tru64, la + seule manière de gérer à la fois IPv6 et IPv4 passe + par l'utilisation d'adresses traduites. Si vous voulez que httpd gère + des connexions IPv4 et IPv6 avec un minimum de points de connexion, + ce qui nécessite l'utilisation d'adresses IPv6 traduites en IPv4, + utilisez l'option --enable-v4-mapped du script configure.

+ +

L'option --enable-v4-mapped est utilisée par défaut sur + toutes les plateformes sauf FreeBSD, NetBSD, et OpenBSD; + votre httpd a donc probablement été construit avec cette option.

+ +

Si vous souhaitez que httpd ne gère que des connexions IPv4, sans se + soucier de ce que vos plateforme et APR supportent, spécifiez une adresse + IPv4 dans toutes les directives + Listen, comme dans l'exemple + suivant :

+ + 
Listen 0.0.0.0:80
+Listen 192.0.2.1:80
+
+ +

Si votre plateforme le supporte et si vous souhaitez que httpd gère + des connexions IPv4 et IPv6 sur des points de connexion séparés + (c'est à dire désactiver la traduction des adresses IPv6 au format IPv4), + utilisez l'option --disable-v4-mapped du script + configure. --disable-v4-mapped est + utilisé par défaut sur FreeBSD, NetBSD, et OpenBSD.

+
top
+
+

Spécification du protocole avec Listen

+ +

Dans la plupart des configurations, le second paramètre optionnel + protocol de la directive Listen n'est pas obligatoire. S'il + n'est pas spécifié, les protocoles par défaut + sont https pour le port 443, et http pour + tous les autres ports. Le protocole sert à déterminer quel module + doit traiter une requête, et à appliquer les optimisations + spécifiques au protocole via la directive AcceptFilter.

+ +

Vous ne devez définir le protocole que si vous travaillez avec + des ports non standards. Par exemple, pour travailler en + https sur le port 8443 :

+ + 
Listen 192.170.2.1:8443 https
+
+
top
+
+

Comment tout ceci fonctionne-t-il avec les hôtes virtuels

+ + +

La directive Listen n'implémente pas les hôtes virtuels. + Elle indique simplement au serveur principal sur quels adresses et ports + il doit écouter. Si aucune directive + <VirtualHost> + n'est présente, le serveur se comportera de la même façon pour toutes + les requêtes acceptées. En revanche, la directive + <VirtualHost> + peut être utilisée pour provoquer une réaction différente du serveur + pour un ou plusieurs adresses ou ports. Pour implémenter un hôte virtuel, + on doit d'abord indiquer au serveur sur quels adresses et ports il doit écouter. + Ensuite, une section + <VirtualHost> + doit être créée pour le couple adresse+port spécifié afin de définir le + comportement de cet hôte virtuel. Notez que si la directive + <VirtualHost> + est définie pour une adresse et un port sur lesquels le serveur n'est pas censé + écouter, cet hôte virtuel ne sera pas accessible.

+
+
+

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

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/caching.html.en b/docs/manual/caching.html.en index 0dc267ac54..a1be1692df 100644 --- a/docs/manual/caching.html.en +++ b/docs/manual/caching.html.en @@ -24,8 +24,8 @@ Apache > HTTP Server > Documentation > Version 2.5

Caching Guide

Available Languages:  en  | - fr  | - tr 

+ fr  | + tr 

This document supplements the mod_cache, @@ -879,8 +879,8 @@ sys 0m0.000s

Available Languages:  en  | - fr  | - tr 

+ fr  | + tr 

top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
- - -
-

Modules | Directives | FAQ | Glossaire | Plan du site

-

Serveur HTTP Apache Version 2.5

-
-
<-
-

Guide de la mise en cache

-
-

Langues Disponibles:  en  | - fr  | - tr 

-
- -

Ce document complète la documentation de référence des modules - mod_cache, mod_cache_disk, - mod_file_cache et du programme htcacheclean. - Il décrit l'utilisation des fonctionnalités de mise en - cache du serveur HTTP Apache - pour accélérer les services web et proxy, tout en évitant les problèmes - courants et les erreurs de configuration.

-
- -
top
-
-

Introduction

- - -

Le serveur HTTP Apache offre tout un ensemble de fonctionnalités - de mise en cache qui ont été conçues pour améliorer les performances - du serveur de différentes manières.

- -
-
Mise en cache HTTP à trois états RFC2616
-
mod_cache et son module de fournisseur - mod_cache_disk proposent une mise en cache - intelligente de niveau HTTP. Le contenu proprement dit est - stocké dans le cache, et mod_cache vise à respecter tous les - en-têtes HTTP, ainsi que les options qui contrôlent la mise en - cache du contenu comme décrit dans la Section - 13 de la RFC2616. mod_cache peut gérer des - configurations de mise en cache simples, mais aussi complexes - comme dans les cas où vous avez à faire à des contenus mandatés, - à des contenus locaux dynamiques, ou lorsque vous avez besoin - d'accélérer l'accès aux fichiers locaux situés sur disque - supposé lent. -
- -
Mise en cache d'objets partagés de forme clé/valeur à deux - états
-
- L'API du cache d'objets partagés (socache) - et ses modules de fournisseurs - proposent une mise en cache d'objets partagés à base de - couples clé/valeur de niveau serveur. Ces modules sont - conçus pour la mise en cache de données de bas niveau comme - les sessions SSL et les données d'authentification. les - serveurs d'arrière-plan permettent le stockage des données - au niveau serveur en mémoire partagée, ou au niveau - datacenter dans un cache comme memcache ou distcache. -
- -
Mise en cache de fichiers spécialisée
-
- mod_file_cache offre la possibilité de - précharger des fichiers en mémoire au démarrage du serveur, - et peut améliorer les temps d'accès et sauvegarder les - gestionnaires de fichiers pour les fichiers qui font l'objet - d'accès fréquents, évitant ainsi d'avoir à accéder au disque - à chaque requête. -
-
- -

Pour tirer parti efficacement de ce document, les bases de HTTP doivent - vous être familières, et vous devez avoir lu les sections - Mise en correspondance des - URLs avec le système de fichiers et - Négociation sur le contenu - du guide de l'utilisateur.

- -
top
-
-

Mise en cache HTTP à trois états RFC2616

- - - -
Modules ApparentésDirectives Apparentées
- -

Le module mod_cache permet de tirer avantage du - mécanisme de mise en cache en ligne faisant partie - intégrante du protocole HTTP, et décrit dans la section - 13 de la RFC2616.

- -

A la différence d'un cache simple clé/valeur à deux états où le - contenu est supprimé lorsqu'il est périmé, un cache HTTP comporte un - mécanisme permettant de conserver temporairement un contenu périmé, - de demander au serveur original si ce contenu périmé a été modifié, - et dans le cas contraire de le rendre à nouveau valide.

- -

Une entrée d'un cache HTTP peut se présenter sous un de ces trois - états :

- -
-
Frais
-
- Si un contenu est suffisamment récent (plus jeune que sa - durée de fraîcheur), il est considéré comme - frais. Un cache HTTP peut servir un contenu - frais sans avoir à demander quoi que ce soit au serveur - d'origine. -
-
Périmé
-
-

Si le contenu est trop ancien (plus vieux que sa - durée de fraîcheur), il est considéré comme - périmé. Un cache HTTP doit contacter le serveur - original pour vérifier si le contenu, même s'il est périmé, est - encore à jour avant de le servir au client. Soit le serveur - original va répondre en envoyant un contenu de remplacement si - le contenu périmé n'est plus à jour, soit dans le cas idéal il - renverra un code pour signaler au cache que le contenu est - encore à jour, et qu'il est inutile de le générer ou de - l'envoyer à nouveau. Le contenu repasse à l'état "frais" et le - cycle continue.

- -

Le protocole HTTP permet au cache de servir des données - périmées dans certaines circonstances, comme lorsqu'une - tentative de rafraîchir une entrée depuis un serveur original - se solde par un échec avec un code d'erreur 5xx, ou lorsqu'une - autre requête est déjà en train d'essayer de rafraîchir la même - entrée. Dans ces cas, un en-tête Warning est ajouté - à la réponse.

-
-
Non Existent
-
- Si le cache est plein, il se réserve la possibilité de supprimer - des entrées pour faire de la place. Une entrée peut être - supprimée à tout moment, qu'elle soit fraîche ou périmée. - L'outil htcacheclean - peut être utilisé à la demande, ou lancé en tant que démon afin - de conserver la taille du cache ou le nombre d'inodes en deçà de - valeurs spécifiées. Cet outil essaie cependant de - supprimer les entrées périmées avant les entrées fraîches. -
-
- -

Le fonctionnement détaillé d'un cache HTTP est décrit dans la Section - 13 de la RFC2616.

- -

Interaction avec le serveur

- - -

Le module mod_cache interagit avec le serveur - à deux niveaux possibles en fonction de la directive CacheQuickHandler : -

- -
-
Phase du gestionnaire rapide
-
-

Cette phase se déroule très tôt au cours du traitement de - la requête, juste après l'interprétation de cette dernière. Si - le contenu se trouve dans le cache, il est servi immédiatement - et pratiquement tout le reste du traitement de la requête est - court-circuité.

- -

Dans ce scénario, le cache se comporte comme s'il avait - été "boulonné" à l'entrée du serveur.

- -

Ce mode possède les meilleures performances car la - majorité des traitements au niveau du serveur sont - court-circuités. Cependant, il court-circuite aussi les - phases d'authentification et d'autorisation du traitement - au niveau du serveur, et il doit donc être utilisé avec - prudence lorsque que ces phases sont importantes.

- -

Les requêtes contenant un en-tête "Authorization" - header (par exemple dans le cas de l'authentification HTTP - basique) ne peuvent ni être mises en cache, ni servies - depuis le cache lorsque mod_cache - s'exécute dans cette phase.

-
-
Phase du gestionnaire normal
-
-

Cette phase se déroule très tard au cours du traitement - de la requête, en fait après toutes les phases de ce - traitement.

- -

Dans ce scénario, le cache se comporte comme s'il avait - été "boulonné" à la sortie du serveur.

- -

Ce mode offre la plus grande souplesse, car il permet - de faire intervenir la mise en cache en un point - précisément spécifié de la chaîne de filtrage, et le - contenu issu du cache peut être filtré ou personnalisé - avant d'être servi au client.

-
-
- -

Si l'URL ne se trouve pas dans le cache, - mod_cache ajoutera un filtre à la chaîne de filtrage afin - d'enregistrer la réponse dans le cache, puis passera la main - pour permettre le déroulement normal de la suite du traitement - de la requête. Si la mise en cache du contenu est autorisée, il - sera enregistré dans le cache pour pouvoir être servi à nouveau - ; dans le cas contraire, le contenu sera ignoré.

- -

Si le contenu trouvé dans le cache est périmé, le module - mod_cache convertit la requête en - requête conditionnelle. Si le serveur original - renvoie une réponse normale, elle est enregistrée dans le cache - en lieu et place du contenu périmé. Si le serveur original - renvoie une réponse "304 Not Modified", le contenu repasse à - l'état "frais" et est servi par le filtre au lieu d'être - sauvegardé.

- - -

Amélioration du taux de présence dans le cache

- - -

Lorsqu'un serveur virtuel est connu sous la forme d'un des - nombreux alias du serveur, la définition de la directive - UseCanonicalName à - On peut augmenter de manière significative le nombre - de correspondances positives dans le cache. Ceci est du au fait - que la clé du cache contient le nom d'hôte du serveur virtuel. - Avec UseCanonicalName positionnée - à On, - les hôtes virtuels possédant plusieurs noms de serveur ou alias ne - généreront pas d'entités de cache différentes, et le contenu sera mis en - cache en faisant référence au nom d'hôte canonique.

- - - -

Durée de fraîcheur

- - -

Un contenu bien formé destiné à être mis en cache doit déclarer - explicitement une durée de fraîcheur via les champs - max-age ou s-maxage de l'en-tête - Cache-Control, ou en incluant un en-tête - Expires.

- -

De plus, un client peut passer outre la durée de fraîcheur - définie pour le serveur original en ajoutant son propre en-tête - Cache-Control à la requête. Dans ce cas, c'est la - durée de fraîcheur la plus basse entre la requête et la réponse - qui l'emporte.

- -

Lorsque cette durée de fraîcheur est absente de la requête ou - de la réponse, une durée de fraîcheur par défaut s'applique. La - durée de fraîcheur par défaut des entrées du cache est d'une heure - ; elle peut cependant être facilement modifiée à l'aide de - la directive CacheDefaultExpire.

- -

Si une réponse ne contient pas d'en-tête Expires mais - inclut un en-tête Last-Modified, mod_cache - peut déduire une durée de fraîcheur en se basant sur une - heuristique, qui peut être contrôlée via la directive CacheLastModifiedFactor.

- -

Pour les contenus locaux, ou les contenus distants qui ne - spécifient pas leur propre en-tête Expires, - mod_expires permet de régler finement la durée de - fraîcheur via les paramètres max-age et - Expires.

- -

On peut aussi contrôler la durée de fraîcheur maximale en utilisant - la directive CacheMaxExpire.

- - - -

Guide succinct des requêtes conditionnelles

- - -

Lorsqu'un contenu du cache est périmé, httpd modifie la requête - pour en faire une requête conditionnelle

- -

Lorsque la réponse originale du cache contient un en-tête - ETag, mod_cache ajoute un en-tête - If-None-Match à la requête envoyée au serveur - d'origine. Lorsque la réponse originale du cache contient un en-tête - Last-Modified, mod_cache ajoute un en-tête - If-Modified-Since à la requête envoyée au serveur - d'origine. Dans ces deux cas, la requête devient une requête - conditionnelle.

- -

Lorsqu'un serveur d'origine reçoit une requête conditionnelle, - il vérifie si le paramètre Etag ou Last-Modified a été modifié en - fonction des paramètres de la requête. Si ce n'est pas le cas, il - répondra avec le message lapidaire "304 Not Modified". Ceci - informe le cache que le contenu est périmé mais encore à jour, et - peut être utilisé tel quel pour les prochaines requêtes jusqu'à ce - qu'il atteigne à nouveau sa date de péremption.

- -

Si le contenu a été modifié, il est servi comme s'il s'agissait - d'une requête normale et non conditionnelle.

- -

Les requêtes conditionnelles offrent deux avantages. D'une - part, il est facile de déterminer si le contenu du serveur - d'origine correspond à celui situé - dans le cache, et ainsi d'économiser la consommation de ressources - nécessaire au transfert du contenu dans son ensemble.

- -

D'autre part, un serveur d'origine bien conçu sera configuré de - telle manière que les requêtes conditionnelles nécessitent pour - leur production bien moins de ressources qu'une réponse complète. - Dans le cas des fichiers statiques, il suffit en général d'un - appel système de type stat() ou similaire pour - déterminer si la taille ou la date de modification du fichier a - été modifiée. Ainsi, même un contenu local pourra être servi plus - rapidement depuis le cache s'il n'a pas été modifié.

- -

Il serait souhaitable que tous les serveurs d'origine - supportent les requêtes conditionnelles, car dans le cas - contraire, ils répondent comme s'il s'agissait d'une requête - normale, et le cache répond comme si le contenu avait été - modifié et enregistre ce dernier. Le cache se comporte alors - comme un simple cache à deux état, où le contenu est servi s'il - est à jour, ou supprimé dans le cas contraire.

- - -

Que peut-on mettre en cache ?

- - -

La liste complète des conditions nécessaires pour qu'une - réponse puisse être enregistrée dans un cache HTTP est fournie - dans la section - 13.4 Response Cacheability de la RFC2616, et peut se résumer - ainsi :

- -
    -
  1. La mise en cache doit être activée pour cette URL. Voir les - directives CacheEnable et CacheDisable.
    2. - -
  2. Si la reponse possède un code de statut HTTP autre que 200, 203, 300, 301 - ou 410, elle doit aussi comporter un en-tête "Expires" ou - "Cache-Control".
    3. - -
  3. La requête doit être de type HTTP GET.
    4. - -
  4. Si la réponse contient un en-tête "Authorization:", elle doit aussi - contenir une option "s-maxage", "must-revalidate" ou "public" - dans l'en-tête "Cache-Control:".
    5. - -
  5. Si l'URL contient une chaîne de requête - (provenant par exemple d'une méthode GET de formulaire HTML), elle ne - sera pas mise en cache, à moins que la réponse ne - spécifie explicitement un délai d'expiration via un - en-tête "Expires:" ou une directive max-age ou s-maxage de - l'en-tête "Cache-Control:" comme indiqué dans les - sections 13.2.1. et 13.9 de la RFC2616.
    6. - -
  6. Si la réponse a un statut de 200 (OK), elle doit aussi contenir - au moins un des en-têtes "Etag", "Last-Modified" ou - "Expires", ou une directive max-age ou s-maxage de - l'en-tête "Cache-Control:", à moins que la directive - CacheIgnoreNoLastMod - ne précise d'autres contraintes.
    7. - -
  7. Si la réponse contient l'option "private" dans un en-tête - "Cache-Control:", elle ne sera pas mise en cache à moins que la - directive - CacheStorePrivate - ne précise d'autres contraintes.
    8. - -
  8. De même, si la réponse contient l'option "no-store" dans un en-tête - "Cache-Control:", elle ne sera pas mise en cache à moins que la - directive - CacheStoreNoStore - n'ait été utilisée.
    9. - -
  9. Une réponse ne sera pas mise en cache si elle comporte un en-tête - "Vary:" contenant le caractère "*" qui correspond à toute - chaîne de caractères.
    10. -
- - -

Qu'est ce qui ne doit pas être mis en cache ?

- - -

Le client qui crée la requête ou le serveur d'origine qui - génère la réponse doit être à même de déterminer si le contenu - doit pouvoir être mis en cache ou non en définissant correctement - l'en-tête Cache-Control, et - mod_cache sera alors en mesure de satisfaire les - souhaits du client ou du serveur de manière appropriée. -

- -

Les contenus qui varient au cours du temps, ou en fonction de - particularités de la requête non prises en compte par la - négociation HTTP ne doivent pas être mis en cache. Ce type de - contenu doit se déclarer lui-même "à ne pas mettre en cache" via - l'en-tête Cache-Control.

- -

Si le contenu change souvent, suite par exemple à une durée de - fraîcheur de l'ordre de la minute ou de la seconde, il peut tout - de même être mis en cache, mais il est alors fortement souhaitable - que le serveur d'origine supporte correctement les - requêtes conditionnelles afin que des réponses - complètes ne soient pas systématiquement générées.

- -

Un contenu qui varie en fonction d'en-têtes de requête fournis - par le client peut être mis en cache, sous réserve d'une - utilisation appropriée de l'en-tête de réponse Vary.

- - -

Contenu variable et/ou négocié

- - -

Lorsque le serveur d'origine est configuré pour servir des - contenus différents en fonction de la valeur de certains en-têtes - de la requête, par exemple pour servir une ressource en plusieurs - langages à partir d'une seule URL, le mécanisme de mise en cache - d'HTTP permet de mettre en cache plusieurs variantes de la même - page à partir d'une seule URL.

- -

Pour y parvenir, le serveur d'origine ajoute un en-tête - Vary pour indiquer quels en-têtes doivent être pris - en compte par un cache pour déterminer si deux variantes sont - différentes l'une de l'autre.

- -

Si par exemple, une réponse est reçue avec l'en-tête Vary suivant,

- -

-Vary: negotiate,accept-language,accept-charset -

- -

mod_cache ne servira aux demandeurs que le contenu - mis en cache qui correspond au contenu des en-têtes accept-language et - accept-charset de la requête originale.

- -

Plusieurs variantes d'un contenu peuvent être mises en cache - simultanément ; mod_cache utilise l'en-tête - Vary et les valeurs correspondantes des en-têtes de - la requête spécifiés dans ce dernier pour - déterminer quelle variante doit être servie au client.

- - - -
top
-
-

Exemples de configuration du cache

- - - -
Modules ApparentésDirectives Apparentées
- -

Mise en cache sur disque

- - -

Le module mod_cache s'appuie sur des - implémentations de stockage sous-jacentes spécifiques pour gérer - le cache ; à ce titre, mod_cache_disk fournit le - support de la mise en cache sur disque.

- -

En général, le module se configure comme suit :

- - 
CacheRoot   "/var/cache/apache/"
-CacheEnable disk /
-CacheDirLevels 2
-CacheDirLength 1
- - -

Il est important de savoir que, les fichiers mis en cache étant stockés - localement, la mise en cache par l'intermédiaire du système d'exploitation - sera en général aussi appliquée à leurs accès. Si bien que même si les - fichiers sont stockés sur disque, s'il font l'objet d'accès fréquents, - il est probable que le système d'exploitation s'appliquera à ce qu'ils - soient servis à partir de la mémoire.

- - - -

Comprendre le stockage dans le cache

- - -

Pour stocker des entités dans le cache, - le module mod_cache_disk crée une empreinte (hash) de 22 - caractères de l'URL qui a fait l'objet d'une requête. Cette empreinte - comprend le nom d'hôte, le protocole, le port, le chemin et tout argument - de type CGI associé à l'URL, ainsi que les éléments - spécifiés dans l'en-tête Vary afin d'être sur que plusieurs URLs - n'interfèrent pas entre elles.

- -

Chaque position de l'empreinte peut contenir un caractère - choisi parmi 64 caractères différents, il y a donc - 64^22 possibilités pour une empreinte. Par exemple, une URL peut posséder - l'empreinte xyTGxSMO2b68mBCykqkp1w. Cette empreinte est - utilisée pour préfixer les noms de fichiers spécifiques à cette URL à - l'intérieur du cache; cependant, elle est tout d'abord placée dans les - répertoires du cache selon les directives - CacheDirLevels et - CacheDirLength.

- -

La directive - CacheDirLevels - définit le nombre de niveaux de sous-répertoires, et - CacheDirLength - le nombre de caractères composant le nom des sous-répertoires. Dans - l'exemple donné plus haut, l'empreinte se trouvera à : - /var/cache/apache/x/y/TGxSMO2b68mBCykqkp1w.

- -

Cette technique a pour but principal de réduire le nombre de - sous-répertoires ou de fichiers contenus dans un répertoire particulier, - car le fonctionnement de la plupart des systèmes de fichiers est ralenti - quand ce nombre augmente. Avec la valeur "1" pour la directive - CacheDirLength, - il peut y avoir au plus 64 sous-répertoires à un niveau quelconque. - Avec la valeur "2", il peut y en avoir 64 * 64, etc... - A moins d'avoir une bonne raison pour ne pas le faire, l'utilisation de - la valeur "1" pour la directive - CacheDirLength - est recommandée.

- -

Le paramétrage de la directive - CacheDirLevels - dépend du nombre de fichiers que vous pensez stocker dans le cache. - Avec une valeur de "2" comme dans l'exemple donné plus haut, - 4096 sous-répertoires peuvent être créés au total. Avec 1 million de - fichiers dans le cache, cela équivaut à environ 245 URLs mises en cache - dans chaque répertoire.

- -

Chaque URL nécessite au moins deux fichiers dans le cache. Ce sont en - général un fichier ".header", qui contient des meta-informations à propos - de l'URL, comme la date de son arrivée à expiration, - et un fichier ".data" qui est la copie exacte du contenu à servir.

- -

Dans le cas d'un contenu négocié via l'en-tête "Vary", un répertoire - ".vary" sera créé pour l'URL en question. Ce répertoire contiendra de - multiples fichiers ".data" correspondant aux différents contenus - négociés.

- - -

Maintenance du cache sur disque

- - -

Le module mod_cache_disk n'effectue aucune - régulation de l'espace disque utilisé par le cache, mais s'il - s'arrête en douceur en cas d'erreur disque et se comporte alors - comme si le cache n'avait jamais existé.

- -

Par contre l'utilitaire - htcacheclean fourni avec - httpd - vous permet de nettoyer le cache périodiquement. - Déterminer la fréquence à laquelle lancer htcacheclean et la taille souhaitée - pour le cache est une tâche relativement complexe et il vous faudra de - nombreux essais et erreurs pour arriver à sélectionner des valeurs - optimales.

- -

htcacheclean opère selon deux - modes. Il peut s'exécuter comme démon résident, ou être lancé - périodiquement par cron. htcacheclean peut mettre une heure - ou plus pour traiter de très grands caches (plusieurs dizaines de - Gigaoctets) et si vous l'exécutez à partir de cron, il vous est - conseillé de déterminer la durée typique d'un traitement, afin d'éviter - d'exécuter plusieurs instances à la fois.

- -

Il est aussi conseillé d'attribuer un niveau de priorité "nice" - approprié à htcacheclean de façon à ce qu'il n'effectue pas trop - d'accès disque pendant le fonctionnement du serveur.

- -

-
- Figure 1: Croissance - typique du cache / séquence de nettoyage.

- -

Comme mod_cache_disk ne tient pas compte de l'espace - utilisé dans le cache, vous devez vous assurer que - htcacheclean est configuré de - façon à laisser suffisamment d'"espace de croissance" - à la suite d'un nettoyage.

- - -

Cache en mémoire

- - -

En utilisant le module mod_cache_socache, - mod_cache peut mettre en cache des données à partir de - diverses implémentations aussi nommées "fournisseurs". Par exemple, en - utilisant le module mod_socache_memcache, on peut - spécifier que c'est memcached qui doit - être utilisé comme mécanisme de stockage sous-jacent.

- -

Typiquement, le module sera configuré comme suit :

- - 
CacheEnable socache /
-CacheSocache memcache:memcd.example.com:11211
- - -

En outre, il est possible de spécifier plusieurs serveurs - memcached en les ajoutant à la fin de la ligne - CacheSocache memcache: et en les séparant par des virgules :

- - 
CacheEnable socache /
-CacheSocache memcache:mem1.example.com:11211,mem2.example.com:11212
- - -

Divers autres fournisseurs mod_cache_socache utilisent - aussi ce format. Par exemple :

- - 
CacheEnable socache /
-CacheSocache shmcb:/path/to/datafile(512000)
- - - 
CacheEnable socache /
-CacheSocache dbm:/path/to/datafile
- - - - -
top
-
-

Mise en cache générale d'objets partagés à deux états de forme - clé/valeur

- - - -
Modules ApparentésDirectives Apparentées
- -

Le serveur HTTP Apache fournit un cache d'objets partagés de bas - niveau pour la mise en cache d'informations comme les sessions SSL - ou les données d'authentification dans l'interface socache.

- -

Pour chaque implémentation un module supplémentaire est fourni - qui offre les services d'arrière-plan suivants :

- -
-
mod_socache_dbm
-
Cache d'objets partagés basé sur DBM.
-
mod_socache_dc
-
Cache d'objets partagés basé sur Distcache.
-
mod_socache_memcache
-
Cache d'objets partagés basé sur Memcache.
-
mod_socache_shmcb
-
Cache d'objets partagés basé sur la mémoire partagée.
-
- -

Mise en cache des données d'authentification

- - -
Modules ApparentésDirectives Apparentées
- -

Le module mod_authn_socache permet la mise en - cache des données issues d'une authentification, diminuant ainsi - la charge des serveurs d'authentification d'arrière-plan.

- - - -

Mise en cache des sessions SSL

- - -
Modules ApparentésDirectives Apparentées
- -

Le module mod_ssl utilise l'interface - socache pour fournir un cache de session et un cache - de base.

- - - -
top
-
-

Mise en cache à base de fichiers spécialisés

- - - -
Modules ApparentésDirectives Apparentées
- -

Sur les plateformes où le système de fichiers peut être lent, ou - lorsque les descripteurs de fichiers sont gourmands en ressources, - il est possible de précharger des fichiers en mémoire au démarrage - du serveur.

- -

Sur les systèmes où l'ouverture des fichiers est lente, il est - possible d'ouvrir le fichier au démarrage du serveur et de mettre en - cache le descripteur de fichier. Ces options peuvent vous aider sur - les systèmes où l'accès aux fichiers statiques est lent.

- -

Mise en cache des descripteurs de fichier

- - -

Le processus d'ouverture d'un fichier peut être en soi une - source de ralentissement, en particulier sur les systèmes de - fichiers sur le réseau. httpd permet d'éviter ce ralentissement en - maintenant un cache des descripteurs de fichiers ouverts pour les - fichiers souvent servis. Actuellement, httpd fournit une seule - implémentation de mise en cache des descripteurs de fichiers.

- -

CacheFile

- - -

La forme la plus basique de mise en cache que propose httpd - est la mise en cache des descripteurs de fichiers fournie par le - module mod_file_cache. Plutôt que de mettre en - cache le contenu des fichiers, ce cache maintient une table des - descripteurs de fichiers ouverts. Les fichiers devant faire - l'objet d'une mise en cache de ce type sont spécifiés dans le - fichier de configuration via la directive CacheFile.

- -

La directive CacheFile informe httpd - qu'il doit ouvrir le fichier lors de son démarrage et qu'il doit - réutiliser le descripteur de fichier mis en cache pour tous les - accès futurs à ce fichier.

- - 
CacheFile /usr/local/apache2/htdocs/index.html
- - -

Si vous désirez mettre en cache un grand nombre de fichiers - de cette manière, vous devez vous assurer que le nombre maximal - de fichiers ouverts pour votre système d'exploitation est défini - à une valeur suffisante.

- -

Bien que l'utilisation de la directive CacheFile n'entraîne pas de - mise en cache du contenu du fichier proprement dit, elle - implique que si le fichier est modifié pendant l'exécution du - serveur, ces modifications ne seront pas prises en compte. Le - fichier sera toujours servi dans l'état où il se trouvait au - moment du démarrage du serveur.

- -

Si le fichier est supprimé pendant l'exécution du serveur, ce - dernier conservera le descripteur de fichier ouvert associé et - servira le fichier dans l'état où il se trouvait au - moment du démarrage du serveur. Cela signifie aussi que même si - le fichier a été supprimé, et n'apparaît donc plus dans le - système de fichiers, l'espace disque libéré ne sera disponible - qu'une fois le serveur httpd arrêté et donc le descripteur de - fichier fermé.

- - - - -

In-Memory Caching

- - -

Servir un contenu directement depuis la mémoire système est - universellement reconnu comme la méthode la plus rapide. Lire des fichiers - depuis un contrôleur de disque ou pire, depuis un réseau distant est plus - lent de plusieurs ordres de grandeur. Les contrôleurs de disque réalisent - en général des opérations mécaniques, et l'accès au réseau est limité par la - bande passante dont vous disposez. Par contre, les temps d'accès à la - mémoire sont de l'ordre de la nano-seconde.

- -

Cependant la mémoire système n'est pas bon marché; à capacité égale, - c'est de loin le type de stockage le plus coûteux et il est important de - s'assurer qu'elle est utilisée efficacement. Le fait de mettre en cache - des fichiers en mémoire diminue d'autant la quantité de mémoire système - disponible. Comme nous le verrons plus loin, ce n'est pas un problème en - soi dans le cas de la mise en cache par l'intermédiaire du système - d'exploitation, mais si l'on utilise la mise en cache en mémoire propre à - httpd, il faut prendre garde à ne pas allouer trop de mémoire au cache. - Sinon le système sera contraint d'utiliser le swap, ce qui dégradera - sensiblement les performances.

- -

Mise en cache par l'intermédiaire du système d'exploitation

- - -

Dans la plupart des systèmes d'exploitation modernes, c'est le noyau - qui gère directement la mise en cache en mémoire des données relatives - aux fichiers. C'est une fonctionnalité puissante, et les systèmes - d'exploitation s'en acquittent fort bien pour la plus grande partie. - Considérons par exemple, dans le cas de Linux, la différence entre le - temps nécessaire à la première lecture d'un fichier et le temps - nécessaire à sa deuxième lecture;

- - 
colm@coroebus:~$ time cat testfile > /dev/null
-real    0m0.065s
-user    0m0.000s
-sys     0m0.001s
-colm@coroebus:~$ time cat testfile > /dev/null
-real    0m0.003s
-user    0m0.003s
-sys     0m0.000s
- -

Même pour ce petit fichier, il y a une grande différence entre les - temps nécessaires pour lire le fichier. Ceci est du au fait que le - noyau a mis en cache le contenu du fichier en mémoire.

- -

Du fait de toujours pouvoir disposer de mémoire système, vous pouvez - être assuré qu'il y aura de plus en plus de contenus de fichiers stockés - dans ce cache. Ceci peut s'avérer une méthode de mise en cache en mémoire - très efficace, et ne nécessite aucune configuration supplémentaire - de httpd.

- -

De plus, comme le système d'exploitation sait si des fichiers - ont été - supprimés ou modifiés, il peut effacer automatiquement des contenus de - fichiers du cache lorsque cela s'avère nécessaire. Ceci constitue un gros - avantage par rapport à la mise en cache en mémoire - de httpd qui n'a - aucune possibilité de savoir si un fichier a été modifié.

- - -

En dépit des performances et des avantages de la mise en cache - automatique par le système d'exploitation, la mise en cache en mémoire - peut être effectuée plus efficacement par httpd dans certaines - circonstances.

- -

Mise en cache à l'aide de la directive MMapFile

- - -

La directive MMapFile - fournie par le module mod_file_cache vous permet de - demander à httpd de charger un contenu de fichier statique en mémoire - lors de son démarrage (à l'aide de l'appel - système mmap). httpd - utilisera le contenu chargé en mémoire pour satisfaire ultérieurement - toutes les demandes d'accès à ce fichier.

- - 
MMapFile /usr/local/apache2/htdocs/index.html
- - -

Comme dans le cas de la directive - CacheFile, toute - modification du fichier ne sera plus prise en compte par httpd une fois - ce dernier démarré.

- -

La directive - MMapFile ne gardant - pas la trace de la quantité de mémoire qu'elle alloue, vous devez prendre - garde de ne pas en abuser. Chaque processus enfant de httpd utilisant - sa propre réplique de la mémoire allouée, il est donc d'une importance - critique de s'assurer que les fichiers chargés ne sont pas d'une taille - trop importante afin d'épargner au système l'utilisation du swap.

- - - -
top
-
-

Considérations sur la sécurité

- - -

Autorisation et contrôle d'accès

- - -

Utiliser mod_cache revient sensiblement à la même - chose qu'avoir un mandataire inverse intégré (reverse-proxy). Les requêtes - seront servies par le module de mise en cache sauf si ce dernier - détermine qu'un processus d'arrière-plan doit être appelé. La mise en - cache de ressources locales modifie considérablement le modèle de - sécurité de httpd.

- -

Comme le parcours de la hiérarchie d'un système de fichiers pour - examiner le contenu d'éventuels fichiers - .htaccess serait une opération très coûteuse en ressources, - annulant partiellement de ce fait l'intérêt de la mise en cache - (accélérer le traitement des requêtes), - mod_cache ne se préoccupe pas de savoir s'il a - l'autorisation de servir une entité mise en cache. En d'autres termes, - si mod_cache a mis en cache un certain contenu, ce - dernier sera servi à partir du cache tant qu'il ne sera pas arrivé à - expiration.

- -

Si par exemple, votre configuration autorise l'accès à une ressource - en fonction de l'adresse IP, vous devez vous assurer que ce contenu n'est - pas mis en cache. Ceci est possible en utilisant la directive - CacheDisable, ou le module - mod_expires. Livré à lui-même, - mod_cache - pratiquement comme un mandataire inverse - - mettrait en cache le contenu lors de son service, et le servirait ensuite - à tout client, vers n'importe quelle adresse IP.

- -

Lorsque la directive CacheQuickHandler est définie à - Off, toutes les phases du traitement de la requête - sont exécutées et le modèle de sécurité reste le même.

- - - -

Piratages locaux

- - -

Etant donné que les requêtes des utilisateurs finaux peuvent être - servies depuis le cache, ce dernier est une cible potentielle pour ceux - qui veulent défigurer un contenu ou interférer avec lui. Il est important - de garder à l'esprit que l'utilisateur sous lequel tourne - httpd doit - toujours avoir l'accès en écriture dans le cache. Ceci est en contraste - total avec la recommandation usuelle d'interdire à l'utilisateur sous - lequel tourne Apache - l'accès en écriture à tout contenu.

- -

Si l'utilisateur sous lequel tourne Apache est compromis, - par exemple à cause d'une - faille de sécurité dans un processus CGI, il est possible que le cache - fasse l'objet d'une attaque. Il est relativement aisé d'insérer ou de - modifier une entité dans le cache en utilisant le module - mod_cache_disk.

- -

Cela représente un risque relativement élévé par rapport aux autres - types d'attaques qu'il est possible de mener sous l'utilisateur apache. - Si vous utilisez mod_cache_disk, vous devez garder ceci - à l'esprit : effectuez toujours les mises à jour de - httpdquand des - correctifs de sécurité sont annoncés et exécutez les processus CGI sous - un utilisateur autre qu'apache en utilisant - suEXEC dans la mesure du possible.

- - - -

Empoisonnement du cache (Cache Poisoning)

- - -

Si vous utilisez httpd comme serveur mandataire avec mise en cache, - vous vous exposez aussi à un éventuel "Empoisonnement du - cache" (Cache poisoning). L'empoisonnement du cache est un terme général - pour désigner les attaques au cours desquelles l'attaquant fait en sorte - que le serveur mandataire renvoie à un contenu incorrect (et souvent - indésirable) suite à en provenance du serveur d'arrière-plan. -

- -

Par exemple, si les serveur DNS qu'utilise votre système où tourne - httpd sont vulnérables à l'empoisonnement du cache des DNS, un attaquant - pourra contrôler vers où httpd se connecte lorsqu'il demande un contenu - depuis le serveur d'origine. - Un autre exemple est constitué par les attaques ainsi nommées - "Dissimulation de requêtes HTTP" (HTTP request-smuggling).

- -

Ce document n'est pas le bon endroit pour une discussion approfondie - à propos de la Dissimulation de requêtes HTTP (utilisez plutôt votre - moteur de recherche favori); il est cependant important de savoir qu'il - est possible d'élaborer une série de requêtes, et d'exploiter une - vulnérabilité d'un serveur web d'origine de telle façon que l'attaquant - puisse contrôler entièrement le contenu renvoyé par le mandataire.

- - -

Déni de Service / Cachebusting

- - -

Le mécanisme utilisé via l'en-tête Vary permet de mettre en - cache simultanément plusieurs variantes d'une ressource avec la - même URL. Le cache sélectionne la variante correcte à envoyer au - client en fonction des valeurs d'en-tête fournies par ce dernier. - Ce mécanisme peut devenir un problème lorsqu'on tente d'appliquer - le mécanisme des variantes à un en-tête connu pour pouvoir - posséder un grand nombre de valeurs - possibles en utilisation normal, comme par exemple l'en-tête - User-Agent. En fonction de la popularité du site web, - des milliers ou même des millions d'entrées de cache dupliquées - peuvent être créées pour la même URL, submergeant les autres - entrées du cache.

- -

Dans d'autres cas, il peut être nécessaire de modifier l'URL - d'une ressource particulière à chaque requête, en général en lui - ajoutant une chaîne "cachebuster". Si ce contenu est déclaré comme - pouvant être mis en cache par un serveur avec une durée de - fraîcheur significative, ces entrées peuvent submerger les entrées - légitimes du cache. Alors que mod_cache fournit - une directive CacheIgnoreURLSessionIdentifiers, - cette dernière doit être utilisée avec prudence pour s'assurer que - les caches du navigateur ou du mandataire le plus proche - (downstream proxy) ne sont pas victimes du même problème de Déni de - service.

- -
-
-

Langues Disponibles:  en  | - fr  | - tr 

-
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
-
- \ No newline at end of file diff --git a/docs/manual/caching.html.fr.utf8 b/docs/manual/caching.html.fr.utf8 new file mode 100644 index 0000000000..cfd850872c --- /dev/null +++ b/docs/manual/caching.html.fr.utf8 @@ -0,0 +1,1003 @@ + + + + + +Guide de la mise en cache - Serveur HTTP Apache Version 2.5 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.5

+
+
<-
+

Guide de la mise en cache

+
+

Langues Disponibles:  en  | + fr  | + tr 

+
+ +

Ce document complète la documentation de référence des modules + mod_cache, mod_cache_disk, + mod_file_cache et du programme htcacheclean. + Il décrit l'utilisation des fonctionnalités de mise en + cache du serveur HTTP Apache + pour accélérer les services web et proxy, tout en évitant les problèmes + courants et les erreurs de configuration.

+
+ +
top
+
+

Introduction

+ + +

Le serveur HTTP Apache offre tout un ensemble de fonctionnalités + de mise en cache qui ont été conçues pour améliorer les performances + du serveur de différentes manières.

+ +
+
Mise en cache HTTP à trois états RFC2616
+
mod_cache et son module de fournisseur + mod_cache_disk proposent une mise en cache + intelligente de niveau HTTP. Le contenu proprement dit est + stocké dans le cache, et mod_cache vise à respecter tous les + en-têtes HTTP, ainsi que les options qui contrôlent la mise en + cache du contenu comme décrit dans la Section + 13 de la RFC2616. mod_cache peut gérer des + configurations de mise en cache simples, mais aussi complexes + comme dans les cas où vous avez à faire à des contenus mandatés, + à des contenus locaux dynamiques, ou lorsque vous avez besoin + d'accélérer l'accès aux fichiers locaux situés sur disque + supposé lent. +
+ +
Mise en cache d'objets partagés de forme clé/valeur à deux + états
+
+ L'API du cache d'objets partagés (socache) + et ses modules de fournisseurs + proposent une mise en cache d'objets partagés à base de + couples clé/valeur de niveau serveur. Ces modules sont + conçus pour la mise en cache de données de bas niveau comme + les sessions SSL et les données d'authentification. les + serveurs d'arrière-plan permettent le stockage des données + au niveau serveur en mémoire partagée, ou au niveau + datacenter dans un cache comme memcache ou distcache. +
+ +
Mise en cache de fichiers spécialisée
+
+ mod_file_cache offre la possibilité de + précharger des fichiers en mémoire au démarrage du serveur, + et peut améliorer les temps d'accès et sauvegarder les + gestionnaires de fichiers pour les fichiers qui font l'objet + d'accès fréquents, évitant ainsi d'avoir à accéder au disque + à chaque requête. +
+
+ +

Pour tirer parti efficacement de ce document, les bases de HTTP doivent + vous être familières, et vous devez avoir lu les sections + Mise en correspondance des + URLs avec le système de fichiers et + Négociation sur le contenu + du guide de l'utilisateur.

+ +
top
+
+

Mise en cache HTTP à trois états RFC2616

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

Le module mod_cache permet de tirer avantage du + mécanisme de mise en cache en ligne faisant partie + intégrante du protocole HTTP, et décrit dans la section + 13 de la RFC2616.

+ +

A la différence d'un cache simple clé/valeur à deux états où le + contenu est supprimé lorsqu'il est périmé, un cache HTTP comporte un + mécanisme permettant de conserver temporairement un contenu périmé, + de demander au serveur original si ce contenu périmé a été modifié, + et dans le cas contraire de le rendre à nouveau valide.

+ +

Une entrée d'un cache HTTP peut se présenter sous un de ces trois + états :

+ +
+
Frais
+
+ Si un contenu est suffisamment récent (plus jeune que sa + durée de fraîcheur), il est considéré comme + frais. Un cache HTTP peut servir un contenu + frais sans avoir à demander quoi que ce soit au serveur + d'origine. +
+
Périmé
+
+

Si le contenu est trop ancien (plus vieux que sa + durée de fraîcheur), il est considéré comme + périmé. Un cache HTTP doit contacter le serveur + original pour vérifier si le contenu, même s'il est périmé, est + encore à jour avant de le servir au client. Soit le serveur + original va répondre en envoyant un contenu de remplacement si + le contenu périmé n'est plus à jour, soit dans le cas idéal il + renverra un code pour signaler au cache que le contenu est + encore à jour, et qu'il est inutile de le générer ou de + l'envoyer à nouveau. Le contenu repasse à l'état "frais" et le + cycle continue.

+ +

Le protocole HTTP permet au cache de servir des données + périmées dans certaines circonstances, comme lorsqu'une + tentative de rafraîchir une entrée depuis un serveur original + se solde par un échec avec un code d'erreur 5xx, ou lorsqu'une + autre requête est déjà en train d'essayer de rafraîchir la même + entrée. Dans ces cas, un en-tête Warning est ajouté + à la réponse.

+
+
Non Existent
+
+ Si le cache est plein, il se réserve la possibilité de supprimer + des entrées pour faire de la place. Une entrée peut être + supprimée à tout moment, qu'elle soit fraîche ou périmée. + L'outil htcacheclean + peut être utilisé à la demande, ou lancé en tant que démon afin + de conserver la taille du cache ou le nombre d'inodes en deçà de + valeurs spécifiées. Cet outil essaie cependant de + supprimer les entrées périmées avant les entrées fraîches. +
+
+ +

Le fonctionnement détaillé d'un cache HTTP est décrit dans la Section + 13 de la RFC2616.

+ +

Interaction avec le serveur

+ + +

Le module mod_cache interagit avec le serveur + à deux niveaux possibles en fonction de la directive CacheQuickHandler : +

+ +
+
Phase du gestionnaire rapide
+
+

Cette phase se déroule très tôt au cours du traitement de + la requête, juste après l'interprétation de cette dernière. Si + le contenu se trouve dans le cache, il est servi immédiatement + et pratiquement tout le reste du traitement de la requête est + court-circuité.

+ +

Dans ce scénario, le cache se comporte comme s'il avait + été "boulonné" à l'entrée du serveur.

+ +

Ce mode possède les meilleures performances car la + majorité des traitements au niveau du serveur sont + court-circuités. Cependant, il court-circuite aussi les + phases d'authentification et d'autorisation du traitement + au niveau du serveur, et il doit donc être utilisé avec + prudence lorsque que ces phases sont importantes.

+ +

Les requêtes contenant un en-tête "Authorization" + header (par exemple dans le cas de l'authentification HTTP + basique) ne peuvent ni être mises en cache, ni servies + depuis le cache lorsque mod_cache + s'exécute dans cette phase.

+
+
Phase du gestionnaire normal
+
+

Cette phase se déroule très tard au cours du traitement + de la requête, en fait après toutes les phases de ce + traitement.

+ +

Dans ce scénario, le cache se comporte comme s'il avait + été "boulonné" à la sortie du serveur.

+ +

Ce mode offre la plus grande souplesse, car il permet + de faire intervenir la mise en cache en un point + précisément spécifié de la chaîne de filtrage, et le + contenu issu du cache peut être filtré ou personnalisé + avant d'être servi au client.

+
+
+ +

Si l'URL ne se trouve pas dans le cache, + mod_cache ajoutera un filtre à la chaîne de filtrage afin + d'enregistrer la réponse dans le cache, puis passera la main + pour permettre le déroulement normal de la suite du traitement + de la requête. Si la mise en cache du contenu est autorisée, il + sera enregistré dans le cache pour pouvoir être servi à nouveau + ; dans le cas contraire, le contenu sera ignoré.

+ +

Si le contenu trouvé dans le cache est périmé, le module + mod_cache convertit la requête en + requête conditionnelle. Si le serveur original + renvoie une réponse normale, elle est enregistrée dans le cache + en lieu et place du contenu périmé. Si le serveur original + renvoie une réponse "304 Not Modified", le contenu repasse à + l'état "frais" et est servi par le filtre au lieu d'être + sauvegardé.

+ + +

Amélioration du taux de présence dans le cache

+ + +

Lorsqu'un serveur virtuel est connu sous la forme d'un des + nombreux alias du serveur, la définition de la directive + UseCanonicalName à + On peut augmenter de manière significative le nombre + de correspondances positives dans le cache. Ceci est du au fait + que la clé du cache contient le nom d'hôte du serveur virtuel. + Avec UseCanonicalName positionnée + à On, + les hôtes virtuels possédant plusieurs noms de serveur ou alias ne + généreront pas d'entités de cache différentes, et le contenu sera mis en + cache en faisant référence au nom d'hôte canonique.

+ + + +

Durée de fraîcheur

+ + +

Un contenu bien formé destiné à être mis en cache doit déclarer + explicitement une durée de fraîcheur via les champs + max-age ou s-maxage de l'en-tête + Cache-Control, ou en incluant un en-tête + Expires.

+ +

De plus, un client peut passer outre la durée de fraîcheur + définie pour le serveur original en ajoutant son propre en-tête + Cache-Control à la requête. Dans ce cas, c'est la + durée de fraîcheur la plus basse entre la requête et la réponse + qui l'emporte.

+ +

Lorsque cette durée de fraîcheur est absente de la requête ou + de la réponse, une durée de fraîcheur par défaut s'applique. La + durée de fraîcheur par défaut des entrées du cache est d'une heure + ; elle peut cependant être facilement modifiée à l'aide de + la directive CacheDefaultExpire.

+ +

Si une réponse ne contient pas d'en-tête Expires mais + inclut un en-tête Last-Modified, mod_cache + peut déduire une durée de fraîcheur en se basant sur une + heuristique, qui peut être contrôlée via la directive CacheLastModifiedFactor.

+ +

Pour les contenus locaux, ou les contenus distants qui ne + spécifient pas leur propre en-tête Expires, + mod_expires permet de régler finement la durée de + fraîcheur via les paramètres max-age et + Expires.

+ +

On peut aussi contrôler la durée de fraîcheur maximale en utilisant + la directive CacheMaxExpire.

+ + + +

Guide succinct des requêtes conditionnelles

+ + +

Lorsqu'un contenu du cache est périmé, httpd modifie la requête + pour en faire une requête conditionnelle

+ +

Lorsque la réponse originale du cache contient un en-tête + ETag, mod_cache ajoute un en-tête + If-None-Match à la requête envoyée au serveur + d'origine. Lorsque la réponse originale du cache contient un en-tête + Last-Modified, mod_cache ajoute un en-tête + If-Modified-Since à la requête envoyée au serveur + d'origine. Dans ces deux cas, la requête devient une requête + conditionnelle.

+ +

Lorsqu'un serveur d'origine reçoit une requête conditionnelle, + il vérifie si le paramètre Etag ou Last-Modified a été modifié en + fonction des paramètres de la requête. Si ce n'est pas le cas, il + répondra avec le message lapidaire "304 Not Modified". Ceci + informe le cache que le contenu est périmé mais encore à jour, et + peut être utilisé tel quel pour les prochaines requêtes jusqu'à ce + qu'il atteigne à nouveau sa date de péremption.

+ +

Si le contenu a été modifié, il est servi comme s'il s'agissait + d'une requête normale et non conditionnelle.

+ +

Les requêtes conditionnelles offrent deux avantages. D'une + part, il est facile de déterminer si le contenu du serveur + d'origine correspond à celui situé + dans le cache, et ainsi d'économiser la consommation de ressources + nécessaire au transfert du contenu dans son ensemble.

+ +

D'autre part, un serveur d'origine bien conçu sera configuré de + telle manière que les requêtes conditionnelles nécessitent pour + leur production bien moins de ressources qu'une réponse complète. + Dans le cas des fichiers statiques, il suffit en général d'un + appel système de type stat() ou similaire pour + déterminer si la taille ou la date de modification du fichier a + été modifiée. Ainsi, même un contenu local pourra être servi plus + rapidement depuis le cache s'il n'a pas été modifié.

+ +

Il serait souhaitable que tous les serveurs d'origine + supportent les requêtes conditionnelles, car dans le cas + contraire, ils répondent comme s'il s'agissait d'une requête + normale, et le cache répond comme si le contenu avait été + modifié et enregistre ce dernier. Le cache se comporte alors + comme un simple cache à deux état, où le contenu est servi s'il + est à jour, ou supprimé dans le cas contraire.

+ + +

Que peut-on mettre en cache ?

+ + +

La liste complète des conditions nécessaires pour qu'une + réponse puisse être enregistrée dans un cache HTTP est fournie + dans la section + 13.4 Response Cacheability de la RFC2616, et peut se résumer + ainsi :

+ +
    +
  1. La mise en cache doit être activée pour cette URL. Voir les + directives CacheEnable et CacheDisable.
    2. + +
  2. Si la reponse possède un code de statut HTTP autre que 200, 203, 300, 301 + ou 410, elle doit aussi comporter un en-tête "Expires" ou + "Cache-Control".
    3. + +
  3. La requête doit être de type HTTP GET.
    4. + +
  4. Si la réponse contient un en-tête "Authorization:", elle doit aussi + contenir une option "s-maxage", "must-revalidate" ou "public" + dans l'en-tête "Cache-Control:".
    5. + +
  5. Si l'URL contient une chaîne de requête + (provenant par exemple d'une méthode GET de formulaire HTML), elle ne + sera pas mise en cache, à moins que la réponse ne + spécifie explicitement un délai d'expiration via un + en-tête "Expires:" ou une directive max-age ou s-maxage de + l'en-tête "Cache-Control:" comme indiqué dans les + sections 13.2.1. et 13.9 de la RFC2616.
    6. + +
  6. Si la réponse a un statut de 200 (OK), elle doit aussi contenir + au moins un des en-têtes "Etag", "Last-Modified" ou + "Expires", ou une directive max-age ou s-maxage de + l'en-tête "Cache-Control:", à moins que la directive + CacheIgnoreNoLastMod + ne précise d'autres contraintes.
    7. + +
  7. Si la réponse contient l'option "private" dans un en-tête + "Cache-Control:", elle ne sera pas mise en cache à moins que la + directive + CacheStorePrivate + ne précise d'autres contraintes.
    8. + +
  8. De même, si la réponse contient l'option "no-store" dans un en-tête + "Cache-Control:", elle ne sera pas mise en cache à moins que la + directive + CacheStoreNoStore + n'ait été utilisée.
    9. + +
  9. Une réponse ne sera pas mise en cache si elle comporte un en-tête + "Vary:" contenant le caractère "*" qui correspond à toute + chaîne de caractères.
    10. +
+ + +

Qu'est ce qui ne doit pas être mis en cache ?

+ + +

Le client qui crée la requête ou le serveur d'origine qui + génère la réponse doit être à même de déterminer si le contenu + doit pouvoir être mis en cache ou non en définissant correctement + l'en-tête Cache-Control, et + mod_cache sera alors en mesure de satisfaire les + souhaits du client ou du serveur de manière appropriée. +

+ +

Les contenus qui varient au cours du temps, ou en fonction de + particularités de la requête non prises en compte par la + négociation HTTP ne doivent pas être mis en cache. Ce type de + contenu doit se déclarer lui-même "à ne pas mettre en cache" via + l'en-tête Cache-Control.

+ +

Si le contenu change souvent, suite par exemple à une durée de + fraîcheur de l'ordre de la minute ou de la seconde, il peut tout + de même être mis en cache, mais il est alors fortement souhaitable + que le serveur d'origine supporte correctement les + requêtes conditionnelles afin que des réponses + complètes ne soient pas systématiquement générées.

+ +

Un contenu qui varie en fonction d'en-têtes de requête fournis + par le client peut être mis en cache, sous réserve d'une + utilisation appropriée de l'en-tête de réponse Vary.

+ + +

Contenu variable et/ou négocié

+ + +

Lorsque le serveur d'origine est configuré pour servir des + contenus différents en fonction de la valeur de certains en-têtes + de la requête, par exemple pour servir une ressource en plusieurs + langages à partir d'une seule URL, le mécanisme de mise en cache + d'HTTP permet de mettre en cache plusieurs variantes de la même + page à partir d'une seule URL.

+ +

Pour y parvenir, le serveur d'origine ajoute un en-tête + Vary pour indiquer quels en-têtes doivent être pris + en compte par un cache pour déterminer si deux variantes sont + différentes l'une de l'autre.

+ +

Si par exemple, une réponse est reçue avec l'en-tête Vary suivant,

+ +

+Vary: negotiate,accept-language,accept-charset +

+ +

mod_cache ne servira aux demandeurs que le contenu + mis en cache qui correspond au contenu des en-têtes accept-language et + accept-charset de la requête originale.

+ +

Plusieurs variantes d'un contenu peuvent être mises en cache + simultanément ; mod_cache utilise l'en-tête + Vary et les valeurs correspondantes des en-têtes de + la requête spécifiés dans ce dernier pour + déterminer quelle variante doit être servie au client.

+ + + +
top
+
+

Exemples de configuration du cache

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

Mise en cache sur disque

+ + +

Le module mod_cache s'appuie sur des + implémentations de stockage sous-jacentes spécifiques pour gérer + le cache ; à ce titre, mod_cache_disk fournit le + support de la mise en cache sur disque.

+ +

En général, le module se configure comme suit :

+ + 
CacheRoot   "/var/cache/apache/"
+CacheEnable disk /
+CacheDirLevels 2
+CacheDirLength 1
+ + +

Il est important de savoir que, les fichiers mis en cache étant stockés + localement, la mise en cache par l'intermédiaire du système d'exploitation + sera en général aussi appliquée à leurs accès. Si bien que même si les + fichiers sont stockés sur disque, s'il font l'objet d'accès fréquents, + il est probable que le système d'exploitation s'appliquera à ce qu'ils + soient servis à partir de la mémoire.

+ + + +

Comprendre le stockage dans le cache

+ + +

Pour stocker des entités dans le cache, + le module mod_cache_disk crée une empreinte (hash) de 22 + caractères de l'URL qui a fait l'objet d'une requête. Cette empreinte + comprend le nom d'hôte, le protocole, le port, le chemin et tout argument + de type CGI associé à l'URL, ainsi que les éléments + spécifiés dans l'en-tête Vary afin d'être sur que plusieurs URLs + n'interfèrent pas entre elles.

+ +

Chaque position de l'empreinte peut contenir un caractère + choisi parmi 64 caractères différents, il y a donc + 64^22 possibilités pour une empreinte. Par exemple, une URL peut posséder + l'empreinte xyTGxSMO2b68mBCykqkp1w. Cette empreinte est + utilisée pour préfixer les noms de fichiers spécifiques à cette URL à + l'intérieur du cache; cependant, elle est tout d'abord placée dans les + répertoires du cache selon les directives + CacheDirLevels et + CacheDirLength.

+ +

La directive + CacheDirLevels + définit le nombre de niveaux de sous-répertoires, et + CacheDirLength + le nombre de caractères composant le nom des sous-répertoires. Dans + l'exemple donné plus haut, l'empreinte se trouvera à : + /var/cache/apache/x/y/TGxSMO2b68mBCykqkp1w.

+ +

Cette technique a pour but principal de réduire le nombre de + sous-répertoires ou de fichiers contenus dans un répertoire particulier, + car le fonctionnement de la plupart des systèmes de fichiers est ralenti + quand ce nombre augmente. Avec la valeur "1" pour la directive + CacheDirLength, + il peut y avoir au plus 64 sous-répertoires à un niveau quelconque. + Avec la valeur "2", il peut y en avoir 64 * 64, etc... + A moins d'avoir une bonne raison pour ne pas le faire, l'utilisation de + la valeur "1" pour la directive + CacheDirLength + est recommandée.

+ +

Le paramétrage de la directive + CacheDirLevels + dépend du nombre de fichiers que vous pensez stocker dans le cache. + Avec une valeur de "2" comme dans l'exemple donné plus haut, + 4096 sous-répertoires peuvent être créés au total. Avec 1 million de + fichiers dans le cache, cela équivaut à environ 245 URLs mises en cache + dans chaque répertoire.

+ +

Chaque URL nécessite au moins deux fichiers dans le cache. Ce sont en + général un fichier ".header", qui contient des meta-informations à propos + de l'URL, comme la date de son arrivée à expiration, + et un fichier ".data" qui est la copie exacte du contenu à servir.

+ +

Dans le cas d'un contenu négocié via l'en-tête "Vary", un répertoire + ".vary" sera créé pour l'URL en question. Ce répertoire contiendra de + multiples fichiers ".data" correspondant aux différents contenus + négociés.

+ + +

Maintenance du cache sur disque

+ + +

Le module mod_cache_disk n'effectue aucune + régulation de l'espace disque utilisé par le cache, mais s'il + s'arrête en douceur en cas d'erreur disque et se comporte alors + comme si le cache n'avait jamais existé.

+ +

Par contre l'utilitaire + htcacheclean fourni avec + httpd + vous permet de nettoyer le cache périodiquement. + Déterminer la fréquence à laquelle lancer htcacheclean et la taille souhaitée + pour le cache est une tâche relativement complexe et il vous faudra de + nombreux essais et erreurs pour arriver à sélectionner des valeurs + optimales.

+ +

htcacheclean opère selon deux + modes. Il peut s'exécuter comme démon résident, ou être lancé + périodiquement par cron. htcacheclean peut mettre une heure + ou plus pour traiter de très grands caches (plusieurs dizaines de + Gigaoctets) et si vous l'exécutez à partir de cron, il vous est + conseillé de déterminer la durée typique d'un traitement, afin d'éviter + d'exécuter plusieurs instances à la fois.

+ +

Il est aussi conseillé d'attribuer un niveau de priorité "nice" + approprié à htcacheclean de façon à ce qu'il n'effectue pas trop + d'accès disque pendant le fonctionnement du serveur.

+ +

+
+ Figure 1: Croissance + typique du cache / séquence de nettoyage.

+ +

Comme mod_cache_disk ne tient pas compte de l'espace + utilisé dans le cache, vous devez vous assurer que + htcacheclean est configuré de + façon à laisser suffisamment d'"espace de croissance" + à la suite d'un nettoyage.

+ + +

Cache en mémoire

+ + +

En utilisant le module mod_cache_socache, + mod_cache peut mettre en cache des données à partir de + diverses implémentations aussi nommées "fournisseurs". Par exemple, en + utilisant le module mod_socache_memcache, on peut + spécifier que c'est memcached qui doit + être utilisé comme mécanisme de stockage sous-jacent.

+ +

Typiquement, le module sera configuré comme suit :

+ + 
CacheEnable socache /
+CacheSocache memcache:memcd.example.com:11211
+ + +

En outre, il est possible de spécifier plusieurs serveurs + memcached en les ajoutant à la fin de la ligne + CacheSocache memcache: et en les séparant par des virgules :

+ + 
CacheEnable socache /
+CacheSocache memcache:mem1.example.com:11211,mem2.example.com:11212
+ + +

Divers autres fournisseurs mod_cache_socache utilisent + aussi ce format. Par exemple :

+ + 
CacheEnable socache /
+CacheSocache shmcb:/path/to/datafile(512000)
+ + + 
CacheEnable socache /
+CacheSocache dbm:/path/to/datafile
+ + + + +
top
+
+

Mise en cache générale d'objets partagés à deux états de forme + clé/valeur

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

Le serveur HTTP Apache fournit un cache d'objets partagés de bas + niveau pour la mise en cache d'informations comme les sessions SSL + ou les données d'authentification dans l'interface socache.

+ +

Pour chaque implémentation un module supplémentaire est fourni + qui offre les services d'arrière-plan suivants :

+ +
+
mod_socache_dbm
+
Cache d'objets partagés basé sur DBM.
+
mod_socache_dc
+
Cache d'objets partagés basé sur Distcache.
+
mod_socache_memcache
+
Cache d'objets partagés basé sur Memcache.
+
mod_socache_shmcb
+
Cache d'objets partagés basé sur la mémoire partagée.
+
+ +

Mise en cache des données d'authentification

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

Le module mod_authn_socache permet la mise en + cache des données issues d'une authentification, diminuant ainsi + la charge des serveurs d'authentification d'arrière-plan.

+ + + +

Mise en cache des sessions SSL

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

Le module mod_ssl utilise l'interface + socache pour fournir un cache de session et un cache + de base.

+ + + +
top
+
+

Mise en cache à base de fichiers spécialisés

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

Sur les plateformes où le système de fichiers peut être lent, ou + lorsque les descripteurs de fichiers sont gourmands en ressources, + il est possible de précharger des fichiers en mémoire au démarrage + du serveur.

+ +

Sur les systèmes où l'ouverture des fichiers est lente, il est + possible d'ouvrir le fichier au démarrage du serveur et de mettre en + cache le descripteur de fichier. Ces options peuvent vous aider sur + les systèmes où l'accès aux fichiers statiques est lent.

+ +

Mise en cache des descripteurs de fichier

+ + +

Le processus d'ouverture d'un fichier peut être en soi une + source de ralentissement, en particulier sur les systèmes de + fichiers sur le réseau. httpd permet d'éviter ce ralentissement en + maintenant un cache des descripteurs de fichiers ouverts pour les + fichiers souvent servis. Actuellement, httpd fournit une seule + implémentation de mise en cache des descripteurs de fichiers.

+ +

CacheFile

+ + +

La forme la plus basique de mise en cache que propose httpd + est la mise en cache des descripteurs de fichiers fournie par le + module mod_file_cache. Plutôt que de mettre en + cache le contenu des fichiers, ce cache maintient une table des + descripteurs de fichiers ouverts. Les fichiers devant faire + l'objet d'une mise en cache de ce type sont spécifiés dans le + fichier de configuration via la directive CacheFile.

+ +

La directive CacheFile informe httpd + qu'il doit ouvrir le fichier lors de son démarrage et qu'il doit + réutiliser le descripteur de fichier mis en cache pour tous les + accès futurs à ce fichier.

+ + 
CacheFile /usr/local/apache2/htdocs/index.html
+ + +

Si vous désirez mettre en cache un grand nombre de fichiers + de cette manière, vous devez vous assurer que le nombre maximal + de fichiers ouverts pour votre système d'exploitation est défini + à une valeur suffisante.

+ +

Bien que l'utilisation de la directive CacheFile n'entraîne pas de + mise en cache du contenu du fichier proprement dit, elle + implique que si le fichier est modifié pendant l'exécution du + serveur, ces modifications ne seront pas prises en compte. Le + fichier sera toujours servi dans l'état où il se trouvait au + moment du démarrage du serveur.

+ +

Si le fichier est supprimé pendant l'exécution du serveur, ce + dernier conservera le descripteur de fichier ouvert associé et + servira le fichier dans l'état où il se trouvait au + moment du démarrage du serveur. Cela signifie aussi que même si + le fichier a été supprimé, et n'apparaît donc plus dans le + système de fichiers, l'espace disque libéré ne sera disponible + qu'une fois le serveur httpd arrêté et donc le descripteur de + fichier fermé.

+ + + + +

In-Memory Caching

+ + +

Servir un contenu directement depuis la mémoire système est + universellement reconnu comme la méthode la plus rapide. Lire des fichiers + depuis un contrôleur de disque ou pire, depuis un réseau distant est plus + lent de plusieurs ordres de grandeur. Les contrôleurs de disque réalisent + en général des opérations mécaniques, et l'accès au réseau est limité par la + bande passante dont vous disposez. Par contre, les temps d'accès à la + mémoire sont de l'ordre de la nano-seconde.

+ +

Cependant la mémoire système n'est pas bon marché; à capacité égale, + c'est de loin le type de stockage le plus coûteux et il est important de + s'assurer qu'elle est utilisée efficacement. Le fait de mettre en cache + des fichiers en mémoire diminue d'autant la quantité de mémoire système + disponible. Comme nous le verrons plus loin, ce n'est pas un problème en + soi dans le cas de la mise en cache par l'intermédiaire du système + d'exploitation, mais si l'on utilise la mise en cache en mémoire propre à + httpd, il faut prendre garde à ne pas allouer trop de mémoire au cache. + Sinon le système sera contraint d'utiliser le swap, ce qui dégradera + sensiblement les performances.

+ +

Mise en cache par l'intermédiaire du système d'exploitation

+ + +

Dans la plupart des systèmes d'exploitation modernes, c'est le noyau + qui gère directement la mise en cache en mémoire des données relatives + aux fichiers. C'est une fonctionnalité puissante, et les systèmes + d'exploitation s'en acquittent fort bien pour la plus grande partie. + Considérons par exemple, dans le cas de Linux, la différence entre le + temps nécessaire à la première lecture d'un fichier et le temps + nécessaire à sa deuxième lecture;

+ + 
colm@coroebus:~$ time cat testfile > /dev/null
+real    0m0.065s
+user    0m0.000s
+sys     0m0.001s
+colm@coroebus:~$ time cat testfile > /dev/null
+real    0m0.003s
+user    0m0.003s
+sys     0m0.000s
+ +

Même pour ce petit fichier, il y a une grande différence entre les + temps nécessaires pour lire le fichier. Ceci est du au fait que le + noyau a mis en cache le contenu du fichier en mémoire.

+ +

Du fait de toujours pouvoir disposer de mémoire système, vous pouvez + être assuré qu'il y aura de plus en plus de contenus de fichiers stockés + dans ce cache. Ceci peut s'avérer une méthode de mise en cache en mémoire + très efficace, et ne nécessite aucune configuration supplémentaire + de httpd.

+ +

De plus, comme le système d'exploitation sait si des fichiers + ont été + supprimés ou modifiés, il peut effacer automatiquement des contenus de + fichiers du cache lorsque cela s'avère nécessaire. Ceci constitue un gros + avantage par rapport à la mise en cache en mémoire + de httpd qui n'a + aucune possibilité de savoir si un fichier a été modifié.

+ + +

En dépit des performances et des avantages de la mise en cache + automatique par le système d'exploitation, la mise en cache en mémoire + peut être effectuée plus efficacement par httpd dans certaines + circonstances.

+ +

Mise en cache à l'aide de la directive MMapFile

+ + +

La directive MMapFile + fournie par le module mod_file_cache vous permet de + demander à httpd de charger un contenu de fichier statique en mémoire + lors de son démarrage (à l'aide de l'appel + système mmap). httpd + utilisera le contenu chargé en mémoire pour satisfaire ultérieurement + toutes les demandes d'accès à ce fichier.

+ + 
MMapFile /usr/local/apache2/htdocs/index.html
+ + +

Comme dans le cas de la directive + CacheFile, toute + modification du fichier ne sera plus prise en compte par httpd une fois + ce dernier démarré.

+ +

La directive + MMapFile ne gardant + pas la trace de la quantité de mémoire qu'elle alloue, vous devez prendre + garde de ne pas en abuser. Chaque processus enfant de httpd utilisant + sa propre réplique de la mémoire allouée, il est donc d'une importance + critique de s'assurer que les fichiers chargés ne sont pas d'une taille + trop importante afin d'épargner au système l'utilisation du swap.

+ + + +
top
+
+

Considérations sur la sécurité

+ + +

Autorisation et contrôle d'accès

+ + +

Utiliser mod_cache revient sensiblement à la même + chose qu'avoir un mandataire inverse intégré (reverse-proxy). Les requêtes + seront servies par le module de mise en cache sauf si ce dernier + détermine qu'un processus d'arrière-plan doit être appelé. La mise en + cache de ressources locales modifie considérablement le modèle de + sécurité de httpd.

+ +

Comme le parcours de la hiérarchie d'un système de fichiers pour + examiner le contenu d'éventuels fichiers + .htaccess serait une opération très coûteuse en ressources, + annulant partiellement de ce fait l'intérêt de la mise en cache + (accélérer le traitement des requêtes), + mod_cache ne se préoccupe pas de savoir s'il a + l'autorisation de servir une entité mise en cache. En d'autres termes, + si mod_cache a mis en cache un certain contenu, ce + dernier sera servi à partir du cache tant qu'il ne sera pas arrivé à + expiration.

+ +

Si par exemple, votre configuration autorise l'accès à une ressource + en fonction de l'adresse IP, vous devez vous assurer que ce contenu n'est + pas mis en cache. Ceci est possible en utilisant la directive + CacheDisable, ou le module + mod_expires. Livré à lui-même, + mod_cache - pratiquement comme un mandataire inverse - + mettrait en cache le contenu lors de son service, et le servirait ensuite + à tout client, vers n'importe quelle adresse IP.

+ +

Lorsque la directive CacheQuickHandler est définie à + Off, toutes les phases du traitement de la requête + sont exécutées et le modèle de sécurité reste le même.

+ + + +

Piratages locaux

+ + +

Etant donné que les requêtes des utilisateurs finaux peuvent être + servies depuis le cache, ce dernier est une cible potentielle pour ceux + qui veulent défigurer un contenu ou interférer avec lui. Il est important + de garder à l'esprit que l'utilisateur sous lequel tourne + httpd doit + toujours avoir l'accès en écriture dans le cache. Ceci est en contraste + total avec la recommandation usuelle d'interdire à l'utilisateur sous + lequel tourne Apache + l'accès en écriture à tout contenu.

+ +

Si l'utilisateur sous lequel tourne Apache est compromis, + par exemple à cause d'une + faille de sécurité dans un processus CGI, il est possible que le cache + fasse l'objet d'une attaque. Il est relativement aisé d'insérer ou de + modifier une entité dans le cache en utilisant le module + mod_cache_disk.

+ +

Cela représente un risque relativement élévé par rapport aux autres + types d'attaques qu'il est possible de mener sous l'utilisateur apache. + Si vous utilisez mod_cache_disk, vous devez garder ceci + à l'esprit : effectuez toujours les mises à jour de + httpdquand des + correctifs de sécurité sont annoncés et exécutez les processus CGI sous + un utilisateur autre qu'apache en utilisant + suEXEC dans la mesure du possible.

+ + + +

Empoisonnement du cache (Cache Poisoning)

+ + +

Si vous utilisez httpd comme serveur mandataire avec mise en cache, + vous vous exposez aussi à un éventuel "Empoisonnement du + cache" (Cache poisoning). L'empoisonnement du cache est un terme général + pour désigner les attaques au cours desquelles l'attaquant fait en sorte + que le serveur mandataire renvoie à un contenu incorrect (et souvent + indésirable) suite à en provenance du serveur d'arrière-plan. +

+ +

Par exemple, si les serveur DNS qu'utilise votre système où tourne + httpd sont vulnérables à l'empoisonnement du cache des DNS, un attaquant + pourra contrôler vers où httpd se connecte lorsqu'il demande un contenu + depuis le serveur d'origine. + Un autre exemple est constitué par les attaques ainsi nommées + "Dissimulation de requêtes HTTP" (HTTP request-smuggling).

+ +

Ce document n'est pas le bon endroit pour une discussion approfondie + à propos de la Dissimulation de requêtes HTTP (utilisez plutôt votre + moteur de recherche favori); il est cependant important de savoir qu'il + est possible d'élaborer une série de requêtes, et d'exploiter une + vulnérabilité d'un serveur web d'origine de telle façon que l'attaquant + puisse contrôler entièrement le contenu renvoyé par le mandataire.

+ + +

Déni de Service / Cachebusting

+ + +

Le mécanisme utilisé via l'en-tête Vary permet de mettre en + cache simultanément plusieurs variantes d'une ressource avec la + même URL. Le cache sélectionne la variante correcte à envoyer au + client en fonction des valeurs d'en-tête fournies par ce dernier. + Ce mécanisme peut devenir un problème lorsqu'on tente d'appliquer + le mécanisme des variantes à un en-tête connu pour pouvoir + posséder un grand nombre de valeurs + possibles en utilisation normal, comme par exemple l'en-tête + User-Agent. En fonction de la popularité du site web, + des milliers ou même des millions d'entrées de cache dupliquées + peuvent être créées pour la même URL, submergeant les autres + entrées du cache.

+ +

Dans d'autres cas, il peut être nécessaire de modifier l'URL + d'une ressource particulière à chaque requête, en général en lui + ajoutant une chaîne "cachebuster". Si ce contenu est déclaré comme + pouvant être mis en cache par un serveur avec une durée de + fraîcheur significative, ces entrées peuvent submerger les entrées + légitimes du cache. Alors que mod_cache fournit + une directive CacheIgnoreURLSessionIdentifiers, + cette dernière doit être utilisée avec prudence pour s'assurer que + les caches du navigateur ou du mandataire le plus proche + (downstream proxy) ne sont pas victimes du même problème de Déni de + service.

+ +
+
+

Langues Disponibles:  en  | + fr  | + tr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/compliance.html.en b/docs/manual/compliance.html.en index 3ec6b78fc4..8a34b10f7f 100644 --- a/docs/manual/compliance.html.en +++ b/docs/manual/compliance.html.en @@ -24,7 +24,7 @@ Apache > HTTP Server > Documentation > Version 2.5

HTTP Protocol Compliance

Available Languages:  en  | - fr 

+ fr 

This document describes the mechanism to set a policy for HTTP @@ -466,7 +466,7 @@

Available Languages:  en  | - fr 

+ fr 

top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
- - -
-

Modules | Directives | FAQ | Glossaire | Plan du site

-

Serveur HTTP Apache Version 2.5

-
-
<-
-

Conformité au protocole HTTP

-
-

Langues Disponibles:  en  | - fr 

-
- -

Ce document décrit le mécanisme utilisé pour définir une - politique de conformité au protocole HTTP pour un espace d'URL au - niveau des serveurs d'origine ou des application sous-jacentes à cet - espace d'URL.

- -

Chaque politique de conformité est décrite ci-dessous à - destination de tous ceux qui ont reçu un message d'erreur suite à un - rejet en provenance d'une politique, et ont donc besoin de savoir à - quoi est du ce rejet et ce qu'ils doivent faire pour corriger - l'erreur.

-
- -
top
-
-

Imposer la conformité au protocole HTTP dans Apache 2

- -
Modules ApparentésDirectives Apparentées
- -

Le protocole HTTP applique le principe de - robustesse décrit dans la RFC1122, et stipulant - "Soyez libéral pour ce que vous acceptez, conservateur pour - ce que vous envoyez". Selon ce principe, les clients HTTP - vont compenser en corrigeant les réponses incorrectes ou mal - configurées, ou ne pouvant pas être mises en cache.

- -

Comme un site web est configuré pour faire face à un trafic - toujours grandissant, des applications mal configurées ou non - optimisées ou certaines configurations de serveur peuvent menacer la stabilité - et l'évolutivité du site web, ainsi que les coûts d'hébergement qui - y sont associés. L'évolution d'un site web pour faire face à une - complexité croissante de sa configuration accroît les - difficultés rencontrées pour détecter et enregistrer les espaces - d'URL mal configurés pour un serveur donné.

- -

De ce fait, un point peut être atteint où le principe - "conservateur pour ce que vous envoyez" doit être imposé par - l'administrateur du serveur.

- -

Le module mod_policy fournit un jeu de filtres - qui peuvent être appliqués à un serveur, permettant de tester - explicitement les points clé du protocle HTTP, et de journaliser en - tant qu'avertissements les réponses non conformes, ou même de - simplement les rejeter avec un code d'erreur. Chaque filtre peut - être appliqué séparément, permettant à l'administrateur de choisir - quelles politiques de conformité doivent être imposées en fonction - de l'environnement. -

- -

Les filtres peuvent être mis en place dans des environnements de - test ou de simulation à destination des développeurs d'applications - et de sites web, ou s'appliquer à des serveurs en production pour - protéger l'infrastructure de systèmes en dehors du contrôle direct - de l'administrateur.

- -

- Imposer la conformité au protocole HTTP pour un serveur d'applications -

- -

Dans l'exemple ci-dessus, un serveur Apache httpd a été intercalé - entre le serveur d'applications et l'internet au sens large, et - configuré pour mettre en cache les réponses en provenance du serveur - d'applications. Les filtres de mod_policy ont été - ajoutés pour imposer le support de la mise en cache de contenu et - des requêtes conditionnelles, assurant ainsi que - mod_cache et les caches publics de l'internet - seront pleinement capables de mettre en cache le contenu créé avec - efficacité par le serveur d'applications.

- -

- Imposer la conformité au protocole HTTP pour un serveur statique -

- -

Dans l'exemple plus simple ci-dessus, un serveur statique qui - sert du contenu ayant une forte probabilité d'être mis en cache, - se voit appliqué un jeu de règles afin de - s'assurer que sa configuration respecte un niveau minimum de - conformité au protocole HTTP.

- -
top
-
-

Politique des requêtes conditionnelles

- -
Modules ApparentésDirectives Apparentées
- -

Cette politique sera rejetée si le serveur ne répond pas à une - requête conditionnelle avec le code d'état approprié.

- -

C'est grâce aux requêtes conditionnelles qu'un cache HTTP peut - rafraîchir un contenu périmé, et en particulier dans le cas des - contenus à durée de validité courte, l'absence de support des - requêtes conditionnelles peut augmenter la charge du serveur.

- -

Plus particulièrement, la présence d'une des en-têtes suivantes - dans la requête rend cette dernière conditionnelle :

- -
-
If-Match
-
Si l'ETag fourni dans l'en-tête If-Match ne - correspond pas à l'ETag de la réponse, le serveur doit renvoyer un - code d'erreur 412 Precondition Failed. Vous trouverez - tous les détails du traitement d'un en-tête If-Match - dans la RFC2616 - section 14.24.
- -
If-None-Match
-
Si l'ETag fourni dans l'en-tête If-None-Match - correspond à l'ETag de la réponse, le serveur doit renvoyer soit - 304 Not Modified pour les requêtes GET/HEAD, soit - 412 Precondition Failed pour les autres méthodes. Vous trouverez - tous les détails du traitement d'un en-tête - If-None-Match dans la RFC2616 - section 14.26.
- -
If-Modified-Since
-
Si la date fournie dans l'en-tête If-Modified-Since - est plus ancienne que celle de l'en-tête Last-Modified - de la réponse, le serveur doit renvoyer 304 Not Modified. Vous trouverez - tous les détails du traitement d'un en-tête - If-Modified-Since dans la RFC2616 - section 14.25.
- -
If-Unmodified-Since
-
Si la date fournie dans l'en-tête - If-Unmodified-Since est plus récente que celle de - l'en-tête Last-Modified de la réponse, le serveur doit - renvoyer 412 Precondition Failed. Vous trouverez - tous les détails du traitement d'un en-tête - If-Unmodified-Since dans la RFC2616 - section 14.28.
- -
If-Range
-
Si l'ETag fourni dans l'en-tête If-Range correspond - à l'ETag ou à l'en-tête Last-Modified de la réponse, et si un - en-tête Range valide est présent, le serveur doit - renvoyer 206 Partial Response. Vous trouverez - tous les détails du traitement d'un en-tête If-Range - dans la RFC2616 - section 14.27.
- -
- -

Si la réponse est considérée comme ayant réussi (une réponse - 2xx), alors qu'elle était conditionnelle et qu'une des réponses - ci-dessus était attendue à la place, cette politique sera rejetée. - Les réponses qui indiquent une redirection ou une erreur de toute - sorte (3xx, 4xx, 5xx) seront ignorées de cette politique.

- -

Cette politique est implémentée par le filtre - POLICY_CONDITIONAL.

- -
top
-
-

Politique de gestion de l'en-tête Content-Length

- -
Modules ApparentésDirectives Apparentées
- -

Cette politique sera rejetée si la réponse du serveur ne contient pas d'en-tête - Content-Length explicite.

- -

De nombreuses méthodes pour déterminer la taille d'un - corps de réponse sont décrites dans la RFC2616 - section 4.4 Message Length.

- -

Lorsque l'en-tête Content-Length est présente, la - taille du corps est déclarée au début de la réponse. Si cette - information est manquante, un cache HTTP pourrait choisir d'ignorer - la réponse, car il ne pourrait pas déterminer a priori si la réponse - reste dans les limites définies du cache.

- -

Pour indiquer la fin de la réponse au client sans que ce dernier - ait à en connaître la taille au préalable, HTTP/1.1 propose - l'en-tête Transfer-Encoding comme une alternative à - Content-Length. Cependant, lors du traitement de - requêtes HTTP/1.0, et si l'en-tête Content-Length est - absente, le seul mécanisme dont dispose le serveur pour indiquer la - fin de la requête consiste à couper la connexion. Dans un - environnement contenant des répartiteurs de charge, cela peut - court-circuiter le mécanisme des connexions persistantes - (keepalive). -

- -

Si la réponse est considérée comme réussie (une réponse 2xx) et - possède un corps (ce qui exclut les réponses 204 No - Content), et si l'en-tête Content-Length est - absente, la réponse sera rejetée. Aucune réponse indiquant une - redirection ou une erreur de toute nature (3xx, 4xx, 5xx) n'est - prise en compte par cette politique.

- -
Notez que certains modules comme - mod_proxy ajoutent leur propre en-tête - Content-Length sous réserve que la réponse où cette - en-tête est absente soit suffisamment courte pour que le module ait - pu la lire en une seule passe. De ce fait, des réponses courtes pourront - être acceptées par la politique, alors que d'autres plus longues - seront rejetées pour la même URL.
- -

Cette politique est implémentée par le filtre - POLICY_LENGTH.

- -
top
-
-

Politique de filtrage de l'en-tête Content-Type

- -
Modules ApparentésDirectives Apparentées
- -

Cette politique sera rejetée si la réponse du serveur ne contient pas d'en-tête - Content-Type explicite et valide du point de vue de la - syntaxe, correspondant au modèle défini par le serveur.

- -

Le type de media du corps est placé dans une en-tête - Content-Type dont le format est décrit en détail dans - la - RFC2616 section 3.7 Media Types.

- -

Une en-tête Content-Type dont la syntaxe est valide - sera du style :

- -

- Content-Type: text/html; charset=iso-8859-1 -

- -

Exemples d'en-têtes Content-Type non valides :

- -

- # invalide
- Content-Type: foo
- # vide
- Content-Type: -

- -

L'administrateur peut restreindre la politique à un ou plusieurs - types spécifiques, ou utiliser des caractères génériques comme - */*.

- -

Cette politique est mise en oeuvre par le filtre - POLICY_TYPE.

- -
top
-
-

Politique de gestion des connexions persistantes (Keepalive)

- -
Modules ApparentésDirectives Apparentées
- -

Cette politique era rejetée si la réponse du serveur ne contient pas d'en-tête - Content-Length explicite, ou d'en-tête - Transfer-Encoding défini à chunked.

- -

De nombreuses manières pour déterminer la taille d'un - corps de réponse sont décrites dans la RFC2616 - section 4.4 Message Length.

- -

Pour indiquer la fin de la réponse au client sans que ce dernier - ait à en connaître la taille au préalable, HTTP/1.1 propose - l'en-tête Transfer-Encoding comme une alternative à - Content-Length. Cependant, lors du traitement de - requêtes HTTP/1.0, et si l'en-tête Content-Length est - absent, le seul mécanisme dont dispose le serveur pour indiquer la - fin de la requête consiste à couper la connexion. Dans un - environnement contenant des répartiteurs de charge, cela peut - court-circuiter le mécanisme des connexions persistantes - (keepalive). -

- -

En particulier, les règles suivantes sont appliquées :

- -
-
Si
-
cette connexion n'est pas marquée en erreur ;
- -
et
-
le client n'attend pas 100-continue ;
- -
et
-
le code de statut de la réponse ne nécessite pas de fermeture de connexion ;
- -
et
-
le corps de la réponse a une taille définie suite au code de - statut 304 ou 204, la méthode de requête est HEAD, un en-tête - Content-Length ou Transfer-Encoding: chunked a déjà été défini, ou - la requête est de type HTTP/1.1 et peut donc être définie à chunked.
- -
alors
-
keepalive est supporté.
-
- -
Le serveur peut décider de désactiver les - connexions persistantes pour de nombreuses raisons, comme un arrêt - imminent, un Connection: close en provenance du client, ou une - requête client de type HTTP/1.0 dont la réponse ne comporte pas - d'en-tête Content-Length, mais pour ce qui nous - concerne, nous ne vérifions que la possibilité des connexions - persistantes depuis l'application, et non si les connexions - persistantes sont activées.
- -

Notez aussi que le serveur HTTP Apache propose un filtre qui - ajoute un codage chunked aux réponses qui ne contiennent pas - d'en-tête Content-Length explicite. Cette politique - prend en compte les cas où le filtre est court-circuité ou - désactivé.

- -

Cette politique est implémentée par le filtre - POLICY_KEEPALIVE.

- -
top
-
-

Durée de fraîcheur / Politique de gestion de l'âge maximum

- -
Modules ApparentésDirectives Apparentées
- -

Cette politique se verra rejetée si la réponse du serveur ne - contient pas de durée de fraîcheur explicite au - moins grande que la limite définie par le serveur, ou si la - durée de fraîcheur est calculée à partir d'une heuristique.

- -

Vous trouverez tous les détails à propos du calcul d'une durée de - fraîcheur dans la RFC2616 - section 13.2 Expiration Model.

- -

Pendant la durée de fraîcheur, un cache n'a pas besoin de - contacter le serveur original, et il peut renvoyer le contenu situé - dans le cache tel quel au client.

- -

Lorsque la date de péremption est atteinte, le cache doit - contacter le serveur original dans le but de vérifier si le contenu - situé dans le cache est encore à jour, et si ce n'est pas le cas, de - le remplacer par le contenu correspondant sur le serveur original.

- -

Lorsque la durée de fraîcheur est trop courte, il peut en - résulter un excès de charge pour le serveur. De plus, si une - interruption de service survient, et si cette dernière est longue, - ou plus longue que la durée de fraîcheur, tout le contenu du cache - s'en trouvera périmé, ce qui causera un trafic très important - lorsque le serveur ou le réseau sera rétabli.

- -

Cette politique est implémentée par le filtre - POLICY_MAXAGE.

- -
top
-
-

Politique de gestion des contenus qui ne peuvent pas être mis - en cache

- -
Modules ApparentésDirectives Apparentées
- -

Cette politique sera rejetée si la réponse du serveur - déclare elle-même qu'elle ne doit pas être mise en cache à l'aide - d'un en-tête Cache-Control ou Pragma.

- -

Vous trouverez tous les détails à propos de la manière dont un - contenu peut être déclaré comme non cachable dans la RFC2616 - section 14.9.1 What is Cacheable, et au sein de la définition de - l'en-tête Pragma dans la RFC2616 - section 14.32 Pragma.

- -

Plus précisément, si une combinaison des en-têtes suivants existe - dans la réponse, cette dernière sera rejetée :

- -
    -
  • Cache-Control: no-cache
    • -
  • Cache-Control: no-store
    • -
  • Cache-Control: private
    • -
  • Pragma: no-cache
    • -
- -

D'une manière générale, lorsque cette politique est activée, et - si d'une manière inattendue un contenu non cachable peut induire un - niveau de charge du serveur inacceptable, tout contenu défini comme - non cachable par le serveur sera rejeté.

- -

Cette politique est implémentée par le filtre - POLICY_NOCACHE.

- -
top
-
-

Politique de validation

- -
Modules ApparentésDirectives Apparentées
- -

Cette politique sera rejetée si la réponse du serveur - ne contient aucune en-tête syntaxiquement correct ETag - ou Last-Modified.

- -

Vous trouverez une description complète de l'en-tête - ETag dans la RFC2616 - section 14.19 Etag, et de l'en-tête Last-Modified - dans la RFC2616 - section 14.29 Last-Modified.

- -

La vérification est effectuée non seulement en ce qui concerne la - présence des en-têtes, mais aussi du point de vue de leur syntaxe.

- -

Si une en-tête ETag n'est pas entourée de guillemets, - ou n'est pas déclarée "weak" en le préfixant avec un "W/", la politique - sera rejetée. De même, si l'interprétation d'une en-tête - Last-Modified ne fournit pas de date valide, la réponse - sera rejetée.

- -

Cette politique est implémentée par le filtre - POLICY_VALIDATION.

- -
top
-
-

Politique de gestion de l'en-tête Vary

- -
Modules ApparentésDirectives Apparentées
- -

Cette politique se verra rejetée si la réponse du serveur - contient une en-tête Vary, et si cette en-tête - contient à son tour une en-tête mise en liste noire par - l'administrateur.

- -

L'en-tête Vary est décrite en détails dans la RFC2616 - section 14.44 Vary.

- -

Certaines en-têtes définies par les clients, comme - User-Agent, peuvent contenir des milliers ou même des - millions de combinaisons de valeurs au cours du temps, et si la - réponse est considérée comme pouvant être mise en cache, le cache - peut tenter d'enregistrer toutes ces réponses, ce qui peut l'amener - à saturation et à noyer les autres entrées qu'il contient. Avec ce - scénario, cette politique sera rejetée.

- -

Cette politique est implémentée par le filtre - POLICY_VARY.

- -
top
-
-

Politique de gestion des versions de protocole

- -
Modules ApparentésDirectives Apparentées
- -

Cette politique sera rejetée si la réponse du serveur - a été générée avec un numéro de version inférieur à la version - de HTTP spécifiée.

- -

Cette politique s'utilise en général avec les applications qui - nécessitent un contrôle du type du client. Elle peut être utilisée en - concomitance avec le filtre POLICY_KEEPALIVE afin de - s'assurer que les clients HTTP/1.0 n'engendrent pas la fermeture des - connexions persistantes.

- -

Les versions minimales pouvant être spécifiées sont :

- -
  • HTTP/1.1
    • -
  • HTTP/1.0
    • -
  • HTTP/0.9
    • -
- -

Cette politique est implémentée par le filtre - POLICY_VERSON.

- -
-
-

Langues Disponibles:  en  | - fr 

-
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
-
- \ No newline at end of file diff --git a/docs/manual/compliance.html.fr.utf8 b/docs/manual/compliance.html.fr.utf8 new file mode 100644 index 0000000000..feaf2bdf34 --- /dev/null +++ b/docs/manual/compliance.html.fr.utf8 @@ -0,0 +1,520 @@ + + + + + +Conformité au protocole HTTP - Serveur HTTP Apache Version 2.5 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.5

+
+
<-
+

Conformité au protocole HTTP

+
+

Langues Disponibles:  en  | + fr 

+
+ +

Ce document décrit le mécanisme utilisé pour définir une + politique de conformité au protocole HTTP pour un espace d'URL au + niveau des serveurs d'origine ou des application sous-jacentes à cet + espace d'URL.

+ +

Chaque politique de conformité est décrite ci-dessous à + destination de tous ceux qui ont reçu un message d'erreur suite à un + rejet en provenance d'une politique, et ont donc besoin de savoir à + quoi est du ce rejet et ce qu'ils doivent faire pour corriger + l'erreur.

+
+ +
top
+
+

Imposer la conformité au protocole HTTP dans Apache 2

+ +
Modules ApparentésDirectives Apparentées
+ +

Le protocole HTTP applique le principe de + robustesse décrit dans la RFC1122, et stipulant + "Soyez libéral pour ce que vous acceptez, conservateur pour + ce que vous envoyez". Selon ce principe, les clients HTTP + vont compenser en corrigeant les réponses incorrectes ou mal + configurées, ou ne pouvant pas être mises en cache.

+ +

Comme un site web est configuré pour faire face à un trafic + toujours grandissant, des applications mal configurées ou non + optimisées ou certaines configurations de serveur peuvent menacer la stabilité + et l'évolutivité du site web, ainsi que les coûts d'hébergement qui + y sont associés. L'évolution d'un site web pour faire face à une + complexité croissante de sa configuration accroît les + difficultés rencontrées pour détecter et enregistrer les espaces + d'URL mal configurés pour un serveur donné.

+ +

De ce fait, un point peut être atteint où le principe + "conservateur pour ce que vous envoyez" doit être imposé par + l'administrateur du serveur.

+ +

Le module mod_policy fournit un jeu de filtres + qui peuvent être appliqués à un serveur, permettant de tester + explicitement les points clé du protocle HTTP, et de journaliser en + tant qu'avertissements les réponses non conformes, ou même de + simplement les rejeter avec un code d'erreur. Chaque filtre peut + être appliqué séparément, permettant à l'administrateur de choisir + quelles politiques de conformité doivent être imposées en fonction + de l'environnement. +

+ +

Les filtres peuvent être mis en place dans des environnements de + test ou de simulation à destination des développeurs d'applications + et de sites web, ou s'appliquer à des serveurs en production pour + protéger l'infrastructure de systèmes en dehors du contrôle direct + de l'administrateur.

+ +

+ Imposer la conformité au protocole HTTP pour un serveur d'applications +

+ +

Dans l'exemple ci-dessus, un serveur Apache httpd a été intercalé + entre le serveur d'applications et l'internet au sens large, et + configuré pour mettre en cache les réponses en provenance du serveur + d'applications. Les filtres de mod_policy ont été + ajoutés pour imposer le support de la mise en cache de contenu et + des requêtes conditionnelles, assurant ainsi que + mod_cache et les caches publics de l'internet + seront pleinement capables de mettre en cache le contenu créé avec + efficacité par le serveur d'applications.

+ +

+ Imposer la conformité au protocole HTTP pour un serveur statique +

+ +

Dans l'exemple plus simple ci-dessus, un serveur statique qui + sert du contenu ayant une forte probabilité d'être mis en cache, + se voit appliqué un jeu de règles afin de + s'assurer que sa configuration respecte un niveau minimum de + conformité au protocole HTTP.

+ +
top
+
+

Politique des requêtes conditionnelles

+ +
Modules ApparentésDirectives Apparentées
+ +

Cette politique sera rejetée si le serveur ne répond pas à une + requête conditionnelle avec le code d'état approprié.

+ +

C'est grâce aux requêtes conditionnelles qu'un cache HTTP peut + rafraîchir un contenu périmé, et en particulier dans le cas des + contenus à durée de validité courte, l'absence de support des + requêtes conditionnelles peut augmenter la charge du serveur.

+ +

Plus particulièrement, la présence d'une des en-têtes suivantes + dans la requête rend cette dernière conditionnelle :

+ +
+
If-Match
+
Si l'ETag fourni dans l'en-tête If-Match ne + correspond pas à l'ETag de la réponse, le serveur doit renvoyer un + code d'erreur 412 Precondition Failed. Vous trouverez + tous les détails du traitement d'un en-tête If-Match + dans la RFC2616 + section 14.24.
+ +
If-None-Match
+
Si l'ETag fourni dans l'en-tête If-None-Match + correspond à l'ETag de la réponse, le serveur doit renvoyer soit + 304 Not Modified pour les requêtes GET/HEAD, soit + 412 Precondition Failed pour les autres méthodes. Vous trouverez + tous les détails du traitement d'un en-tête + If-None-Match dans la RFC2616 + section 14.26.
+ +
If-Modified-Since
+
Si la date fournie dans l'en-tête If-Modified-Since + est plus ancienne que celle de l'en-tête Last-Modified + de la réponse, le serveur doit renvoyer 304 Not Modified. Vous trouverez + tous les détails du traitement d'un en-tête + If-Modified-Since dans la RFC2616 + section 14.25.
+ +
If-Unmodified-Since
+
Si la date fournie dans l'en-tête + If-Unmodified-Since est plus récente que celle de + l'en-tête Last-Modified de la réponse, le serveur doit + renvoyer 412 Precondition Failed. Vous trouverez + tous les détails du traitement d'un en-tête + If-Unmodified-Since dans la RFC2616 + section 14.28.
+ +
If-Range
+
Si l'ETag fourni dans l'en-tête If-Range correspond + à l'ETag ou à l'en-tête Last-Modified de la réponse, et si un + en-tête Range valide est présent, le serveur doit + renvoyer 206 Partial Response. Vous trouverez + tous les détails du traitement d'un en-tête If-Range + dans la RFC2616 + section 14.27.
+ +
+ +

Si la réponse est considérée comme ayant réussi (une réponse + 2xx), alors qu'elle était conditionnelle et qu'une des réponses + ci-dessus était attendue à la place, cette politique sera rejetée. + Les réponses qui indiquent une redirection ou une erreur de toute + sorte (3xx, 4xx, 5xx) seront ignorées de cette politique.

+ +

Cette politique est implémentée par le filtre + POLICY_CONDITIONAL.

+ +
top
+
+

Politique de gestion de l'en-tête Content-Length

+ +
Modules ApparentésDirectives Apparentées
+ +

Cette politique sera rejetée si la réponse du serveur ne contient pas d'en-tête + Content-Length explicite.

+ +

De nombreuses méthodes pour déterminer la taille d'un + corps de réponse sont décrites dans la RFC2616 + section 4.4 Message Length.

+ +

Lorsque l'en-tête Content-Length est présente, la + taille du corps est déclarée au début de la réponse. Si cette + information est manquante, un cache HTTP pourrait choisir d'ignorer + la réponse, car il ne pourrait pas déterminer a priori si la réponse + reste dans les limites définies du cache.

+ +

Pour indiquer la fin de la réponse au client sans que ce dernier + ait à en connaître la taille au préalable, HTTP/1.1 propose + l'en-tête Transfer-Encoding comme une alternative à + Content-Length. Cependant, lors du traitement de + requêtes HTTP/1.0, et si l'en-tête Content-Length est + absente, le seul mécanisme dont dispose le serveur pour indiquer la + fin de la requête consiste à couper la connexion. Dans un + environnement contenant des répartiteurs de charge, cela peut + court-circuiter le mécanisme des connexions persistantes + (keepalive). +

+ +

Si la réponse est considérée comme réussie (une réponse 2xx) et + possède un corps (ce qui exclut les réponses 204 No + Content), et si l'en-tête Content-Length est + absente, la réponse sera rejetée. Aucune réponse indiquant une + redirection ou une erreur de toute nature (3xx, 4xx, 5xx) n'est + prise en compte par cette politique.

+ +
Notez que certains modules comme + mod_proxy ajoutent leur propre en-tête + Content-Length sous réserve que la réponse où cette + en-tête est absente soit suffisamment courte pour que le module ait + pu la lire en une seule passe. De ce fait, des réponses courtes pourront + être acceptées par la politique, alors que d'autres plus longues + seront rejetées pour la même URL.
+ +

Cette politique est implémentée par le filtre + POLICY_LENGTH.

+ +
top
+
+

Politique de filtrage de l'en-tête Content-Type

+ +
Modules ApparentésDirectives Apparentées
+ +

Cette politique sera rejetée si la réponse du serveur ne contient pas d'en-tête + Content-Type explicite et valide du point de vue de la + syntaxe, correspondant au modèle défini par le serveur.

+ +

Le type de media du corps est placé dans une en-tête + Content-Type dont le format est décrit en détail dans + la + RFC2616 section 3.7 Media Types.

+ +

Une en-tête Content-Type dont la syntaxe est valide + sera du style :

+ +

+ Content-Type: text/html; charset=iso-8859-1 +

+ +

Exemples d'en-têtes Content-Type non valides :

+ +

+ # invalide
+ Content-Type: foo
+ # vide
+ Content-Type: +

+ +

L'administrateur peut restreindre la politique à un ou plusieurs + types spécifiques, ou utiliser des caractères génériques comme + */*.

+ +

Cette politique est mise en oeuvre par le filtre + POLICY_TYPE.

+ +
top
+
+

Politique de gestion des connexions persistantes (Keepalive)

+ +
Modules ApparentésDirectives Apparentées
+ +

Cette politique era rejetée si la réponse du serveur ne contient pas d'en-tête + Content-Length explicite, ou d'en-tête + Transfer-Encoding défini à chunked.

+ +

De nombreuses manières pour déterminer la taille d'un + corps de réponse sont décrites dans la RFC2616 + section 4.4 Message Length.

+ +

Pour indiquer la fin de la réponse au client sans que ce dernier + ait à en connaître la taille au préalable, HTTP/1.1 propose + l'en-tête Transfer-Encoding comme une alternative à + Content-Length. Cependant, lors du traitement de + requêtes HTTP/1.0, et si l'en-tête Content-Length est + absent, le seul mécanisme dont dispose le serveur pour indiquer la + fin de la requête consiste à couper la connexion. Dans un + environnement contenant des répartiteurs de charge, cela peut + court-circuiter le mécanisme des connexions persistantes + (keepalive). +

+ +

En particulier, les règles suivantes sont appliquées :

+ +
+
Si
+
cette connexion n'est pas marquée en erreur ;
+ +
et
+
le client n'attend pas 100-continue ;
+ +
et
+
le code de statut de la réponse ne nécessite pas de fermeture de connexion ;
+ +
et
+
le corps de la réponse a une taille définie suite au code de + statut 304 ou 204, la méthode de requête est HEAD, un en-tête + Content-Length ou Transfer-Encoding: chunked a déjà été défini, ou + la requête est de type HTTP/1.1 et peut donc être définie à chunked.
+ +
alors
+
keepalive est supporté.
+
+ +
Le serveur peut décider de désactiver les + connexions persistantes pour de nombreuses raisons, comme un arrêt + imminent, un Connection: close en provenance du client, ou une + requête client de type HTTP/1.0 dont la réponse ne comporte pas + d'en-tête Content-Length, mais pour ce qui nous + concerne, nous ne vérifions que la possibilité des connexions + persistantes depuis l'application, et non si les connexions + persistantes sont activées.
+ +

Notez aussi que le serveur HTTP Apache propose un filtre qui + ajoute un codage chunked aux réponses qui ne contiennent pas + d'en-tête Content-Length explicite. Cette politique + prend en compte les cas où le filtre est court-circuité ou + désactivé.

+ +

Cette politique est implémentée par le filtre + POLICY_KEEPALIVE.

+ +
top
+
+

Durée de fraîcheur / Politique de gestion de l'âge maximum

+ +
Modules ApparentésDirectives Apparentées
+ +

Cette politique se verra rejetée si la réponse du serveur ne + contient pas de durée de fraîcheur explicite au + moins grande que la limite définie par le serveur, ou si la + durée de fraîcheur est calculée à partir d'une heuristique.

+ +

Vous trouverez tous les détails à propos du calcul d'une durée de + fraîcheur dans la RFC2616 + section 13.2 Expiration Model.

+ +

Pendant la durée de fraîcheur, un cache n'a pas besoin de + contacter le serveur original, et il peut renvoyer le contenu situé + dans le cache tel quel au client.

+ +

Lorsque la date de péremption est atteinte, le cache doit + contacter le serveur original dans le but de vérifier si le contenu + situé dans le cache est encore à jour, et si ce n'est pas le cas, de + le remplacer par le contenu correspondant sur le serveur original.

+ +

Lorsque la durée de fraîcheur est trop courte, il peut en + résulter un excès de charge pour le serveur. De plus, si une + interruption de service survient, et si cette dernière est longue, + ou plus longue que la durée de fraîcheur, tout le contenu du cache + s'en trouvera périmé, ce qui causera un trafic très important + lorsque le serveur ou le réseau sera rétabli.

+ +

Cette politique est implémentée par le filtre + POLICY_MAXAGE.

+ +
top
+
+

Politique de gestion des contenus qui ne peuvent pas être mis + en cache

+ +
Modules ApparentésDirectives Apparentées
+ +

Cette politique sera rejetée si la réponse du serveur + déclare elle-même qu'elle ne doit pas être mise en cache à l'aide + d'un en-tête Cache-Control ou Pragma.

+ +

Vous trouverez tous les détails à propos de la manière dont un + contenu peut être déclaré comme non cachable dans la RFC2616 + section 14.9.1 What is Cacheable, et au sein de la définition de + l'en-tête Pragma dans la RFC2616 + section 14.32 Pragma.

+ +

Plus précisément, si une combinaison des en-têtes suivants existe + dans la réponse, cette dernière sera rejetée :

+ +
    +
  • Cache-Control: no-cache
    • +
  • Cache-Control: no-store
    • +
  • Cache-Control: private
    • +
  • Pragma: no-cache
    • +
+ +

D'une manière générale, lorsque cette politique est activée, et + si d'une manière inattendue un contenu non cachable peut induire un + niveau de charge du serveur inacceptable, tout contenu défini comme + non cachable par le serveur sera rejeté.

+ +

Cette politique est implémentée par le filtre + POLICY_NOCACHE.

+ +
top
+
+

Politique de validation

+ +
Modules ApparentésDirectives Apparentées
+ +

Cette politique sera rejetée si la réponse du serveur + ne contient aucune en-tête syntaxiquement correct ETag + ou Last-Modified.

+ +

Vous trouverez une description complète de l'en-tête + ETag dans la RFC2616 + section 14.19 Etag, et de l'en-tête Last-Modified + dans la RFC2616 + section 14.29 Last-Modified.

+ +

La vérification est effectuée non seulement en ce qui concerne la + présence des en-têtes, mais aussi du point de vue de leur syntaxe.

+ +

Si une en-tête ETag n'est pas entourée de guillemets, + ou n'est pas déclarée "weak" en le préfixant avec un "W/", la politique + sera rejetée. De même, si l'interprétation d'une en-tête + Last-Modified ne fournit pas de date valide, la réponse + sera rejetée.

+ +

Cette politique est implémentée par le filtre + POLICY_VALIDATION.

+ +
top
+
+

Politique de gestion de l'en-tête Vary

+ +
Modules ApparentésDirectives Apparentées
+ +

Cette politique se verra rejetée si la réponse du serveur + contient une en-tête Vary, et si cette en-tête + contient à son tour une en-tête mise en liste noire par + l'administrateur.

+ +

L'en-tête Vary est décrite en détails dans la RFC2616 + section 14.44 Vary.

+ +

Certaines en-têtes définies par les clients, comme + User-Agent, peuvent contenir des milliers ou même des + millions de combinaisons de valeurs au cours du temps, et si la + réponse est considérée comme pouvant être mise en cache, le cache + peut tenter d'enregistrer toutes ces réponses, ce qui peut l'amener + à saturation et à noyer les autres entrées qu'il contient. Avec ce + scénario, cette politique sera rejetée.

+ +

Cette politique est implémentée par le filtre + POLICY_VARY.

+ +
top
+
+

Politique de gestion des versions de protocole

+ +
Modules ApparentésDirectives Apparentées
+ +

Cette politique sera rejetée si la réponse du serveur + a été générée avec un numéro de version inférieur à la version + de HTTP spécifiée.

+ +

Cette politique s'utilise en général avec les applications qui + nécessitent un contrôle du type du client. Elle peut être utilisée en + concomitance avec le filtre POLICY_KEEPALIVE afin de + s'assurer que les clients HTTP/1.0 n'engendrent pas la fermeture des + connexions persistantes.

+ +

Les versions minimales pouvant être spécifiées sont :

+ +
  • HTTP/1.1
    • +
  • HTTP/1.0
    • +
  • HTTP/0.9
    • +
+ +

Cette politique est implémentée par le filtre + POLICY_VERSON.

+ +
+
+

Langues Disponibles:  en  | + fr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/configuring.html.en b/docs/manual/configuring.html.en index 7b6edd5beb..6853db8c47 100644 --- a/docs/manual/configuring.html.en +++ b/docs/manual/configuring.html.en @@ -25,10 +25,10 @@

Available Languages:  de  |  en  | - fr  | + fr  |  ja  |  ko  | - tr 

+ tr 

This document describes the files used to configure Apache HTTP @@ -204,10 +204,10 @@ Server.

Available Languages:  de  |  en  | - fr  | + fr  |  ja  |  ko  | - tr 

+ tr 

top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
- - -
-

Modules | Directives | FAQ | Glossaire | Plan du site

-

Serveur HTTP Apache Version 2.5

-
-
<-
-

Fichiers de configuration

-
-

Langues Disponibles:  de  | - en  | - fr  | - ja  | - ko  | - tr 

-
- -

Ce document décrit les fichiers utilisés pour configurer -le Serveur HTTP Apache.

-
- -
top
-
-

Fichiers de configuration principaux

- -
Modules ApparentésDirectives Apparentées
- -

La configuration du serveur HTTP Apache est effectuée en plaçant des directives dans des fichiers de - configuration au format texte. Le fichier de configuration principal se nomme - en général - httpd.conf. La localisation de ce fichier est définie - à la compilation, mais peut être redéfinie à l'aide de l'option - de ligne de commande -f. En outre, d'autres fichiers de - configuration peuvent être ajoutés à l'aide de la directive - Include, et des caractères de - remplacement - peuvent être utilisés pour inclure de nombreux fichiers de configuration. - Des directives de tous types peuvent être placées dans chacun de ces fichiers - de configuration. Les modifications dans les fichiers de configuration - principaux ne sont prises en compte par httpd que lorsque le serveur - est démarré ou redémarré.

- -

Le serveur lit aussi un fichier contenant les types de document mime; - ce fichier est défini par la directive TypesConfig, - et se nomme mime.types par défaut.

-
top
-
-

Syntaxe des fichiers de configuration

- - -

Les fichiers de configuration de httpd contiennent une directive - par ligne. - On peut utiliser l'anti-slash "\" comme dernier caractère d'une ligne - pour indiquer que la directive continue à la ligne suivante. - Il ne doit y avoir aucun caractère ni espace entre l'anti-slash et - la fin de la ligne.

- -

Les arguments des directives sont séparés les uns des autres par - des espaces. Si un argument contient des espaces, il doit être - entouré de guillemets.

- -

Les directives dans les fichiers de configuration ne sont pas - sensibles à la casse, mais leurs arguments le sont souvent. Les lignes - qui débutent par le caractère "#" sont interprétées comme des - commentaires, et sont ignorées. Les commentaires ne doivent - pas apparaître sur la même ligne qu'une directive - de configuration. Les espaces précédant une directive - sont ignorés; vous pouvez par conséquent indenter les directives - afin d'améliorer la lisibilité. Les lignes vides sont - aussi ignorées.

- -

Les valeurs des variables d'environnement ou des variables - définies via la directive Define peuvent être utilisées dans le - fichier de configuration en utilisant la syntaxe - ${VAR}. Si "VAR" est le nom d'une variable valide, la - valeur de la variable est alors substituée à la chaîne - ${VAR}, et le processus de lecture du fichier de - configuration continue comme si la chaîne correspondant à la valeur - de la variable s'y était trouvée littéralement. Les variables définies - via la directive Define - l'emportent sur les autres variables d'environnement du shell. Si la - variable "VAR" n'est pas trouvée, la chaîne ${VAR} - n'est pas modifiée, et un avertissement est enregistré dans le - journal. Le caractère ":" est interdit dans les noms de variables - afin d'éviter tout conflit avec la syntaxe de la directive RewriteMap.

- -

Seules les variables d'environnement du shell définies avant le démarrage - du serveur peuvent être utilisées dans les extensions. - Les variables d'environnement - définies dans le fichier de configuration lui-même, par exemple avec SetEnv, prennent effet trop tard pour - pouvoir être utilisées dans les extensions au sein du fichier de - configuration.

- -

La longueur maximale d'une ligne dans un fichier de configuration - normal, après substitution des variables et fusion des lignes - interrompues, est approximativement de 16 Mo. Dans les fichiers .htaccess, la longueur - maximale est de 8190 caractères.

- -

Vous pouvez vérifier l'absence d'erreurs de syntaxe dans vos fichiers - de configuration sans démarrer le serveur à l'aide de la commande - apachectl configtest ou de l'option de ligne de commande - -t.

- -

Vous pouvez utiliser la définition -DDUMP_CONFIG de - mod_info pour afficher la configuration avec tous - les fichiers inclus et les variables d'environnement évaluées, tous - les commentaires et les sections <IfDefine> et <IfModule> non actives ayant - été supprimés. Cependant, la sortie ne reflète - pas les fusions ou écrasements pouvant intervenir en cas de - définitions multiples de directives.

-
top
-
-

Modules

- - -
Modules ApparentésDirectives Apparentées
- -

httpd est un serveur modulaire. Ceci implique que seules les - fonctionnalités les plus courantes sont incluses dans le serveur de base. - Les fonctionnalités étendues sont fournies à l'aide de modules qui peuvent être chargés dans httpd. - Par défaut, un jeu de modules de base est inclus dans le - serveur à la compilation. Si le serveur est compilé de façon à utiliser - les modules chargés dynamiquement, - alors les modules peuvent être compilés séparément et chargés à - n'importe quel moment à l'aide de la directive - LoadModule. - Dans le cas contraire, httpd doit être recompilé pour ajouter ou - supprimer des modules. - Les directives de configuration peuvent être incluses de manière - conditionnelle selon la présence ou l'absence d'un module particulier - en les plaçant dans un bloc <IfModule>.

- -

Pour voir quels modules ont été compilés avec le serveur, - vous pouvez utiliser l'option de ligne de commande -l.

-
top
-
-

Portée des directives

- - -
Modules ApparentésDirectives Apparentées
- -

Les directives placées dans les fichiers de configuration principaux - s'appliquent au serveur dans son ensemble. Si vous souhaitez modifier la - configuration d'une partie du serveur seulement, vous pouvez limiter la - portée de vos directives en les plaçant dans une section - <Directory>, <DirectoryMatch>, <Files>, <FilesMatch>, <Location>, ou <LocationMatch>. - Ces sections limitent le champ d'application des directives qu'elles - contiennent à des URls ou des portions du système de fichiers particulières. - Elles peuvent aussi être imbriquées, ce qui permet - une configuration très fine.

- -

httpd peut servir simultanément de nombreux sites web au travers des - Hôtes Virtuels. La portée des directives peut ainsi - être limitée en les plaçant dans des sections - <VirtualHost>, - afin qu'elles ne s'appliquent qu'aux requêtes - pour un site web particulier.

- -

Bien que la plupart des directives puissent être placées dans - chacune de ces sections, certaines d'entre elles n'ont aucun sens - dans certains contextes. - Par exemple, les directives qui contrôlent la création des processus - n'ont de sens que dans le contexte du serveur principal. Pour déterminer - quelles directives peuvent être placées dans quelles sections, consultez - le Contexte de la - directive. Pour plus d'informations, nous fournissons des détails dans - Comment fonctionnent les sections Directory, - Location et Files.

-
top
-
-

Fichiers .htaccess

- - -
Modules ApparentésDirectives Apparentées
- -

httpd permet la gestion décentralisée de la configuration - via des fichiers spéciaux placés dans l'arborescence du site web. - Ces fichiers spéciaux se nomment en général .htaccess, - mais tout autre nom peut être spécifié à l'aide de la directive - AccessFileName. - Les directives placées dans les fichiers .htaccess - s'appliquent au répertoire dans lequel vous avez placé le fichier, - ainsi qu'à tous ses sous-répertoires. - La syntaxe des fichiers .htaccess est la même que celle - des fichiers de configuration principaux. Comme les fichiers - .htaccess sont lus à chaque requête, les modifications de - ces fichiers prennent effet immédiatement.

- -

Pour déterminer quelles directives peuvent être placées - dans les fichiers .htaccess, consultez le - Contexte de la - directive. L'administrateur du serveur peut contrôler quelles - directives peuvent être placées dans les fichiers - .htaccess en définissant la directive - AllowOverride - dans les fichiers de configuration principaux.

- -

Pour plus d'informations sur les fichiers .htaccess, - se référer au tutoriel .htaccess.

-
-
-

Langues Disponibles:  de  | - en  | - fr  | - ja  | - ko  | - tr 

-
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
-
- \ No newline at end of file diff --git a/docs/manual/configuring.html.fr.utf8 b/docs/manual/configuring.html.fr.utf8 new file mode 100644 index 0000000000..66403b04a7 --- /dev/null +++ b/docs/manual/configuring.html.fr.utf8 @@ -0,0 +1,253 @@ + + + + + +Fichiers de configuration - Serveur HTTP Apache Version 2.5 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.5

+
+
<-
+

Fichiers de configuration

+
+

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

+
+ +

Ce document décrit les fichiers utilisés pour configurer +le Serveur HTTP Apache.

+
+ +
top
+
+

Fichiers de configuration principaux

+ +
Modules ApparentésDirectives Apparentées
+ +

La configuration du serveur HTTP Apache est effectuée en plaçant des directives dans des fichiers de + configuration au format texte. Le fichier de configuration principal se nomme + en général + httpd.conf. La localisation de ce fichier est définie + à la compilation, mais peut être redéfinie à l'aide de l'option + de ligne de commande -f. En outre, d'autres fichiers de + configuration peuvent être ajoutés à l'aide de la directive + Include, et des caractères de + remplacement + peuvent être utilisés pour inclure de nombreux fichiers de configuration. + Des directives de tous types peuvent être placées dans chacun de ces fichiers + de configuration. Les modifications dans les fichiers de configuration + principaux ne sont prises en compte par httpd que lorsque le serveur + est démarré ou redémarré.

+ +

Le serveur lit aussi un fichier contenant les types de document mime; + ce fichier est défini par la directive TypesConfig, + et se nomme mime.types par défaut.

+
top
+
+

Syntaxe des fichiers de configuration

+ + +

Les fichiers de configuration de httpd contiennent une directive + par ligne. + On peut utiliser l'anti-slash "\" comme dernier caractère d'une ligne + pour indiquer que la directive continue à la ligne suivante. + Il ne doit y avoir aucun caractère ni espace entre l'anti-slash et + la fin de la ligne.

+ +

Les arguments des directives sont séparés les uns des autres par + des espaces. Si un argument contient des espaces, il doit être + entouré de guillemets.

+ +

Les directives dans les fichiers de configuration ne sont pas + sensibles à la casse, mais leurs arguments le sont souvent. Les lignes + qui débutent par le caractère "#" sont interprétées comme des + commentaires, et sont ignorées. Les commentaires ne doivent + pas apparaître sur la même ligne qu'une directive + de configuration. Les espaces précédant une directive + sont ignorés; vous pouvez par conséquent indenter les directives + afin d'améliorer la lisibilité. Les lignes vides sont + aussi ignorées.

+ +

Les valeurs des variables d'environnement ou des variables + définies via la directive Define peuvent être utilisées dans le + fichier de configuration en utilisant la syntaxe + ${VAR}. Si "VAR" est le nom d'une variable valide, la + valeur de la variable est alors substituée à la chaîne + ${VAR}, et le processus de lecture du fichier de + configuration continue comme si la chaîne correspondant à la valeur + de la variable s'y était trouvée littéralement. Les variables définies + via la directive Define + l'emportent sur les autres variables d'environnement du shell. Si la + variable "VAR" n'est pas trouvée, la chaîne ${VAR} + n'est pas modifiée, et un avertissement est enregistré dans le + journal. Le caractère ":" est interdit dans les noms de variables + afin d'éviter tout conflit avec la syntaxe de la directive RewriteMap.

+ +

Seules les variables d'environnement du shell définies avant le démarrage + du serveur peuvent être utilisées dans les extensions. + Les variables d'environnement + définies dans le fichier de configuration lui-même, par exemple avec SetEnv, prennent effet trop tard pour + pouvoir être utilisées dans les extensions au sein du fichier de + configuration.

+ +

La longueur maximale d'une ligne dans un fichier de configuration + normal, après substitution des variables et fusion des lignes + interrompues, est approximativement de 16 Mo. Dans les fichiers .htaccess, la longueur + maximale est de 8190 caractères.

+ +

Vous pouvez vérifier l'absence d'erreurs de syntaxe dans vos fichiers + de configuration sans démarrer le serveur à l'aide de la commande + apachectl configtest ou de l'option de ligne de commande + -t.

+ +

Vous pouvez utiliser la définition -DDUMP_CONFIG de + mod_info pour afficher la configuration avec tous + les fichiers inclus et les variables d'environnement évaluées, tous + les commentaires et les sections <IfDefine> et <IfModule> non actives ayant + été supprimés. Cependant, la sortie ne reflète + pas les fusions ou écrasements pouvant intervenir en cas de + définitions multiples de directives.

+
top
+
+

Modules

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

httpd est un serveur modulaire. Ceci implique que seules les + fonctionnalités les plus courantes sont incluses dans le serveur de base. + Les fonctionnalités étendues sont fournies à l'aide de modules qui peuvent être chargés dans httpd. + Par défaut, un jeu de modules de base est inclus dans le + serveur à la compilation. Si le serveur est compilé de façon à utiliser + les modules chargés dynamiquement, + alors les modules peuvent être compilés séparément et chargés à + n'importe quel moment à l'aide de la directive + LoadModule. + Dans le cas contraire, httpd doit être recompilé pour ajouter ou + supprimer des modules. + Les directives de configuration peuvent être incluses de manière + conditionnelle selon la présence ou l'absence d'un module particulier + en les plaçant dans un bloc <IfModule>.

+ +

Pour voir quels modules ont été compilés avec le serveur, + vous pouvez utiliser l'option de ligne de commande -l.

+
top
+
+

Portée des directives

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

Les directives placées dans les fichiers de configuration principaux + s'appliquent au serveur dans son ensemble. Si vous souhaitez modifier la + configuration d'une partie du serveur seulement, vous pouvez limiter la + portée de vos directives en les plaçant dans une section + <Directory>, <DirectoryMatch>, <Files>, <FilesMatch>, <Location>, ou <LocationMatch>. + Ces sections limitent le champ d'application des directives qu'elles + contiennent à des URls ou des portions du système de fichiers particulières. + Elles peuvent aussi être imbriquées, ce qui permet + une configuration très fine.

+ +

httpd peut servir simultanément de nombreux sites web au travers des + Hôtes Virtuels. La portée des directives peut ainsi + être limitée en les plaçant dans des sections + <VirtualHost>, + afin qu'elles ne s'appliquent qu'aux requêtes + pour un site web particulier.

+ +

Bien que la plupart des directives puissent être placées dans + chacune de ces sections, certaines d'entre elles n'ont aucun sens + dans certains contextes. + Par exemple, les directives qui contrôlent la création des processus + n'ont de sens que dans le contexte du serveur principal. Pour déterminer + quelles directives peuvent être placées dans quelles sections, consultez + le Contexte de la + directive. Pour plus d'informations, nous fournissons des détails dans + Comment fonctionnent les sections Directory, + Location et Files.

+
top
+
+

Fichiers .htaccess

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

httpd permet la gestion décentralisée de la configuration + via des fichiers spéciaux placés dans l'arborescence du site web. + Ces fichiers spéciaux se nomment en général .htaccess, + mais tout autre nom peut être spécifié à l'aide de la directive + AccessFileName. + Les directives placées dans les fichiers .htaccess + s'appliquent au répertoire dans lequel vous avez placé le fichier, + ainsi qu'à tous ses sous-répertoires. + La syntaxe des fichiers .htaccess est la même que celle + des fichiers de configuration principaux. Comme les fichiers + .htaccess sont lus à chaque requête, les modifications de + ces fichiers prennent effet immédiatement.

+ +

Pour déterminer quelles directives peuvent être placées + dans les fichiers .htaccess, consultez le + Contexte de la + directive. L'administrateur du serveur peut contrôler quelles + directives peuvent être placées dans les fichiers + .htaccess en définissant la directive + AllowOverride + dans les fichiers de configuration principaux.

+ +

Pour plus d'informations sur les fichiers .htaccess, + se référer au tutoriel .htaccess.

+
+
+

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

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/content-negotiation.html.en b/docs/manual/content-negotiation.html.en index 031147a9c7..b25658f807 100644 --- a/docs/manual/content-negotiation.html.en +++ b/docs/manual/content-negotiation.html.en @@ -24,10 +24,10 @@ Apache > HTTP Server > Documentation > Version 2.5

Content Negotiation

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

+ tr 

@@ -680,10 +680,10 @@ factors to 5 decimal places before choosing the best variant.

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

+ tr 

top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
- - -
-

Modules | Directives | FAQ | Glossaire | Plan du site

-

Serveur HTTP Apache Version 2.5

-
-
<-
-

Négociation de contenu

-
-

Langues Disponibles:  en  | - fr  | - ja  | - ko  | - tr 

-
- - -

Apache HTTPD supporte la négociation de - contenu telle qu'elle est décrite - dans la spécification HTTP/1.1. Il peut choisir la meilleure représentation - d'une ressource en fonction des préférences du navigateur pour ce qui - concerne le type de media, les langages, le jeu de caractères et son - encodage. Il implémente aussi quelques fonctionnalités pour traiter de - manière plus intelligente les requêtes en provenance de navigateurs qui - envoient des informations de négociation incomplètes.

- -

La négociation de contenu est assurée par le module - mod_negotiation qui est compilé par défaut - dans le serveur.

-
- -
top
-
-

À propos de la négociation de contenu

- -

Une ressource peut être disponible selon différentes représentations. - Par exemple, elle peut être disponible en différents langages ou pour - différents types de média, ou une combinaison des deux. - Pour faire le meilleur choix, on peut fournir à l'utilisateur une page - d'index, et le laisser choisir. Cependant, le serveur peut souvent faire - ce choix automatiquement. Ceci est possible car les navigateurs peuvent - envoyer des informations sur les - représentations qu'ils préfèrent à l'intérieur de chaque requête. - Par exemple, un navigateur peut indiquer - qu'il préfère voir les informations en français, mais qu'en cas - d'impossibilité l'anglais peut convenir. Les navigateurs indiquent leurs - préférences à l'aide d'en-têtes dans la requête. Pour ne demander que des - représentations en français, le navigateur peut utiliser l'en-tête :

- -

Accept-Language: fr

- -

Notez qu'il ne sera tenu compte de cette préférence que s'il existe un - choix de représentations et que ces dernières varient en fonction - du langage.

- -

À titre d'exemple d'une requête plus complexe, ce navigateur a été - configuré pour accepter le français et l'anglais, avec une préférence pour - le français, et accepter différents types de média, avec une préférence - pour HTML par rapport à au texte plat ("plain text") ou autres types de fichiers texte, et - avec une préférence pour GIF ou JPEG par rapport à tout autre type de - média, mais autorisant tout autre type de média en dernier ressort :

- -

- Accept-Language: fr; q=1.0, en; q=0.5
- Accept: text/html; q=1.0, text/*; q=0.8, image/gif; q=0.6, image/jpeg; q=0.6, image/*; q=0.5, */*; q=0.1 -

- -

httpd supporte la négociation de contenu "server driven" (telle qu'elle - est définie dans la spécification HTTP/1.1), où c'est le serveur qui - décide quelle est la meilleure représentation à retourner pour la ressource - demandée. Il supporte entièrement les en-têtes de requête - Accept, Accept-Language, - Accept-Charset et Accept-Encoding. - httpd supporte aussi la négociation de contenu transparente, qui est un - protocole de négociation expérimental défini dans les RFC 2295 et 2296. - Il ne supporte pas la négociation de fonctionnalité (feature negotiation) - telle qu'elle est définie dans ces RFCs.

- -

Une ressource est une entité conceptuelle identifiée - par une URI (RFC 2396). Un serveur HTTP comme le serveur HTTP Apache - propose l'accès à des - représentations de la ressource à l'intérieur de son - espace de nommage, chaque représentation étant composée d'une séquence - d'octets avec la définition d'un type de media, d'un jeu de caractères, - d'un encodage, etc... A un instant donné, chaque ressource peut être - associée avec zéro, une ou plusieurs représentations. Si plusieurs - représentations sont disponibles, la ressource est qualifiée de - négociable et chacune de ses représentations se nomme - variante. Les différences entre les - variantes disponibles d'une ressource négociable constituent les - dimensions de la négociation.

-
top
-
-

La négociation avec httpd

- -

Afin de négocier une ressource, on doit fournir au serveur des - informations à propos de chacune des variantes. Il y a deux manières - d'accomplir ceci :

- -
    -
  • Utiliser une liste de correspondances de type ("type-map") (c'est à dire - un fichier *.var) qui nomme explicitement les fichiers - contenant les variantes, ou
    • - -
  • Utiliser une recherche "multivues", où le serveur effectue une - recherche de correspondance sur un motif de nom de fichier implicite et - fait son choix parmi les différents résultats.
    • -
- -

Utilisation d'un fichier de - correspondances de types (type-map)

- -

Une liste de correspondances de types est un document associé au - gestionnaire type-map (ou, dans un souci de compatibilité - ascendante avec des configurations de httpd plus anciennes, le - type MIME - application/x-type-map). Notez que pour utiliser cette - fonctionnalité, vous devez, dans le fichier de configuration, définir un - gestionnaire qui associe un suffixe de fichier à une type-map; - ce qui se fait simplement en ajoutant

- -
AddHandler type-map .var
- - -

dans le fichier de configuration du serveur.

- -

Les fichiers de correspondances de types doivent posséder le même nom que - la ressource qu'ils décrivent, avec pour extension - .var. Dans l'exemple ci-dessous, la ressource a pour - nom foo, et le fichier de correspondances se nomme donc - foo.var.

- -

Ce fichier doit comporter une entrée pour chaque variante - disponible; chaque entrée consiste en une ligne contiguë d'en-têtes au - format HTTP. les entrées sont séparées par des lignes vides. Les lignes - vides à l'intérieur d'une entrée sont interdites. Par convention, le - fichier de correspondances de types débute par une entrée concernant l'entité - considérée dans son ensemble (bien que ce ne soit pas obligatoire, et - ignoré si présent). Un exemple de fichier de - correspondance de types est fourni - ci-dessous.

- -

Les URIs de ce fichier sont relatifs à la localisation du fichier - de correspondances de types. En général, ces fichiers se trouveront dans le - même répertoire que le fichier de correspondances de types, mais ce - n'est pas obligatoire. Vous pouvez utiliser des URIs absolus ou - relatifs pour tout fichier situé sur le même serveur que le fichier - de correspondances.

- -

- URI: foo
-
- URI: foo.en.html
- Content-type: text/html
- Content-language: en
-
- URI: foo.fr.de.html
- Content-type: text/html;charset=iso-8859-2
- Content-language: fr, de
-

- -

Notez aussi qu'un fichier de correspondances de types prend le pas sur - les extensions de noms de fichiers, même si les Multivues sont activées. - Si les variantes sont de qualités différentes, on doit l'indiquer - à l'aide du paramètre "qs" à la suite du type de média, comme pour cette - image - (disponible aux formats JPEG, GIF, ou ASCII-art) :

- -

- URI: foo
-
- URI: foo.jpeg
- Content-type: image/jpeg; qs=0.8
-
- URI: foo.gif
- Content-type: image/gif; qs=0.5
-
- URI: foo.txt
- Content-type: text/plain; qs=0.01
-

- -

Les valeurs de qs peuvent varier de 0.000 à 1.000. Notez que toute - variante possédant une valeur de qs de 0.000 ne sera jamais choisie. - Les variantes qui n'ont pas de paramètre qs défini se voient attribuer - une valeur de 1.0. Le paramètre qs indique la qualité relative de la - variante comparée à celle des autres variantes disponibles, sans tenir - compte des capacités du client. Par exemple, un fichier JPEG possède - en général une qualité supérieure à celle d'un fichier ASCII s'il - représente une photographie. Cependant, si la ressource représentée est - à un ASCII art original, la représentation ASCII sera de meilleure qualité - que la représentation JPEG. Ainsi une valeur de qs est associée à une - variante en fonction de la nature de la ressource qu'elle représente.

- -

La liste complète des en-têtes reconnus est disponible dans la - documentation sur les correspondances de types du - module mod_negotiation.

- - -

Multivues (option Multiviews)

- -

MultiViews est une option qui s'applique à un répertoire, - ce qui signifie qu'elle peut être activée à l'aide d'une directive - Options à l'intérieur d'une section - <Directory>, <Location> ou <Files> dans - httpd.conf, ou (si AllowOverride est correctement positionnée) dans - des fichiers - .htaccess. Notez que Options All - n'active pas MultiViews; vous devez activer cette option en - la nommant explicitement.

- -

L'effet de MultiViews est le suivant : si le serveur reçoit - une requête pour /tel/répertoire/foo, si - MultiViews est activée pour - /tel/répertoire, et si - /tel/répertoire/foo n'existe pas, le serveur parcourt - le répertoire à la recherche de fichiers nommés foo.*, et simule - littéralement une correspondance de types (type map) qui liste tous ces - fichiers, en leur associant les mêmes types de média et encodages de - contenu qu'ils auraient eu si le client avait demandé l'accès à l'un - d'entre eux par son nom. Il choisit ensuite ce qui correspond le mieux - aux besoins du client.

- -

MultiViews peut aussi s'appliquer à la recherche du fichier - nommé par la directive DirectoryIndex, si le serveur tente d'indexer - un répertoire. Si les fichiers de configuration spécifient

-
DirectoryIndex index
- -

le serveur va choisir entre index.html - et index.html3 si les deux fichiers sont présents. Si aucun - n'est présent, mais index.cgi existe, - le serveur l'exécutera.

- -

Si, parcequ'elle n'est pas reconnue par mod_mime, - l'extension d'un des fichiers du répertoire ne permet pas de - déterminer son jeu de caractères, son type de contenu, son langage, ou son - encodage, alors - le résultat dépendra de la définition de la directive MultiViewsMatch. Cette directive détermine - si les gestionnaires (handlers), les filtres, et autres types d'extensions - peuvent participer à la négociation MultiVues.

- -
top
-
-

Les méthodes de négociation

- -

Une fois obtenue la liste des variantes pour une ressource donnée, - httpd dispose de deux méthodes pour choisir la meilleure variante à - retourner, s'il y a lieu, soit à partir d'un fichier de - correspondances de types, soit en se basant sur les noms de fichiers du - répertoire. Il n'est pas nécessaire de connaître en détails comment la - négociation fonctionne réellement pour pouvoir utiliser les fonctionnalités - de négociation de contenu de httpd. La suite de ce document explique - cependant les méthodes utilisées pour ceux ou celles qui sont - intéressés(ées).

- -

Il existe deux méthodes de négociation :

- -
    -
  1. La négociation effectuée par le serveur selon l'algorithme - de httpd est normalement utilisée. l'algorithme de - httpd est - expliqué plus en détails ci-dessous. Quand cet algorithme est utilisé, - httpd peut parfois "bricoler" le facteur de qualité (qs) d'une dimension - particulière afin d'obtenir un meilleur résultat. - La manière dont httpd peut modifier les facteurs de qualité est - expliquée plus en détails ci-dessous.
    2. - -
  2. La négociation de contenu transparente est utilisée - quand le navigateur le demande explicitement selon le mécanisme défini - dans la RFC 2295. Cette méthode de négociation donne au navigateur le - contrôle total du choix de la meilleure variante; le résultat dépend - cependant de la spécificité des algorithmes utilisés par le navigateur. - Au cours du processus de négociation transparente, le navigateur peut - demander à httpd d'exécuter l'"algorithme de sélection de variante à - distance" défini dans la RFC 2296.
    3. -
- -

Les dimensions de la négociation

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
DimensionNotes
Type de médiaLe navigateur affiche ses préférences à l'aide du champ d'en-tête - Accept. Chaque type de média peut se voir associé un facteur de - qualité. La description de la variante peut aussi avoir un facteur de - qualité (le paramètre "qs").
LangageLe navigateur affiche ses préférences à l'aide du champ d'en-tête - Accept-Language. Chaque langue peut se voir associé un facteur de - qualité. Les variantes peuvent être associées avec zéro, un ou - plusieurs langages.
EncodingLe navigateur affiche ses préférences à l'aide du champ d'en-tête - Accept-Encoding. Chaque encodage peut se voir associé un facteur de - qualité.
CharsetLe navigateur affiche ses préférences à l'aide du champ d'en-tête - Accept-Charset. Chaque jeu de caractère peut se voir associé un facteur de - qualité. Les variantes peuvent préciser un jeu de caractères comme - paramètre du type de média.
- - -

L'algorithme de négociation de -httpd

- -

httpd peut utiliser l'algorithme suivant pour choisir la "meilleure" - variante (s'il y en a une) à retourner au navigateur. Cet algorithme n'est pas - configurable. Il fonctionne comme suit :

- -
    -
  1. En premier lieu, pour chaque dimension de la négociation, consulter - le champ d'en-tête Accept* approprié et assigner une qualité à - chaque variante. Si l'en-tête Accept* pour toute dimension - implique que la variante n'est pas acceptable, éliminer cette dernière. - S'il ne reste plus de variante, aller à l'étape 4.
    2. - -
  2. - Choisir la "meilleure" variante par élimination. Chacun des tests - suivants est effectué dans cet ordre. Toute variante non sélectionnée - à l'issue d'un test est éliminée. Après chaque test, s'il reste une - seule variante, choisir cette dernière comme celle qui correspond le - mieux puis aller à l'étape 3. S'il reste plusieurs variantes, passer - au test suivant. - -
      -
    1. Multiplier le facteur de qualité de l'en-tête - Accept par le facteur de qualité "qs" pour le type de - média de ces variantes, et choisir la variante qui possède la valeur - la plus importante.
      2. - -
    2. Sélectionner les variantes qui possèdent le facteur de qualité - de langage le plus haut.
      3. - -
    3. Sélectionner les variantes dont le langage correspond le mieux, - en se basant sur l'ordre des langages de l'en-tête - Accept-Language (s'il existe), ou de la directive - LanguagePriority (si elle existe).
      4. - -
    4. Sélectionner les variantes possédant le paramètre de média - "level" le plus élevé (utilisé pour préciser la version des types de - média text/html).
      5. - -
    5. Sélectionner les variantes possédant le paramètre de média - "charset" (jeu de caractères) qui correspond le mieux, en se basant - sur la ligne d'en-tête Accept-Charset . Le jeu de - caractères ISO-8859-1 est acceptable sauf s'il est explicitement - exclus. Les variantes avec un type de média text/* - mais non explicitement associées avec un jeu de caractères - particulier sont supposées être en ISO-8859-1.
      6. - -
    6. Sélectionner les variantes dont le paramètre de média "charset" - associé n'est pas ISO-8859-1. S'il n'en existe pas, - sélectionner toutes les variantes.
      7. - -
    7. Sélectionner les variantes avec le meilleur encodage. S'il existe - des variantes avec un encodage acceptable pour le client, - sélectionner celles-ci. Sinon, s'il existe des variantes encodées et - des variantes non encodées, ne sélectionner que les variantes non - encodées. Si toutes les variantes sont encodées ou si aucune - ne l'est, sélectionner toutes les variantes.
      8. - -
    8. Sélectionner les variantes dont le contenu a la longueur - la plus courte.
      9. - -
    9. Sélectionner la première des variantes restantes. Il s'agira - soit de la première variante listée dans le fichier de - correspondances de types, soit, quand les variantes sont lues depuis - le répertoire, la première par ordre alphabétique quand elles sont - triées selon le code ASCII.
      10. -
    -
    3. - -
  3. L'algorithme a maintenant sélectionné une variante considérée comme - la "meilleure", il la retourne donc au client en guise de réponse. - L'en-tête HTTP Vary de la réponse est renseigné de façon à - indiquer les dimensions de la négociation (les navigateurs et les caches - peuvent utiliser cette information lors de la mise en cache de la - ressource). Travail terminé.
    4. - -
  4. Le passage par cette étape signifie qu'aucune variante n'a été - sélectionnée (parcequ'aucune n'est acceptable pour le navigateur). - Envoyer une réponse avec un code de statut 406 (qui signifie "Aucune - représentation acceptable") et un corps comportant un document HTML qui - affiche les variantes disponibles. Renseigner aussi l'en-tête HTTP - Vary de façon à indiquer les dimensions de la variante.
    5. -
- -
top
-
-

Ajustement des valeurs de qualité

- -

Parfois httpd modifie les valeurs de qualité par rapport à celles qui - découleraient d'une stricte interprétation de l'algorithme de négociation - de httpd ci-dessus, ceci pour améliorer les résultats de l'algorithme pour - les navigateurs qui envoient des informations incomplètes ou inappropriées. - Certains des navigateurs les plus populaires envoient des informations dans - l'en-tête Accept qui, sans ce traitement, provoqueraient la - sélection d'une variante inappropriée dans de nombreux cas. Quand un - navigateur envoie des informations complètes et correctes ces ajustements - ne sont pas effectués.

- -

Types de média et caractères génériques

- -

L'en-tête de requête Accept: indique les types de média - souhaités. Il peut aussi contenir des types de média avec caractères - génériques, comme "image/*" ou "*/*" où * correspond à n'importe quelle - chaîne de caractères. Ainsi une requête contenant :

- -

Accept: image/*, */*

- -

indiquerait que tout type de média est acceptable, avec une préférence - pour les types commençant par "image/". - Certains navigateurs ajoutent par défaut des types de média avec caractères - génériques aux types explicitement nommés qu'ils peuvent gérer. - Par exemple :

- -

- Accept: text/html, text/plain, image/gif, image/jpeg, */* -

-

Ceci indique que les types explicitement listés sont préférés, mais - qu'une représentation avec un type différent de ces derniers conviendra - aussi. Les valeurs de qualités explicites, - afin de préciser ce que veut vraiment le navigateur, s'utilisent - comme suit :

-

- Accept: text/html, text/plain, image/gif, image/jpeg, */*; q=0.01 -

-

Les types explicites n'ont pas de facteur de qualité, la valeur par - défaut de leur préférence est donc de 1.0 (la plus haute). Le type avec - caractères génériques */* se voit attribuer une préférence basse de 0.01, - si bien que les types autres que ceux explicitement listés ne seront retournés - que s'il n'existe pas de variante correspondant à un type explicitement - listé.

- -

Si l'en-tête Accept: ne contient pas aucun - facteur de qualité, httpd positionne la valeur de qualité de - "*/*", si present, à 0.01 pour simuler l'effet désiré. Il positionne aussi - la valeur de qualité des types avec caractères génériques au format - "type/*" à 0.02 (ils sont donc préférés à ceux correspondant à "*/*"). Si - un type de média dans l'en-tête Accept: contient un facteur de - qualité, ces valeurs spéciales ne seront pas appliquées, de façon - à ce que les requêtes de navigateurs qui envoient les informations - explicites à prendre en compte fonctionnent comme souhaité.

- - -

Exceptions dans la négociation du -langage

- -

A partir de la version 2.0 de httpd, certaines exceptions ont été - ajoutées à l'algorithme de négociation afin de ménager une issue de secours - quand la négociation ne trouve aucun langage correspondant.

- -

Quand un client demande une page sur votre serveur, si ce dernier ne - parvient pas à trouver une page dont la langue corresponde à l'en-tête - Accept-language envoyé par le navigateur, il enverra au client - une réponse "Aucune variante acceptable" ou "Plusieurs choix possibles". - Pour éviter ces - messages d'erreur, il est possible de configurer httpd de façon à ce que, - dans ces cas, il ignore l'en-tête Accept-language et fournisse - tout de même un document, même s'il ne correspond pas exactement à la - demande explicite du client. La directive ForceLanguagePriority - peut être utilisée pour éviter ces messages d'erreur et leur substituer une - page dont le langage sera déterminé en fonction du contenu de la directive - LanguagePriority.

- -

Le serveur va aussi essayer d'étendre sa recherche de correspondance aux - sous-ensembles de langages quand aucune correspondance exacte ne peut être - trouvée. Par exemple, si un client demande des documents possédant le - langage en-GB, c'est à dire anglais britannique, le standard - HTTP/1.1 n'autorise normalement pas le serveur à faire correspondre cette - demande à un document dont le langage est simplement en. - (Notez qu'inclure en-GB et non en dans l'en-tête - Accept-Language constitue une quasi-erreur de configuration, - car il est très peu probable qu'un lecteur qui comprend l'anglais - britannique, ne comprenne pas l'anglais en général. Malheureusement, de - nombreux clients ont réellement des configurations par défaut de ce type.) - Cependant, si aucune autre correspondance de langage n'est possible, et que le - serveur est sur le point de retourner une erreur "Aucune variable - acceptable" ou de choisir le langage défini par la directive LanguagePriority, le serveur ignorera - la spécification du sous-ensemble de langage et associera la demande en - en-GB à des documents en en. Implicitement, - httpd ajoute le langage parent à la liste de langues acceptés par le - client avec une valeur de qualité très basse. Notez cependant que si le - client demande "en-GB; q=0.9, fr; q=0.8", et le serveur dispose de - documents estampillés "en" et "fr", alors c'est le document "fr" qui sera - retourné, tout ceci dans un souci de compatibilité avec la spécification - HTTP/1.1 et afin de fonctionner efficacement avec les clients - correctement configurés.

- -

Pour supporter les techniques avancées (comme les cookies ou les chemins - d'URL spéciaux) afin de déterminer le langage préféré de l'utilisateur, le - module mod_negotiation reconnaît la - variable d'environnement - prefer-language - depuis la version 2.0.47 de httpd. Si elle est définie et contient un - symbole de langage approprié, mod_negotiation va essayer - de sélectionner une variante correspondante. S'il n'existe pas de telle - variante, le processus normal de négociation sera lancé.

- -

Exemple

SetEnvIf Cookie "language=(.+)" prefer-language=$1
-Header append Vary cookie
-
- -
top
-
-

Extensions à la négociation de contenu -transparente

- -

httpd étend le protocole de négociation de contenu transparente (RFC -2295) comme suit. Un nouvel élément {encodage ..} est utilisé dans -les listes de variantes pour marquer celles qui ne sont disponibles qu'avec un -encodage de contenu spécifique. L'implémentation de l'algorithme -RVSA/1.0 (RFC 2296) est étendue à la reconnaissance de variantes encodées dans -la liste, et à leur utilisation en tant que variantes candidates à partir du -moment où leur encodage satisfait au contenu de l'en-tête de requête -Accept-Encoding. L'implémentation RVSA/1.0 n'arrondit pas les -facteurs de qualité calculés à 5 décimales avant d'avoir choisi la meilleure -variante.

-
top
-
-

Remarques à propos des liens hypertextes et des -conventions de nommage

- -

Si vous utilisez la négociation de langage, vous avez le choix entre - différentes conventions de nommage, car les fichiers peuvent posséder - plusieurs extensions, et l'ordre dans lequel ces dernières apparaissent - est en général sans rapport (voir la documentation sur le module mod_mime - pour plus de détails).

- -

Un fichier type possède une extension liée au type MIME - (par exemple, html), mais parfois aussi une - extension liée à l'encodage (par exemple, gz), - et bien sûr une extension liée au langage - (par exemple, en) quand plusieurs variantes de - langage sont disponibles pour ce fichier.

- -

Exemples :

- -
    -
  • foo.en.html
    • - -
  • foo.html.en
    • - -
  • foo.en.html.gz
    • -
- -

Ci-dessous d'autres exemples de noms de fichiers avec des liens - hypertextes valides et invalides :

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Nom fichierlien valideLien invalide
foo.html.enfoo
- foo.html		-
foo.en.htmlfoofoo.html
foo.html.en.gzfoo
- foo.html		foo.gz
- foo.html.gz
foo.en.html.gzfoofoo.html
- foo.html.gz
- foo.gz
foo.gz.html.enfoo
- foo.gz
- foo.gz.html		foo.html
foo.html.gz.enfoo
- foo.html
- foo.html.gz		foo.gz
- -

En regardant la table ci-dessus, vous remarquerez qu'il est toujours - possible d'utiliser le nom de fichier sans extension dans un lien - (par exemple, foo). L'avantage est de pouvoir - dissimuler le type réel du fichier associé à un document et de pouvoir - le modifier - ultérieurement, par exemple, de html à - shtml ou cgi sans avoir à - mettre à jour aucun lien.

- -

Si vous souhaitez continuer à utiliser un type MIME dans vos liens - (par exemple foo.html), l'extension liée au langage - (y compris une extension liée à l'encodage s'il en existe une) - doit se trouver à droite de l'extension liée au type MIME - (par exemple, foo.html.en).

-
top
-
-

Remarque sur la mise en cache

- -

Quand un cache stocke une représentation, il l'associe avec l'URL de la - requête. Lorsque cette URL est à nouveau demandée, le cache peut utiliser - la représentation stockée. Cependant, si la ressource est négociable au - niveau du serveur, il se peut que seule la première variante demandée soit - mise en cache et de ce fait, la correspondance positive du cache peut - entraîner une réponse inappropriée. Pour - éviter ceci, httpd marque par - défaut toutes les réponses qui sont retournées après une négociation de - contenu comme "non-cachables" par les clients HTTP/1.0. httpd supporte - aussi les fonctionnalités du protocole HTTP/1.1 afin de permettre la mise - en cache des réponses négociées.

- -

Pour les requêtes en provenance d'un client compatible HTTP/1.0 - (un navigateur ou un cache), la directive CacheNegotiatedDocs peut être utilisée - pour permettre la mise en cache des réponses qui ont fait l'objet d'une - négociation. Cette directive peut intervenir dans la configuration au - niveau du serveur ou de l'hôte virtuel, et n'accepte aucun argument. Elle - n'a aucun effet sur les requêtes en provenance de clients HTTP/1.1.

- -

Pour les clients HTTP/1.1, httpd envoie un en-tête de réponse HTTP - Vary afin d'indiquer les dimensions de la négociation pour - cette réponse. Les caches peuvent - utiliser cette information afin de déterminer - si une requête peut être servie à partir de la copie locale. Pour inciter - un cache à utiliser la copie locale sans tenir compte des dimensions de la - négociation, définissez la - variable d'environnement - force-no-vary.

- -
-
-

Langues Disponibles:  en  | - fr  | - ja  | - ko  | - tr 

-
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
-
- \ No newline at end of file diff --git a/docs/manual/content-negotiation.html.fr.utf8 b/docs/manual/content-negotiation.html.fr.utf8 new file mode 100644 index 0000000000..37eb6109db --- /dev/null +++ b/docs/manual/content-negotiation.html.fr.utf8 @@ -0,0 +1,742 @@ + + + + + +Négociation de contenu - Serveur HTTP Apache Version 2.5 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.5

+
+
<-
+

Négociation de contenu

+
+

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

+
+ + +

Apache HTTPD supporte la négociation de + contenu telle qu'elle est décrite + dans la spécification HTTP/1.1. Il peut choisir la meilleure représentation + d'une ressource en fonction des préférences du navigateur pour ce qui + concerne le type de media, les langages, le jeu de caractères et son + encodage. Il implémente aussi quelques fonctionnalités pour traiter de + manière plus intelligente les requêtes en provenance de navigateurs qui + envoient des informations de négociation incomplètes.

+ +

La négociation de contenu est assurée par le module + mod_negotiation qui est compilé par défaut + dans le serveur.

+
+ +
top
+
+

À propos de la négociation de contenu

+ +

Une ressource peut être disponible selon différentes représentations. + Par exemple, elle peut être disponible en différents langages ou pour + différents types de média, ou une combinaison des deux. + Pour faire le meilleur choix, on peut fournir à l'utilisateur une page + d'index, et le laisser choisir. Cependant, le serveur peut souvent faire + ce choix automatiquement. Ceci est possible car les navigateurs peuvent + envoyer des informations sur les + représentations qu'ils préfèrent à l'intérieur de chaque requête. + Par exemple, un navigateur peut indiquer + qu'il préfère voir les informations en français, mais qu'en cas + d'impossibilité l'anglais peut convenir. Les navigateurs indiquent leurs + préférences à l'aide d'en-têtes dans la requête. Pour ne demander que des + représentations en français, le navigateur peut utiliser l'en-tête :

+ +

Accept-Language: fr

+ +

Notez qu'il ne sera tenu compte de cette préférence que s'il existe un + choix de représentations et que ces dernières varient en fonction + du langage.

+ +

À titre d'exemple d'une requête plus complexe, ce navigateur a été + configuré pour accepter le français et l'anglais, avec une préférence pour + le français, et accepter différents types de média, avec une préférence + pour HTML par rapport à au texte plat ("plain text") ou autres types de fichiers texte, et + avec une préférence pour GIF ou JPEG par rapport à tout autre type de + média, mais autorisant tout autre type de média en dernier ressort :

+ +

+ Accept-Language: fr; q=1.0, en; q=0.5
+ Accept: text/html; q=1.0, text/*; q=0.8, image/gif; q=0.6, image/jpeg; q=0.6, image/*; q=0.5, */*; q=0.1 +

+ +

httpd supporte la négociation de contenu "server driven" (telle qu'elle + est définie dans la spécification HTTP/1.1), où c'est le serveur qui + décide quelle est la meilleure représentation à retourner pour la ressource + demandée. Il supporte entièrement les en-têtes de requête + Accept, Accept-Language, + Accept-Charset et Accept-Encoding. + httpd supporte aussi la négociation de contenu transparente, qui est un + protocole de négociation expérimental défini dans les RFC 2295 et 2296. + Il ne supporte pas la négociation de fonctionnalité (feature negotiation) + telle qu'elle est définie dans ces RFCs.

+ +

Une ressource est une entité conceptuelle identifiée + par une URI (RFC 2396). Un serveur HTTP comme le serveur HTTP Apache + propose l'accès à des + représentations de la ressource à l'intérieur de son + espace de nommage, chaque représentation étant composée d'une séquence + d'octets avec la définition d'un type de media, d'un jeu de caractères, + d'un encodage, etc... A un instant donné, chaque ressource peut être + associée avec zéro, une ou plusieurs représentations. Si plusieurs + représentations sont disponibles, la ressource est qualifiée de + négociable et chacune de ses représentations se nomme + variante. Les différences entre les + variantes disponibles d'une ressource négociable constituent les + dimensions de la négociation.

+
top
+
+

La négociation avec httpd

+ +

Afin de négocier une ressource, on doit fournir au serveur des + informations à propos de chacune des variantes. Il y a deux manières + d'accomplir ceci :

+ +
    +
  • Utiliser une liste de correspondances de type ("type-map") (c'est à dire + un fichier *.var) qui nomme explicitement les fichiers + contenant les variantes, ou
    • + +
  • Utiliser une recherche "multivues", où le serveur effectue une + recherche de correspondance sur un motif de nom de fichier implicite et + fait son choix parmi les différents résultats.
    • +
+ +

Utilisation d'un fichier de + correspondances de types (type-map)

+ +

Une liste de correspondances de types est un document associé au + gestionnaire type-map (ou, dans un souci de compatibilité + ascendante avec des configurations de httpd plus anciennes, le + type MIME + application/x-type-map). Notez que pour utiliser cette + fonctionnalité, vous devez, dans le fichier de configuration, définir un + gestionnaire qui associe un suffixe de fichier à une type-map; + ce qui se fait simplement en ajoutant

+ +
AddHandler type-map .var
+ + +

dans le fichier de configuration du serveur.

+ +

Les fichiers de correspondances de types doivent posséder le même nom que + la ressource qu'ils décrivent, avec pour extension + .var. Dans l'exemple ci-dessous, la ressource a pour + nom foo, et le fichier de correspondances se nomme donc + foo.var.

+ +

Ce fichier doit comporter une entrée pour chaque variante + disponible; chaque entrée consiste en une ligne contiguë d'en-têtes au + format HTTP. les entrées sont séparées par des lignes vides. Les lignes + vides à l'intérieur d'une entrée sont interdites. Par convention, le + fichier de correspondances de types débute par une entrée concernant l'entité + considérée dans son ensemble (bien que ce ne soit pas obligatoire, et + ignoré si présent). Un exemple de fichier de + correspondance de types est fourni + ci-dessous.

+ +

Les URIs de ce fichier sont relatifs à la localisation du fichier + de correspondances de types. En général, ces fichiers se trouveront dans le + même répertoire que le fichier de correspondances de types, mais ce + n'est pas obligatoire. Vous pouvez utiliser des URIs absolus ou + relatifs pour tout fichier situé sur le même serveur que le fichier + de correspondances.

+ +

+ URI: foo
+
+ URI: foo.en.html
+ Content-type: text/html
+ Content-language: en
+
+ URI: foo.fr.de.html
+ Content-type: text/html;charset=iso-8859-2
+ Content-language: fr, de
+

+ +

Notez aussi qu'un fichier de correspondances de types prend le pas sur + les extensions de noms de fichiers, même si les Multivues sont activées. + Si les variantes sont de qualités différentes, on doit l'indiquer + à l'aide du paramètre "qs" à la suite du type de média, comme pour cette + image + (disponible aux formats JPEG, GIF, ou ASCII-art) :

+ +

+ URI: foo
+
+ URI: foo.jpeg
+ Content-type: image/jpeg; qs=0.8
+
+ URI: foo.gif
+ Content-type: image/gif; qs=0.5
+
+ URI: foo.txt
+ Content-type: text/plain; qs=0.01
+

+ +

Les valeurs de qs peuvent varier de 0.000 à 1.000. Notez que toute + variante possédant une valeur de qs de 0.000 ne sera jamais choisie. + Les variantes qui n'ont pas de paramètre qs défini se voient attribuer + une valeur de 1.0. Le paramètre qs indique la qualité relative de la + variante comparée à celle des autres variantes disponibles, sans tenir + compte des capacités du client. Par exemple, un fichier JPEG possède + en général une qualité supérieure à celle d'un fichier ASCII s'il + représente une photographie. Cependant, si la ressource représentée est + à un ASCII art original, la représentation ASCII sera de meilleure qualité + que la représentation JPEG. Ainsi une valeur de qs est associée à une + variante en fonction de la nature de la ressource qu'elle représente.

+ +

La liste complète des en-têtes reconnus est disponible dans la + documentation sur les correspondances de types du + module mod_negotiation.

+ + +

Multivues (option Multiviews)

+ +

MultiViews est une option qui s'applique à un répertoire, + ce qui signifie qu'elle peut être activée à l'aide d'une directive + Options à l'intérieur d'une section + <Directory>, <Location> ou <Files> dans + httpd.conf, ou (si AllowOverride est correctement positionnée) dans + des fichiers + .htaccess. Notez que Options All + n'active pas MultiViews; vous devez activer cette option en + la nommant explicitement.

+ +

L'effet de MultiViews est le suivant : si le serveur reçoit + une requête pour /tel/répertoire/foo, si + MultiViews est activée pour + /tel/répertoire, et si + /tel/répertoire/foo n'existe pas, le serveur parcourt + le répertoire à la recherche de fichiers nommés foo.*, et simule + littéralement une correspondance de types (type map) qui liste tous ces + fichiers, en leur associant les mêmes types de média et encodages de + contenu qu'ils auraient eu si le client avait demandé l'accès à l'un + d'entre eux par son nom. Il choisit ensuite ce qui correspond le mieux + aux besoins du client.

+ +

MultiViews peut aussi s'appliquer à la recherche du fichier + nommé par la directive DirectoryIndex, si le serveur tente d'indexer + un répertoire. Si les fichiers de configuration spécifient

+
DirectoryIndex index
+ +

le serveur va choisir entre index.html + et index.html3 si les deux fichiers sont présents. Si aucun + n'est présent, mais index.cgi existe, + le serveur l'exécutera.

+ +

Si, parcequ'elle n'est pas reconnue par mod_mime, + l'extension d'un des fichiers du répertoire ne permet pas de + déterminer son jeu de caractères, son type de contenu, son langage, ou son + encodage, alors + le résultat dépendra de la définition de la directive MultiViewsMatch. Cette directive détermine + si les gestionnaires (handlers), les filtres, et autres types d'extensions + peuvent participer à la négociation MultiVues.

+ +
top
+
+

Les méthodes de négociation

+ +

Une fois obtenue la liste des variantes pour une ressource donnée, + httpd dispose de deux méthodes pour choisir la meilleure variante à + retourner, s'il y a lieu, soit à partir d'un fichier de + correspondances de types, soit en se basant sur les noms de fichiers du + répertoire. Il n'est pas nécessaire de connaître en détails comment la + négociation fonctionne réellement pour pouvoir utiliser les fonctionnalités + de négociation de contenu de httpd. La suite de ce document explique + cependant les méthodes utilisées pour ceux ou celles qui sont + intéressés(ées).

+ +

Il existe deux méthodes de négociation :

+ +
    +
  1. La négociation effectuée par le serveur selon l'algorithme + de httpd est normalement utilisée. l'algorithme de + httpd est + expliqué plus en détails ci-dessous. Quand cet algorithme est utilisé, + httpd peut parfois "bricoler" le facteur de qualité (qs) d'une dimension + particulière afin d'obtenir un meilleur résultat. + La manière dont httpd peut modifier les facteurs de qualité est + expliquée plus en détails ci-dessous.
    2. + +
  2. La négociation de contenu transparente est utilisée + quand le navigateur le demande explicitement selon le mécanisme défini + dans la RFC 2295. Cette méthode de négociation donne au navigateur le + contrôle total du choix de la meilleure variante; le résultat dépend + cependant de la spécificité des algorithmes utilisés par le navigateur. + Au cours du processus de négociation transparente, le navigateur peut + demander à httpd d'exécuter l'"algorithme de sélection de variante à + distance" défini dans la RFC 2296.
    3. +
+ +

Les dimensions de la négociation

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
DimensionNotes
Type de médiaLe navigateur affiche ses préférences à l'aide du champ d'en-tête + Accept. Chaque type de média peut se voir associé un facteur de + qualité. La description de la variante peut aussi avoir un facteur de + qualité (le paramètre "qs").
LangageLe navigateur affiche ses préférences à l'aide du champ d'en-tête + Accept-Language. Chaque langue peut se voir associé un facteur de + qualité. Les variantes peuvent être associées avec zéro, un ou + plusieurs langages.
EncodingLe navigateur affiche ses préférences à l'aide du champ d'en-tête + Accept-Encoding. Chaque encodage peut se voir associé un facteur de + qualité.
CharsetLe navigateur affiche ses préférences à l'aide du champ d'en-tête + Accept-Charset. Chaque jeu de caractère peut se voir associé un facteur de + qualité. Les variantes peuvent préciser un jeu de caractères comme + paramètre du type de média.
+ + +

L'algorithme de négociation de +httpd

+ +

httpd peut utiliser l'algorithme suivant pour choisir la "meilleure" + variante (s'il y en a une) à retourner au navigateur. Cet algorithme n'est pas + configurable. Il fonctionne comme suit :

+ +
    +
  1. En premier lieu, pour chaque dimension de la négociation, consulter + le champ d'en-tête Accept* approprié et assigner une qualité à + chaque variante. Si l'en-tête Accept* pour toute dimension + implique que la variante n'est pas acceptable, éliminer cette dernière. + S'il ne reste plus de variante, aller à l'étape 4.
    2. + +
  2. + Choisir la "meilleure" variante par élimination. Chacun des tests + suivants est effectué dans cet ordre. Toute variante non sélectionnée + à l'issue d'un test est éliminée. Après chaque test, s'il reste une + seule variante, choisir cette dernière comme celle qui correspond le + mieux puis aller à l'étape 3. S'il reste plusieurs variantes, passer + au test suivant. + +
      +
    1. Multiplier le facteur de qualité de l'en-tête + Accept par le facteur de qualité "qs" pour le type de + média de ces variantes, et choisir la variante qui possède la valeur + la plus importante.
      2. + +
    2. Sélectionner les variantes qui possèdent le facteur de qualité + de langage le plus haut.
      3. + +
    3. Sélectionner les variantes dont le langage correspond le mieux, + en se basant sur l'ordre des langages de l'en-tête + Accept-Language (s'il existe), ou de la directive + LanguagePriority (si elle existe).
      4. + +
    4. Sélectionner les variantes possédant le paramètre de média + "level" le plus élevé (utilisé pour préciser la version des types de + média text/html).
      5. + +
    5. Sélectionner les variantes possédant le paramètre de média + "charset" (jeu de caractères) qui correspond le mieux, en se basant + sur la ligne d'en-tête Accept-Charset . Le jeu de + caractères ISO-8859-1 est acceptable sauf s'il est explicitement + exclus. Les variantes avec un type de média text/* + mais non explicitement associées avec un jeu de caractères + particulier sont supposées être en ISO-8859-1.
      6. + +
    6. Sélectionner les variantes dont le paramètre de média "charset" + associé n'est pas ISO-8859-1. S'il n'en existe pas, + sélectionner toutes les variantes.
      7. + +
    7. Sélectionner les variantes avec le meilleur encodage. S'il existe + des variantes avec un encodage acceptable pour le client, + sélectionner celles-ci. Sinon, s'il existe des variantes encodées et + des variantes non encodées, ne sélectionner que les variantes non + encodées. Si toutes les variantes sont encodées ou si aucune + ne l'est, sélectionner toutes les variantes.
      8. + +
    8. Sélectionner les variantes dont le contenu a la longueur + la plus courte.
      9. + +
    9. Sélectionner la première des variantes restantes. Il s'agira + soit de la première variante listée dans le fichier de + correspondances de types, soit, quand les variantes sont lues depuis + le répertoire, la première par ordre alphabétique quand elles sont + triées selon le code ASCII.
      10. +
    +
    3. + +
  3. L'algorithme a maintenant sélectionné une variante considérée comme + la "meilleure", il la retourne donc au client en guise de réponse. + L'en-tête HTTP Vary de la réponse est renseigné de façon à + indiquer les dimensions de la négociation (les navigateurs et les caches + peuvent utiliser cette information lors de la mise en cache de la + ressource). Travail terminé.
    4. + +
  4. Le passage par cette étape signifie qu'aucune variante n'a été + sélectionnée (parcequ'aucune n'est acceptable pour le navigateur). + Envoyer une réponse avec un code de statut 406 (qui signifie "Aucune + représentation acceptable") et un corps comportant un document HTML qui + affiche les variantes disponibles. Renseigner aussi l'en-tête HTTP + Vary de façon à indiquer les dimensions de la variante.
    5. +
+ +
top
+
+

Ajustement des valeurs de qualité

+ +

Parfois httpd modifie les valeurs de qualité par rapport à celles qui + découleraient d'une stricte interprétation de l'algorithme de négociation + de httpd ci-dessus, ceci pour améliorer les résultats de l'algorithme pour + les navigateurs qui envoient des informations incomplètes ou inappropriées. + Certains des navigateurs les plus populaires envoient des informations dans + l'en-tête Accept qui, sans ce traitement, provoqueraient la + sélection d'une variante inappropriée dans de nombreux cas. Quand un + navigateur envoie des informations complètes et correctes ces ajustements + ne sont pas effectués.

+ +

Types de média et caractères génériques

+ +

L'en-tête de requête Accept: indique les types de média + souhaités. Il peut aussi contenir des types de média avec caractères + génériques, comme "image/*" ou "*/*" où * correspond à n'importe quelle + chaîne de caractères. Ainsi une requête contenant :

+ +

Accept: image/*, */*

+ +

indiquerait que tout type de média est acceptable, avec une préférence + pour les types commençant par "image/". + Certains navigateurs ajoutent par défaut des types de média avec caractères + génériques aux types explicitement nommés qu'ils peuvent gérer. + Par exemple :

+ +

+ Accept: text/html, text/plain, image/gif, image/jpeg, */* +

+

Ceci indique que les types explicitement listés sont préférés, mais + qu'une représentation avec un type différent de ces derniers conviendra + aussi. Les valeurs de qualités explicites, + afin de préciser ce que veut vraiment le navigateur, s'utilisent + comme suit :

+

+ Accept: text/html, text/plain, image/gif, image/jpeg, */*; q=0.01 +

+

Les types explicites n'ont pas de facteur de qualité, la valeur par + défaut de leur préférence est donc de 1.0 (la plus haute). Le type avec + caractères génériques */* se voit attribuer une préférence basse de 0.01, + si bien que les types autres que ceux explicitement listés ne seront retournés + que s'il n'existe pas de variante correspondant à un type explicitement + listé.

+ +

Si l'en-tête Accept: ne contient pas aucun + facteur de qualité, httpd positionne la valeur de qualité de + "*/*", si present, à 0.01 pour simuler l'effet désiré. Il positionne aussi + la valeur de qualité des types avec caractères génériques au format + "type/*" à 0.02 (ils sont donc préférés à ceux correspondant à "*/*"). Si + un type de média dans l'en-tête Accept: contient un facteur de + qualité, ces valeurs spéciales ne seront pas appliquées, de façon + à ce que les requêtes de navigateurs qui envoient les informations + explicites à prendre en compte fonctionnent comme souhaité.

+ + +

Exceptions dans la négociation du +langage

+ +

A partir de la version 2.0 de httpd, certaines exceptions ont été + ajoutées à l'algorithme de négociation afin de ménager une issue de secours + quand la négociation ne trouve aucun langage correspondant.

+ +

Quand un client demande une page sur votre serveur, si ce dernier ne + parvient pas à trouver une page dont la langue corresponde à l'en-tête + Accept-language envoyé par le navigateur, il enverra au client + une réponse "Aucune variante acceptable" ou "Plusieurs choix possibles". + Pour éviter ces + messages d'erreur, il est possible de configurer httpd de façon à ce que, + dans ces cas, il ignore l'en-tête Accept-language et fournisse + tout de même un document, même s'il ne correspond pas exactement à la + demande explicite du client. La directive ForceLanguagePriority + peut être utilisée pour éviter ces messages d'erreur et leur substituer une + page dont le langage sera déterminé en fonction du contenu de la directive + LanguagePriority.

+ +

Le serveur va aussi essayer d'étendre sa recherche de correspondance aux + sous-ensembles de langages quand aucune correspondance exacte ne peut être + trouvée. Par exemple, si un client demande des documents possédant le + langage en-GB, c'est à dire anglais britannique, le standard + HTTP/1.1 n'autorise normalement pas le serveur à faire correspondre cette + demande à un document dont le langage est simplement en. + (Notez qu'inclure en-GB et non en dans l'en-tête + Accept-Language constitue une quasi-erreur de configuration, + car il est très peu probable qu'un lecteur qui comprend l'anglais + britannique, ne comprenne pas l'anglais en général. Malheureusement, de + nombreux clients ont réellement des configurations par défaut de ce type.) + Cependant, si aucune autre correspondance de langage n'est possible, et que le + serveur est sur le point de retourner une erreur "Aucune variable + acceptable" ou de choisir le langage défini par la directive LanguagePriority, le serveur ignorera + la spécification du sous-ensemble de langage et associera la demande en + en-GB à des documents en en. Implicitement, + httpd ajoute le langage parent à la liste de langues acceptés par le + client avec une valeur de qualité très basse. Notez cependant que si le + client demande "en-GB; q=0.9, fr; q=0.8", et le serveur dispose de + documents estampillés "en" et "fr", alors c'est le document "fr" qui sera + retourné, tout ceci dans un souci de compatibilité avec la spécification + HTTP/1.1 et afin de fonctionner efficacement avec les clients + correctement configurés.

+ +

Pour supporter les techniques avancées (comme les cookies ou les chemins + d'URL spéciaux) afin de déterminer le langage préféré de l'utilisateur, le + module mod_negotiation reconnaît la + variable d'environnement + prefer-language + depuis la version 2.0.47 de httpd. Si elle est définie et contient un + symbole de langage approprié, mod_negotiation va essayer + de sélectionner une variante correspondante. S'il n'existe pas de telle + variante, le processus normal de négociation sera lancé.

+ +

Exemple

SetEnvIf Cookie "language=(.+)" prefer-language=$1
+Header append Vary cookie
+
+ +
top
+
+

Extensions à la négociation de contenu +transparente

+ +

httpd étend le protocole de négociation de contenu transparente (RFC +2295) comme suit. Un nouvel élément {encodage ..} est utilisé dans +les listes de variantes pour marquer celles qui ne sont disponibles qu'avec un +encodage de contenu spécifique. L'implémentation de l'algorithme +RVSA/1.0 (RFC 2296) est étendue à la reconnaissance de variantes encodées dans +la liste, et à leur utilisation en tant que variantes candidates à partir du +moment où leur encodage satisfait au contenu de l'en-tête de requête +Accept-Encoding. L'implémentation RVSA/1.0 n'arrondit pas les +facteurs de qualité calculés à 5 décimales avant d'avoir choisi la meilleure +variante.

+
top
+
+

Remarques à propos des liens hypertextes et des +conventions de nommage

+ +

Si vous utilisez la négociation de langage, vous avez le choix entre + différentes conventions de nommage, car les fichiers peuvent posséder + plusieurs extensions, et l'ordre dans lequel ces dernières apparaissent + est en général sans rapport (voir la documentation sur le module mod_mime + pour plus de détails).

+ +

Un fichier type possède une extension liée au type MIME + (par exemple, html), mais parfois aussi une + extension liée à l'encodage (par exemple, gz), + et bien sûr une extension liée au langage + (par exemple, en) quand plusieurs variantes de + langage sont disponibles pour ce fichier.

+ +

Exemples :

+ +
    +
  • foo.en.html
    • + +
  • foo.html.en
    • + +
  • foo.en.html.gz
    • +
+ +

Ci-dessous d'autres exemples de noms de fichiers avec des liens + hypertextes valides et invalides :

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Nom fichierlien valideLien invalide
foo.html.enfoo
+ foo.html		-
foo.en.htmlfoofoo.html
foo.html.en.gzfoo
+ foo.html		foo.gz
+ foo.html.gz
foo.en.html.gzfoofoo.html
+ foo.html.gz
+ foo.gz
foo.gz.html.enfoo
+ foo.gz
+ foo.gz.html		foo.html
foo.html.gz.enfoo
+ foo.html
+ foo.html.gz		foo.gz
+ +

En regardant la table ci-dessus, vous remarquerez qu'il est toujours + possible d'utiliser le nom de fichier sans extension dans un lien + (par exemple, foo). L'avantage est de pouvoir + dissimuler le type réel du fichier associé à un document et de pouvoir + le modifier + ultérieurement, par exemple, de html à + shtml ou cgi sans avoir à + mettre à jour aucun lien.

+ +

Si vous souhaitez continuer à utiliser un type MIME dans vos liens + (par exemple foo.html), l'extension liée au langage + (y compris une extension liée à l'encodage s'il en existe une) + doit se trouver à droite de l'extension liée au type MIME + (par exemple, foo.html.en).

+
top
+
+

Remarque sur la mise en cache

+ +

Quand un cache stocke une représentation, il l'associe avec l'URL de la + requête. Lorsque cette URL est à nouveau demandée, le cache peut utiliser + la représentation stockée. Cependant, si la ressource est négociable au + niveau du serveur, il se peut que seule la première variante demandée soit + mise en cache et de ce fait, la correspondance positive du cache peut + entraîner une réponse inappropriée. Pour + éviter ceci, httpd marque par + défaut toutes les réponses qui sont retournées après une négociation de + contenu comme "non-cachables" par les clients HTTP/1.0. httpd supporte + aussi les fonctionnalités du protocole HTTP/1.1 afin de permettre la mise + en cache des réponses négociées.

+ +

Pour les requêtes en provenance d'un client compatible HTTP/1.0 + (un navigateur ou un cache), la directive CacheNegotiatedDocs peut être utilisée + pour permettre la mise en cache des réponses qui ont fait l'objet d'une + négociation. Cette directive peut intervenir dans la configuration au + niveau du serveur ou de l'hôte virtuel, et n'accepte aucun argument. Elle + n'a aucun effet sur les requêtes en provenance de clients HTTP/1.1.

+ +

Pour les clients HTTP/1.1, httpd envoie un en-tête de réponse HTTP + Vary afin d'indiquer les dimensions de la négociation pour + cette réponse. Les caches peuvent + utiliser cette information afin de déterminer + si une requête peut être servie à partir de la copie locale. Pour inciter + un cache à utiliser la copie locale sans tenir compte des dimensions de la + négociation, définissez la + variable d'environnement + force-no-vary.

+ +
+
+

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

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/convenience.map b/docs/manual/convenience.map index 2900545621..5dcab5c066 100644 --- a/docs/manual/convenience.map +++ b/docs/manual/convenience.map @@ -215,6 +215,7 @@ dbdriver mod/mod_dbd.html#dbdriver defaulticon mod/mod_autoindex.html#defaulticon defaultlanguage mod/mod_mime.html#defaultlanguage defaultruntimedir mod/core.html#defaultruntimedir +defaultstatedir mod/core.html#defaultstatedir defaulttype mod/core.html#defaulttype define mod/core.html#define deflatealteretag mod/mod_deflate.html#deflatealteretag diff --git a/docs/manual/custom-error.html b/docs/manual/custom-error.html index 70e342a219..5401fc36bd 100644 --- a/docs/manual/custom-error.html +++ b/docs/manual/custom-error.html @@ -6,7 +6,7 @@ Content-type: text/html; charset=ISO-8859-1 URI: custom-error.html.es Content-Language: es -Content-type: text/html; charset=ISO-8859-1 +Content-type: text/html; charset=UTF-8 URI: custom-error.html.fr Content-Language: fr diff --git a/docs/manual/custom-error.html.en b/docs/manual/custom-error.html.en index c71dd61bf9..1444a68f8d 100644 --- a/docs/manual/custom-error.html.en +++ b/docs/manual/custom-error.html.en @@ -24,11 +24,11 @@ Apache > HTTP Server > Documentation > Version 2.5

Custom Error Responses

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

+ tr 

@@ -205,11 +205,11 @@ printf "Status: %s Condition Intercepted\n", $ENV{"REDIRECT_STATUS"};

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

+ tr 

top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
- - -
-

Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

-

Versin 2.5 del Servidor HTTP Apache

-
-
<-
-

Respuestas de Error Personalizadas

-
-

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

-
- - -

Aunque el Servidor Apache HTTP ofrece respuestas de error genricos en - el caso de los cdigos de estado 4xx o 5xx HTTP, stas respuestas son - bastante austeras, no informativas, y puede ser intimidante para los - usuarios del sitio. Si lo desea, para proporcionar respuestas de error - personalizados que son o bien ms amables, o en algn idioma que no sea - Ingls, o tal vez que son de un estilo ms acorde con su diseo del sitio.

- -

Respuestas de error personalizadas se pueden definir para cualquier cdigo HTTP - designado como condicin de error - Esto es, cualquier estado 4xx 5xx.

- -

Adems, se proporcionan un conjunto de valores, de manera que el - documento de error puede ser personalizado ms adelante, basado en - los valores de estas variables, usando Inclusiones del - Lado del Servidor (SSI). O bien, puede tener condiciones de error que maneje - un cgi, u otro controlador dinmico (PHP, mod_perl, etc), que - hace uso de estas variables.

- -
- -
top
-
-

Configuracin

- -

Los documentos de error personalizados se configuran - mediante la directiva ErrorDocument, - que puede ser usado en el conjunto general, de los hosts virtuales o en directorios. - Tambin pueden ser usados en los ficheros .htaccess si - AllowOverrideesta configurado a - FileInfo.

- - 
ErrorDocument 500 "Perdn, Nuestro escript ha fallado. Ay Madre!"

-ErrorDocument 500 /cgi-bin/crash-recover

-ErrorDocument 500 http://error.example.com/server_error.html

-ErrorDocument 404 /errors/not_found.html 

-ErrorDocument 401 /subscription/como_suscribirse.html
- - -

La sintaxis de la directiva de ErrorDocument es:

- - 
ErrorDocument <cdigo-de-3-dgitos> <accin>
- - -

Donde la accin ser tratada como:

- -
    -
  1. Una URL local a la que redireccionar (si la accin empieza con "/").
    2. -
  2. Una URL externa a la que redireccionar (si la accin es una URL vlida).
    3. -
  3. Texto para mostrar (si ninguna de las anteriores). El texto tiene que estar - entrecomillado ("ERROR") si consiste de mas de una palabra.
    4. -
- -

Cuando se redirija a una URL local, se establecen variables de - entorno adicionales de manera que la respuesta puede ser personalizada. - stas variables no se envan a URLs externas

- -
top
-
-

Variables Disponibles

- -

Redireccionando a otra URL puede ser til, pero slo si algo de informacin - puede ser pasado como parmetro, lo cul puede ser usado para explicar de - forma ms clara el error o crear un log del mismo.

- -

Para conseguir esto, cuando se enva el redireccionamiento de error, - se establecern variables de entorno adicionales, que ser generado a - partir de las cabeceras prestadas a la solicitud original, anteponiendo 'REDIRECT_' - en el nombre de la cabecera original. Esto proporciona el - documento de error en el mbito de la peticin original

- -

Por ejemplo, es posible que se reciba, adems de las variables de - entorno ms habituales, lo siguiente:

- -

- REDIRECT_HTTP_ACCEPT=*/*, image/gif, image/jpeg, image/png
- REDIRECT_HTTP_USER_AGENT=Mozilla/5.0 Fedora/3.5.8-1.fc12 Firefox/3.5.8
- REDIRECT_PATH=.:/bin:/usr/local/bin:/sbin
- REDIRECT_QUERY_STRING=
- REDIRECT_REMOTE_ADDR=121.345.78.123
- REDIRECT_REMOTE_HOST=client.example.com
- REDIRECT_SERVER_NAME=www.example.edu
- REDIRECT_SERVER_PORT=80
- REDIRECT_SERVER_SOFTWARE=Apache/2.2.15
- REDIRECT_URL=/cgi-bin/buggy.pl -

- -

Las variables de entorno de tipo REDIRECT_ se crean a partir - de las variables de entorno que existan antes de la redireccin. Se renombran - con prefijo REDIRECT_, por ejemplo:, - HTTP_USER_AGENT se convierte en - REDIRECT_HTTP_USER_AGENT.

- -

REDIRECT_URL, REDIRECT_STATUS, y - REDIRECT_QUERY_STRING estn garantizados para ser fijado, y - se establecern las otras cabeceras solo si existan antes de - la condicin de error.

- -

Ninguna de estas condiciones se establecer - si elobjetivo de ErrorDocument es una - redireccin external (nada a partir de un nombre de esquema - como http:, incluso si se refiere a la misma mquina que el servidor.

-
top
-
-

Personalizando Respuestas de Errores

- -

Si apunta su ErrorDocument a alguna variedad de controlador - dinmico como un documento que se incluye en el lado del servidor como CGI, - script u otro tipo de manejador, es posible que desee utilizar las variables - de entorno disponibles para personalizar esta respuesta.

- -

Si el ErrorDocument especifica una redireccin local a un script CGI, el - script debe incluir un campo de cabecera de tipo "Status:" en - su salida con el fin de asegurar la propagacin de - todo el camino de vuelta al cliente de la condicin de error que se gener. - Por ejemplo, un script de Perl ErrorDocument podra incluir lo siguiente:

- - 
...
-print  "Content-type: text/html\n"; 

-printf "Status: %s Condition Intercepted\n", $ENV{"REDIRECT_STATUS"}; 

-...
- - -

Si el script est dedicado al manejo de una condicin de error en particular, - como por ejemplo 404 Not Found, puede usar el propio - cdigo y el error de texto en su lugar.

- -

Tenga en cuenta que si la respuesta contiene Location: - header (con el fin de emitir una redireccin del lado del cliente), el - script deberemitir una cabecera apropiada con el Status: - (como 302 Found). De lo contrario la cabecera - Location: no tendr ningn efecto.

- -
top
-
-

Documentos de error personalizados - Multilengua

- -

Con la instalacin de Apache HTTP Server se proporciona un directorio - personal con diferentes mensajes de errores traducidos a 16 idiomas - diferentes. Tambin hay un archivo de configuracin el el directorio - conf/extra que puede ser incluido para aadir esta funcionalidad.

- -

En el archivo de configuracin del servidor, ver una lnea como:

- - 
    # Multi-language error messages

-    #Include conf/extra/httpd-multilang-errordoc.conf
- - -

Descomentando ste Include habilitar esta caracterstica, - y proporcionar mensajes de error de idioma-negociado, - basado en el idioma de preferencia establecido en el navegador del cliente.

- -

Adems, estos documentos contienen varias variables del tipo - REDIRECT_, con lo que se le puede aadir informacin adicional - de lo que ha ocurrido al usuario final, y que pueden hacer ahora.

- -

Estos documentos pueden ser personalizados de cualquier forma que desee - mostrar ms informacin al usuario a cerca del su sitio web, y que podrn encontrar en l.

- -

mod_include y mod_negotiation - Tienen que estar habilitados para usar estas caractersticas.

- -
-
-

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

-
top

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
-
- \ No newline at end of file diff --git a/docs/manual/custom-error.html.es.utf8 b/docs/manual/custom-error.html.es.utf8 new file mode 100644 index 0000000000..37ba32dbbb --- /dev/null +++ b/docs/manual/custom-error.html.es.utf8 @@ -0,0 +1,233 @@ + + + + + +Respuestas de Error Personalizadas - Servidor HTTP Apache Versin 2.5 + + + + + + +
+

Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

+

Versin 2.5 del Servidor HTTP Apache

+
+
<-
+

Respuestas de Error Personalizadas

+
+

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

+
+ + +

Aunque el Servidor Apache HTTP ofrece respuestas de error genricos en + el caso de los cdigos de estado 4xx o 5xx HTTP, stas respuestas son + bastante austeras, no informativas, y puede ser intimidante para los + usuarios del sitio. Si lo desea, para proporcionar respuestas de error + personalizados que son o bien ms amables, o en algn idioma que no sea + Ingls, o tal vez que son de un estilo ms acorde con su diseo del sitio.

+ +

Respuestas de error personalizadas se pueden definir para cualquier cdigo HTTP + designado como condicin de error - Esto es, cualquier estado 4xx 5xx.

+ +

Adems, se proporcionan un conjunto de valores, de manera que el + documento de error puede ser personalizado ms adelante, basado en + los valores de estas variables, usando Inclusiones del + Lado del Servidor (SSI). O bien, puede tener condiciones de error que maneje + un cgi, u otro controlador dinmico (PHP, mod_perl, etc), que + hace uso de estas variables.

+ +
+ +
top
+
+

Configuracin

+ +

Los documentos de error personalizados se configuran + mediante la directiva ErrorDocument, + que puede ser usado en el conjunto general, de los hosts virtuales o en directorios. + Tambin pueden ser usados en los ficheros .htaccess si + AllowOverrideesta configurado a + FileInfo.

+ + 
ErrorDocument 500 "Perdn, Nuestro escript ha fallado. Ay Madre!"

+ErrorDocument 500 /cgi-bin/crash-recover

+ErrorDocument 500 http://error.example.com/server_error.html

+ErrorDocument 404 /errors/not_found.html 

+ErrorDocument 401 /subscription/como_suscribirse.html
+ + +

La sintaxis de la directiva de ErrorDocument es:

+ + 
ErrorDocument <cdigo-de-3-dgitos> <accin>
+ + +

Donde la accin ser tratada como:

+ +
    +
  1. Una URL local a la que redireccionar (si la accin empieza con "/").
    2. +
  2. Una URL externa a la que redireccionar (si la accin es una URL vlida).
    3. +
  3. Texto para mostrar (si ninguna de las anteriores). El texto tiene que estar + entrecomillado ("ERROR") si consiste de mas de una palabra.
    4. +
+ +

Cuando se redirija a una URL local, se establecen variables de + entorno adicionales de manera que la respuesta puede ser personalizada. + stas variables no se envan a URLs externas

+ +
top
+
+

Variables Disponibles

+ +

Redireccionando a otra URL puede ser til, pero slo si algo de informacin + puede ser pasado como parmetro, lo cul puede ser usado para explicar de + forma ms clara el error o crear un log del mismo.

+ +

Para conseguir esto, cuando se enva el redireccionamiento de error, + se establecern variables de entorno adicionales, que ser generado a + partir de las cabeceras prestadas a la solicitud original, anteponiendo 'REDIRECT_' + en el nombre de la cabecera original. Esto proporciona el + documento de error en el mbito de la peticin original

+ +

Por ejemplo, es posible que se reciba, adems de las variables de + entorno ms habituales, lo siguiente:

+ +

+ REDIRECT_HTTP_ACCEPT=*/*, image/gif, image/jpeg, image/png
+ REDIRECT_HTTP_USER_AGENT=Mozilla/5.0 Fedora/3.5.8-1.fc12 Firefox/3.5.8
+ REDIRECT_PATH=.:/bin:/usr/local/bin:/sbin
+ REDIRECT_QUERY_STRING=
+ REDIRECT_REMOTE_ADDR=121.345.78.123
+ REDIRECT_REMOTE_HOST=client.example.com
+ REDIRECT_SERVER_NAME=www.example.edu
+ REDIRECT_SERVER_PORT=80
+ REDIRECT_SERVER_SOFTWARE=Apache/2.2.15
+ REDIRECT_URL=/cgi-bin/buggy.pl +

+ +

Las variables de entorno de tipo REDIRECT_ se crean a partir + de las variables de entorno que existan antes de la redireccin. Se renombran + con prefijo REDIRECT_, por ejemplo:, + HTTP_USER_AGENT se convierte en + REDIRECT_HTTP_USER_AGENT.

+ +

REDIRECT_URL, REDIRECT_STATUS, y + REDIRECT_QUERY_STRING estn garantizados para ser fijado, y + se establecern las otras cabeceras solo si existan antes de + la condicin de error.

+ +

Ninguna de estas condiciones se establecer + si elobjetivo de ErrorDocument es una + redireccin external (nada a partir de un nombre de esquema + como http:, incluso si se refiere a la misma mquina que el servidor.

+
top
+
+

Personalizando Respuestas de Errores

+ +

Si apunta su ErrorDocument a alguna variedad de controlador + dinmico como un documento que se incluye en el lado del servidor como CGI, + script u otro tipo de manejador, es posible que desee utilizar las variables + de entorno disponibles para personalizar esta respuesta.

+ +

Si el ErrorDocument especifica una redireccin local a un script CGI, el + script debe incluir un campo de cabecera de tipo "Status:" en + su salida con el fin de asegurar la propagacin de + todo el camino de vuelta al cliente de la condicin de error que se gener. + Por ejemplo, un script de Perl ErrorDocument podra incluir lo siguiente:

+ + 
...
+print  "Content-type: text/html\n"; 

+printf "Status: %s Condition Intercepted\n", $ENV{"REDIRECT_STATUS"}; 

+...
+ + +

Si el script est dedicado al manejo de una condicin de error en particular, + como por ejemplo 404 Not Found, puede usar el propio + cdigo y el error de texto en su lugar.

+ +

Tenga en cuenta que si la respuesta contiene Location: + header (con el fin de emitir una redireccin del lado del cliente), el + script deberemitir una cabecera apropiada con el Status: + (como 302 Found). De lo contrario la cabecera + Location: no tendr ningn efecto.

+ +
top
+
+

Documentos de error personalizados + Multilengua

+ +

Con la instalacin de Apache HTTP Server se proporciona un directorio + personal con diferentes mensajes de errores traducidos a 16 idiomas + diferentes. Tambin hay un archivo de configuracin el el directorio + conf/extra que puede ser incluido para aadir esta funcionalidad.

+ +

En el archivo de configuracin del servidor, ver una lnea como:

+ + 
    # Multi-language error messages

+    #Include conf/extra/httpd-multilang-errordoc.conf
+ + +

Descomentando ste Include habilitar esta caracterstica, + y proporcionar mensajes de error de idioma-negociado, + basado en el idioma de preferencia establecido en el navegador del cliente.

+ +

Adems, estos documentos contienen varias variables del tipo + REDIRECT_, con lo que se le puede aadir informacin adicional + de lo que ha ocurrido al usuario final, y que pueden hacer ahora.

+ +

Estos documentos pueden ser personalizados de cualquier forma que desee + mostrar ms informacin al usuario a cerca del su sitio web, y que podrn encontrar en l.

+ +

mod_include y mod_negotiation + Tienen que estar habilitados para usar estas caractersticas.

+ +
+
+

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

+
top

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/custom-error.html.fr b/docs/manual/custom-error.html.fr deleted file mode 100644 index 522385e3cd..0000000000 --- a/docs/manual/custom-error.html.fr +++ /dev/null @@ -1,250 +0,0 @@ - - - - - -Messages d'erreur personnalisés - Serveur HTTP Apache Version 2.5 - - - - - - -
-

Modules | Directives | FAQ | Glossaire | Plan du site

-

Serveur HTTP Apache Version 2.5

-
-
<-
-

Messages d'erreur personnalisés

-
-

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

-
- -

Le serveur HTTP Apache fournit des messages d'erreur génériques - pour les codes de statut 4xx ou 5xx ; ces messages sont cependant - relativement austères, imprécis, et peuvent s'avérer intimidants - pour les visiteurs du site. Si vous le souhaitez, vous pouvez - afficher des messages d'erreur plus conviviaux, dans un langage - autre que l'anglais, ou même sous une forme plus en adéquation avec - le style de votre site.

- -

Il est possible de définir des messages d'erreur personnalisés - pour chaque code de statut HTTP associé à une condition d'erreur - - c'est à dire tout code de statut 4xx ou 5xx.

- -

De plus, il est possible de - personnaliser le message d'erreur en fonction d'un jeu de valeurs - fourni, en utilisant les Inclusions Côté - Serveur (SSI). Un programme CGI ou un autre gestionnaire - dynamique (PHP, mod_perl, etc...) peut aussi utiliser ces variables - pour gérer les conditions d'erreur.

- - -
- -
top
-
-

Configuration

- -

Les messages d'erreur personnalisés sont configurés via la - directive ErrorDocument, qui - peut être utilisée dans un contexte global, serveur virtuel ou - répertoire. On peut utiliser cette directive dans les fichiers - .htaccess si AllowOverride est - définie à FileInfo.

- - 
ErrorDocument 500 "Désolé, notre script s'est
-crashé ; comme c'est dommage !"
-ErrorDocument 500 /cgi-bin/crash-recover
-ErrorDocument 500 http://error.example.com/server_error.html
-ErrorDocument 404 /errors/not_found.html 
-ErrorDocument 401 /subscription/how_to_subscribe.html
- - -

La syntaxe de la directive ErrorDocument est :

- 
ErrorDocument <code_3_chiffres> <action>
- -

où action peut être traitée comme :

-
    -
  1. Une URL de redirection local (si l'action commence par un "/").
    2. -
  2. Une URL de redirection externe (si action est une URL valide).
    3. -
  3. Le texte à afficher (si l'action ne répond à aucune des - deux conditions précédentes). Entourez le texte de guillemets (") - s'il contient plusieurs mots.
    4. -
- -

Dans le cas d'une redirection vers une URL locale, des variables - d'environnement supplémentaires sont définies de façon à ce que la - réponse puisse être personnalisée par la suite. Elles ne sont pas - envoyées aux URLs externes.

- -
top
-
-

Variables disponibles

- -

La redirection vers une autre URL peut être utile, mais - seulement s'il est possible de transmettre certaines informations - qui pourront être utilisées pour expliquer ou journaliser - la condition d'erreur ou le problème plus clairement.

- -

Pour y parvenir, lorsque la redirection d'erreur est envoyée, - des variables d'environnement supplémentaires sont définies à - partir des en-têtes de la requête originale en préfixant le nom - d'origine de l'en-tête par 'REDIRECT_', ce qui permet de fournir au - message d'erreur le contexte de la requête originelle.

- -

Par exemple, en plus des variables d'environnement habituelles, - vous pouvez recevoir ce qui suit :

- - -

- REDIRECT_HTTP_ACCEPT=*/*, image/gif, image/jpeg, image/png
- REDIRECT_HTTP_USER_AGENT=Mozilla/5.0 Fedora/3.5.8-1.fc12 Firefox/3.5.8
- REDIRECT_PATH=.:/bin:/usr/local/bin:/sbin
- REDIRECT_QUERY_STRING=
- REDIRECT_REMOTE_ADDR=121.345.78.123
- REDIRECT_REMOTE_HOST=client.example.com
- REDIRECT_SERVER_NAME=www.example.edu
- REDIRECT_SERVER_PORT=80
- REDIRECT_SERVER_SOFTWARE=Apache/2.2.15
- REDIRECT_URL=/cgi-bin/buggy.pl -

- -

Les variables d'environnement REDIRECT_ sont - créées à partir des variables d'environnement préexistantes à la - redirection qui sont préfixées par la chaîne REDIRECT_ ; - par exemple, HTTP_USER_AGENT devient - REDIRECT_HTTP_USER_AGENT.

- -

REDIRECT_URL, REDIRECT_STATUS, et - REDIRECT_QUERY_STRING sont systématiquement définies, - les autres variables n'étant définies que si l'en-tête - correspondant existait avant la condition d'erreur.

- -

Aucune d'entre elles ne sera définie si votre - directive ErrorDocument - spécifie une redirection externe (toute URL commençant - par un protocole du style http:, même si elle fait - référence au même hôte que le serveur).

- -
top
-
-

Personnalisation des messages d'erreur

- - -

Si vous faites pointer votre directive - ErrorDocument vers certains gestionnaires - dynamiques comme les inclusions côté serveur, les scripts CGI ou - d'autres gestionnaires, vous pouvez utiliser les variables - d'environnement supplémentaires disponibles pour personnaliser - le message.

- - -

Si la directive ErrorDname-basedocument spécifie une redirection locale - vers un script CGI, ce dernier doit ajouter un en-tête - "Status:" dans sa sortie afin de s'assurer du bon - acheminement jusqu'au client de la condition d'erreur qui a - provoqué cette redirection. Par exemple, un script Perl spécifié - par une directive ErrorDocument pourrait contenir ce qui suit - :

- - 
...
-print  "Content-type: text/html\n"; 
-printf "Status: %s Condition Intercepted\n", $ENV{"REDIRECT_STATUS"}; 
-...
- - -

Si un script est dédié à la gestion d'une condition d'erreur - spécifique, telle que 404 Not Found, il - peut utiliser le code et le texte de l'erreur spécifiques à la - place.

- -

Notez que si la réponse contient un en-tête - Location: (afin d'initier une redirection côté - client), le script doit émettre un en-tête approprié - (comme 302 Found). Dans le cas contraire, - l'en-tête Location: ne produira aucun effet.

-
top
-
-

Messages d'erreur personnalisés - multilingues

- -

Vous trouverez dans la distribution du serveur HTTP Apache un - répertoire contenant des messages d'erreur personnalisés traduits en - 16 langues différentes. Pour activer cette fonctionnalité, vous - pouvez aussi inclure un fichier de configuration qui se trouve dans - le répertoire de configuration conf/extra.

- -

Dans le fichier de configuration de votre serveur, vous trouverez - un groupe de lignes du style :

- - 
    # Multi-language error messages
-    #Include conf/extra/httpd-multilang-errordoc.conf
- - -

Décommentez la ligne Include pour activer cette - fonctionnalité, et présenter des messages d'erreur dont le langage - sera négocié en fonction du langage préféré défini au niveau du - navigateur du client.

- -

De plus, ces documents contiennent diverses variables - REDIRECT_, de façon à ce que l'utilisateur final - dispose d'informations supplémentaires à propos de ce qui a pu se - produire, et de ce qu'il est susceptible de faire maintenant.

- -

Ces documents peuvent être personnalisés en fournissant autant - d'informations utiles que vous le souhaitez aux utilisateurs à - propos de votre site, et de ce qu'ils sont susceptibles d'y trouver.

- -

Pour pouvoir utiliser cette fonctionnalité, vous devez activer - mod_include et mod_negotiation.

- -
-
-

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

-
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
-
- \ No newline at end of file diff --git a/docs/manual/custom-error.html.fr.utf8 b/docs/manual/custom-error.html.fr.utf8 new file mode 100644 index 0000000000..522385e3cd --- /dev/null +++ b/docs/manual/custom-error.html.fr.utf8 @@ -0,0 +1,250 @@ + + + + + +Messages d'erreur personnalisés - Serveur HTTP Apache Version 2.5 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.5

+
+
<-
+

Messages d'erreur personnalisés

+
+

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

+
+ +

Le serveur HTTP Apache fournit des messages d'erreur génériques + pour les codes de statut 4xx ou 5xx ; ces messages sont cependant + relativement austères, imprécis, et peuvent s'avérer intimidants + pour les visiteurs du site. Si vous le souhaitez, vous pouvez + afficher des messages d'erreur plus conviviaux, dans un langage + autre que l'anglais, ou même sous une forme plus en adéquation avec + le style de votre site.

+ +

Il est possible de définir des messages d'erreur personnalisés + pour chaque code de statut HTTP associé à une condition d'erreur - + c'est à dire tout code de statut 4xx ou 5xx.

+ +

De plus, il est possible de + personnaliser le message d'erreur en fonction d'un jeu de valeurs + fourni, en utilisant les Inclusions Côté + Serveur (SSI). Un programme CGI ou un autre gestionnaire + dynamique (PHP, mod_perl, etc...) peut aussi utiliser ces variables + pour gérer les conditions d'erreur.

+ + +
+ +
top
+
+

Configuration

+ +

Les messages d'erreur personnalisés sont configurés via la + directive ErrorDocument, qui + peut être utilisée dans un contexte global, serveur virtuel ou + répertoire. On peut utiliser cette directive dans les fichiers + .htaccess si AllowOverride est + définie à FileInfo.

+ + 
ErrorDocument 500 "Désolé, notre script s'est
+crashé ; comme c'est dommage !"
+ErrorDocument 500 /cgi-bin/crash-recover
+ErrorDocument 500 http://error.example.com/server_error.html
+ErrorDocument 404 /errors/not_found.html 
+ErrorDocument 401 /subscription/how_to_subscribe.html
+ + +

La syntaxe de la directive ErrorDocument est :

+ 
ErrorDocument <code_3_chiffres> <action>
+ +

où action peut être traitée comme :

+
    +
  1. Une URL de redirection local (si l'action commence par un "/").
    2. +
  2. Une URL de redirection externe (si action est une URL valide).
    3. +
  3. Le texte à afficher (si l'action ne répond à aucune des + deux conditions précédentes). Entourez le texte de guillemets (") + s'il contient plusieurs mots.
    4. +
+ +

Dans le cas d'une redirection vers une URL locale, des variables + d'environnement supplémentaires sont définies de façon à ce que la + réponse puisse être personnalisée par la suite. Elles ne sont pas + envoyées aux URLs externes.

+ +
top
+
+

Variables disponibles

+ +

La redirection vers une autre URL peut être utile, mais + seulement s'il est possible de transmettre certaines informations + qui pourront être utilisées pour expliquer ou journaliser + la condition d'erreur ou le problème plus clairement.

+ +

Pour y parvenir, lorsque la redirection d'erreur est envoyée, + des variables d'environnement supplémentaires sont définies à + partir des en-têtes de la requête originale en préfixant le nom + d'origine de l'en-tête par 'REDIRECT_', ce qui permet de fournir au + message d'erreur le contexte de la requête originelle.

+ +

Par exemple, en plus des variables d'environnement habituelles, + vous pouvez recevoir ce qui suit :

+ + +

+ REDIRECT_HTTP_ACCEPT=*/*, image/gif, image/jpeg, image/png
+ REDIRECT_HTTP_USER_AGENT=Mozilla/5.0 Fedora/3.5.8-1.fc12 Firefox/3.5.8
+ REDIRECT_PATH=.:/bin:/usr/local/bin:/sbin
+ REDIRECT_QUERY_STRING=
+ REDIRECT_REMOTE_ADDR=121.345.78.123
+ REDIRECT_REMOTE_HOST=client.example.com
+ REDIRECT_SERVER_NAME=www.example.edu
+ REDIRECT_SERVER_PORT=80
+ REDIRECT_SERVER_SOFTWARE=Apache/2.2.15
+ REDIRECT_URL=/cgi-bin/buggy.pl +

+ +

Les variables d'environnement REDIRECT_ sont + créées à partir des variables d'environnement préexistantes à la + redirection qui sont préfixées par la chaîne REDIRECT_ ; + par exemple, HTTP_USER_AGENT devient + REDIRECT_HTTP_USER_AGENT.

+ +

REDIRECT_URL, REDIRECT_STATUS, et + REDIRECT_QUERY_STRING sont systématiquement définies, + les autres variables n'étant définies que si l'en-tête + correspondant existait avant la condition d'erreur.

+ +

Aucune d'entre elles ne sera définie si votre + directive ErrorDocument + spécifie une redirection externe (toute URL commençant + par un protocole du style http:, même si elle fait + référence au même hôte que le serveur).

+ +
top
+
+

Personnalisation des messages d'erreur

+ + +

Si vous faites pointer votre directive + ErrorDocument vers certains gestionnaires + dynamiques comme les inclusions côté serveur, les scripts CGI ou + d'autres gestionnaires, vous pouvez utiliser les variables + d'environnement supplémentaires disponibles pour personnaliser + le message.

+ + +

Si la directive ErrorDname-basedocument spécifie une redirection locale + vers un script CGI, ce dernier doit ajouter un en-tête + "Status:" dans sa sortie afin de s'assurer du bon + acheminement jusqu'au client de la condition d'erreur qui a + provoqué cette redirection. Par exemple, un script Perl spécifié + par une directive ErrorDocument pourrait contenir ce qui suit + :

+ + 
...
+print  "Content-type: text/html\n"; 
+printf "Status: %s Condition Intercepted\n", $ENV{"REDIRECT_STATUS"}; 
+...
+ + +

Si un script est dédié à la gestion d'une condition d'erreur + spécifique, telle que 404 Not Found, il + peut utiliser le code et le texte de l'erreur spécifiques à la + place.

+ +

Notez que si la réponse contient un en-tête + Location: (afin d'initier une redirection côté + client), le script doit émettre un en-tête approprié + (comme 302 Found). Dans le cas contraire, + l'en-tête Location: ne produira aucun effet.

+
top
+
+

Messages d'erreur personnalisés + multilingues

+ +

Vous trouverez dans la distribution du serveur HTTP Apache un + répertoire contenant des messages d'erreur personnalisés traduits en + 16 langues différentes. Pour activer cette fonctionnalité, vous + pouvez aussi inclure un fichier de configuration qui se trouve dans + le répertoire de configuration conf/extra.

+ +

Dans le fichier de configuration de votre serveur, vous trouverez + un groupe de lignes du style :

+ + 
    # Multi-language error messages
+    #Include conf/extra/httpd-multilang-errordoc.conf
+ + +

Décommentez la ligne Include pour activer cette + fonctionnalité, et présenter des messages d'erreur dont le langage + sera négocié en fonction du langage préféré défini au niveau du + navigateur du client.

+ +

De plus, ces documents contiennent diverses variables + REDIRECT_, de façon à ce que l'utilisateur final + dispose d'informations supplémentaires à propos de ce qui a pu se + produire, et de ce qu'il est susceptible de faire maintenant.

+ +

Ces documents peuvent être personnalisés en fournissant autant + d'informations utiles que vous le souhaitez aux utilisateurs à + propos de votre site, et de ce qu'ils sont susceptibles d'y trouver.

+ +

Pour pouvoir utiliser cette fonctionnalité, vous devez activer + mod_include et mod_negotiation.

+ +
+
+

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

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/dns-caveats.html.en b/docs/manual/dns-caveats.html.en index 298c345709..1b5c602299 100644 --- a/docs/manual/dns-caveats.html.en +++ b/docs/manual/dns-caveats.html.en @@ -24,10 +24,10 @@ Apache > HTTP Server > Documentation > Version 2.5

Issues Regarding DNS and Apache HTTP Server

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

+ tr 

This page could be summarized with the statement: don't @@ -186,10 +186,10 @@

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

+ tr 

top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
- - -
-

Modules | Directives | FAQ | Glossaire | Plan du site

-

Serveur HTTP Apache Version 2.5

-
-
<-
-

Problèmes liés au DNS avec le serveur HTTP Apache

-
-

Langues Disponibles:  en  | - fr  | - ja  | - ko  | - tr 

-
- -

Cette page pourrait se résumer ainsi : configurez le - serveur HTTP Apache de façon - à ce qu'il n'ait pas besoin de résolution DNS pour interpréter les - fichiers de configuration. Si httpd doit effectuer des résolutions - DNS pour interpréter les fichiers de configuration, votre serveur - pourra présenter des problèmes de fiabilité (en d'autres termes, - il est possible qu'il refuse de démarrer), ou d'attaques par déni ou - usurpation de service (y compris l'attribution de requêtes à un - serveur virtuel autre que le serveur virtuel voulu).

-
- -
top
-
-

Un exemple simple

- - - 
# Ceci est un exemple de mauvaise configuration ; ne l'utilisez pas comme base
-# de configuration
-<VirtualHost www.example.dom>
-  ServerAdmin webgirl@example.dom
-  DocumentRoot "/www/example"
-</VirtualHost>
- - -

Pour fonctionner correctement, le serveur a absolument besoin de deux - informations à propos de chaque serveur virtuel : le nom du serveur - défini par la directive ServerName, et au moins une adresse IP à - laquelle le serveur va se rattacher et répondre. L'exemple ci-dessus - ne comporte pas d'adresse IP, si bien que httpd devra utiliser le - DNS pour trouver l'adresse IP de www.example.dom. Si pour - une raison quelconque, le DNS n'est pas disponible au moment où - votre serveur interprète son fichier de configuration, ce serveur - virtuel ne sera pas pris en compte dans la - configuration. Il sera incapable de - répondre à toute requête pour ce serveur virtuel.

- -

Supposons que l'adresse de www.example.dom soit - 192.0.2.1, et examinons cet extrait de configuration :

- - 
# Ceci est un exemple de mauvaise configuration ; ne l'utilisez pas comme base
-# de configuration
-<VirtualHost 192.0.2.1>
-  ServerAdmin webgirl@example.dom
-  DocumentRoot "/www/example"
-</VirtualHost>
- - -

Cette fois, httpd doit effectuer une recherche DNS inverse pour - trouver le nom ServerName de ce serveur virtuel. Si - cette recherche inverse échoue, le serveur virtuel sera - partiellement désactivé. Si le serveur - virtuel est à base de nom, il sera en fait totalement désactivé, - mais s'il est à base d'adresse IP, il fonctionnera probablement. - Cependant, httpd échouera s'il doit générer une URL complète pour - le serveur qui inclut ce nom de serveur (comme dans le cas d'une - redirection).

- -

Voici un extrait de configuration qui permet d'éviter ces deux - types de problèmes :

- - 
<VirtualHost 192.0.2.1>
-  ServerName www.example.dom
-  ServerAdmin webgirl@example.dom
-  DocumentRoot "/www/example"
-</VirtualHost>
- -
top
-
-

Déni de service

- - -

Considérons cet extrait de configuration :

- - 
<VirtualHost www.example1.dom>
-  ServerAdmin webgirl@example1.dom
-  DocumentRoot "/www/example1"
-</VirtualHost>
-<VirtualHost www.example2.dom>
-  ServerAdmin webguy@example2.dom
-  DocumentRoot "/www/example2"
-</VirtualHost>
- - -

Supposons que vous ayez assigné 192.0.2.1 à - www.example1.dom et 192.0.2.2 à www.example2.dom. En - outre, supposons que example1.dom gère son propre DNS. Avec - cette configuration, example1.dom sera en mesure de - détourner tout trafic destiné à example2.dom. Pour y - parvenir, tout ce qu'ils ont à faire consiste à - assigner 192.0.2.2 à - www.example1.dom. Comme ils gèrent leur propre DNS, vous ne - pouvez pas les empêcher de faire pointer l'enregistrement - www.example1.dom vers l'adresse qu'ils veulent.

- -

Les requêtes à destination de 192.0.2.2 (y compris toutes celles - où l'utilisateur à tapé une URL de la forme - http://www.example2.dom/quelquepart), seront toutes servies - par le serveur virtuel example1.dom. Une meilleur - compréhension de la raison pour laquelle ceci peut se produire - nécessite une discussion plus approfondie à propos de la manière - dont httpd associe les requêtes entrantes aux différents serveurs - virtuels qui vont les servir. Un document de base décrivant ceci est disponible.

-
top
-
-

L'adresse du "serveur principal"

- - -

Le support des - serveurs virtuels à base de nom oblige httpd à - connaître la/les adresse(s) IP de l'hôte sur - lequel httpd s'exécute. Pour obtenir cette - adresse, soit il utilise la directive ServerName globale (si elle est présente), - soit il fait appel à la fonction C gethostname (qui - doit renvoyer le même nom que la commande shell "hostname"). Il - effectue ensuite une recherche DNS sur cette adresse. Pour le - moment, il n'existe aucun moyen d'éviter cette recherche DNS.

- -

Si vous craignez que cette recherche DNS échoue parce que votre - serveur DNS est arrêté, vous pouvez insérer le nom d'hôte dans le - fichier /etc/hosts (où il est probablement déjà - enregistré afin que la machine démarre correctement). Assurez-vous - ensuite que la machine est configurée pour utiliser - /etc/hosts dans le cas où la recherche DNS échoue. - Suivant le système d'exploitation que vous utilisez, vous y - parviendrez en éditant /etc/resolv.conf, ou - /etc/nsswitch.conf.

- -

Si votre serveur n'a aucune autre raison d'effectuer des - recherches DNS, vous pouvez définir la variable d'environnement - HOSTRESORDER à "local", et vous serez alors en mesure - d'exécuter httpd. Tout dépend du système d'exploitation et des - bibliothèques de résolution de noms que vous utilisez. Elle affecte - aussi les programmes CGI, à moins que vous n'utilisiez - mod_env pour contrôler l'environnement. Il est - conseillé de consulter les pages de manuel ou les FAQs de votre - système d'exploitation.

-
top
-
-

Conseils pour éviter ce genre de problème

- - -
    -
  • - utilisez des adresses IP au sein des VirtualHost -
    • - -
  • - utilisez des adresses IP avec la directive Listen -
    • - -
  • - vérifiez que tous les serveurs virtuels possèdent un nom - ServerName explicite -
    • - -
  • créez un serveur virtuel <VirtualHost - _default_:*> qui n'a aucune page à servir
    • -
-
-
-

Langues Disponibles:  en  | - fr  | - ja  | - ko  | - tr 

-
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
-
- \ No newline at end of file diff --git a/docs/manual/dns-caveats.html.fr.utf8 b/docs/manual/dns-caveats.html.fr.utf8 new file mode 100644 index 0000000000..6a85d8afd5 --- /dev/null +++ b/docs/manual/dns-caveats.html.fr.utf8 @@ -0,0 +1,226 @@ + + + + + +Problèmes liés au DNS avec le serveur HTTP Apache - Serveur HTTP Apache Version 2.5 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.5

+
+
<-
+

Problèmes liés au DNS avec le serveur HTTP Apache

+
+

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

+
+ +

Cette page pourrait se résumer ainsi : configurez le + serveur HTTP Apache de façon + à ce qu'il n'ait pas besoin de résolution DNS pour interpréter les + fichiers de configuration. Si httpd doit effectuer des résolutions + DNS pour interpréter les fichiers de configuration, votre serveur + pourra présenter des problèmes de fiabilité (en d'autres termes, + il est possible qu'il refuse de démarrer), ou d'attaques par déni ou + usurpation de service (y compris l'attribution de requêtes à un + serveur virtuel autre que le serveur virtuel voulu).

+
+ +
top
+
+

Un exemple simple

+ + + 
# Ceci est un exemple de mauvaise configuration ; ne l'utilisez pas comme base
+# de configuration
+<VirtualHost www.example.dom>
+  ServerAdmin webgirl@example.dom
+  DocumentRoot "/www/example"
+</VirtualHost>
+ + +

Pour fonctionner correctement, le serveur a absolument besoin de deux + informations à propos de chaque serveur virtuel : le nom du serveur + défini par la directive ServerName, et au moins une adresse IP à + laquelle le serveur va se rattacher et répondre. L'exemple ci-dessus + ne comporte pas d'adresse IP, si bien que httpd devra utiliser le + DNS pour trouver l'adresse IP de www.example.dom. Si pour + une raison quelconque, le DNS n'est pas disponible au moment où + votre serveur interprète son fichier de configuration, ce serveur + virtuel ne sera pas pris en compte dans la + configuration. Il sera incapable de + répondre à toute requête pour ce serveur virtuel.

+ +

Supposons que l'adresse de www.example.dom soit + 192.0.2.1, et examinons cet extrait de configuration :

+ + 
# Ceci est un exemple de mauvaise configuration ; ne l'utilisez pas comme base
+# de configuration
+<VirtualHost 192.0.2.1>
+  ServerAdmin webgirl@example.dom
+  DocumentRoot "/www/example"
+</VirtualHost>
+ + +

Cette fois, httpd doit effectuer une recherche DNS inverse pour + trouver le nom ServerName de ce serveur virtuel. Si + cette recherche inverse échoue, le serveur virtuel sera + partiellement désactivé. Si le serveur + virtuel est à base de nom, il sera en fait totalement désactivé, + mais s'il est à base d'adresse IP, il fonctionnera probablement. + Cependant, httpd échouera s'il doit générer une URL complète pour + le serveur qui inclut ce nom de serveur (comme dans le cas d'une + redirection).

+ +

Voici un extrait de configuration qui permet d'éviter ces deux + types de problèmes :

+ + 
<VirtualHost 192.0.2.1>
+  ServerName www.example.dom
+  ServerAdmin webgirl@example.dom
+  DocumentRoot "/www/example"
+</VirtualHost>
+ +
top
+
+

Déni de service

+ + +

Considérons cet extrait de configuration :

+ + 
<VirtualHost www.example1.dom>
+  ServerAdmin webgirl@example1.dom
+  DocumentRoot "/www/example1"
+</VirtualHost>
+<VirtualHost www.example2.dom>
+  ServerAdmin webguy@example2.dom
+  DocumentRoot "/www/example2"
+</VirtualHost>
+ + +

Supposons que vous ayez assigné 192.0.2.1 à + www.example1.dom et 192.0.2.2 à www.example2.dom. En + outre, supposons que example1.dom gère son propre DNS. Avec + cette configuration, example1.dom sera en mesure de + détourner tout trafic destiné à example2.dom. Pour y + parvenir, tout ce qu'ils ont à faire consiste à + assigner 192.0.2.2 à + www.example1.dom. Comme ils gèrent leur propre DNS, vous ne + pouvez pas les empêcher de faire pointer l'enregistrement + www.example1.dom vers l'adresse qu'ils veulent.

+ +

Les requêtes à destination de 192.0.2.2 (y compris toutes celles + où l'utilisateur à tapé une URL de la forme + http://www.example2.dom/quelquepart), seront toutes servies + par le serveur virtuel example1.dom. Une meilleur + compréhension de la raison pour laquelle ceci peut se produire + nécessite une discussion plus approfondie à propos de la manière + dont httpd associe les requêtes entrantes aux différents serveurs + virtuels qui vont les servir. Un document de base décrivant ceci est disponible.

+
top
+
+

L'adresse du "serveur principal"

+ + +

Le support des + serveurs virtuels à base de nom oblige httpd à + connaître la/les adresse(s) IP de l'hôte sur + lequel httpd s'exécute. Pour obtenir cette + adresse, soit il utilise la directive ServerName globale (si elle est présente), + soit il fait appel à la fonction C gethostname (qui + doit renvoyer le même nom que la commande shell "hostname"). Il + effectue ensuite une recherche DNS sur cette adresse. Pour le + moment, il n'existe aucun moyen d'éviter cette recherche DNS.

+ +

Si vous craignez que cette recherche DNS échoue parce que votre + serveur DNS est arrêté, vous pouvez insérer le nom d'hôte dans le + fichier /etc/hosts (où il est probablement déjà + enregistré afin que la machine démarre correctement). Assurez-vous + ensuite que la machine est configurée pour utiliser + /etc/hosts dans le cas où la recherche DNS échoue. + Suivant le système d'exploitation que vous utilisez, vous y + parviendrez en éditant /etc/resolv.conf, ou + /etc/nsswitch.conf.

+ +

Si votre serveur n'a aucune autre raison d'effectuer des + recherches DNS, vous pouvez définir la variable d'environnement + HOSTRESORDER à "local", et vous serez alors en mesure + d'exécuter httpd. Tout dépend du système d'exploitation et des + bibliothèques de résolution de noms que vous utilisez. Elle affecte + aussi les programmes CGI, à moins que vous n'utilisiez + mod_env pour contrôler l'environnement. Il est + conseillé de consulter les pages de manuel ou les FAQs de votre + système d'exploitation.

+
top
+
+

Conseils pour éviter ce genre de problème

+ + +
    +
  • + utilisez des adresses IP au sein des VirtualHost +
    • + +
  • + utilisez des adresses IP avec la directive Listen +
    • + +
  • + vérifiez que tous les serveurs virtuels possèdent un nom + ServerName explicite +
    • + +
  • créez un serveur virtuel <VirtualHost + _default_:*> qui n'a aucune page à servir
    • +
+
+
+

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

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/dso.html.en b/docs/manual/dso.html.en index 61c24cf42c..3769f4ee91 100644 --- a/docs/manual/dso.html.en +++ b/docs/manual/dso.html.en @@ -24,10 +24,10 @@ Apache > HTTP Server > Documentation > Version 2.5

Dynamic Shared Object (DSO) Support

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

+ tr 

The Apache HTTP Server is a modular program where the @@ -301,10 +301,10 @@ $ apxs -cia mod_foo.c

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

+ tr 

top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
- - -
-

Modules | Directives | FAQ | Glossaire | Plan du site

-

Serveur HTTP Apache Version 2.5

-
-
<-
-

Support des objets dynamiques partagés (DSO)

-
-

Langues Disponibles:  en  | - fr  | - ja  | - ko  | - tr 

-
- -

La conception modulaire du serveur HTTP Apache permet à l'administrateur - de choisir les fonctionnalités à inclure dans le serveur en sélectionnant - un certain nombre de modules. Les modules seront compilés en tant - qu'Objets Dynamiques Partagés (Dynamic Shared Objects ou DSOs) - qui mènent une existence séparée du fichier binaire principal - httpd. Les modules DSO peuvent être compilés en - même temps que le serveur, ou compilés et ajoutés ultérieurement via - l'Outil des Extensions à Apache (Apache Extension Tool ou - apxs).

-

Les modules peuvent aussi être intégrés statiquement dans le - binaire httpd lors de la compilation de ce - dernier.

- -

Ce document décrit l'utilisation des modules DSO ainsi que les dessous - de leur fonctionnement.

-
- -
top
-
-

Implémentation

- -
Modules ApparentésDirectives Apparentées
- -

Le support DSO pour le chargement de modules individuels d'Apache - httpd est - assuré par un module nommé mod_so qui doit être compilé - statiquement dans le coeur d'Apache httpd. Il s'agit du seul module avec le - module core à ne pas pouvoir être compilé en tant que - module DSO lui-même. Pratiquement tous les autres modules d'Apache httpd - distribués seront alors compilés en tant que modules DSO. Une fois - compilé en tant que module DSO nommé mod_foo.so, un - module peut être chargé en mémoire au - démarrage ou redémarrage du serveur à l'aide de - la directive LoadModule du module - mod_so, placée - dans votre fichier httpd.conf.

-

La compilation en mode DSO peut être désactivée pour certains - modules via l'option --enable-mods-static du script - configure, comme expliqué dans la Documentation sur l'installation.

- -

Un utilitaire permet de simplifier la création de - fichiers DSO pour les modules d'Apache httpd - (particulièrement pour les modules tiers) ; il s'agit du programme nommé - apxs (APache - eXtenSion). On peut l'utiliser pour construire des modules de type - DSO en dehors de l'arborescence des sources d'Apache httpd. L'idée est - simple : à l'installation du serveur HTTP Apache, la procédure make install - du script configure installe les fichiers d'en-têtes - d'Apache httpd et positionne, pour la plateforme de compilation, les drapeaux du compilateur et de - l'éditeur de liens à l'intérieur du programme - apxs, qui sera utilisé pour la construction de fichiers DSO. - Il est ainsi possible d'utiliser le programme apxs - pour compiler ses sources de modules Apache httpd sans avoir besoin de - l'arborescence des sources de la distribution d'Apache, et sans avoir à - régler les drapeaux du compilateur et de l'éditeur de liens pour le support DSO.

-
top
-
-

Mode d'emploi succinct

- -

Afin que vous puissiez vous faire une idée des fonctionnalités DSO - du serveur HTTP Apache 2.x, en voici un résumé court et concis :

- -
    -
  1. -

    Construire et installer un module Apache httpd faisant partie de la - distribution, par exemple mod_foo.c, - en tant que module DSO mod_foo.so :

    - -

    -$ ./configure --prefix=/chemin/vers/installation --enable-foo
    -$ make install -

    -
    2. - -
  2. -

    Configure le serveur HTTP Apache avec tous les modules - activés. Seul un jeu de modules de base sera chargé au - démarrage du serveur. Vous pouvez modifier ce jeu de modules - chargés au démarrage en activant ou désactivant les directives LoadModule correspondantes dans le - fichier httpd.conf.

    - -

    -$ ./configure --enable-mods-shared=all
    -$ make install -

    - -

    L'argument most de l'option - --enable-modules indique que tous les modules - non-expérimentaux ou qui ne sont pas là à titre d'exemple seront - compilés.

    -
    3. - -
  3. -

    Certains modules ne sont utilisés que par les développeurs et - ne seront pas compilés. Si vous voulez les utiliser, spécifiez - l'option all. Pour compiler tous les modules disponibles, - y compris les modules de développeurs, spécifiez l'option - reallyall. En outre, la directive LoadModule peut être activée pour tous - les modules compilés via l'option du script configure - --enable-load-all-modules.

    - -

    -$ ./configure --enable-mods-shared=reallyall --enable-load-all-modules
    -$ make install -

    -
    4. - -
  4. - Construire et installer un module Apache httpd tiers, par exemple - mod_foo.c, en tant que module DSO - mod_foo.so en dehors de l'arborescence des sources - d'Apache httpd à l'aide du programme apxs : - -

    -$ cd /chemin/vers/module_tiers
    -$ apxs -cia mod_foo.c -

    -
    5. -
- -

Dans tous les cas, une fois le module partagé compilé, vous devez - ajouter une directive LoadModule - dans le fichier httpd.conf pour qu'Apache httpd active le module.

- -

Voir la documentation sur apxs - pour plus de détails.

-
top
-
-

Les dessous du fonctionnement des DSO

- -

Les clônes modernes d'UNIX proposent un mécanisme - appelé édition de liens et chargement dynamiques d' - Objets Dynamiques Partagés (DSO), qui permet de construire un - morceau de programme dans un format spécial pour le rendre chargeable - à l'exécution dans l'espace d'adressage d'un programme exécutable.

- -

Ce chargement peut s'effectuer de deux manières : automatiquement par - un programme système appelé ld.so quand un programme - exécutable est démarré, ou manuellement à partir du programme en cours - d'exécution via sa propre interface système vers le chargeur Unix à l'aide - des appels système dlopen()/dlsym().

- -

Dans la première méthode, les DSO sont en général appelés - bibliothèques partagées ou encore bibliothèques DSO, et - possèdent des noms du style - libfoo.so ou libfoo.so.1.2. Ils résident dans un - répertoire système (en général /usr/lib) - et le lien avec le programme exécutable est établi à la compilation en - ajoutant -lfoo à la commande de l'éditeur de liens. Les - références à la bibliothèque sont ainsi codées en dur dans le fichier du - programme exécutable de façon à ce qu'au démarrage du programme, le - chargeur Unix soit capable de localiser libfoo.so dans - /usr/lib, dans des chemins codés en dur à l'aide d'options de - l'éditeur de liens comme -R ou dans des chemins définis par la - variable d'environnement - LD_LIBRARY_PATH. Le chargeur peut dès lors résoudre tous les symboles - (jusque là non encore résolus) du DSO dans le programme exécutable.

- -

Les symboles du programme exécutable ne sont en général pas - référencés par le DSO (car c'est une bibliothèque de code à usage général - et réutilisable), - et ainsi aucune résolution supplémentaire n'est nécessaire. De son côté, - le programme exécutable ne doit accomplir aucune action particulière - pour utiliser les - symboles du DSO car toutes les résolutions sont effectuées par le chargeur - Unix. En fait, le code permettant d'invoquer - ld.so fait partie du code de démarrage pour l'exécution qui - est lié dans tout programme exécutable non statiquement lié. - L'avantage du chargement dynamique du code d'une bibliothèque partagée est - évident : le code de la bibliothèque ne doit être stocké qu'une seule fois - dans une bibliothèque système telle que libc.so, ce qui permet - d'économiser de l'espace disque pour les autres programmes.

- -

Dans la seconde méthode, les DSO sont en général appelés objets - partagés ou fichiers DSO, et peuvent être nommés avec - l'extension de son choix (bien que le nom conseillé soit du style - foo.so). Ces fichiers résident en général dans un répertoire - spécifique à un programme, et aucun lien n'est automatiquement établi avec - le programme exécutable dans lequel ils sont utilisés. - Le programme exécutable charge manuellement le DSO à l'exécution dans son - espace d'adressage à l'aide de l'appel système dlopen(). - A ce moment, aucune résolution de symboles du DSO n'est effectuée pour le - programme exécutable. Par contre le chargeur Unix - résoud automatiquement tout symbole du DSO (non encore résolu) - faisant partie de l'ensemble de symboles exporté par le programme - exécutable et ses bibliothèques DSO déjà chargées (et en particulier tous - les symboles de la bibliothèque à tout faire libc.so). - De cette façon, le DSO prend connaissance de l'ensemble de symboles du - programme exécutable comme s'il avait été lié statiquement avec lui - auparavant.

- -

Finalement, pour tirer profit de l'API des DSO, le programme exécutable - doit résoudre certains symboles du DSO à l'aide de l'appel système - dlsym() pour une utilisation ultérieure dans les tables de - distribution, etc... En d'autres termes, le programme exécutable doit - résoudre manuellement tous les symboles dont il a besoin pour pouvoir les - utiliser. - Avantage d'un tel mécanisme : les modules optionnels du programme n'ont pas - besoin d'être chargés (et ne gaspillent donc pas de ressources mémoire) - tant qu'il ne sont pas nécessaires au programme en question. Si nécessaire, - ces modules peuvent être chargés dynamiquement afin d'étendre les - fonctionnalités de base du programme.

- -

Bien que ce mécanisme DSO paraisse évident, il comporte au moins une - étape difficile : la résolution des symboles depuis le programme exécutable - pour le DSO lorsqu'on utilise un DSO pour étendre les fonctionnalités d'un - programme (la seconde méthode). Pourquoi ? Parce que la "résolution - inverse" des symboles DSO à partir du jeu de symboles du programme - exécutable dépend de la conception de la bibliothèque (la bibliothèque n'a - aucune information sur le programme qui l'utilise) et n'est ni standardisée - ni disponible sur toutes les plateformes. En pratique, les symboles globaux - du programme exécutable ne sont en général pas réexportés et donc - indisponibles pour l'utilisation dans un DSO. Trouver une méthode pour - forcer l'éditeur de liens à exporter tous les symboles globaux est le - principal problème que l'on doit résoudre lorsqu'on utilise un DSO pour - étendre les fonctionnalités d'un programme au moment de son exécution.

- -

L'approche des bibliothèques partagées est la plus courante, parce que - c'est dans cette optique que le mécanisme DSO a été conçu ; c'est cette - approche qui est ainsi - utilisée par pratiquement tous les types de bibliothèques que fournit le - système d'exploitation.

- -
top
-
-

Avantages et inconvénients

- -

Les fonctionnalités ci-dessus basées sur les DSO présentent les - avantages suivants :

- -
    -
  • Le paquetage du serveur est plus flexible à l'exécution car le - processus serveur peut être assemblé à l'exécution via la - directive LoadModule du fichier de - configuration httpd.conf plutôt que par des options du script - configure à la compilation. Par exemple, - on peut ainsi exécuter différentes instances du serveur - (standard et version SSL, version minimale et version dynamique - [mod_perl, mod_php], etc...) à partir d'une seule installation - d'Apache httpd.
    • - -
  • Le paquetage du serveur peut être facilement étendu avec des modules - tiers, même après l'installation. Ceci présente un gros - avantage pour les mainteneurs de paquetages destinés aux distributions, - car ils peuvent créer un paquetage Apache httpd de base, et des paquetages - additionnels contenant des extensions telles que PHP, mod_perl, mod_fastcgi, - etc...
    • - -
  • Une facilité de prototypage des modules Apache httpd, car la paire - DSO/apxs vous permet d'une part de travailler en - dehors de l'arborescence des sources d'Apache httpd, et d'autre part de n'avoir - besoin que de la commande apxs -i - suivie d'un apachectl restart pour introduire une nouvelle - version de votre module fraîchement développé dans le serveur HTTP Apache - en cours d'exécution.
    • -
- -

Inconvénients des DSO :

- -
    -
  • Le serveur est environ 20 % plus lent au démarrage - à cause des résolutions de symboles supplémentaires que le chargeur - Unix doit effectuer.
    • - -
  • Le serveur est environ 5 % plus lent à l'exécution - sur certaines plates-formes, car le code indépendant de la position (PIC) - nécessite parfois des manipulations compliquées en assembleur pour - l'adressage relatif qui ne sont pas toujours aussi rapides que celles - que permet l'adressage absolu.
    • - -
  • Comme les modules DSO ne peuvent pas être liés avec d'autres - bibliothèques basées sur DSO (ld -lfoo) sur toutes les - plates-formes - (par exemple, les plates-formes basées sur a.out ne fournissent en - général pas cette fonctionnalité alors que les plates-formes basées sur - ELF le font), vous ne pouvez pas utiliser le mécanisme DSO pour tous les - types de modules. Ou en d'autres termes, les modules compilés comme - fichiers DSO sont contraints de n'utiliser que les symboles du coeur - d'Apache httpd, de la bibliothèque C - (libc) et toutes autres bibliothèques statiques ou - dynamiques utilisées par le coeur d'Apache httpd, ou d'archives statiques - (libfoo.a) contenant du code indépendant de la - position (PIC). - Il y a deux solutions pour utiliser un autre type de code : soit le - coeur d'Apache httpd contient déjà lui-même une référence au code, soit vous - chargez le code vous-même via dlopen().
    • -
- -
-
-

Langues Disponibles:  en  | - fr  | - ja  | - ko  | - tr 

-
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
-
- \ No newline at end of file diff --git a/docs/manual/dso.html.fr.utf8 b/docs/manual/dso.html.fr.utf8 new file mode 100644 index 0000000000..c595417eb1 --- /dev/null +++ b/docs/manual/dso.html.fr.utf8 @@ -0,0 +1,356 @@ + + + + + +Support des objets dynamiques partagés (DSO) - Serveur HTTP Apache Version 2.5 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.5

+
+
<-
+

Support des objets dynamiques partagés (DSO)

+
+

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

+
+ +

La conception modulaire du serveur HTTP Apache permet à l'administrateur + de choisir les fonctionnalités à inclure dans le serveur en sélectionnant + un certain nombre de modules. Les modules seront compilés en tant + qu'Objets Dynamiques Partagés (Dynamic Shared Objects ou DSOs) + qui mènent une existence séparée du fichier binaire principal + httpd. Les modules DSO peuvent être compilés en + même temps que le serveur, ou compilés et ajoutés ultérieurement via + l'Outil des Extensions à Apache (Apache Extension Tool ou + apxs).

+

Les modules peuvent aussi être intégrés statiquement dans le + binaire httpd lors de la compilation de ce + dernier.

+ +

Ce document décrit l'utilisation des modules DSO ainsi que les dessous + de leur fonctionnement.

+
+ +
top
+
+

Implémentation

+ +
Modules ApparentésDirectives Apparentées
+ +

Le support DSO pour le chargement de modules individuels d'Apache + httpd est + assuré par un module nommé mod_so qui doit être compilé + statiquement dans le coeur d'Apache httpd. Il s'agit du seul module avec le + module core à ne pas pouvoir être compilé en tant que + module DSO lui-même. Pratiquement tous les autres modules d'Apache httpd + distribués seront alors compilés en tant que modules DSO. Une fois + compilé en tant que module DSO nommé mod_foo.so, un + module peut être chargé en mémoire au + démarrage ou redémarrage du serveur à l'aide de + la directive LoadModule du module + mod_so, placée + dans votre fichier httpd.conf.

+

La compilation en mode DSO peut être désactivée pour certains + modules via l'option --enable-mods-static du script + configure, comme expliqué dans la Documentation sur l'installation.

+ +

Un utilitaire permet de simplifier la création de + fichiers DSO pour les modules d'Apache httpd + (particulièrement pour les modules tiers) ; il s'agit du programme nommé + apxs (APache + eXtenSion). On peut l'utiliser pour construire des modules de type + DSO en dehors de l'arborescence des sources d'Apache httpd. L'idée est + simple : à l'installation du serveur HTTP Apache, la procédure make install + du script configure installe les fichiers d'en-têtes + d'Apache httpd et positionne, pour la plateforme de compilation, les drapeaux du compilateur et de + l'éditeur de liens à l'intérieur du programme + apxs, qui sera utilisé pour la construction de fichiers DSO. + Il est ainsi possible d'utiliser le programme apxs + pour compiler ses sources de modules Apache httpd sans avoir besoin de + l'arborescence des sources de la distribution d'Apache, et sans avoir à + régler les drapeaux du compilateur et de l'éditeur de liens pour le support DSO.

+
top
+
+

Mode d'emploi succinct

+ +

Afin que vous puissiez vous faire une idée des fonctionnalités DSO + du serveur HTTP Apache 2.x, en voici un résumé court et concis :

+ +
    +
  1. +

    Construire et installer un module Apache httpd faisant partie de la + distribution, par exemple mod_foo.c, + en tant que module DSO mod_foo.so :

    + +

    +$ ./configure --prefix=/chemin/vers/installation --enable-foo
    +$ make install +

    +
    2. + +
  2. +

    Configure le serveur HTTP Apache avec tous les modules + activés. Seul un jeu de modules de base sera chargé au + démarrage du serveur. Vous pouvez modifier ce jeu de modules + chargés au démarrage en activant ou désactivant les directives LoadModule correspondantes dans le + fichier httpd.conf.

    + +

    +$ ./configure --enable-mods-shared=all
    +$ make install +

    + +

    L'argument most de l'option + --enable-modules indique que tous les modules + non-expérimentaux ou qui ne sont pas là à titre d'exemple seront + compilés.

    +
    3. + +
  3. +

    Certains modules ne sont utilisés que par les développeurs et + ne seront pas compilés. Si vous voulez les utiliser, spécifiez + l'option all. Pour compiler tous les modules disponibles, + y compris les modules de développeurs, spécifiez l'option + reallyall. En outre, la directive LoadModule peut être activée pour tous + les modules compilés via l'option du script configure + --enable-load-all-modules.

    + +

    +$ ./configure --enable-mods-shared=reallyall --enable-load-all-modules
    +$ make install +

    +
    4. + +
  4. + Construire et installer un module Apache httpd tiers, par exemple + mod_foo.c, en tant que module DSO + mod_foo.so en dehors de l'arborescence des sources + d'Apache httpd à l'aide du programme apxs : + +

    +$ cd /chemin/vers/module_tiers
    +$ apxs -cia mod_foo.c +

    +
    5. +
+ +

Dans tous les cas, une fois le module partagé compilé, vous devez + ajouter une directive LoadModule + dans le fichier httpd.conf pour qu'Apache httpd active le module.

+ +

Voir la documentation sur apxs + pour plus de détails.

+
top
+
+

Les dessous du fonctionnement des DSO

+ +

Les clônes modernes d'UNIX proposent un mécanisme + appelé édition de liens et chargement dynamiques d' + Objets Dynamiques Partagés (DSO), qui permet de construire un + morceau de programme dans un format spécial pour le rendre chargeable + à l'exécution dans l'espace d'adressage d'un programme exécutable.

+ +

Ce chargement peut s'effectuer de deux manières : automatiquement par + un programme système appelé ld.so quand un programme + exécutable est démarré, ou manuellement à partir du programme en cours + d'exécution via sa propre interface système vers le chargeur Unix à l'aide + des appels système dlopen()/dlsym().

+ +

Dans la première méthode, les DSO sont en général appelés + bibliothèques partagées ou encore bibliothèques DSO, et + possèdent des noms du style + libfoo.so ou libfoo.so.1.2. Ils résident dans un + répertoire système (en général /usr/lib) + et le lien avec le programme exécutable est établi à la compilation en + ajoutant -lfoo à la commande de l'éditeur de liens. Les + références à la bibliothèque sont ainsi codées en dur dans le fichier du + programme exécutable de façon à ce qu'au démarrage du programme, le + chargeur Unix soit capable de localiser libfoo.so dans + /usr/lib, dans des chemins codés en dur à l'aide d'options de + l'éditeur de liens comme -R ou dans des chemins définis par la + variable d'environnement + LD_LIBRARY_PATH. Le chargeur peut dès lors résoudre tous les symboles + (jusque là non encore résolus) du DSO dans le programme exécutable.

+ +

Les symboles du programme exécutable ne sont en général pas + référencés par le DSO (car c'est une bibliothèque de code à usage général + et réutilisable), + et ainsi aucune résolution supplémentaire n'est nécessaire. De son côté, + le programme exécutable ne doit accomplir aucune action particulière + pour utiliser les + symboles du DSO car toutes les résolutions sont effectuées par le chargeur + Unix. En fait, le code permettant d'invoquer + ld.so fait partie du code de démarrage pour l'exécution qui + est lié dans tout programme exécutable non statiquement lié. + L'avantage du chargement dynamique du code d'une bibliothèque partagée est + évident : le code de la bibliothèque ne doit être stocké qu'une seule fois + dans une bibliothèque système telle que libc.so, ce qui permet + d'économiser de l'espace disque pour les autres programmes.

+ +

Dans la seconde méthode, les DSO sont en général appelés objets + partagés ou fichiers DSO, et peuvent être nommés avec + l'extension de son choix (bien que le nom conseillé soit du style + foo.so). Ces fichiers résident en général dans un répertoire + spécifique à un programme, et aucun lien n'est automatiquement établi avec + le programme exécutable dans lequel ils sont utilisés. + Le programme exécutable charge manuellement le DSO à l'exécution dans son + espace d'adressage à l'aide de l'appel système dlopen(). + A ce moment, aucune résolution de symboles du DSO n'est effectuée pour le + programme exécutable. Par contre le chargeur Unix + résoud automatiquement tout symbole du DSO (non encore résolu) + faisant partie de l'ensemble de symboles exporté par le programme + exécutable et ses bibliothèques DSO déjà chargées (et en particulier tous + les symboles de la bibliothèque à tout faire libc.so). + De cette façon, le DSO prend connaissance de l'ensemble de symboles du + programme exécutable comme s'il avait été lié statiquement avec lui + auparavant.

+ +

Finalement, pour tirer profit de l'API des DSO, le programme exécutable + doit résoudre certains symboles du DSO à l'aide de l'appel système + dlsym() pour une utilisation ultérieure dans les tables de + distribution, etc... En d'autres termes, le programme exécutable doit + résoudre manuellement tous les symboles dont il a besoin pour pouvoir les + utiliser. + Avantage d'un tel mécanisme : les modules optionnels du programme n'ont pas + besoin d'être chargés (et ne gaspillent donc pas de ressources mémoire) + tant qu'il ne sont pas nécessaires au programme en question. Si nécessaire, + ces modules peuvent être chargés dynamiquement afin d'étendre les + fonctionnalités de base du programme.

+ +

Bien que ce mécanisme DSO paraisse évident, il comporte au moins une + étape difficile : la résolution des symboles depuis le programme exécutable + pour le DSO lorsqu'on utilise un DSO pour étendre les fonctionnalités d'un + programme (la seconde méthode). Pourquoi ? Parce que la "résolution + inverse" des symboles DSO à partir du jeu de symboles du programme + exécutable dépend de la conception de la bibliothèque (la bibliothèque n'a + aucune information sur le programme qui l'utilise) et n'est ni standardisée + ni disponible sur toutes les plateformes. En pratique, les symboles globaux + du programme exécutable ne sont en général pas réexportés et donc + indisponibles pour l'utilisation dans un DSO. Trouver une méthode pour + forcer l'éditeur de liens à exporter tous les symboles globaux est le + principal problème que l'on doit résoudre lorsqu'on utilise un DSO pour + étendre les fonctionnalités d'un programme au moment de son exécution.

+ +

L'approche des bibliothèques partagées est la plus courante, parce que + c'est dans cette optique que le mécanisme DSO a été conçu ; c'est cette + approche qui est ainsi + utilisée par pratiquement tous les types de bibliothèques que fournit le + système d'exploitation.

+ +
top
+
+

Avantages et inconvénients

+ +

Les fonctionnalités ci-dessus basées sur les DSO présentent les + avantages suivants :

+ +
    +
  • Le paquetage du serveur est plus flexible à l'exécution car le + processus serveur peut être assemblé à l'exécution via la + directive LoadModule du fichier de + configuration httpd.conf plutôt que par des options du script + configure à la compilation. Par exemple, + on peut ainsi exécuter différentes instances du serveur + (standard et version SSL, version minimale et version dynamique + [mod_perl, mod_php], etc...) à partir d'une seule installation + d'Apache httpd.
    • + +
  • Le paquetage du serveur peut être facilement étendu avec des modules + tiers, même après l'installation. Ceci présente un gros + avantage pour les mainteneurs de paquetages destinés aux distributions, + car ils peuvent créer un paquetage Apache httpd de base, et des paquetages + additionnels contenant des extensions telles que PHP, mod_perl, mod_fastcgi, + etc...
    • + +
  • Une facilité de prototypage des modules Apache httpd, car la paire + DSO/apxs vous permet d'une part de travailler en + dehors de l'arborescence des sources d'Apache httpd, et d'autre part de n'avoir + besoin que de la commande apxs -i + suivie d'un apachectl restart pour introduire une nouvelle + version de votre module fraîchement développé dans le serveur HTTP Apache + en cours d'exécution.
    • +
+ +

Inconvénients des DSO :

+ +
    +
  • Le serveur est environ 20 % plus lent au démarrage + à cause des résolutions de symboles supplémentaires que le chargeur + Unix doit effectuer.
    • + +
  • Le serveur est environ 5 % plus lent à l'exécution + sur certaines plates-formes, car le code indépendant de la position (PIC) + nécessite parfois des manipulations compliquées en assembleur pour + l'adressage relatif qui ne sont pas toujours aussi rapides que celles + que permet l'adressage absolu.
    • + +
  • Comme les modules DSO ne peuvent pas être liés avec d'autres + bibliothèques basées sur DSO (ld -lfoo) sur toutes les + plates-formes + (par exemple, les plates-formes basées sur a.out ne fournissent en + général pas cette fonctionnalité alors que les plates-formes basées sur + ELF le font), vous ne pouvez pas utiliser le mécanisme DSO pour tous les + types de modules. Ou en d'autres termes, les modules compilés comme + fichiers DSO sont contraints de n'utiliser que les symboles du coeur + d'Apache httpd, de la bibliothèque C + (libc) et toutes autres bibliothèques statiques ou + dynamiques utilisées par le coeur d'Apache httpd, ou d'archives statiques + (libfoo.a) contenant du code indépendant de la + position (PIC). + Il y a deux solutions pour utiliser un autre type de code : soit le + coeur d'Apache httpd contient déjà lui-même une référence au code, soit vous + chargez le code vous-même via dlopen().
    • +
+ +
+
+

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

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/env.html.en b/docs/manual/env.html.en index bbc5102fba..59aa9d9057 100644 --- a/docs/manual/env.html.en +++ b/docs/manual/env.html.en @@ -24,10 +24,10 @@ Apache > HTTP Server > Documentation > Version 2.5

Environment Variables in Apache

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

+ tr 

There are two kinds of environment variables that affect @@ -498,10 +498,10 @@ SetEnvIf Referer "^$" local_referal

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

+ tr 

top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
- - -
-

Modules | Directives | FAQ | Glossaire | Plan du site

-

Serveur HTTP Apache Version 2.5

-
-
<-
-

Apache et les variables d'environnement

-
-

Langues Disponibles:  en  | - fr  | - ja  | - ko  | - tr 

-
- -

Deux types de variables d'environnement affectent le serveur - HTTP Apache.

- -

Le premier type correspond aux variables d'environnement - contrôlées par le système d'exploitation sous-jacent et définies - avant le démarrage du serveur. Leurs valeurs peuvent être utilisées - directement dans les fichiers de configuration, et peuvent - éventuellement être transmises aux scripts CGI et SSI via la - directive PassEnv.

- -

Le second type correspond aux variables nommées appelées aussi - variables d'environnement dans lesquelles le serveur HTTP - Apache stocke des informations via un mécanisme spécial. Ces - informations peuvent servir à contrôler diverses opérations comme - l'enregistrement des traces ou le contrôle d'accès. On utilise aussi ces - variables dans le mécanisme de communication avec les programmes externes - comme les scripts CGI. Ce document présente différentes méthodes pour - manipuler et utiliser ces variables.

- -

Bien que ces variables soient référencées comme variables - d'environnement, il ne faut pas les confondre avec les variables - d'environnement contrôlées par le système d'exploitation sous-jacent. - En fait, ces variables sont stockées et manipulées dans une structure - interne à Apache. Elles ne deviennent de véritables variables - d'environnement du système d'exploitation que lorsqu'elles sont mises à la - disposition de scripts CGI et de scripts inclus côté serveur (SSI). Si vous - souhaitez manipuler l'environnement du système d'exploitation sous lequel - le serveur s'exécute, vous devez utiliser les mécanismes standards de - manipulation de l'environnement fournis par l'interpréteur de commandes - (shell) de votre système d'exploitation.

-
- -
top
-
-

Définition des variables d'environnement

- -
Modules ApparentésDirectives Apparentées
- -

Manipulations de base de l'environnement

- - -

La méthode la plus élémentaire pour définir une variable - d'environnement au niveau d'Apache consiste à utiliser la directive - inconditionnelle SetEnv. Les variables peuvent aussi être transmises depuis - l'environnement du shell à partir duquel le serveur a été démarré en - utilisant la directive - PassEnv.

- - -

Définitions conditionnelles en fonction des requêtes

- - -

Pour plus de souplesse, les directives fournies par le module - mod_setenvif permettent de définir les - variables d'environnement en tenant compte des caractéristiques - de chaque requête. Par exemple, une - variable pourrait n'être définie que lorsqu'un navigateur spécifique - (User-Agent) a généré la requête, ou seulement quand un en-tête - Referer particulier est présent. La directive - RewriteRule du module - mod_rewrite qui utilise l'option - [E=...] pour définir - les variables d'environnement apporte encore plus de souplesse.

- - -

Identifiants uniques

- - -

Finalement, le module mod_unique_id définit la variable - d'environnement UNIQUE_ID pour chaque requête à une valeur - qui est garantie unique parmi "toutes" les requêtes - sous des conditions très spécifiques.

- - -

Variables CGI standards

- - -

En plus de l'ensemble des variables d'environnement internes à la - configuration d'Apache et de celles transmises depuis le shell, - les scripts CGI et les pages SSI - se voient affectés un ensemble de variables - d'environnement contenant des méta-informations à propos de la requête - comme préconisé dans la - spécification - sur les CGIs.

- - -

Quelques mises en garde

- - -
    -
  • Les directives de manipulation de l'environnement ne permettent - pas de supplanter ou modifier les variables CGI standards.
    • - -
  • Lorsqu'on utilise suexec pour exécuter des - scripts CGI, l'environnement est nettoyé et réduit à un ensemble de - variables sûres avant l'exécution du script. La liste des - variables sûres est définie à la compilation dans - suexec.c.
    • - -
  • Pour des raisons de portabilité, les noms des variables - d'environnement ne peuvent contenir que des lettres, des chiffres, et - le caractère "sousligné". En outre, le premier caractère ne doit pas - être un chiffre. Les caractères qui ne satisfont pas à ces conditions - seront remplacés par un caractère "sousligné" quand ils seront - transmis aux scripts CGI et aux pages SSI.
    • - -
  • Les contenus d'en-têtes HTTP transmis aux scripts de type - CGI ou autre via des variables d'environnement constituent un - cas particulier (voir plus loin). Leur nom est converti en - majuscules et seuls les tirets sont remplacés par des - caractères '_' ("souligné") ; si le format du nom de l'en-tête - n'est pas valide, celui-ci est ignoré. Voir plus loin pour une solution de - contournement du problème.
    • - -
  • La directive SetEnv s'exécute assez tard au - cours du traitement de la requête, ce qui signifie que des - directives telles que SetEnvIf et RewriteCond ne verront pas - les variables qu'elle aura définies.
    • - -
  • Lorsque le serveur cherche un chemin via une sous-requête interne (par exemple la - recherche d'un DirectoryIndex), ou lorsqu'il génère un - listing du contenu d'un répertoire via le module - mod_autoindex, la sous-requête n'hérite pas des - variables d'environnement spécifiques à la requête. En outre, à cause - des phases de l'API auxquelles mod_setenvif prend - part, les directives SetEnvIf ne sont pas évaluées - séparément dans la sous-requête.
    • -
- -
top
-
-

Utilisation des variables d'environnement

- - -
Modules ApparentésDirectives Apparentées
- -

Scripts CGI

- - -

La communication d'informations aux scripts CGI constitue une des - principales utilisations des variables d'environnement. Comme indiqué - plus haut, l'environnement transmis aux scripts CGI comprend des - méta-informations standards à propos de la requête, en plus des - variables définies dans la configuration d'Apache. Pour plus de - détails, se référer au - tutoriel CGI.

- - -

Pages SSI

- - -

Les documents inclus côté serveur (SSI) traités par le filtre - INCLUDES du module mod_include, - peuvent afficher les - variables d'environnement à l'aide de l'élément echo, - et peuvent utiliser des variables d'environnement dans les éléments - de contrôle de flux pour rendre certaines parties d'une page - conditionnelles en fonction des caractéristiques de la requête. - Apache fournit aussi les variables d'environnement CGI standards - aux pages SSI - comme indiqué plus haut. Pour plus de détails, se référer au - tutoriel SSI.

- - -

Contrôle d'accès

- - -

L'accès au serveur peut être contrôlé en fonction de la valeur de - variables d'environnement à l'aide des directives - allow from env= et deny from env=. - En association avec la directive - SetEnvIf, ceci confère une - grande souplesse au contrôle d'accès au serveur en fonction des - caractéristiques du client. Par exemple, vous pouvez utiliser ces - directives pour interdire l'accès depuis un navigateur particulier - (User-Agent). -

- - -

Enregistrement conditionnel des traces

- - -

Les variables d'environnement peuvent être enregistrées dans le - fichier de log des accès à l'aide de l'option %e de la - directive LogFormat. - En outre, la décision de tracer ou non les requêtes peut être prise - en fonction de l'état de variables d'environnement en utilisant la - forme conditionnelle de la directive - CustomLog. En - association avec la directive SetEnvIf, ceci confère une grande souplesse au contrôle - du traçage des requêtes. Par exemple, vous pouvez choisir de ne pas - tracer les requêtes pour des noms de fichiers se terminant par - gif, ou encore de ne tracer que les requêtes des clients - n'appartenant pas à votre sous-réseau.

- - -

En-têtes de réponse conditionnels

- - -

La directive Header - peut se baser sur la présence ou l'absence d'une variable - d'environnement pour décider si un certain en-tête HTTP sera placé - dans la réponse au client. Ceci permet, par exemple, de n'envoyer un - certain en-tête de réponse que si un en-tête correspondant est présent - dans la requête du client.

- - - -

Activation de filtres externes

- - -

Les filtres externes configurés par le module - mod_ext_filter à l'aide de la directive ExtFilterDefine peuvent être - activés de manière conditionnelle en fonction d'une variable - d'environnement à l'aide des options - disableenv= et enableenv=.

- - -

Réécriture d'URL

- - -

La forme %{ENV:variable} de - TestString dans la - directive RewriteCond - permet au moteur de réécriture du module - mod_rewrite de prendre des - décisions conditionnées par des variables d'environnement. - Notez que les variables accessibles dans - mod_rewrite sans le préfixe - ENV: ne sont pas de véritables variables - d'environnement. Ce sont plutôt des variables spécifiques à - mod_rewrite - qui ne sont pas accessibles pour les autres modules.

- -
top
-
-

Variables d'environnement à usage spécial

- - -

Des problèmes d'interopérabilité ont conduit à l'introduction de - mécanismes permettant de modifier le comportement d'Apache lorsqu'il - dialogue avec certains clients. Afin de rendre ces mécanismes aussi - souples que possible, ils sont invoqués en définissant des variables - d'environnement, en général à l'aide de la directive - BrowserMatch, bien que les - directives SetEnv et - PassEnv puissent aussi être - utilisées, par exemple.

- -

downgrade-1.0

- - -

Ceci force le traitement d'une requête comme une requête HTTP/1.0 - même si elle a été rédigée dans un langage plus récent.

- - -

force-gzip

- -

Si le filtre DEFLATE est activé, cette variable - d'environnement ignorera les réglages accept-encoding de votre - navigateur et enverra une sortie compressée inconditionnellement.

- -

force-no-vary

- - -

Cette variable entraîne la suppression de tout champ - Vary des en-têtes de la réponse avant que cette dernière - soit renvoyée au client. Certains clients n'interprètent pas ce champ - correctement, et la définition de cette variable permet de contourner - ce problème, mais implique aussi la définition de - force-response-1.0.

- - -

force-response-1.0

- - -

Cette variable force une réponse en langage HTTP/1.0 aux clients - qui envoient des requêtes dans le même langage. Elle fut implémentée à - l'origine suite à des problèmes avec les mandataires d'AOL. Certains - clients en langage HTTP/1.0 ne réagissent pas correctement face à une - réponse en langage HTTP/1.1, et cette variable peut être utilisée pour - assurer l'interopérabilité avec eux.

- - - -

gzip-only-text/html

- - -

Positionnée à "1", cette variable désactive le filtre en sortie - DEFLATE fourni par le module mod_deflate pour les - types de contenu autres que text/html. Si vous préférez - utiliser des fichiers compressés statiquement, - mod_negotiation évalue aussi la variable (non - seulement pour gzip, mais aussi pour tous les encodages autres que - "identity").

- - -

no-gzip

- -

Quand cette variable est définie, le filtre DEFLATE du - module mod_deflate est désactivé, et - mod_negotiation refusera de délivrer des ressources - encodées.

- - - -

no-cache

-

Disponible dans les versions 2.2.12 et ultérieures d'Apache

- -

Lorsque cette variable est définie, - mod_cache ne sauvegardera pas de réponse - susceptible d'être mise en cache. Cette variable d'environnement - n'a aucune incidence sur le fait qu'une réponse déjà enregistrée - dans la cache soit utilisée ou non pour la requête courante.

- - - -

nokeepalive

- - -

Quand cette variable est définie, la directive - KeepAlive est désactivée.

- - - -

prefer-language

- -

Cette variable modifie le comportement du module - mod_negotiation. Si elle contient un symbole de - langage (tel que en, ja - ou x-klingon), mod_negotiation essaie de - délivrer une variante dans ce langage. S'il n'existe pas de telle - variante, le processus normal de - négociation s'applique.

- - - -

redirect-carefully

- - -

Cette variable force le serveur à être plus prudent lors de l'envoi - d'une redirection au client. Elle est en général utilisée quand un - client présente un problème connu avec les redirections. Elle fut - implémentée à l'origine suite a un problème rencontré avec le logiciel - WebFolders de Microsoft qui ne gère pas correctement les redirections - vers des ressources de type répertoire via des méthodes DAV.

- - - -

suppress-error-charset

- - -

Disponible dans les versions postérieures à 2.0.54

- -

Quand Apache génère une redirection en réponse à une requête client, - la réponse inclut un texte destiné à être affiché au cas où le client ne - suivrait pas, ou ne pourrait pas suivre automatiquement la redirection. - Habituellement, Apache marque ce texte en accord avec le jeu de caractères - qu'il utilise, à savoir ISO-8859-1.

-

Cependant, si la redirection fait référence à une page qui utilise un - jeu de caractères différent, certaines versions de navigateurs obsolètes - essaieront d'utiliser le jeu de caractères du texte de la redirection - plutôt que celui de la page réelle. - Ceci peut entraîner, par exemple, un rendu incorrect du Grec.

-

Si cette variable d'environnement est définie, Apache omettra le jeu de - caractères pour le texte de la redirection, et les navigateurs obsolètes - précités utiliseront correctement celui de la page de destination.

- -
-

Note concernant la sécurité

- -

L'envoi de pages d'erreur sans spécifier un jeu de caractères peut - conduire à des attaques de type "cross-site-scripting" pour les - navigateurs qui ne respectent pas la spécification HTTP/1.1 (MSIE) et - tentent de déduire le jeu de caractères à partir du contenu. De tels - navigateurs peuvent être facilement trompés et utiliser le jeu de - caractères UTF-7 ; les contenus des données en entrée de type UTF-7 - (comme les URI de requête) ne seront alors plus protégés par les - mécanismes d'échappement usuels conçus pour prévenir les attaques - de type "cross-site-scripting".

-
- - - -

force-proxy-request-1.0, proxy-nokeepalive, proxy-sendchunked, - proxy-sendcl, proxy-chain-auth, proxy-interim-response, proxy-initial-not-pooled

- -

Ces directives modifient le comportement protocolaire du module - mod_proxy. Voir la documentation sur - mod_proxy et mod_proxy_http pour plus de détails.

- - -
top
-
-

Exemples

- - -

Transmission du contenu d'en-têtes non valides aux scripts - CGI

- - -

Avec la version 2.4, Apache est plus strict avec la conversion - des en-têtes HTTP en variables d'environnement dans - mod_cgi et d'autres modules : dans les versions - précédentes, tout caractère invalide dans les noms d'en-têtes - était tout simplement remplacé par un caractère '_', ce qui - pouvait exposer à des attaques de type cross-site-scripting via - injection d'en-têtes (voir Bogues - du Web inhabituelles, planche 19/20).

- -

Si vous devez supporter un client qui envoie des en-têtes non - conformes et si ceux-ci ne peuvent pas être corrigés, il existe - une solution de contournement simple mettant en jeu les modules - mod_setenvif et mod_headers, - et permettant de prendre en compte ces en-têtes :

- -
# L'exemple suivant montre comment prendre en compte un en-tête

-# Accept_Encoding non conforme envoyé par un client.
-#
-SetEnvIfNoCase ^Accept.Encoding$ ^(.*)$ fix_accept_encoding=$1
-RequestHeader set Accept-Encoding %{fix_accept_encoding}e env=fix_accept_encoding
- - - - -

Modification du comportement protocolaire face à des clients - réagissant de manière non conforme

- - -

Les versions antérieures recommandaient l'ajout de ces lignes dans - httpd.conf pour tenir compte de problèmes connus avec certains clients. - Comme les clients concernés sont maintenant très peu utilisés, cet - ajout n'est pratiquement plus nécessaire.

-
#
-# The following directives modify normal HTTP response behavior.
-# The first directive disables keepalive for Netscape 2.x and browsers that
-# spoof it. There are known problems with these browser implementations.
-# The second directive is for Microsoft Internet Explorer 4.0b2
-# which has a broken HTTP/1.1 implementation and does not properly
-# support keepalive when it is used on 301 or 302 (redirect) responses.
-#
-BrowserMatch "Mozilla/2" nokeepalive
-BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0
-
-#
-# The following directive disables HTTP/1.1 responses to browsers which
-# are in violation of the HTTP/1.0 spec by not being able to grok a
-# basic 1.1 response.
-#
-BrowserMatch "RealPlayer 4\.0" force-response-1.0
-BrowserMatch "Java/1\.0" force-response-1.0
-BrowserMatch "JDK/1\.0" force-response-1.0
- - - -

Ne pas tracer les requêtes pour des images dans le fichier de - trace des accès

- - -

Dans cet exemple, les requêtes pour des images n'apparaissent pas - dans le fichier de trace des accès. Il peut être facilement adapté pour - empêcher le traçage de répertoires particuliers, ou de requêtes - en provenance de certains hôtes.

- 
SetEnvIf Request_URI \.gif image-request
-SetEnvIf Request_URI \.jpg image-request
-SetEnvIf Request_URI \.png image-request
-CustomLog "logs/access_log" common env=!image-request
- - - -

Prévention du "Vol d'image"

- - -

Cet exemple montre comment empêcher les utilisateurs ne faisant pas - partie de votre serveur d'utiliser des images de votre serveur comme - images en ligne dans leurs pages. Cette configuration n'est pas - recommandée, mais elle peut fonctionner dans des circonstances bien - définies. Nous supposons que toutes vos images sont enregistrées dans - un répertoire nommé /web/images.

- 
SetEnvIf Referer "^http://www\.example\.com/" local_referal
-# Autorise les navigateurs qui n'envoient aucune information de Referer
-SetEnvIf Referer "^$" local_referal
-<Directory "/web/images">
-    Require env local_referal
-</Directory>
- - -

Pour plus d'informations sur cette technique, voir le tutoriel sur - ServerWatch - "Keeping Your Images from Adorning Other Sites".

- -
-
-

Langues Disponibles:  en  | - fr  | - ja  | - ko  | - tr 

-
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
-
- \ No newline at end of file diff --git a/docs/manual/env.html.fr.utf8 b/docs/manual/env.html.fr.utf8 new file mode 100644 index 0000000000..50927a0db5 --- /dev/null +++ b/docs/manual/env.html.fr.utf8 @@ -0,0 +1,560 @@ + + + + + +Apache et les variables d'environnement - Serveur HTTP Apache Version 2.5 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.5

+
+
<-
+

Apache et les variables d'environnement

+
+

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

+
+ +

Deux types de variables d'environnement affectent le serveur + HTTP Apache.

+ +

Le premier type correspond aux variables d'environnement + contrôlées par le système d'exploitation sous-jacent et définies + avant le démarrage du serveur. Leurs valeurs peuvent être utilisées + directement dans les fichiers de configuration, et peuvent + éventuellement être transmises aux scripts CGI et SSI via la + directive PassEnv.

+ +

Le second type correspond aux variables nommées appelées aussi + variables d'environnement dans lesquelles le serveur HTTP + Apache stocke des informations via un mécanisme spécial. Ces + informations peuvent servir à contrôler diverses opérations comme + l'enregistrement des traces ou le contrôle d'accès. On utilise aussi ces + variables dans le mécanisme de communication avec les programmes externes + comme les scripts CGI. Ce document présente différentes méthodes pour + manipuler et utiliser ces variables.

+ +

Bien que ces variables soient référencées comme variables + d'environnement, il ne faut pas les confondre avec les variables + d'environnement contrôlées par le système d'exploitation sous-jacent. + En fait, ces variables sont stockées et manipulées dans une structure + interne à Apache. Elles ne deviennent de véritables variables + d'environnement du système d'exploitation que lorsqu'elles sont mises à la + disposition de scripts CGI et de scripts inclus côté serveur (SSI). Si vous + souhaitez manipuler l'environnement du système d'exploitation sous lequel + le serveur s'exécute, vous devez utiliser les mécanismes standards de + manipulation de l'environnement fournis par l'interpréteur de commandes + (shell) de votre système d'exploitation.

+
+ +
top
+
+

Définition des variables d'environnement

+ +
Modules ApparentésDirectives Apparentées
+ +

Manipulations de base de l'environnement

+ + +

La méthode la plus élémentaire pour définir une variable + d'environnement au niveau d'Apache consiste à utiliser la directive + inconditionnelle SetEnv. Les variables peuvent aussi être transmises depuis + l'environnement du shell à partir duquel le serveur a été démarré en + utilisant la directive + PassEnv.

+ + +

Définitions conditionnelles en fonction des requêtes

+ + +

Pour plus de souplesse, les directives fournies par le module + mod_setenvif permettent de définir les + variables d'environnement en tenant compte des caractéristiques + de chaque requête. Par exemple, une + variable pourrait n'être définie que lorsqu'un navigateur spécifique + (User-Agent) a généré la requête, ou seulement quand un en-tête + Referer particulier est présent. La directive + RewriteRule du module + mod_rewrite qui utilise l'option + [E=...] pour définir + les variables d'environnement apporte encore plus de souplesse.

+ + +

Identifiants uniques

+ + +

Finalement, le module mod_unique_id définit la variable + d'environnement UNIQUE_ID pour chaque requête à une valeur + qui est garantie unique parmi "toutes" les requêtes + sous des conditions très spécifiques.

+ + +

Variables CGI standards

+ + +

En plus de l'ensemble des variables d'environnement internes à la + configuration d'Apache et de celles transmises depuis le shell, + les scripts CGI et les pages SSI + se voient affectés un ensemble de variables + d'environnement contenant des méta-informations à propos de la requête + comme préconisé dans la + spécification + sur les CGIs.

+ + +

Quelques mises en garde

+ + +
    +
  • Les directives de manipulation de l'environnement ne permettent + pas de supplanter ou modifier les variables CGI standards.
    • + +
  • Lorsqu'on utilise suexec pour exécuter des + scripts CGI, l'environnement est nettoyé et réduit à un ensemble de + variables sûres avant l'exécution du script. La liste des + variables sûres est définie à la compilation dans + suexec.c.
    • + +
  • Pour des raisons de portabilité, les noms des variables + d'environnement ne peuvent contenir que des lettres, des chiffres, et + le caractère "sousligné". En outre, le premier caractère ne doit pas + être un chiffre. Les caractères qui ne satisfont pas à ces conditions + seront remplacés par un caractère "sousligné" quand ils seront + transmis aux scripts CGI et aux pages SSI.
    • + +
  • Les contenus d'en-têtes HTTP transmis aux scripts de type + CGI ou autre via des variables d'environnement constituent un + cas particulier (voir plus loin). Leur nom est converti en + majuscules et seuls les tirets sont remplacés par des + caractères '_' ("souligné") ; si le format du nom de l'en-tête + n'est pas valide, celui-ci est ignoré. Voir plus loin pour une solution de + contournement du problème.
    • + +
  • La directive SetEnv s'exécute assez tard au + cours du traitement de la requête, ce qui signifie que des + directives telles que SetEnvIf et RewriteCond ne verront pas + les variables qu'elle aura définies.
    • + +
  • Lorsque le serveur cherche un chemin via une sous-requête interne (par exemple la + recherche d'un DirectoryIndex), ou lorsqu'il génère un + listing du contenu d'un répertoire via le module + mod_autoindex, la sous-requête n'hérite pas des + variables d'environnement spécifiques à la requête. En outre, à cause + des phases de l'API auxquelles mod_setenvif prend + part, les directives SetEnvIf ne sont pas évaluées + séparément dans la sous-requête.
    • +
+ +
top
+
+

Utilisation des variables d'environnement

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

Scripts CGI

+ + +

La communication d'informations aux scripts CGI constitue une des + principales utilisations des variables d'environnement. Comme indiqué + plus haut, l'environnement transmis aux scripts CGI comprend des + méta-informations standards à propos de la requête, en plus des + variables définies dans la configuration d'Apache. Pour plus de + détails, se référer au + tutoriel CGI.

+ + +

Pages SSI

+ + +

Les documents inclus côté serveur (SSI) traités par le filtre + INCLUDES du module mod_include, + peuvent afficher les + variables d'environnement à l'aide de l'élément echo, + et peuvent utiliser des variables d'environnement dans les éléments + de contrôle de flux pour rendre certaines parties d'une page + conditionnelles en fonction des caractéristiques de la requête. + Apache fournit aussi les variables d'environnement CGI standards + aux pages SSI + comme indiqué plus haut. Pour plus de détails, se référer au + tutoriel SSI.

+ + +

Contrôle d'accès

+ + +

L'accès au serveur peut être contrôlé en fonction de la valeur de + variables d'environnement à l'aide des directives + allow from env= et deny from env=. + En association avec la directive + SetEnvIf, ceci confère une + grande souplesse au contrôle d'accès au serveur en fonction des + caractéristiques du client. Par exemple, vous pouvez utiliser ces + directives pour interdire l'accès depuis un navigateur particulier + (User-Agent). +

+ + +

Enregistrement conditionnel des traces

+ + +

Les variables d'environnement peuvent être enregistrées dans le + fichier de log des accès à l'aide de l'option %e de la + directive LogFormat. + En outre, la décision de tracer ou non les requêtes peut être prise + en fonction de l'état de variables d'environnement en utilisant la + forme conditionnelle de la directive + CustomLog. En + association avec la directive SetEnvIf, ceci confère une grande souplesse au contrôle + du traçage des requêtes. Par exemple, vous pouvez choisir de ne pas + tracer les requêtes pour des noms de fichiers se terminant par + gif, ou encore de ne tracer que les requêtes des clients + n'appartenant pas à votre sous-réseau.

+ + +

En-têtes de réponse conditionnels

+ + +

La directive Header + peut se baser sur la présence ou l'absence d'une variable + d'environnement pour décider si un certain en-tête HTTP sera placé + dans la réponse au client. Ceci permet, par exemple, de n'envoyer un + certain en-tête de réponse que si un en-tête correspondant est présent + dans la requête du client.

+ + + +

Activation de filtres externes

+ + +

Les filtres externes configurés par le module + mod_ext_filter à l'aide de la directive ExtFilterDefine peuvent être + activés de manière conditionnelle en fonction d'une variable + d'environnement à l'aide des options + disableenv= et enableenv=.

+ + +

Réécriture d'URL

+ + +

La forme %{ENV:variable} de + TestString dans la + directive RewriteCond + permet au moteur de réécriture du module + mod_rewrite de prendre des + décisions conditionnées par des variables d'environnement. + Notez que les variables accessibles dans + mod_rewrite sans le préfixe + ENV: ne sont pas de véritables variables + d'environnement. Ce sont plutôt des variables spécifiques à + mod_rewrite + qui ne sont pas accessibles pour les autres modules.

+ +
top
+
+

Variables d'environnement à usage spécial

+ + +

Des problèmes d'interopérabilité ont conduit à l'introduction de + mécanismes permettant de modifier le comportement d'Apache lorsqu'il + dialogue avec certains clients. Afin de rendre ces mécanismes aussi + souples que possible, ils sont invoqués en définissant des variables + d'environnement, en général à l'aide de la directive + BrowserMatch, bien que les + directives SetEnv et + PassEnv puissent aussi être + utilisées, par exemple.

+ +

downgrade-1.0

+ + +

Ceci force le traitement d'une requête comme une requête HTTP/1.0 + même si elle a été rédigée dans un langage plus récent.

+ + +

force-gzip

+ +

Si le filtre DEFLATE est activé, cette variable + d'environnement ignorera les réglages accept-encoding de votre + navigateur et enverra une sortie compressée inconditionnellement.

+ +

force-no-vary

+ + +

Cette variable entraîne la suppression de tout champ + Vary des en-têtes de la réponse avant que cette dernière + soit renvoyée au client. Certains clients n'interprètent pas ce champ + correctement, et la définition de cette variable permet de contourner + ce problème, mais implique aussi la définition de + force-response-1.0.

+ + +

force-response-1.0

+ + +

Cette variable force une réponse en langage HTTP/1.0 aux clients + qui envoient des requêtes dans le même langage. Elle fut implémentée à + l'origine suite à des problèmes avec les mandataires d'AOL. Certains + clients en langage HTTP/1.0 ne réagissent pas correctement face à une + réponse en langage HTTP/1.1, et cette variable peut être utilisée pour + assurer l'interopérabilité avec eux.

+ + + +

gzip-only-text/html

+ + +

Positionnée à "1", cette variable désactive le filtre en sortie + DEFLATE fourni par le module mod_deflate pour les + types de contenu autres que text/html. Si vous préférez + utiliser des fichiers compressés statiquement, + mod_negotiation évalue aussi la variable (non + seulement pour gzip, mais aussi pour tous les encodages autres que + "identity").

+ + +

no-gzip

+ +

Quand cette variable est définie, le filtre DEFLATE du + module mod_deflate est désactivé, et + mod_negotiation refusera de délivrer des ressources + encodées.

+ + + +

no-cache

+

Disponible dans les versions 2.2.12 et ultérieures d'Apache

+ +

Lorsque cette variable est définie, + mod_cache ne sauvegardera pas de réponse + susceptible d'être mise en cache. Cette variable d'environnement + n'a aucune incidence sur le fait qu'une réponse déjà enregistrée + dans la cache soit utilisée ou non pour la requête courante.

+ + + +

nokeepalive

+ + +

Quand cette variable est définie, la directive + KeepAlive est désactivée.

+ + + +

prefer-language

+ +

Cette variable modifie le comportement du module + mod_negotiation. Si elle contient un symbole de + langage (tel que en, ja + ou x-klingon), mod_negotiation essaie de + délivrer une variante dans ce langage. S'il n'existe pas de telle + variante, le processus normal de + négociation s'applique.

+ + + +

redirect-carefully

+ + +

Cette variable force le serveur à être plus prudent lors de l'envoi + d'une redirection au client. Elle est en général utilisée quand un + client présente un problème connu avec les redirections. Elle fut + implémentée à l'origine suite a un problème rencontré avec le logiciel + WebFolders de Microsoft qui ne gère pas correctement les redirections + vers des ressources de type répertoire via des méthodes DAV.

+ + + +

suppress-error-charset

+ + +

Disponible dans les versions postérieures à 2.0.54

+ +

Quand Apache génère une redirection en réponse à une requête client, + la réponse inclut un texte destiné à être affiché au cas où le client ne + suivrait pas, ou ne pourrait pas suivre automatiquement la redirection. + Habituellement, Apache marque ce texte en accord avec le jeu de caractères + qu'il utilise, à savoir ISO-8859-1.

+

Cependant, si la redirection fait référence à une page qui utilise un + jeu de caractères différent, certaines versions de navigateurs obsolètes + essaieront d'utiliser le jeu de caractères du texte de la redirection + plutôt que celui de la page réelle. + Ceci peut entraîner, par exemple, un rendu incorrect du Grec.

+

Si cette variable d'environnement est définie, Apache omettra le jeu de + caractères pour le texte de la redirection, et les navigateurs obsolètes + précités utiliseront correctement celui de la page de destination.

+ +
+

Note concernant la sécurité

+ +

L'envoi de pages d'erreur sans spécifier un jeu de caractères peut + conduire à des attaques de type "cross-site-scripting" pour les + navigateurs qui ne respectent pas la spécification HTTP/1.1 (MSIE) et + tentent de déduire le jeu de caractères à partir du contenu. De tels + navigateurs peuvent être facilement trompés et utiliser le jeu de + caractères UTF-7 ; les contenus des données en entrée de type UTF-7 + (comme les URI de requête) ne seront alors plus protégés par les + mécanismes d'échappement usuels conçus pour prévenir les attaques + de type "cross-site-scripting".

+
+ + + +

force-proxy-request-1.0, proxy-nokeepalive, proxy-sendchunked, + proxy-sendcl, proxy-chain-auth, proxy-interim-response, proxy-initial-not-pooled

+ +

Ces directives modifient le comportement protocolaire du module + mod_proxy. Voir la documentation sur + mod_proxy et mod_proxy_http pour plus de détails.

+ + +
top
+
+

Exemples

+ + +

Transmission du contenu d'en-têtes non valides aux scripts + CGI

+ + +

Avec la version 2.4, Apache est plus strict avec la conversion + des en-têtes HTTP en variables d'environnement dans + mod_cgi et d'autres modules : dans les versions + précédentes, tout caractère invalide dans les noms d'en-têtes + était tout simplement remplacé par un caractère '_', ce qui + pouvait exposer à des attaques de type cross-site-scripting via + injection d'en-têtes (voir Bogues + du Web inhabituelles, planche 19/20).

+ +

Si vous devez supporter un client qui envoie des en-têtes non + conformes et si ceux-ci ne peuvent pas être corrigés, il existe + une solution de contournement simple mettant en jeu les modules + mod_setenvif et mod_headers, + et permettant de prendre en compte ces en-têtes :

+ +
# L'exemple suivant montre comment prendre en compte un en-tête

+# Accept_Encoding non conforme envoyé par un client.
+#
+SetEnvIfNoCase ^Accept.Encoding$ ^(.*)$ fix_accept_encoding=$1
+RequestHeader set Accept-Encoding %{fix_accept_encoding}e env=fix_accept_encoding
+ + + + +

Modification du comportement protocolaire face à des clients + réagissant de manière non conforme

+ + +

Les versions antérieures recommandaient l'ajout de ces lignes dans + httpd.conf pour tenir compte de problèmes connus avec certains clients. + Comme les clients concernés sont maintenant très peu utilisés, cet + ajout n'est pratiquement plus nécessaire.

+
#
+# The following directives modify normal HTTP response behavior.
+# The first directive disables keepalive for Netscape 2.x and browsers that
+# spoof it. There are known problems with these browser implementations.
+# The second directive is for Microsoft Internet Explorer 4.0b2
+# which has a broken HTTP/1.1 implementation and does not properly
+# support keepalive when it is used on 301 or 302 (redirect) responses.
+#
+BrowserMatch "Mozilla/2" nokeepalive
+BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0
+
+#
+# The following directive disables HTTP/1.1 responses to browsers which
+# are in violation of the HTTP/1.0 spec by not being able to grok a
+# basic 1.1 response.
+#
+BrowserMatch "RealPlayer 4\.0" force-response-1.0
+BrowserMatch "Java/1\.0" force-response-1.0
+BrowserMatch "JDK/1\.0" force-response-1.0
+ + + +

Ne pas tracer les requêtes pour des images dans le fichier de + trace des accès

+ + +

Dans cet exemple, les requêtes pour des images n'apparaissent pas + dans le fichier de trace des accès. Il peut être facilement adapté pour + empêcher le traçage de répertoires particuliers, ou de requêtes + en provenance de certains hôtes.

+ 
SetEnvIf Request_URI \.gif image-request
+SetEnvIf Request_URI \.jpg image-request
+SetEnvIf Request_URI \.png image-request
+CustomLog "logs/access_log" common env=!image-request
+ + + +

Prévention du "Vol d'image"

+ + +

Cet exemple montre comment empêcher les utilisateurs ne faisant pas + partie de votre serveur d'utiliser des images de votre serveur comme + images en ligne dans leurs pages. Cette configuration n'est pas + recommandée, mais elle peut fonctionner dans des circonstances bien + définies. Nous supposons que toutes vos images sont enregistrées dans + un répertoire nommé /web/images.

+ 
SetEnvIf Referer "^http://www\.example\.com/" local_referal
+# Autorise les navigateurs qui n'envoient aucune information de Referer
+SetEnvIf Referer "^$" local_referal
+<Directory "/web/images">
+    Require env local_referal
+</Directory>
+ + +

Pour plus d'informations sur cette technique, voir le tutoriel sur + ServerWatch + "Keeping Your Images from Adorning Other Sites".

+ +
+
+

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

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/expr.html.en b/docs/manual/expr.html.en index 1d348b9083..d3425071e3 100644 --- a/docs/manual/expr.html.en +++ b/docs/manual/expr.html.en @@ -24,7 +24,7 @@ Apache > HTTP Server > Documentation > Version 2.5

Expressions in Apache HTTP Server

Available Languages:  en  | - fr 

+ fr 

Historically, there are several syntax variants for expressions @@ -720,7 +720,7 @@ CustomLog logs/access-errors-specific.log common "expr=%{REQUEST_STATUS} -in {'4

Available Languages:  en  | - fr 

+ fr 

top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
- - -
-

Modules | Directives | FAQ | Glossaire | Plan du site

-

Serveur HTTP Apache Version 2.5

-
-
<-
-

Les expressions dans le serveur HTTP Apache

-
-

Langues Disponibles:  en  | - fr 

-
- -

Historiquement, il existe de nombreuses variantes dans la syntaxe - des expressions permettant d'exprimer une condition dans les - différents modules du serveur HTTP Apache. À ce titre, des travaux sont - en cours pour n'utiliser qu'une seule variante nommée - ap_expr, pour toutes les directives de configuration. Ce - document décrit l'interpréteur d'expressions ap_expr. -

-

Le type d'expression ap_expr est appelé à remplacer la - plupart des autres types d'expressions dans HTTPD. Par exemple, la - directive obsolète SSLRequire peut être remplacée par la - directive Require - expr. -

-
- -
top
-
-

Syntaxe en Forme de Backus-Naur

- -

La Forme de Backus-Naur - (souvent abrégée en BNF, de l'anglais Backus-Naur Form) est une notation permettant de décrire - les règles syntaxiques des langages de programmation. En - général, les expressions représentent des valeurs booléennes. Dans - ce cas, le point de départ de la BNF est cond. - Les directives comme - ErrorDocument, - Require, - AuthName, - Redirect, - Header, - CryptoKey ou - LogMessage utilisent comme - paramètres des expressions qui représentent des chaînes de - caractères. Dans ce cas, le point de départ de la BNF est - string. -

-
-
expr        ::= cond
-              | string
-
-string      ::= substring
-              | string substring
-
-cond        ::= "true" 
-              | "false"
-              | "!" cond
-              | cond "&&" cond
-              | cond "||" cond
-              | comp
-	      | "(" cond ")"
-
-comp        ::= stringcomp
-              | integercomp
-              | unaryop word
-              | word binaryop word
-              | word "in" listfunc
-              | word "=~" regex
-              | word "!~" regex
-	      | word "in" "{" list "}"
-
-
-stringcomp  ::= word "==" word
-              | word "!=" word
-              | word "<"  word
-              | word "<=" word
-              | word ">"  word
-              | word ">=" word
-
-integercomp ::= word "-eq" word | word "eq" word
-              | word "-ne" word | word "ne" word
-              | word "-lt" word | word "lt" word
-              | word "-le" word | word "le" word
-              | word "-gt" word | word "gt" word
-              | word "-ge" word | word "ge" word
-
-word        ::= digits
-              | "'" string "'"
-              | '"' string '"'
-              | word "." word
-              | variable
-	      | sub
-              | join
-              | function
-	      | "(" word ")"
-
-list        ::= split
-              | listfunc
-              | "{" words "}"
-              | "(" list ")"
-
-substring   ::= cstring
-              | variable
-
-
-variable    ::= "%{" varname "}"
-              | "%{" funcname ":" funcargs "}"
-	      | "%{:" word ":}"
-              | "%{:" cond ":}"
-              | rebackref
-
-sub         ::= "sub" ["("] regsub "," word [")"]
-
-join        ::= "join" ["("] list [")"]
-              | "join" ["("] list "," word [")"]
-
-split       ::= "split" ["("] regany "," list [")"]
-              | "split" ["("] regany "," word [")"]
-
-function    ::= funcname "(" words ")"
-
-listfunc    ::= listfuncname "(" words ")"
-
-words       ::= word
-              | word "," list
-
-regex       ::= "/" regpattern "/" [regflags]
-              | "m" regsep regpattern regsep [regflags]
-
-regsub      ::= "s" regsep regpattern regsep string regsep [regflags]
-
-regany      ::= regex | regsub
-
-regsep      ::= "/" | "#" | "$" | "%" | "^" | "|" | "?" | "!" | "'" | '"' | "," | ";" | ":" | "." | "_" | "-"
-
-regflags    ::= 1*("i" | "s" | "m" | "g")
-regpattern  ::= cstring ; except enclosing regsep
-
-rebackref   ::= "$" DIGIT
-
-digits      ::= 1*(DIGIT)
-cstring     ::= 0*(TEXT)
-
-TEXT        ::= <any OCTET except CTLs>
-DIGIT       ::= <any US-ASCII digit "0".."9">
-
-
top
-
-

Variables

- - -

L'interpréteur d'expressions fournit plusieurs variables de la - forme %{HTTP_HOST}. Notez que la valeur d'une variable - peut dépendre de la phase du traitement de la requête au cours de - laquelle elle est évaluée. Par exemple, une expression utilisée dans - une directive <If > sera évaluée avant - la phase d'authentification. Par conséquent, la variable - %{REMOTE_USER} ne sera pas encore définie à ce stade.

- -

Les variables suivantes contiennent la valeur de l'en-tête de - requête HTTP correspondant. La fonction - req permet d'extraire les valeurs des autres - en-têtes. L'utilisation de ces variables peut provoquer - l'ajout du nom d'en-tête correspondant à l'en-tête Vary de la - réponse HTTP, sauf spécification contraire pour la directive - qui accepte l'expression comme paramètre. La function req_novary permet de - modifier ce comportement.

- - - - - - - - - -
Nom
HTTP_ACCEPT
HTTP_COOKIE
HTTP_FORWARDED
HTTP_HOST
HTTP_PROXY_CONNECTION
HTTP_REFERER
HTTP_USER_AGENT
- -

Autres variables liées aux requêtes

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NomDescription
REQUEST_METHODLa méthode HTTP de la requête entrante (par exemple - GET)
REQUEST_SCHEMELe protocole associé à l'URI de la requête
REQUEST_URILa partie chemin de l'URI de la requête
DOCUMENT_URIIdem REQUEST_URI
REQUEST_FILENAMELe chemin complet dans le système de fichiers local du - fichier ou du script correspondant à la requête, si le serveur - l'a dèjà déterminé à l'instant où REQUEST_FILENAME - est référencée. Dans le cas contraire, comme dans un - contexte de serveur virtuel, même valeur que REQUEST_URI
SCRIPT_FILENAMEIdentique à REQUEST_FILENAME
LAST_MODIFIEDLa date et heure de dernière modification du fichier au - format 20101231235959, si elle est déjà connue du - serveur au moment où LAST_MODIFIED est référencé. -
SCRIPT_USERLe nom d'utilisateur du propriétaire du script.
SCRIPT_GROUPLe nom du groupe auquel appartient le script.
PATH_INFOL'information relative au nom de chemin située en fin, voir - la directive AcceptPathInfo
QUERY_STRINGLa chaîne de paramètres de la requête courante
IS_SUBREQ"true" si la requête courante est une - sous-requête, "false" dans le cas contraire
THE_REQUESTLa requête complète (par exemple "GET /index.html - HTTP/1.1")
REMOTE_ADDRL'adresse IP de l'hôte distant
REMOTE_PORTLe port de l'hôte distant (à partir de la version 2.4.26)
REMOTE_HOSTLe nom d'hôte de l'hôte distant
REMOTE_USERLe nom de l'utilisateur authentifié, s'il existe (non - disponible à l'intérieur d'un bloc <If>)
REMOTE_IDENTLe nom de l'utilisateur défini par mod_ident
SERVER_NAMELa valeur de la directive ServerName du serveur virtuel courant
SERVER_PORTLe port associé au serveur virtuel courant ; voir la - directive ServerName
SERVER_ADMINLa valeur de la directive ServerAdmin du serveur virtuel courant
SERVER_PROTOCOLLe protocole utilisé par la requête (par - exemple HTTP/1.1). Avec certains types de sous-requêtes - internes, cette variable prend la valeur INCLUDED.
SERVER_PROTOCOL_VERSIONUn nombre qui représente la version HTTP de la requête : - 1000 * major + minor. Par exemple, - 1001 correspond à HTTP/1.1 et 9 à - HTTP/0.9.
SERVER_PROTOCOL_VERSION_MAJORLa partie majeure de la version HTTP de la requête, par - exemple 1 pour HTTP/1.0.
SERVER_PROTOCOL_VERSION_MINORLa partie mineure de la version HTTP de la requête, par - exemple 0 pour HTTP/1.0.
DOCUMENT_ROOTLa valeur de la directive DocumentRoot du serveur virtuel - courant
AUTH_TYPELa valeur de la directive AuthType (par exemple - "basic")
CONTENT_TYPELe type de contenu de la réponse (non - disponible à l'intérieur d'un bloc <If>)
HANDLERLe nom du gestionnaire qui a - généré la réponse
HTTP2"on" si la requête utilise http/2, - "off" dans le cas contraire
HTTPS"on" si la requête utilise https, - "off" dans le cas contraire
IPV6"on" si la connexion utilise IPv6, - "off" dans le cas contraire
REQUEST_STATUSLe code d'erreur HTTP de la requête (non - disponible à l'intérieur d'un bloc <If>)
REQUEST_LOG_IDL'identifiant du message d'erreur associé à la requête (voir - la directive ErrorLogFormat)
CONN_LOG_IDL'identifiant du message d'erreur associé à la connexion - (voir la directive ErrorLogFormat)
CONN_REMOTE_ADDRL'adresse IP du correspondant pour la connexion (voir le module - mod_remoteip)
CONTEXT_PREFIX
CONTEXT_DOCUMENT_ROOT
- -

Variables diverses

- - - - - - - - - - - - - - - - - - - - - - -
NomDescription
TIME_YEARL'année courante (par exemple 2010)
TIME_MONLe mois courant (01, ..., 12)
TIME_DAYLe jour courant dans le mois (01, ...)
TIME_HOURLes heures de la date courante (00, ..., - 23)
TIME_MINLes minutes de la date courante
TIME_SECLes secondes de la date courante
TIME_WDAYLe jour de la semaine (à partir de 0 pour - dimanche)
TIMELa date et heure au format 20101231235959
SERVER_SOFTWARELa chaîne contenant la version du serveur
API_VERSIONLa date de la version de l'API (module magic number)
- -

Certains modules, comme mod_ssl, définissent des - variables supplémentaires.

- -

Toute variable peut être insérée dans une chaîne, et ceci non - seulement dans les chaînes entre quotes des expressions booléennes, mais - aussi dans les expressions littérales issues de la concaténation de chaînes - constantes et dynamiques.

- -

On peut utiliser ici les variables (temporaires) du style - %{:word:} qui permettent d'insérer dans les deux types - d'expressions des variables (et des constructions) avec la syntaxe puissante - word sans entrer en conflit avec les parties constantes de telles - chaînes. Même si la syntaxe word est directement utilisable au sein - des expressions booléennes, ces variables sont cependant surtout utiles dans - les expressions littérales. Ces variables permettent d'évaluer des - expressions rationnelles, des substitutions, de concaténer ou dissocier des - chaînes et des listes au sein des expressions littérales, et donc de - construire des chaînes complexes dynamiquement.

- -
top
-
-

Opérateurs binaires

- - -

À l'exception de quelques opérateurs de comparaison internes, les - opérateurs binaires sont de la forme - "-[a-zA-Z][a-zA-Z0-9_]+", autrement dit un signe moins - et au moins deux caractères. Le nom est insensible à la casse. Les - modules peuvent fournir des opérateurs binaires supplémentaires.

- -

Opérateurs de comparaison

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NomAlternative Description
===Egalité de chaînes
!= - Inégalité de chaînes
< - Chaîne inférieure à
<= - Chaîne inférieure ou égale à
> - Chaîne supérieure à
>= - Chaîne supérieure ou égale à
=~ - La chaîne correspond à l'expression rationnelle
!~ - La chaîne ne correspond pas à l'expression rationnelle
-eqeqEgalité d'entiers
-neneInégalité d'entiers
-ltltEntier inférieur à
-leleEntier inférieur ou égal à
-gtgtEntier supérieur à
-gegeEntier supérieur ou égal à
- - -

Autres opérateurs binaires

- - - - - - - - - - - -
NomDescription
-ipmatchL'adresse IP correspond à adresse/masque
-strmatchla chaîne de gauche correspond au modèle constitué par la - chaîne de droite (contenant des caractères génériques *, ?, [])
-strcmatchidem -strmatch, mais insensible à la casse
-fnmatchidem -strmatch, mais les slashes ne sont pas - pris en compte par les caractères génériques
- - -
top
-
-

Opérateurs unaires

- - -

Les opérateurs unaires acceptent un seul argument et sont - de la forme "-[a-zA-Z]", - autrement dit le signe moins et un caractère. Le nom est - sensible à la casse. Les modules peuvent fournir des opérateurs - unaires supplémentaires.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NomDescriptionRestreint
-dL'argument est traité comme un nom de fichier. - Vrai si le fichier existe et correspond à un - répertoireoui
-eL'argument est traité comme un nom de fichier. Vrai si le - fichier (ou dir ou special) existeoui
-fL'argument est traité comme un nom de fichier. Vrai si le - fichier existe et correspond à un fichier - régulieroui
-sL'argument est traité comme un nom de fichier. Vrai si le - fichier existe et n'est pas videoui
-LL'argument est traité comme un nom de fichier. Vrai si le - fichier existe et correspond à un lien - symboliqueoui
-hL'argument est traité comme un nom de fichier. Vrai si le - fichier existe et correspond à un lien symbolique - (identique à -L)oui
-FVrai si la chaîne correspond a un fichier valide, accessible - avec tous les contrôles d'accès configurés pour ce chemin. A - cette fin, une sous-requête effectue la vérification, et vous - devez utiliser ce drapeau avec soin car il peut impacter les - performances de votre serveur !
-UVrai si la chaîne correspond a une URL valide, accessible - avec tous les contrôles d'accès configurés pour ce chemin. A - cette fin, une sous-requête effectue la vérification, et vous - devez utiliser ce drapeau avec soin car il peut impacter les - performances de votre serveur !
-AAlias pour -U
-nVrai si la chaîne n'est pas vide
-zVrai si la chaîne est vide
-TFaux si la chaîne est vide, "0", - "off", "false", ou "no" - (insensibilité à la casse). Vrai dans le cas contraire.
-RIdem "%{REMOTE_ADDR} -ipmatch ...", en plus - efficace -
- -

Les opérateurs marqués comme "restreints" ne sont pas disponibles - avec certains modules comme mod_include.

- -
top
-
-

Fonctions

- - -

Normalement, les fonctions dont la valeur est une chaîne acceptent une chaîne - comme argument et renvoient une chaîne. Les noms de fonctions sont - insensibles à la casse. Les modules peuvent fournir des fonctions - supplémentaires.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NomDescriptionRemarques particulières
req, httpLit l'en-tête de requête HTTP ; les noms - d'en-tête correspondants peuvent être ajoutés à l'en-tête Vary, - voir ci-dessous
req_novaryIdentique à req, mais les noms - d'en-tête correspondants ne seront pas ajoutés à l'en-tête Vary
respLit l'en-tête de réponse HTTP (la plupart des - en-tête de la réponse ne sont pas encore définis pendant - l'exécution de la directive <If>)
reqenvRecherche une variable d'environnement de requête (on - peut aussi utiliser le raccourci v). - ordonnancement
osenvRecherche une variable d'environnement du système - d'exploitation
noteRecherche une note de requêteordonnancement
envRenvoie le premier résultat positif de note, - reqenv, osenvordonnancement
tolowerConvertit une chaîne en minuscules
toupperConvertit une chaîne en majuscules
escapeEchappe les caractères spéciaux en codage hexadécimal
unescape"Déséchappe" les chaînes codées - en hexadécimal, en ne gardant encodés que les slashes; renvoie la chaîne vide - si la séquence %00 est rencontrée
base64Encode la chaîne en utilisant le codage base64
unbase64Décode une chaîne codée en base64, renvoie une chaîne - tronquée si le caractère 0x00 est rencontré
md5Effectue un hashage MD5 de la chaîne, puis encode le hash - avec un codage hexadécimal
sha1Effectue un hashage SHA1 de la chaîne, puis encode le hash - avec un codage hexadécimal
fileLit le contenu d'un fichier (fins de lignes incluses, si - elles existent)limité
filemodRenvoie la date de dernière modification d'un fichier (ou 0 - si le fichier n'existe pas ou n'est pas un fichier - régulier)limité
filesizeRenvoie la taille d'un fichier (ou 0 si le fichier n'existe - pas ou ne correspond pas à un fichier - régulier)limité
ldapEchappe les caractères selon la RFC4514 (Echappement des - noms distinctifs LDAP - DN) et la RFC4515 (Echappement des - filtres LDAP).
replacereplace(chaîne, "de", "vers") remplace dans la chaîne - spécifiée toutes les occurrences de "de" par "vers".
- -

Les fonctions marquées comme "limité" dans la dernière colonne ne sont - pas disponibles avec certains modules comme - mod_include.

- -

Les fonctions marquées comme "ordonnancement" dans la dernière colonne - nécessitent une attention particulière pour l'ordonnancement des différents - composants du serveur, spécialement lorsque la fonction est utilisée au sein - d'une directive <If> qui est - évaluée relativement tôt.

-
-

Ordonnancement des variables d'environnement

- Lorsque des variables d'environnement sont évaluées au sein d'une directive - <If>, il est important de tenir - compte du moment où cette évaluation intervient dans le traitement de la - requête. Par exemple, toute directive définie en dehors d'un contexte de - serveur virtuel (directory, location, htaccess) aura peu de chance d'être - déjà exécutée. Ainsi la directive SetEnvIf est une directive qui s'exécute - avant cette évaluation. -
-
- Lorsque reqenv est utilisé en dehors de la directive - <If>, l'évaluation survient en - général plus tard, mais le moment exact dépend de la directive dans laquelle - l'expression a été utilisée. -
- -

Lorsque les fonctions req ou http sont - utilisées, le nom d'en-tête sera automatiquement ajouté à l'en-tête - Vary de la réponse HTTP, sauf spécification contraire pour la - directive qui accepte l'expression comme paramètre. La fonction - req_novary permet d'empêcher cet ajout.

- -

En plus des fonctions dont la valeur est une chaîne, il existe - aussi des fonctions dont la valeur est une liste, qui acceptent une - chaîne comme argument, et renvoient une liste , par exemple - une liste de chaînes. La liste peut être utilisée avec - l'opérateur spécial -in. Les noms de fonctions sont - insensibles à la casse. Les modules peuvent fournir des fonctions - supplémentaires.

- -

Il n'existe pas de fonctions internes dont la valeur est une - liste. Le module mod_ssl fournit la fonction - PeerExtList. Voir la description de la directive - SSLRequire pour plus de - détails (notez que la fonction PeerExtList peut aussi - être utilisée en dehors de la directive SSLRequire).

- -
top
-
-

Exemples d'expressions

- - -

Les exemples suivants montent comment utiliser les - expressions pour évaluer les requêtes :

- - 
# Comparer le nom d'hôte avec example.com et rediriger vers
-# www.example.com si le nom d'hôte correspond
-<If "%{HTTP_HOST} == 'example.com'">
-    Redirect permanent "/" "http://www.example.com/"
-</If>
-
-# Forcer le type text/plain si un fichier fait l'objet d'une
-# requête dont la chaîne de paramètres contient 'forcetext'
-<If "%{QUERY_STRING} =~ /forcetext/">
-    ForceType text/plain
-</If>
-
-# N'autoriser l'accès à ce contenu que pendant les heures de
-# travail
-<Directory "/foo/bar/business">
-     Require expr %{TIME_HOUR} -gt 9 && %{TIME_HOUR} -lt 17
-</Directory>	
-
-# Vérifie si un en-tête HTTP correspond à une des valeurs d'une liste
-<If "%{HTTP:X-example-header} in { 'foo', 'bar', 'baz' }">
-    La définition de l'en-tête correspond à une des valeurs recherchées
-</If>
-# Recherche la valeur d'une expression rationnelle dans une variable
-# d'environnement, et renvoie la négation du résultat.
-<If "! reqenv('REDIRECT_FOO') =~ /bar/">
-    La condition est vérifiée
-</If>
-
-# Vérifie le résultat de la recherche d'une correspondance d'URI dans un
-# contexte de répertoire avec l'option -f
-<Directory "/var/www">
-    AddEncoding x-gzip gz
-<If "-f '%{REQUEST_FILENAME}.unzipme' && ! %{HTTP:Accept-Encoding} =~ /gzip/">
-      SetOutputFilter INFLATE
-</If>
-</Directory>
-
-# Vérifie l'adresse IP du client
-<If "-R '192.168.1.0/24'">
-    Header set matched true
-</If>
-
-# Exemples de fonctions dans un contexte booléen
-<If "md5('foo') == 'acbd18db4cc2f85cedef654fccc4a4d8'">
-  Header set checksum-matched true
-</If>
-<If "md5('foo') == replace('md5:XXXd18db4cc2f85cedef654fccc4a4d8', 'md5:XXX', 'acb')>
-  Header set checksum-matched-2 true
-</If>
-
-
-# Exemple de fonction dans un contexte littéral
-Header set foo-checksum "expr=%{md5:foo}"
-
-# L'exemple suivant retarde l'évaluation de la clause de condition par rapport à
-# <If>
-Header always set CustomHeader my-value "expr=%{REQUEST_URI} =~
-m#^/special_path\.php$#"
-
-# Ajoute un en-tête permettant d'acheminer le SAN du certificat d'un client vers
-# un quelconque serveur d'arrière-plan
-RequestHeader set X-Client-SAN "expr=%{:join PeerExtList('subjectAltName'):}"
-
-# Impose la présence de l'adresse IP distante dans le SAN du certificat d'un client
-Require expr %{REMOTE_ADDR} -in split s/.*?IP Address:([^,]+)/$1/, PeerExtList('subjectAltName')
-# autre solution :
-Require expr "IP Address:%{REMOTE_ADDR}" -in split/, /, join PeerExtList('subjectAltName')
-
-# Journalisation conditionnelle
-CustomLog logs/access-errors.log common "expr=%{REQUEST_STATUS} >= 400"
-CustomLog logs/access-errors-specific.log common "expr=%{REQUEST_STATUS} -in {'405','410'}"
- -
top
-
-

Autres

- - - - - - - - - - - - - - -
NomAlternative Description
-ininchaîne contenue dans une liste
/regexp/m#regexp#Expression rationnelle (la seconde forme permet de spécifier - des délimiteurs autres que /)
/regexp/im#regexp#iExpression rationnelle insensible à la casse
$0 ... $9 - Références arrières dans les expressions rationnelles
- -

Références arrières dans les expressions rationnelles

- -

Les chaînes $0 ... $9 permettent de - référencer les groupes de capture en provenance d'expressions - rationnelles précédemment exécutées et mises en correspondance avec - succès. Elles ne peuvent normalement être utilisées que dans la - même expression que celle mise en correspondance, mais certains - modules permettent de les utiliser de manière spéciale.

- - -
top
-
-

Comparaison avec SSLRequire

- -

La syntaxe ap_expr consiste principalement en une - surcouche de la syntaxe de la directive obsolète SSLRequire. Vous pouvez consulter la - liste de leur différences dans la documentation de la directive - SSLRequire.

-
top
-
-

Historique de version

- -

La fonction req_novary est - disponible à partir de la version 2.4.4 du serveur HTTP Apache.

-

Les variables - SERVER_PROTOCOL_VERSION, - SERVER_PROTOCOL_VERSION_MAJOR et - SERVER_PROTOCOL_VERSION_MINOR sont disponibles à partir - de la version 2.5.0 du serveur HTTP Apache.

-
-
-

Langues Disponibles:  en  | - fr 

-
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
-
- \ No newline at end of file diff --git a/docs/manual/expr.html.fr.utf8 b/docs/manual/expr.html.fr.utf8 new file mode 100644 index 0000000000..3658c736b1 --- /dev/null +++ b/docs/manual/expr.html.fr.utf8 @@ -0,0 +1,787 @@ + + + + + +Les expressions dans le serveur HTTP Apache - Serveur HTTP Apache Version 2.5 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.5

+
+
<-
+

Les expressions dans le serveur HTTP Apache

+
+

Langues Disponibles:  en  | + fr 

+
+ +

Historiquement, il existe de nombreuses variantes dans la syntaxe + des expressions permettant d'exprimer une condition dans les + différents modules du serveur HTTP Apache. À ce titre, des travaux sont + en cours pour n'utiliser qu'une seule variante nommée + ap_expr, pour toutes les directives de configuration. Ce + document décrit l'interpréteur d'expressions ap_expr. +

+

Le type d'expression ap_expr est appelé à remplacer la + plupart des autres types d'expressions dans HTTPD. Par exemple, la + directive obsolète SSLRequire peut être remplacée par la + directive Require + expr. +

+
+ +
top
+
+

Syntaxe en Forme de Backus-Naur

+ +

La Forme de Backus-Naur + (souvent abrégée en BNF, de l'anglais Backus-Naur Form) est une notation permettant de décrire + les règles syntaxiques des langages de programmation. En + général, les expressions représentent des valeurs booléennes. Dans + ce cas, le point de départ de la BNF est cond. + Les directives comme + ErrorDocument, + Require, + AuthName, + Redirect, + Header, + CryptoKey ou + LogMessage utilisent comme + paramètres des expressions qui représentent des chaînes de + caractères. Dans ce cas, le point de départ de la BNF est + string. +

+
+
expr        ::= cond
+              | string
+
+string      ::= substring
+              | string substring
+
+cond        ::= "true" 
+              | "false"
+              | "!" cond
+              | cond "&&" cond
+              | cond "||" cond
+              | comp
+	      | "(" cond ")"
+
+comp        ::= stringcomp
+              | integercomp
+              | unaryop word
+              | word binaryop word
+              | word "in" listfunc
+              | word "=~" regex
+              | word "!~" regex
+	      | word "in" "{" list "}"
+
+
+stringcomp  ::= word "==" word
+              | word "!=" word
+              | word "<"  word
+              | word "<=" word
+              | word ">"  word
+              | word ">=" word
+
+integercomp ::= word "-eq" word | word "eq" word
+              | word "-ne" word | word "ne" word
+              | word "-lt" word | word "lt" word
+              | word "-le" word | word "le" word
+              | word "-gt" word | word "gt" word
+              | word "-ge" word | word "ge" word
+
+word        ::= digits
+              | "'" string "'"
+              | '"' string '"'
+              | word "." word
+              | variable
+	      | sub
+              | join
+              | function
+	      | "(" word ")"
+
+list        ::= split
+              | listfunc
+              | "{" words "}"
+              | "(" list ")"
+
+substring   ::= cstring
+              | variable
+
+
+variable    ::= "%{" varname "}"
+              | "%{" funcname ":" funcargs "}"
+	      | "%{:" word ":}"
+              | "%{:" cond ":}"
+              | rebackref
+
+sub         ::= "sub" ["("] regsub "," word [")"]
+
+join        ::= "join" ["("] list [")"]
+              | "join" ["("] list "," word [")"]
+
+split       ::= "split" ["("] regany "," list [")"]
+              | "split" ["("] regany "," word [")"]
+
+function    ::= funcname "(" words ")"
+
+listfunc    ::= listfuncname "(" words ")"
+
+words       ::= word
+              | word "," list
+
+regex       ::= "/" regpattern "/" [regflags]
+              | "m" regsep regpattern regsep [regflags]
+
+regsub      ::= "s" regsep regpattern regsep string regsep [regflags]
+
+regany      ::= regex | regsub
+
+regsep      ::= "/" | "#" | "$" | "%" | "^" | "|" | "?" | "!" | "'" | '"' | "," | ";" | ":" | "." | "_" | "-"
+
+regflags    ::= 1*("i" | "s" | "m" | "g")
+regpattern  ::= cstring ; except enclosing regsep
+
+rebackref   ::= "$" DIGIT
+
+digits      ::= 1*(DIGIT)
+cstring     ::= 0*(TEXT)
+
+TEXT        ::= <any OCTET except CTLs>
+DIGIT       ::= <any US-ASCII digit "0".."9">
+
+
top
+
+

Variables

+ + +

L'interpréteur d'expressions fournit plusieurs variables de la + forme %{HTTP_HOST}. Notez que la valeur d'une variable + peut dépendre de la phase du traitement de la requête au cours de + laquelle elle est évaluée. Par exemple, une expression utilisée dans + une directive <If > sera évaluée avant + la phase d'authentification. Par conséquent, la variable + %{REMOTE_USER} ne sera pas encore définie à ce stade.

+ +

Les variables suivantes contiennent la valeur de l'en-tête de + requête HTTP correspondant. La fonction + req permet d'extraire les valeurs des autres + en-têtes. L'utilisation de ces variables peut provoquer + l'ajout du nom d'en-tête correspondant à l'en-tête Vary de la + réponse HTTP, sauf spécification contraire pour la directive + qui accepte l'expression comme paramètre. La function req_novary permet de + modifier ce comportement.

+ + + + + + + + + +
Nom
HTTP_ACCEPT
HTTP_COOKIE
HTTP_FORWARDED
HTTP_HOST
HTTP_PROXY_CONNECTION
HTTP_REFERER
HTTP_USER_AGENT
+ +

Autres variables liées aux requêtes

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NomDescription
REQUEST_METHODLa méthode HTTP de la requête entrante (par exemple + GET)
REQUEST_SCHEMELe protocole associé à l'URI de la requête
REQUEST_URILa partie chemin de l'URI de la requête
DOCUMENT_URIIdem REQUEST_URI
REQUEST_FILENAMELe chemin complet dans le système de fichiers local du + fichier ou du script correspondant à la requête, si le serveur + l'a dèjà déterminé à l'instant où REQUEST_FILENAME + est référencée. Dans le cas contraire, comme dans un + contexte de serveur virtuel, même valeur que REQUEST_URI
SCRIPT_FILENAMEIdentique à REQUEST_FILENAME
LAST_MODIFIEDLa date et heure de dernière modification du fichier au + format 20101231235959, si elle est déjà connue du + serveur au moment où LAST_MODIFIED est référencé. +
SCRIPT_USERLe nom d'utilisateur du propriétaire du script.
SCRIPT_GROUPLe nom du groupe auquel appartient le script.
PATH_INFOL'information relative au nom de chemin située en fin, voir + la directive AcceptPathInfo
QUERY_STRINGLa chaîne de paramètres de la requête courante
IS_SUBREQ"true" si la requête courante est une + sous-requête, "false" dans le cas contraire
THE_REQUESTLa requête complète (par exemple "GET /index.html + HTTP/1.1")
REMOTE_ADDRL'adresse IP de l'hôte distant
REMOTE_PORTLe port de l'hôte distant (à partir de la version 2.4.26)
REMOTE_HOSTLe nom d'hôte de l'hôte distant
REMOTE_USERLe nom de l'utilisateur authentifié, s'il existe (non + disponible à l'intérieur d'un bloc <If>)
REMOTE_IDENTLe nom de l'utilisateur défini par mod_ident
SERVER_NAMELa valeur de la directive ServerName du serveur virtuel courant
SERVER_PORTLe port associé au serveur virtuel courant ; voir la + directive ServerName
SERVER_ADMINLa valeur de la directive ServerAdmin du serveur virtuel courant
SERVER_PROTOCOLLe protocole utilisé par la requête (par + exemple HTTP/1.1). Avec certains types de sous-requêtes + internes, cette variable prend la valeur INCLUDED.
SERVER_PROTOCOL_VERSIONUn nombre qui représente la version HTTP de la requête : + 1000 * major + minor. Par exemple, + 1001 correspond à HTTP/1.1 et 9 à + HTTP/0.9.
SERVER_PROTOCOL_VERSION_MAJORLa partie majeure de la version HTTP de la requête, par + exemple 1 pour HTTP/1.0.
SERVER_PROTOCOL_VERSION_MINORLa partie mineure de la version HTTP de la requête, par + exemple 0 pour HTTP/1.0.
DOCUMENT_ROOTLa valeur de la directive DocumentRoot du serveur virtuel + courant
AUTH_TYPELa valeur de la directive AuthType (par exemple + "basic")
CONTENT_TYPELe type de contenu de la réponse (non + disponible à l'intérieur d'un bloc <If>)
HANDLERLe nom du gestionnaire qui a + généré la réponse
HTTP2"on" si la requête utilise http/2, + "off" dans le cas contraire
HTTPS"on" si la requête utilise https, + "off" dans le cas contraire
IPV6"on" si la connexion utilise IPv6, + "off" dans le cas contraire
REQUEST_STATUSLe code d'erreur HTTP de la requête (non + disponible à l'intérieur d'un bloc <If>)
REQUEST_LOG_IDL'identifiant du message d'erreur associé à la requête (voir + la directive ErrorLogFormat)
CONN_LOG_IDL'identifiant du message d'erreur associé à la connexion + (voir la directive ErrorLogFormat)
CONN_REMOTE_ADDRL'adresse IP du correspondant pour la connexion (voir le module + mod_remoteip)
CONTEXT_PREFIX
CONTEXT_DOCUMENT_ROOT
+ +

Variables diverses

+ + + + + + + + + + + + + + + + + + + + + + +
NomDescription
TIME_YEARL'année courante (par exemple 2010)
TIME_MONLe mois courant (01, ..., 12)
TIME_DAYLe jour courant dans le mois (01, ...)
TIME_HOURLes heures de la date courante (00, ..., + 23)
TIME_MINLes minutes de la date courante
TIME_SECLes secondes de la date courante
TIME_WDAYLe jour de la semaine (à partir de 0 pour + dimanche)
TIMELa date et heure au format 20101231235959
SERVER_SOFTWARELa chaîne contenant la version du serveur
API_VERSIONLa date de la version de l'API (module magic number)
+ +

Certains modules, comme mod_ssl, définissent des + variables supplémentaires.

+ +

Toute variable peut être insérée dans une chaîne, et ceci non + seulement dans les chaînes entre quotes des expressions booléennes, mais + aussi dans les expressions littérales issues de la concaténation de chaînes + constantes et dynamiques.

+ +

On peut utiliser ici les variables (temporaires) du style + %{:word:} qui permettent d'insérer dans les deux types + d'expressions des variables (et des constructions) avec la syntaxe puissante + word sans entrer en conflit avec les parties constantes de telles + chaînes. Même si la syntaxe word est directement utilisable au sein + des expressions booléennes, ces variables sont cependant surtout utiles dans + les expressions littérales. Ces variables permettent d'évaluer des + expressions rationnelles, des substitutions, de concaténer ou dissocier des + chaînes et des listes au sein des expressions littérales, et donc de + construire des chaînes complexes dynamiquement.

+ +
top
+
+

Opérateurs binaires

+ + +

À l'exception de quelques opérateurs de comparaison internes, les + opérateurs binaires sont de la forme + "-[a-zA-Z][a-zA-Z0-9_]+", autrement dit un signe moins + et au moins deux caractères. Le nom est insensible à la casse. Les + modules peuvent fournir des opérateurs binaires supplémentaires.

+ +

Opérateurs de comparaison

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NomAlternative Description
===Egalité de chaînes
!= + Inégalité de chaînes
< + Chaîne inférieure à
<= + Chaîne inférieure ou égale à
> + Chaîne supérieure à
>= + Chaîne supérieure ou égale à
=~ + La chaîne correspond à l'expression rationnelle
!~ + La chaîne ne correspond pas à l'expression rationnelle
-eqeqEgalité d'entiers
-neneInégalité d'entiers
-ltltEntier inférieur à
-leleEntier inférieur ou égal à
-gtgtEntier supérieur à
-gegeEntier supérieur ou égal à
+ + +

Autres opérateurs binaires

+ + + + + + + + + + + +
NomDescription
-ipmatchL'adresse IP correspond à adresse/masque
-strmatchla chaîne de gauche correspond au modèle constitué par la + chaîne de droite (contenant des caractères génériques *, ?, [])
-strcmatchidem -strmatch, mais insensible à la casse
-fnmatchidem -strmatch, mais les slashes ne sont pas + pris en compte par les caractères génériques
+ + +
top
+
+

Opérateurs unaires

+ + +

Les opérateurs unaires acceptent un seul argument et sont + de la forme "-[a-zA-Z]", + autrement dit le signe moins et un caractère. Le nom est + sensible à la casse. Les modules peuvent fournir des opérateurs + unaires supplémentaires.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NomDescriptionRestreint
-dL'argument est traité comme un nom de fichier. + Vrai si le fichier existe et correspond à un + répertoireoui
-eL'argument est traité comme un nom de fichier. Vrai si le + fichier (ou dir ou special) existeoui
-fL'argument est traité comme un nom de fichier. Vrai si le + fichier existe et correspond à un fichier + régulieroui
-sL'argument est traité comme un nom de fichier. Vrai si le + fichier existe et n'est pas videoui
-LL'argument est traité comme un nom de fichier. Vrai si le + fichier existe et correspond à un lien + symboliqueoui
-hL'argument est traité comme un nom de fichier. Vrai si le + fichier existe et correspond à un lien symbolique + (identique à -L)oui
-FVrai si la chaîne correspond a un fichier valide, accessible + avec tous les contrôles d'accès configurés pour ce chemin. A + cette fin, une sous-requête effectue la vérification, et vous + devez utiliser ce drapeau avec soin car il peut impacter les + performances de votre serveur !
-UVrai si la chaîne correspond a une URL valide, accessible + avec tous les contrôles d'accès configurés pour ce chemin. A + cette fin, une sous-requête effectue la vérification, et vous + devez utiliser ce drapeau avec soin car il peut impacter les + performances de votre serveur !
-AAlias pour -U
-nVrai si la chaîne n'est pas vide
-zVrai si la chaîne est vide
-TFaux si la chaîne est vide, "0", + "off", "false", ou "no" + (insensibilité à la casse). Vrai dans le cas contraire.
-RIdem "%{REMOTE_ADDR} -ipmatch ...", en plus + efficace +
+ +

Les opérateurs marqués comme "restreints" ne sont pas disponibles + avec certains modules comme mod_include.

+ +
top
+
+

Fonctions

+ + +

Normalement, les fonctions dont la valeur est une chaîne acceptent une chaîne + comme argument et renvoient une chaîne. Les noms de fonctions sont + insensibles à la casse. Les modules peuvent fournir des fonctions + supplémentaires.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NomDescriptionRemarques particulières
req, httpLit l'en-tête de requête HTTP ; les noms + d'en-tête correspondants peuvent être ajoutés à l'en-tête Vary, + voir ci-dessous
req_novaryIdentique à req, mais les noms + d'en-tête correspondants ne seront pas ajoutés à l'en-tête Vary
respLit l'en-tête de réponse HTTP (la plupart des + en-tête de la réponse ne sont pas encore définis pendant + l'exécution de la directive <If>)
reqenvRecherche une variable d'environnement de requête (on + peut aussi utiliser le raccourci v). + ordonnancement
osenvRecherche une variable d'environnement du système + d'exploitation
noteRecherche une note de requêteordonnancement
envRenvoie le premier résultat positif de note, + reqenv, osenvordonnancement
tolowerConvertit une chaîne en minuscules
toupperConvertit une chaîne en majuscules
escapeEchappe les caractères spéciaux en codage hexadécimal
unescape"Déséchappe" les chaînes codées + en hexadécimal, en ne gardant encodés que les slashes; renvoie la chaîne vide + si la séquence %00 est rencontrée
base64Encode la chaîne en utilisant le codage base64
unbase64Décode une chaîne codée en base64, renvoie une chaîne + tronquée si le caractère 0x00 est rencontré
md5Effectue un hashage MD5 de la chaîne, puis encode le hash + avec un codage hexadécimal
sha1Effectue un hashage SHA1 de la chaîne, puis encode le hash + avec un codage hexadécimal
fileLit le contenu d'un fichier (fins de lignes incluses, si + elles existent)limité
filemodRenvoie la date de dernière modification d'un fichier (ou 0 + si le fichier n'existe pas ou n'est pas un fichier + régulier)limité
filesizeRenvoie la taille d'un fichier (ou 0 si le fichier n'existe + pas ou ne correspond pas à un fichier + régulier)limité
ldapEchappe les caractères selon la RFC4514 (Echappement des + noms distinctifs LDAP - DN) et la RFC4515 (Echappement des + filtres LDAP).
replacereplace(chaîne, "de", "vers") remplace dans la chaîne + spécifiée toutes les occurrences de "de" par "vers".
+ +

Les fonctions marquées comme "limité" dans la dernière colonne ne sont + pas disponibles avec certains modules comme + mod_include.

+ +

Les fonctions marquées comme "ordonnancement" dans la dernière colonne + nécessitent une attention particulière pour l'ordonnancement des différents + composants du serveur, spécialement lorsque la fonction est utilisée au sein + d'une directive <If> qui est + évaluée relativement tôt.

+
+

Ordonnancement des variables d'environnement

+ Lorsque des variables d'environnement sont évaluées au sein d'une directive + <If>, il est important de tenir + compte du moment où cette évaluation intervient dans le traitement de la + requête. Par exemple, toute directive définie en dehors d'un contexte de + serveur virtuel (directory, location, htaccess) aura peu de chance d'être + déjà exécutée. Ainsi la directive SetEnvIf est une directive qui s'exécute + avant cette évaluation. +
+
+ Lorsque reqenv est utilisé en dehors de la directive + <If>, l'évaluation survient en + général plus tard, mais le moment exact dépend de la directive dans laquelle + l'expression a été utilisée. +
+ +

Lorsque les fonctions req ou http sont + utilisées, le nom d'en-tête sera automatiquement ajouté à l'en-tête + Vary de la réponse HTTP, sauf spécification contraire pour la + directive qui accepte l'expression comme paramètre. La fonction + req_novary permet d'empêcher cet ajout.

+ +

En plus des fonctions dont la valeur est une chaîne, il existe + aussi des fonctions dont la valeur est une liste, qui acceptent une + chaîne comme argument, et renvoient une liste , par exemple + une liste de chaînes. La liste peut être utilisée avec + l'opérateur spécial -in. Les noms de fonctions sont + insensibles à la casse. Les modules peuvent fournir des fonctions + supplémentaires.

+ +

Il n'existe pas de fonctions internes dont la valeur est une + liste. Le module mod_ssl fournit la fonction + PeerExtList. Voir la description de la directive + SSLRequire pour plus de + détails (notez que la fonction PeerExtList peut aussi + être utilisée en dehors de la directive SSLRequire).

+ +
top
+
+

Exemples d'expressions

+ + +

Les exemples suivants montent comment utiliser les + expressions pour évaluer les requêtes :

+ + 
# Comparer le nom d'hôte avec example.com et rediriger vers
+# www.example.com si le nom d'hôte correspond
+<If "%{HTTP_HOST} == 'example.com'">
+    Redirect permanent "/" "http://www.example.com/"
+</If>
+
+# Forcer le type text/plain si un fichier fait l'objet d'une
+# requête dont la chaîne de paramètres contient 'forcetext'
+<If "%{QUERY_STRING} =~ /forcetext/">
+    ForceType text/plain
+</If>
+
+# N'autoriser l'accès à ce contenu que pendant les heures de
+# travail
+<Directory "/foo/bar/business">
+     Require expr %{TIME_HOUR} -gt 9 && %{TIME_HOUR} -lt 17
+</Directory>	
+
+# Vérifie si un en-tête HTTP correspond à une des valeurs d'une liste
+<If "%{HTTP:X-example-header} in { 'foo', 'bar', 'baz' }">
+    La définition de l'en-tête correspond à une des valeurs recherchées
+</If>
+# Recherche la valeur d'une expression rationnelle dans une variable
+# d'environnement, et renvoie la négation du résultat.
+<If "! reqenv('REDIRECT_FOO') =~ /bar/">
+    La condition est vérifiée
+</If>
+
+# Vérifie le résultat de la recherche d'une correspondance d'URI dans un
+# contexte de répertoire avec l'option -f
+<Directory "/var/www">
+    AddEncoding x-gzip gz
+<If "-f '%{REQUEST_FILENAME}.unzipme' && ! %{HTTP:Accept-Encoding} =~ /gzip/">
+      SetOutputFilter INFLATE
+</If>
+</Directory>
+
+# Vérifie l'adresse IP du client
+<If "-R '192.168.1.0/24'">
+    Header set matched true
+</If>
+
+# Exemples de fonctions dans un contexte booléen
+<If "md5('foo') == 'acbd18db4cc2f85cedef654fccc4a4d8'">
+  Header set checksum-matched true
+</If>
+<If "md5('foo') == replace('md5:XXXd18db4cc2f85cedef654fccc4a4d8', 'md5:XXX', 'acb')>
+  Header set checksum-matched-2 true
+</If>
+
+
+# Exemple de fonction dans un contexte littéral
+Header set foo-checksum "expr=%{md5:foo}"
+
+# L'exemple suivant retarde l'évaluation de la clause de condition par rapport à
+# <If>
+Header always set CustomHeader my-value "expr=%{REQUEST_URI} =~
+m#^/special_path\.php$#"
+
+# Ajoute un en-tête permettant d'acheminer le SAN du certificat d'un client vers
+# un quelconque serveur d'arrière-plan
+RequestHeader set X-Client-SAN "expr=%{:join PeerExtList('subjectAltName'):}"
+
+# Impose la présence de l'adresse IP distante dans le SAN du certificat d'un client
+Require expr %{REMOTE_ADDR} -in split s/.*?IP Address:([^,]+)/$1/, PeerExtList('subjectAltName')
+# autre solution :
+Require expr "IP Address:%{REMOTE_ADDR}" -in split/, /, join PeerExtList('subjectAltName')
+
+# Journalisation conditionnelle
+CustomLog logs/access-errors.log common "expr=%{REQUEST_STATUS} >= 400"
+CustomLog logs/access-errors-specific.log common "expr=%{REQUEST_STATUS} -in {'405','410'}"
+ +
top
+
+

Autres

+ + + + + + + + + + + + + + +
NomAlternative Description
-ininchaîne contenue dans une liste
/regexp/m#regexp#Expression rationnelle (la seconde forme permet de spécifier + des délimiteurs autres que /)
/regexp/im#regexp#iExpression rationnelle insensible à la casse
$0 ... $9 + Références arrières dans les expressions rationnelles
+ +

Références arrières dans les expressions rationnelles

+ +

Les chaînes $0 ... $9 permettent de + référencer les groupes de capture en provenance d'expressions + rationnelles précédemment exécutées et mises en correspondance avec + succès. Elles ne peuvent normalement être utilisées que dans la + même expression que celle mise en correspondance, mais certains + modules permettent de les utiliser de manière spéciale.

+ + +
top
+
+

Comparaison avec SSLRequire

+ +

La syntaxe ap_expr consiste principalement en une + surcouche de la syntaxe de la directive obsolète SSLRequire. Vous pouvez consulter la + liste de leur différences dans la documentation de la directive + SSLRequire.

+
top
+
+

Historique de version

+ +

La fonction req_novary est + disponible à partir de la version 2.4.4 du serveur HTTP Apache.

+

Les variables + SERVER_PROTOCOL_VERSION, + SERVER_PROTOCOL_VERSION_MAJOR et + SERVER_PROTOCOL_VERSION_MINOR sont disponibles à partir + de la version 2.5.0 du serveur HTTP Apache.

+
+
+

Langues Disponibles:  en  | + fr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/faq/index.html b/docs/manual/faq/index.html index 2cdabe3fc9..5e54691f3e 100644 --- a/docs/manual/faq/index.html +++ b/docs/manual/faq/index.html @@ -6,7 +6,7 @@ Content-type: text/html; charset=ISO-8859-1 URI: index.html.es Content-Language: es -Content-type: text/html; charset=ISO-8859-1 +Content-type: text/html; charset=UTF-8 URI: index.html.fr Content-Language: fr diff --git a/docs/manual/faq/index.html.en b/docs/manual/faq/index.html.en index 949c8af229..6bcf9c1154 100644 --- a/docs/manual/faq/index.html.en +++ b/docs/manual/faq/index.html.en @@ -24,10 +24,10 @@ Apache > HTTP Server > Documentation > Version 2.5

Frequently Asked Questions

Available Languages:  en  | - es  | - fr  | + es  | + fr  |  ko  | - tr  | + tr  |  zh-cn 

@@ -37,10 +37,10 @@

Available Languages:  en  | - es  | - fr  | + es  | + fr  |  ko  | - tr  | + tr  |  zh-cn 

Filters

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

+ tr 

This document describes the use of filters in Apache.

@@ -152,11 +152,11 @@ but deprecated. Use dynamic configuration instead.

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

+ tr 

top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
- - -
-

Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

-

Versin 2.5 del Servidor HTTP Apache

-
-
<-
-

Filtros

-
-

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

-
- -

Este documento describe cmo usar filtros en Apache.

-
- -
top
-
-

Filtros en Apache 2

- -
Mdulos RelacionadosDirectivas Relacionadas
- -

La cadena de filtrado est disponible en Apache 2.0 y superiores. - Un filtro es un proceso que se aplica a los datos que - se reciben o se envan por el servidor. Los datos enviados - por los clientes al servidor son procesados por filtros de - entrada mientras que los datos enviados por el servidor se - procesan por los filtros de salida. A los datos se les - pueden aplicar varios filtros, y el orden en que se aplica cada - filtro puede especificarse explcitamente. - Todo este proceso es independiente de las tradicionales fase de - peticiones

-

- Filters can be chained, in a Data Axis orthogonal to request processing -

-

Algunos ejemplos de filtrado en la distribucin estndar de Apache son:

-
    -
  • mod_include, implementa server-side includes (SSI).
    • -
  • mod_ssl, implementa cifrado SSL (https).
    • -
  • mod_deflate, implementa compresin y descompresin en el acto.
    • -
  • mod_charset_lite, transcodificacin entre diferentes juegos de caracteres.
    • -
  • mod_ext_filter, ejecuta un programa externo como filtro.
    • -
-

Los filtros se usan internamente por Apache para llevar a cabo - funciones tales como chunking y servir peticiones de - byte-range. Adems, los mdulos contienen filtros que se - pueden seleccionar usando directivas de configuracin al - iniciar el servidor.

- -

Una mayor amplitud de aplicaciones son implementadas con mdulos de - filtros de terceros que estan disponibles en modules.apache.org y en otros lados. - algunos de ellos son:

- -
    -
  • Procesamiento y reescritura de HTML y XML.
    • -
  • Transformaciones de XSLT y XIncludes.
    • -
  • Soporte de espacios de nombres en XML.
    • -
  • Manipulacin de carga de archivos y decodificacin de los - formularios HTML.
    • -
  • Procesamiento de imgenes.
    • -
  • Proteccin de aplicaciones vulnerables, tales como scripts PHP
    • -
  • Edicin de texto de bsqueda y remplazo.
    • -
-
top
-
-

Filtrado Inteligente

- -

- Smart filtering applies different filter providers according to the state of request processing -

-

mod_filter, incluido en Apache 2.1 y posterior, - habilita la cadena de filtrado para ser configurada dinmicamente en - tiempo de ejecucin. As, por ejemplo, usted puede configurar un - proxy para que reescriba HTML con un filtro de HTML y imgenes JPEG - con filtros completos por separado, a pesar de que el proxy no tiene - informacin previa sobre lo que enviar al servidor de origen. - Esto funciona usando un engranaje filtros, que enva a diferentes - proveedores dependiendo del contenido en tiempo de ejecucin. - Cualquier filtro puede ser, ya sea insertado directamente en la - cadena y ejecutado incondicionalmente, o usado como proveedor y - aadido dinmicamente - Por ejemplo:

-
    -
  • Un filtro de procesamiento de HTML slo se ejecuta si el - contenido es text/html o application/xhtml + xml.
    • -
  • Un filtro de compresin slo se ejecuta si la entrada es un tipo - compresible y no est ya comprimida.
    • -
  • Se insertar un filtro de conversin de juego de caracteres, - si un documento de texto no est ya en el juego de caracteres - deseado.
    • -
-
top
-
-

Filtros expuestos como un servicio HTTP

- - -

Los filtros pueden ser usados para procesar contenido originado - desde el cliente adems de usarse para procesar el contenido originado - desde el propio servidor usando el mdulo mod_reflector.

- -

mod_reflector acepta peticiones POST de los clientes, y - refleja el cuerpo de la peticin POST recibida, dentro del contenido de la - respuesta de la peticin, pasa a travs de la pila del filtro de salida en - el camino de vuelta al cliente.

- -

Esta tcnica se puede utilizar como una alternativa a un servicio web - que se ejecuta en una pila de de aplicaciones dentro del servidor, - en donde el filtro de salida proporciona la transformacin requerida en el - cuerpo de la peticin. Por ejemplo, el mdulo mod_deflate - puede ser usado para proporcionar un servicio de compresin general, - o un filtro de transformacin de imagen, puede ser convertido en un - servicio de conversin de imgenes. -

- -
top
-
-

Usando los Filtros

- -

Hay dos formas de usar el filtrado: de forma Simple y Dinmica. - Generalmente, deber usar una forma u otra; ya que mezclarlas puede - causar consecuencias inesperadas (a pesar de que reglas de Entrada de - tipo simple pueden ser combinadas libremente con reglas de filtrado - de Salidas de tipo simple o dinmico).

-

La forma ms sencilla es la nica manera de configurar filtros de - Entrada, y es suficiente para filtros de Salida donde se necesita una - cadena de filtros esttica. - Las directivas ms relevantes son: - SetInputFilter, - SetOutputFilter, - AddInputFilter, - AddOutputFilter, - RemoveInputFilter, and - RemoveOutputFilter.

- -

La forma Dinmica habilita ambas configuraciones esttica, y dinmica, para los filtros de Salida, como se plantea en la pgina mod_filter. - Las directivas ms relevantes son: - FilterChain, - FilterDeclare, and - FilterProvider.

- -

Una directiva ms como es AddOutputFilterByType sigue siendo - soportada pero esta obsoleta. Usa en cambio la configuracin dinmica.

- -
-
-

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

-
top

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
-
- \ No newline at end of file diff --git a/docs/manual/filter.html.es.utf8 b/docs/manual/filter.html.es.utf8 new file mode 100644 index 0000000000..0b4affea8d --- /dev/null +++ b/docs/manual/filter.html.es.utf8 @@ -0,0 +1,200 @@ + + + + + +Filtros - Servidor HTTP Apache Versin 2.5 + + + + + + +
+

Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

+

Versin 2.5 del Servidor HTTP Apache

+
+
<-
+

Filtros

+
+

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

+
+ +

Este documento describe cmo usar filtros en Apache.

+
+ +
top
+
+

Filtros en Apache 2

+ +
Mdulos RelacionadosDirectivas Relacionadas
+ +

La cadena de filtrado est disponible en Apache 2.0 y superiores. + Un filtro es un proceso que se aplica a los datos que + se reciben o se envan por el servidor. Los datos enviados + por los clientes al servidor son procesados por filtros de + entrada mientras que los datos enviados por el servidor se + procesan por los filtros de salida. A los datos se les + pueden aplicar varios filtros, y el orden en que se aplica cada + filtro puede especificarse explcitamente. + Todo este proceso es independiente de las tradicionales fase de + peticiones

+

+ Filters can be chained, in a Data Axis orthogonal to request processing +

+

Algunos ejemplos de filtrado en la distribucin estndar de Apache son:

+
    +
  • mod_include, implementa server-side includes (SSI).
    • +
  • mod_ssl, implementa cifrado SSL (https).
    • +
  • mod_deflate, implementa compresin y descompresin en el acto.
    • +
  • mod_charset_lite, transcodificacin entre diferentes juegos de caracteres.
    • +
  • mod_ext_filter, ejecuta un programa externo como filtro.
    • +
+

Los filtros se usan internamente por Apache para llevar a cabo + funciones tales como chunking y servir peticiones de + byte-range. Adems, los mdulos contienen filtros que se + pueden seleccionar usando directivas de configuracin al + iniciar el servidor.

+ +

Una mayor amplitud de aplicaciones son implementadas con mdulos de + filtros de terceros que estan disponibles en modules.apache.org y en otros lados. + algunos de ellos son:

+ +
    +
  • Procesamiento y reescritura de HTML y XML.
    • +
  • Transformaciones de XSLT y XIncludes.
    • +
  • Soporte de espacios de nombres en XML.
    • +
  • Manipulacin de carga de archivos y decodificacin de los + formularios HTML.
    • +
  • Procesamiento de imgenes.
    • +
  • Proteccin de aplicaciones vulnerables, tales como scripts PHP
    • +
  • Edicin de texto de bsqueda y remplazo.
    • +
+
top
+
+

Filtrado Inteligente

+ +

+ Smart filtering applies different filter providers according to the state of request processing +

+

mod_filter, incluido en Apache 2.1 y posterior, + habilita la cadena de filtrado para ser configurada dinmicamente en + tiempo de ejecucin. As, por ejemplo, usted puede configurar un + proxy para que reescriba HTML con un filtro de HTML y imgenes JPEG + con filtros completos por separado, a pesar de que el proxy no tiene + informacin previa sobre lo que enviar al servidor de origen. + Esto funciona usando un engranaje filtros, que enva a diferentes + proveedores dependiendo del contenido en tiempo de ejecucin. + Cualquier filtro puede ser, ya sea insertado directamente en la + cadena y ejecutado incondicionalmente, o usado como proveedor y + aadido dinmicamente + Por ejemplo:

+
    +
  • Un filtro de procesamiento de HTML slo se ejecuta si el + contenido es text/html o application/xhtml + xml.
    • +
  • Un filtro de compresin slo se ejecuta si la entrada es un tipo + compresible y no est ya comprimida.
    • +
  • Se insertar un filtro de conversin de juego de caracteres, + si un documento de texto no est ya en el juego de caracteres + deseado.
    • +
+
top
+
+

Filtros expuestos como un servicio HTTP

+ + +

Los filtros pueden ser usados para procesar contenido originado + desde el cliente adems de usarse para procesar el contenido originado + desde el propio servidor usando el mdulo mod_reflector.

+ +

mod_reflector acepta peticiones POST de los clientes, y + refleja el cuerpo de la peticin POST recibida, dentro del contenido de la + respuesta de la peticin, pasa a travs de la pila del filtro de salida en + el camino de vuelta al cliente.

+ +

Esta tcnica se puede utilizar como una alternativa a un servicio web + que se ejecuta en una pila de de aplicaciones dentro del servidor, + en donde el filtro de salida proporciona la transformacin requerida en el + cuerpo de la peticin. Por ejemplo, el mdulo mod_deflate + puede ser usado para proporcionar un servicio de compresin general, + o un filtro de transformacin de imagen, puede ser convertido en un + servicio de conversin de imgenes. +

+ +
top
+
+

Usando los Filtros

+ +

Hay dos formas de usar el filtrado: de forma Simple y Dinmica. + Generalmente, deber usar una forma u otra; ya que mezclarlas puede + causar consecuencias inesperadas (a pesar de que reglas de Entrada de + tipo simple pueden ser combinadas libremente con reglas de filtrado + de Salidas de tipo simple o dinmico).

+

La forma ms sencilla es la nica manera de configurar filtros de + Entrada, y es suficiente para filtros de Salida donde se necesita una + cadena de filtros esttica. + Las directivas ms relevantes son: + SetInputFilter, + SetOutputFilter, + AddInputFilter, + AddOutputFilter, + RemoveInputFilter, and + RemoveOutputFilter.

+ +

La forma Dinmica habilita ambas configuraciones esttica, y dinmica, para los filtros de Salida, como se plantea en la pgina mod_filter. + Las directivas ms relevantes son: + FilterChain, + FilterDeclare, and + FilterProvider.

+ +

Una directiva ms como es AddOutputFilterByType sigue siendo + soportada pero esta obsoleta. Usa en cambio la configuracin dinmica.

+ +
+
+

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

+
top

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/filter.html.fr b/docs/manual/filter.html.fr deleted file mode 100644 index ea2d9e729b..0000000000 --- a/docs/manual/filter.html.fr +++ /dev/null @@ -1,202 +0,0 @@ - - - - - -Filtres - Serveur HTTP Apache Version 2.5 - - - - - - -
-

Modules | Directives | FAQ | Glossaire | Plan du site

-

Serveur HTTP Apache Version 2.5

-
-
<-
-

Filtres

-
-

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

-
- -

Ce document décrit l'utilisation des filtres avec Apache.

-
- -
top
-
-

Le filtrage avec Apache 2

- -
Modules ApparentésDirectives Apparentées
- -

La chaîne de filtrage est disponible depuis la version 2.0 d'Apache, -et permet aux applications de traiter les données en entrée et en sortie -d'une manière hautement flexible et configurable, quelle que soit la -provenance de ces données. Il est possible de pré-traiter les données -en entrée, et post-traiter les données en sortie, selon -vos souhaits. -Ces traitements sont tout à fait indépendants des traditionnelles phases -de traitement des requêtes.

-

-les filtres peuvent s'enchaîner, perpendiculairement au traitement des requêtes -

-

Voici quelques exemples de filtrage avec la distribution standard d'Apache:

-
    -
  • mod_include, implémente les inclusions côté serveur.
    • -
  • mod_ssl, implémente le cryptage SSL (https).
    • -
  • mod_deflate, implémente la compression/décompression -à la volée.
    • -
  • mod_charset_lite, transcodage entre différents -jeux de caractères.
    • -
  • mod_ext_filter, utilisation d'un programme externe -comme filtre.
    • -
-

Apache utilise aussi plusieurs filtres en interne pour accomplir des tâches -comme le découpage des grosses requêtes (chunking) et la gestion des -requêtes portant sur une partie d'un fichier (byte-range).

- -

Un grand choix d'applications sont implémentées par des modules de filtrage -tiers disponibles à modules.apache.org entre autres. -En voici quelques exemples :

- -
    -
  • Traitement et réécriture HTML et XML
    • -
  • Transformations XSLT et inclusions XML (XIncludes)
    • -
  • Support de l'espace de nommage XML
    • -
  • Gestion du chargement de fichier et décodage des formulaires HTML
    • -
  • Traitement d'image
    • -
  • Protection des applications vulnérables comme les scripts PHP
    • -
  • Edition de texte par Chercher/Remplacer
    • -
-
top
-
-

Filtrage intelligent

- -

-Le filtrage intelligent applique différents fournisseurs de filtrage en fonction de l'état du traitement de la requête -

-

mod_filter, inclus dans les version 2.1 et supérieures -d'Apache, permet de configurer la chaîne de filtrage dynamiquement -à l'exécution. -Ainsi par exemple, vous pouvez définir un proxy pour réécrire du code HTML -avec un filtre HTML et traiter des images JPEG avec un filtre totalement -séparé, bien que le proxy ne possède aucune information préliminaire -sur ce que le serveur à l'origine des données à filtrer va envoyer. -Ceci fonctionne grâce à l'utilisation d'un gestionnaire de filtre, -qui distribue les tâches à différents fournisseurs de filtrage en fonction -du contenu réel à filtrer à l'exécution. Tout filtre peut se voir soit -inséré directement dans la chaîne et lancé inconditionnellement, soit -utilisé comme un fournisseur de filtrage et inséré dynamiquement. -Par exemple,

-
    -
  • un filtre de traitement HTML sera lancé uniquement si le contenu est -de type text/html ou application/xhtml+xml
    • -
  • Un filtre de compression sera lancé uniquement si les données en entrée -sont de type compressible et non déjà compressées
    • -
  • Un filtre de conversion de jeux de caractères ne sera inséré que si -le document texte n'est pas déjà dans le jeu de caractères voulu
    • -
-
top
-
-

Présentation des filtres en tant que service HTTP

- - -

Les filtres permettent de traiter les requêtes des clients avant -traitement par le serveur, ainsi que les contenus issus du serveur avant de les renvoyer -au client. Le module mod_reflector permet aussi -d'utiliser les filtres pour traiter les requêtes des clients avant de -les renvoyer directement à ces derniers.

- -

Le module mod_reflector reçoit les requêtes POST des -clients, et en répercute le corps dans la requête POST constituant la -réponse, lors de l'envoi de cette dernière au client en passant à travers la -pile de filtres en sortie.

- -

Cette technique peut être utilisée comme alternative à un service web -s'exécutant à l'intérieur de la pile d'un serveur d'applications, où un -filtre en sortie effectue la transformation requise sur le corps de la -requête. Par exemple, on peut utiliser le module -mod_deflate pour fournir un service général de -compression ; un filtre de transformation d'images peut aussi se voir -mué en service de transformation d'images.

- -
top
-
-

Utilisation des filtres

- -

Il y a deux manières d'utiliser le filtrage : Simple et Dynamique. -En général, vous utiliserez l'une ou l'autre méthode; le mélange des deux -peut avoir des conséquences inattendues (bien que le filtrage simple en entrée -puisse être associé sans problème avec le filtrage simple ou dynamique -en sortie).

-

La méthode Simple est la seule permettant de configurer les filtres -en entrée, et suffit pour les filtres en sortie pour lesquels vous avez besoin -d'une chaîne de filtres statique. -Les directives correspondantes sont - SetInputFilter, - SetOutputFilter, - AddInputFilter, - AddOutputFilter, - RemoveInputFilter, et - RemoveOutputFilter.

- -

La méthode Dynamique permet une configuration dynamique des filtres en -sortie à la fois statique et flexible, comme discuté dans la page -mod_filter. -Les directives correspondantes sont - FilterChain, - FilterDeclare, et - FilterProvider.

- -

Une autre directive AddOutputFilterByType est encore supportée, -mais obsolète. Utilisez la -configuration dynamique à la place.

- -
-
-

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

-
top

Commentaires

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

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.5

+
+
<-
+

Filtres

+
+

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

+
+ +

Ce document décrit l'utilisation des filtres avec Apache.

+
+ +
top
+
+

Le filtrage avec Apache 2

+ +
Modules ApparentésDirectives Apparentées
+ +

La chaîne de filtrage est disponible depuis la version 2.0 d'Apache, +et permet aux applications de traiter les données en entrée et en sortie +d'une manière hautement flexible et configurable, quelle que soit la +provenance de ces données. Il est possible de pré-traiter les données +en entrée, et post-traiter les données en sortie, selon +vos souhaits. +Ces traitements sont tout à fait indépendants des traditionnelles phases +de traitement des requêtes.

+

+les filtres peuvent s'enchaîner, perpendiculairement au traitement des requêtes +

+

Voici quelques exemples de filtrage avec la distribution standard d'Apache:

+
    +
  • mod_include, implémente les inclusions côté serveur.
    • +
  • mod_ssl, implémente le cryptage SSL (https).
    • +
  • mod_deflate, implémente la compression/décompression +à la volée.
    • +
  • mod_charset_lite, transcodage entre différents +jeux de caractères.
    • +
  • mod_ext_filter, utilisation d'un programme externe +comme filtre.
    • +
+

Apache utilise aussi plusieurs filtres en interne pour accomplir des tâches +comme le découpage des grosses requêtes (chunking) et la gestion des +requêtes portant sur une partie d'un fichier (byte-range).

+ +

Un grand choix d'applications sont implémentées par des modules de filtrage +tiers disponibles à modules.apache.org entre autres. +En voici quelques exemples :

+ +
    +
  • Traitement et réécriture HTML et XML
    • +
  • Transformations XSLT et inclusions XML (XIncludes)
    • +
  • Support de l'espace de nommage XML
    • +
  • Gestion du chargement de fichier et décodage des formulaires HTML
    • +
  • Traitement d'image
    • +
  • Protection des applications vulnérables comme les scripts PHP
    • +
  • Edition de texte par Chercher/Remplacer
    • +
+
top
+
+

Filtrage intelligent

+ +

+Le filtrage intelligent applique différents fournisseurs de filtrage en fonction de l'état du traitement de la requête +

+

mod_filter, inclus dans les version 2.1 et supérieures +d'Apache, permet de configurer la chaîne de filtrage dynamiquement +à l'exécution. +Ainsi par exemple, vous pouvez définir un proxy pour réécrire du code HTML +avec un filtre HTML et traiter des images JPEG avec un filtre totalement +séparé, bien que le proxy ne possède aucune information préliminaire +sur ce que le serveur à l'origine des données à filtrer va envoyer. +Ceci fonctionne grâce à l'utilisation d'un gestionnaire de filtre, +qui distribue les tâches à différents fournisseurs de filtrage en fonction +du contenu réel à filtrer à l'exécution. Tout filtre peut se voir soit +inséré directement dans la chaîne et lancé inconditionnellement, soit +utilisé comme un fournisseur de filtrage et inséré dynamiquement. +Par exemple,

+
    +
  • un filtre de traitement HTML sera lancé uniquement si le contenu est +de type text/html ou application/xhtml+xml
    • +
  • Un filtre de compression sera lancé uniquement si les données en entrée +sont de type compressible et non déjà compressées
    • +
  • Un filtre de conversion de jeux de caractères ne sera inséré que si +le document texte n'est pas déjà dans le jeu de caractères voulu
    • +
+
top
+
+

Présentation des filtres en tant que service HTTP

+ + +

Les filtres permettent de traiter les requêtes des clients avant +traitement par le serveur, ainsi que les contenus issus du serveur avant de les renvoyer +au client. Le module mod_reflector permet aussi +d'utiliser les filtres pour traiter les requêtes des clients avant de +les renvoyer directement à ces derniers.

+ +

Le module mod_reflector reçoit les requêtes POST des +clients, et en répercute le corps dans la requête POST constituant la +réponse, lors de l'envoi de cette dernière au client en passant à travers la +pile de filtres en sortie.

+ +

Cette technique peut être utilisée comme alternative à un service web +s'exécutant à l'intérieur de la pile d'un serveur d'applications, où un +filtre en sortie effectue la transformation requise sur le corps de la +requête. Par exemple, on peut utiliser le module +mod_deflate pour fournir un service général de +compression ; un filtre de transformation d'images peut aussi se voir +mué en service de transformation d'images.

+ +
top
+
+

Utilisation des filtres

+ +

Il y a deux manières d'utiliser le filtrage : Simple et Dynamique. +En général, vous utiliserez l'une ou l'autre méthode; le mélange des deux +peut avoir des conséquences inattendues (bien que le filtrage simple en entrée +puisse être associé sans problème avec le filtrage simple ou dynamique +en sortie).

+

La méthode Simple est la seule permettant de configurer les filtres +en entrée, et suffit pour les filtres en sortie pour lesquels vous avez besoin +d'une chaîne de filtres statique. +Les directives correspondantes sont + SetInputFilter, + SetOutputFilter, + AddInputFilter, + AddOutputFilter, + RemoveInputFilter, et + RemoveOutputFilter.

+ +

La méthode Dynamique permet une configuration dynamique des filtres en +sortie à la fois statique et flexible, comme discuté dans la page +mod_filter. +Les directives correspondantes sont + FilterChain, + FilterDeclare, et + FilterProvider.

+ +

Une autre directive AddOutputFilterByType est encore supportée, +mais obsolète. Utilisez la +configuration dynamique à la place.

+ +
+
+

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

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/getting-started.html.en b/docs/manual/getting-started.html.en index 67285c4e48..2a4b0d6891 100644 --- a/docs/manual/getting-started.html.en +++ b/docs/manual/getting-started.html.en @@ -24,7 +24,7 @@ Apache > HTTP Server > Documentation > Version 2.5

Getting Started

Available Languages:  en  | - fr 

+ fr 

If you're completely new to the Apache HTTP Server, or even to running @@ -224,7 +224,7 @@ know.

Available Languages:  en  | - fr 

+ fr 

top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
- - -
-

Modules | Directives | FAQ | Glossaire | Plan du site

-

Serveur HTTP Apache Version 2.5

-
-
<-
-

Pour démarrer

-
-

Langues Disponibles:  en  | - fr 

-
- -

Si vous ne connaissez rien au serveur HTTP Apache, ou même au -fonctionnement d'un site web, vous vous demandez probablement par où -commencer et quelles questions poser. Ce document vous permettra de -parcourir les bases du sujet.

-
- -
top
-
-

Clients, serveurs et URLs

- - -

-Les adresses des pages web sur la Toile se présentent sous forme d'URLs -- Uniform Resource Locators - qui comportent un protocole (par - exemple http), un nom de serveur (par exemple - www.apache.org), un chemin (par exemple - /docs/current/getting-started.html), et le cas échéant - une chaîne de requête (query string) (par exemple ?arg=value) - permettant de transmettre des informations supplémentaires au serveur. -

- -

Un client (par exemple un navigateur web) se connecte à un serveur -(par exemple votre serveur HTTP Apache) avec un protocole spécifique, et -effectue une requête pour une ressource en spécifiant -son chemin.

- -

Un chemin peut représenter plusieurs types de ressources sur le -serveur. Ce peut être un fichier (comme -getting-started.html), un gestionnaire (comme server-status), ou toute sorte de -programme (comme index.php). Nous décrirons tout ceci plus -en détails ci-dessous dans la section Contenu d'un -site web.

- -

-Le serveur envoie alors une réponse comportant un code -d'état, et éventuellement un corps de réponse. Le code d'état indique si -la requête a été traitée avec succès, ou dans la négative quel type -d'erreur a été rencontré. Le client est alors sensé savoir quoi faire de -la réponse. Vous pouvez vous familiariser avec les différents codes -d'état en consultant le Wiki du -serveur HTTP Apache.

- -

Les détails de la transaction, ainsi que les erreurs rencontrées, -sont enregistrés dans des fichiers journaux. Tout ceci est décrit en -détails ci-dessous dans la section Débogage et fichiers -journaux.

- -
top
-
-

Noms d'hôte et DNS

- - -

Pour se connecter à un serveur, le client doit tout d'abord résoudre -le nom du serveur en adresse IP, cette dernière permettant de localiser -le serveur sur Internet. Ainsi, pour que votre serveur web soit -accessible, son nom doit être enregistré dans le DNS.

- -

Si vous ne savez pas comment effectuer cet enregistrement, vous -devrez contacter votre administrateur réseau ou votre fournisseur -d'accès à Internet afin qu'il effectue cette opération pour vous.

- -

Plusieurs noms d'hôte peuvent pointer vers la même adresse IP, et -plusieurs adresses IP peuvent être attachées au même serveur physique. -Vous pouvez ainsi héberger plusieurs serveurs web sur le même serveur -physique grâce au mécanisme des serveurs virtuels.

- -

Pour tester un serveur non encore accessible sur Internet, vous -pouvez renseigner son nom d'hôte dans votre fichier hosts afin -d'effectuer une résolution de nom locale. Par exemple, pour tester le -serveur web www.example.com depuis le serveur physique qui -l'héberge, vous pouvez ajouter la ligne suivante au fichier hosts de ce -dernier :

- -

-127.0.0.1 www.example.com -

- -

En général, le fichier hosts se trouve dans le répertoire -/etc sur les systèmes de style Unix, ou -C:\Windows\system32\drivers\etc sous Windows.

- -

Vous trouverez plus de détails à propos du fichier hosts à Wikipedia.org/wiki/Hosts_(file), -et à propos du DNS à Wikipedia.org/wiki/Domain_Name_System.

-
top
-
-

Fichiers de configuration et directives

- - -

La configuration du serveur HTTP Apache s'effectue via de simples -fichiers textes. Ces fichiers peuvent se trouver dans de nombreux -endroits différents en fonction du mode d'installation du serveur. Vous -trouverez les positions courantes de ces fichiers dans le wiki httpd. -Si vous installez httpd depuis le code source, le répertoire par défaut -des fichiers de configuration est /usr/local/apache2/conf. -Le nom du fichier de configuration par défaut est en général -httpd.conf, mais peut aussi varier en fonction des -distributions tierces du serveur.

- -

L'ensemble de la configuration est en général divisé en plusieurs -fichiers afin d'en faciliter la gestion. Ces fichiers sont inclus dans -le fichier de configuration principal via la directive Include. Les noms ou positions de ces fichiers -ne sont pas figés et peuvent varier considérablement d'une distribution -à l'autre. N'hésitez pas à les arranger et subdiviser selon -vos goûts et besoins, quitte à en modifier -l'organisation par défaut.

- -

La configuration du serveur s'effectue via des directives de configuration que l'on -insère dans les fichiers de configuration. Une directive se compose d'un -mot-clé suivi d'un ou plusieurs arguments qui définissent sa valeur.

- -

La réponse à la question "Où dois-je placer cette directive -?" dépend en général du niveau auquel cette directive doit être -prise en compte. S'il s'agit du niveau global, elle doit être placée -dans le fichier de configuration principal, et en dehors de toute -section <Directory>, <Location>, <VirtualHost>, ou de toute autre section. Si -par exemple elle ne doit s'appliquer qu'à un répertoire particulier, -elle doit être placée dans la section <Directory> qui fait référence à ce répertoire. -Voir la documentation sur les Sections de -configuration pour plus de détails.

- -

En complément des fichiers de configuration principaux, certaines -directives peuvent être insérées dans des fichiers -.htaccess que l'on place directement dans le répertoire -concerné. Les fichiers .htaccess sont essentiellement -destinés aux personnes qui n'ont pas accès aux fichiers de configuration -du serveur. Vous trouverez plus de détails à propos des fichiers -.htaccess dans ce .htaccesshowto.

- -
top
-
-

Contenu du site web

- - -

Si le contenu du site web peut se présenter sous de nombreuses -formes, il peut en général être scindé en deux formes principales : les -contenus statiques et les contenus dynamiques.

- -

Les contenus statiques sont par exemple les fichiers HTML, les -images, les fichiers CSS et tout autre fichier résidant dans le système -de fichiers. La directive DocumentRoot permet de définir la position -dans l'arborescence du site où vous devez placer ces fichiers. Cette -directive peut être définie au niveau global, ou au niveau de chaque -serveur virtuel. Vous pouvez consulter vos fichiers de configuration -pour vérifier la manière dont cette directive est définie pour votre -serveur.

- -

En général, et si aucun nom de fichier n'est spécifié dans la -requête, c'est une page de nom index.html qui sera -renvoyée. Par exemple, si la directive DocumentRoot est -définie à /var/www/html, et si une requête est effectuée -pour l'adresse http://www.example.com/work/, c'est le -fichier /var/www/html/work/index.html qui sera envoyé au -client par le serveur.

- -

Un contenu dynamique est un contenu qui est généré au moment du -traitement de la requête, et qui peut différer d'une requête à l'autre. -Ces contenus dynamiques peuvent être générés de nombreuses manières par -l'intermédiaire de gestionnaires de contenu -ou "handlers". Il est aussi possible de créer des programmes CGI pour générer le contenu de -votre site.

- -

Enfin, on peut utiliser des modules tiers comme mod_php pour écrire -du code permettant d'effectuer de nombreuses choses. De nombreuses -applications tierces écrites à partir de divers langages ou outils sont -disponibles en téléchargement et peuvent être installées sur votre -serveur HTTP Apache. Le support de ces applications dépasse le sujet de -ce document, et nous vous invitons à consulter le site de leur éditeur -pour accéder à leur documentation.

-
top
-
-

Fichiers journaux et résolution des problèmes

- -

En tant qu'administrateur d'un serveur HTTP Apache, vos sources -d'informations principales sont les fichiers journaux, et en particulier -le journal des erreurs. Toute tentative de résolution d'un problème sans -consulter le journal des erreurs revient à conduire les yeux fermés.

- -

La position dans le système de fichiers du journal des erreurs est -spécifiée par la directive ErrorLog -qui peut être définie au niveau global, ou au niveau de chaque serveur -virtuel. Chaque entrée du journal des erreurs vous informe sur la nature -des problèmes et le moment de leur survenue. En outre, elle vous indique -souvent comment résoudre le problème. Chaque message d'erreur contient -un code d'erreur que vous pouvez utiliser pour effectuer une recherche -en ligne afin d'obtenir une description plus détaillée de la manière de -résoudre le problème. Vous pouvez aussi configurer votre journal des -erreurs de manière à ce qu'il enregistre un identifiant d'erreur que -vous pourrez ensuite utiliser pour effectuer une corrélation avec le -journal des accès afin de déterminer quelle requête est à l'origine de -l'erreur.

- -

Vous trouverez plus de détails à ce sujet dans la Documentation sur la journalisation.

-
top
-
-

Et maintenant, quelle est la suite des opérations ?

- - -

La question des prérequis étant réglée, il est temps de passer aux -choses sérieuses.

- -

Ce document ne couvre que les notions de base. Nous espérons qu'il -vous permettra de mettre le pied à l'étrier, mais il y a encore de -nombreuses choses que vous devez savoir.

- - - -
-
-

Langues Disponibles:  en  | - fr 

-
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
-
- \ No newline at end of file diff --git a/docs/manual/getting-started.html.fr.utf8 b/docs/manual/getting-started.html.fr.utf8 new file mode 100644 index 0000000000..e973dacde2 --- /dev/null +++ b/docs/manual/getting-started.html.fr.utf8 @@ -0,0 +1,276 @@ + + + + + +Pour démarrer - Serveur HTTP Apache Version 2.5 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.5

+
+
<-
+

Pour démarrer

+
+

Langues Disponibles:  en  | + fr 

+
+ +

Si vous ne connaissez rien au serveur HTTP Apache, ou même au +fonctionnement d'un site web, vous vous demandez probablement par où +commencer et quelles questions poser. Ce document vous permettra de +parcourir les bases du sujet.

+
+ +
top
+
+

Clients, serveurs et URLs

+ + +

+Les adresses des pages web sur la Toile se présentent sous forme d'URLs +- Uniform Resource Locators - qui comportent un protocole (par + exemple http), un nom de serveur (par exemple + www.apache.org), un chemin (par exemple + /docs/current/getting-started.html), et le cas échéant + une chaîne de requête (query string) (par exemple ?arg=value) + permettant de transmettre des informations supplémentaires au serveur. +

+ +

Un client (par exemple un navigateur web) se connecte à un serveur +(par exemple votre serveur HTTP Apache) avec un protocole spécifique, et +effectue une requête pour une ressource en spécifiant +son chemin.

+ +

Un chemin peut représenter plusieurs types de ressources sur le +serveur. Ce peut être un fichier (comme +getting-started.html), un gestionnaire (comme server-status), ou toute sorte de +programme (comme index.php). Nous décrirons tout ceci plus +en détails ci-dessous dans la section Contenu d'un +site web.

+ +

+Le serveur envoie alors une réponse comportant un code +d'état, et éventuellement un corps de réponse. Le code d'état indique si +la requête a été traitée avec succès, ou dans la négative quel type +d'erreur a été rencontré. Le client est alors sensé savoir quoi faire de +la réponse. Vous pouvez vous familiariser avec les différents codes +d'état en consultant le Wiki du +serveur HTTP Apache.

+ +

Les détails de la transaction, ainsi que les erreurs rencontrées, +sont enregistrés dans des fichiers journaux. Tout ceci est décrit en +détails ci-dessous dans la section Débogage et fichiers +journaux.

+ +
top
+
+

Noms d'hôte et DNS

+ + +

Pour se connecter à un serveur, le client doit tout d'abord résoudre +le nom du serveur en adresse IP, cette dernière permettant de localiser +le serveur sur Internet. Ainsi, pour que votre serveur web soit +accessible, son nom doit être enregistré dans le DNS.

+ +

Si vous ne savez pas comment effectuer cet enregistrement, vous +devrez contacter votre administrateur réseau ou votre fournisseur +d'accès à Internet afin qu'il effectue cette opération pour vous.

+ +

Plusieurs noms d'hôte peuvent pointer vers la même adresse IP, et +plusieurs adresses IP peuvent être attachées au même serveur physique. +Vous pouvez ainsi héberger plusieurs serveurs web sur le même serveur +physique grâce au mécanisme des serveurs virtuels.

+ +

Pour tester un serveur non encore accessible sur Internet, vous +pouvez renseigner son nom d'hôte dans votre fichier hosts afin +d'effectuer une résolution de nom locale. Par exemple, pour tester le +serveur web www.example.com depuis le serveur physique qui +l'héberge, vous pouvez ajouter la ligne suivante au fichier hosts de ce +dernier :

+ +

+127.0.0.1 www.example.com +

+ +

En général, le fichier hosts se trouve dans le répertoire +/etc sur les systèmes de style Unix, ou +C:\Windows\system32\drivers\etc sous Windows.

+ +

Vous trouverez plus de détails à propos du fichier hosts à Wikipedia.org/wiki/Hosts_(file), +et à propos du DNS à Wikipedia.org/wiki/Domain_Name_System.

+
top
+
+

Fichiers de configuration et directives

+ + +

La configuration du serveur HTTP Apache s'effectue via de simples +fichiers textes. Ces fichiers peuvent se trouver dans de nombreux +endroits différents en fonction du mode d'installation du serveur. Vous +trouverez les positions courantes de ces fichiers dans le wiki httpd. +Si vous installez httpd depuis le code source, le répertoire par défaut +des fichiers de configuration est /usr/local/apache2/conf. +Le nom du fichier de configuration par défaut est en général +httpd.conf, mais peut aussi varier en fonction des +distributions tierces du serveur.

+ +

L'ensemble de la configuration est en général divisé en plusieurs +fichiers afin d'en faciliter la gestion. Ces fichiers sont inclus dans +le fichier de configuration principal via la directive Include. Les noms ou positions de ces fichiers +ne sont pas figés et peuvent varier considérablement d'une distribution +à l'autre. N'hésitez pas à les arranger et subdiviser selon +vos goûts et besoins, quitte à en modifier +l'organisation par défaut.

+ +

La configuration du serveur s'effectue via des directives de configuration que l'on +insère dans les fichiers de configuration. Une directive se compose d'un +mot-clé suivi d'un ou plusieurs arguments qui définissent sa valeur.

+ +

La réponse à la question "Où dois-je placer cette directive +?" dépend en général du niveau auquel cette directive doit être +prise en compte. S'il s'agit du niveau global, elle doit être placée +dans le fichier de configuration principal, et en dehors de toute +section <Directory>, <Location>, <VirtualHost>, ou de toute autre section. Si +par exemple elle ne doit s'appliquer qu'à un répertoire particulier, +elle doit être placée dans la section <Directory> qui fait référence à ce répertoire. +Voir la documentation sur les Sections de +configuration pour plus de détails.

+ +

En complément des fichiers de configuration principaux, certaines +directives peuvent être insérées dans des fichiers +.htaccess que l'on place directement dans le répertoire +concerné. Les fichiers .htaccess sont essentiellement +destinés aux personnes qui n'ont pas accès aux fichiers de configuration +du serveur. Vous trouverez plus de détails à propos des fichiers +.htaccess dans ce .htaccesshowto.

+ +
top
+
+

Contenu du site web

+ + +

Si le contenu du site web peut se présenter sous de nombreuses +formes, il peut en général être scindé en deux formes principales : les +contenus statiques et les contenus dynamiques.

+ +

Les contenus statiques sont par exemple les fichiers HTML, les +images, les fichiers CSS et tout autre fichier résidant dans le système +de fichiers. La directive DocumentRoot permet de définir la position +dans l'arborescence du site où vous devez placer ces fichiers. Cette +directive peut être définie au niveau global, ou au niveau de chaque +serveur virtuel. Vous pouvez consulter vos fichiers de configuration +pour vérifier la manière dont cette directive est définie pour votre +serveur.

+ +

En général, et si aucun nom de fichier n'est spécifié dans la +requête, c'est une page de nom index.html qui sera +renvoyée. Par exemple, si la directive DocumentRoot est +définie à /var/www/html, et si une requête est effectuée +pour l'adresse http://www.example.com/work/, c'est le +fichier /var/www/html/work/index.html qui sera envoyé au +client par le serveur.

+ +

Un contenu dynamique est un contenu qui est généré au moment du +traitement de la requête, et qui peut différer d'une requête à l'autre. +Ces contenus dynamiques peuvent être générés de nombreuses manières par +l'intermédiaire de gestionnaires de contenu +ou "handlers". Il est aussi possible de créer des programmes CGI pour générer le contenu de +votre site.

+ +

Enfin, on peut utiliser des modules tiers comme mod_php pour écrire +du code permettant d'effectuer de nombreuses choses. De nombreuses +applications tierces écrites à partir de divers langages ou outils sont +disponibles en téléchargement et peuvent être installées sur votre +serveur HTTP Apache. Le support de ces applications dépasse le sujet de +ce document, et nous vous invitons à consulter le site de leur éditeur +pour accéder à leur documentation.

+
top
+
+

Fichiers journaux et résolution des problèmes

+ +

En tant qu'administrateur d'un serveur HTTP Apache, vos sources +d'informations principales sont les fichiers journaux, et en particulier +le journal des erreurs. Toute tentative de résolution d'un problème sans +consulter le journal des erreurs revient à conduire les yeux fermés.

+ +

La position dans le système de fichiers du journal des erreurs est +spécifiée par la directive ErrorLog +qui peut être définie au niveau global, ou au niveau de chaque serveur +virtuel. Chaque entrée du journal des erreurs vous informe sur la nature +des problèmes et le moment de leur survenue. En outre, elle vous indique +souvent comment résoudre le problème. Chaque message d'erreur contient +un code d'erreur que vous pouvez utiliser pour effectuer une recherche +en ligne afin d'obtenir une description plus détaillée de la manière de +résoudre le problème. Vous pouvez aussi configurer votre journal des +erreurs de manière à ce qu'il enregistre un identifiant d'erreur que +vous pourrez ensuite utiliser pour effectuer une corrélation avec le +journal des accès afin de déterminer quelle requête est à l'origine de +l'erreur.

+ +

Vous trouverez plus de détails à ce sujet dans la Documentation sur la journalisation.

+
top
+
+

Et maintenant, quelle est la suite des opérations ?

+ + +

La question des prérequis étant réglée, il est temps de passer aux +choses sérieuses.

+ +

Ce document ne couvre que les notions de base. Nous espérons qu'il +vous permettra de mettre le pied à l'étrier, mais il y a encore de +nombreuses choses que vous devez savoir.

+ + + +
+
+

Langues Disponibles:  en  | + fr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/glossary.html b/docs/manual/glossary.html index f0cbbded88..1f3733047a 100644 --- a/docs/manual/glossary.html +++ b/docs/manual/glossary.html @@ -10,7 +10,7 @@ Content-type: text/html; charset=ISO-8859-1 URI: glossary.html.es Content-Language: es -Content-type: text/html; charset=ISO-8859-1 +Content-type: text/html; charset=UTF-8 URI: glossary.html.fr Content-Language: fr diff --git a/docs/manual/glossary.html.en b/docs/manual/glossary.html.en index 77e3060a4d..ed865c0459 100644 --- a/docs/manual/glossary.html.en +++ b/docs/manual/glossary.html.en @@ -25,11 +25,11 @@

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

+ tr 

This glossary defines some of the common terminology related to Apache in @@ -483,11 +483,11 @@

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

+ tr 

top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
- - -
-

Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

-

Versin 2.5 del Servidor HTTP Apache

-
-
<-
-

Glosario

-
-

Idiomas disponibles:  de  | - en  | - es  | - fr  | - ja  | - ko  | - tr 

-
- -

ste glosario define las terminologas ms comunes - relacionada con Apache en particular, y con los servidores web en - general. En los enlaces que hay asociados a cada trmino se puede - encontrar informacin ms detallada de cada uno.

-
-
top
-
-

Definiciones

-
-
Algoritmo
-
Un proceso definido sin ambigedades o un conjunto de reglas - para solucionar un problema en un nmero finito de pasos. - Los algoritmos para encriptar se llaman - normalmente algoritmos de cifrado. -
- - -
Algoritmo de cifrado, (Cipher).
-
Es un algoritmo o sistema de encriptado de informacin. - Ejemplos de estos algoritmos son DES, IDEA, RC4, etc.
- Consulte: Encriptado SSL/TLS
- -
Autenticacin.
-
La identificacin positiva de una entidad de red tal como un - servidor, un cliente, o un usuario.
- Consulte: Autentificacin, Autorizacin, - y Control de Acceso
- - -
Autoridad Certificadora. (CA)
Es una entidad externa de confianza cuyo fin - es firmar certificados para las entidades de red que ha autentificado - usando medios seguros. Otras entidades de red pueden verificar la - firma para comprobar que una Autoridad Certificadora ha autentificado - al poseedor del certificado.
Consulte: Encriptado - SSL/TLS
- - -
Cabecera.
Es la parte de la - peticin y la respuesta HTTP que se - enva antes del contenido propiamente dicho, y que contiene - meta-informacin describiendo el contenido.
- -
Certificado.
-
Una informacin que se almacena para autenticar entidades - de red tales como un servidor o un cliente. Un certificado - contiene piezas de informacin X.509 sobre su poseedor - (llamado sujeto) y sobre la Autoridad Certificadora - (llamada el emisor) que lo firma, ms la clave pblica del propietario y la firma de - la AC(Autoridad Certificadora). Las entidades de red verifican las firmas usando - certificados de las AC.
- Consulte: Encriptado SSL/TLS -
- - - -
Clave Pblica.
-
La clave disponible - pblicamente en un sistema - criptogrfico de Clave Pblica, usado para encriptar - mensajes destinados a su propietario y para desencriptar firmas hechas - por su propietario.
Consulte: Encriptado - SSL/TLS
- - - -
Clave Privada.
-
La clave secreta - de un Sistema criptogrfico de - Clave Pblica, usada para desencriptar los mensajes entrantes - y firmar los salientes.
Consulte: Encriptado - SSL/TLS
- - -
CONNECT
Un mtodo de HTTP para hacer proxy a canales de - datos sin usar HTTP. Puede usarse para encapsular otros protocolos, - tales como el protocolo SSL.
- - - -
Contexto
Un rea en los - ficheros de configuracin - donde estn permitidos ciertos tipos de directivas.
- Consulte: Trminos - usados para describir las directivas de Apache
- - -
Control de Acceso.
-
La - restriccin en el acceso al entorno de una red. En el contexto de - Apache significa normalmente la restriccin en el acceso a - ciertas URLs.
- Consulte: Autentificacin, Autorizacin, y - Control de Acceso
- - -
Criptografa - Simtrica
El estudio y aplicacin de - Algoritmos de Cifrado que usan una sola clave secreta tanto - para cifrar como para descifrar.
Consulte: Encriptado SSL/TLS
- - -
Directiva
-
Un comando de - configuracin que controla uno o ms aspectos del - comportamiento de Apache. Las directivas se ponen en el Fichero de Configuracin
- Consulte: ndice de - Directivas
- -
Directivas de - configuracin.
Consulte: Directivas
- -
Entorno Portable de tiempo de ejecucin de Apache, (APR, Apache Portable Runtime)
-
Es un conjunto de libreras que proveen las interfaces bsicas - entre el servidor y el sistema operativo. El desarrollo de APR es - paralelo al del Servidor HTTP Apache, como un proyecto independiente. - Puedes visitar el proyecto en:
- Apache Portable Runtime - Project -
- -
Export-Crippled
-
Disminucin de la fortaleza criptogrfica (y seguridad) - para cumplir con las Regulaciones sobre Exportacin de la - Administracin de los Estados Unidos (EAR). El software - criptogrfico Export-crippled est limitado a una clave de - pequeo tamao, de tal manera que el texto cifrado - que se consigue con l, puede descifrarse por medio de fuerza bruta.
Consulte: Encriptado SSL/TLS
- - -
Expresiones Regulares - (Regex)
Una forma de describir un patrn en un - texto - por ejemplo, "todas las palabras que empiezan con la letra "A" - o "todos los nmeros de telfono que contienen 10 - dgitos" o incluso "Todas las frases entre comas, y que no - contengan ninguna letra Q". Las Expresiones Regulares son tiles en - Apache porque permiten aplicar ciertos atributos a colecciones de - ficheros o recursos de una forma flexible - por ejemplo, todos los - archivos .gif y .jpg que estn en el directorio "imgenes" - podran ser escritos como "/images/.*(jpg|gif)$". - En los lugares donde expresiones regulares se utilizan para reemplazar - cadenas, las variables especiales $ 1 ... $ 9 contienen - referencias inversa las partes agrupadas (entre parntesis) - de la expresin coincidente. La variable especial $ 0 contiene - una referencia inversa a todo el ejemplar de la expresin. - Para escribir un smbolo de dolar literal en una sustitucin de - una cadena, se puede escapar usando "\". Histricamente, la variable & - se poda usar como un alias a $0 en algunos sitios. - Esto ya no esta soportado desde la versin 2.3.6. - Apache usa Expresiones Regulares compatibles con Perl gracias a la - librera PCRE. - Puedes encontrar ms documentacin sobre las expresiones regulares - de PCRE y su sintaxis en esa pgina o en la - Wikipedia.
- - - -
Fichero de Configuracin.
-
Un fichero de texto que contiene Directivas que controlan la configuracin - de Apache.
Consulte: Ficheros de - Configuracin
- - -
.htaccess
-
Un fichero de configuracin que se - pone dentro de la estructura de directorios del sitio web y aplica directivas de configuracin al directorio - en el que est y a sus subdirectorios. A pesar de su nombre, este - fichero puede contener cualquier tipo de directivas, no solo - directivas de control de acceso.
Consulte: Ficheros de Configuracin para ms informacin.
- -
httpd.conf
-
Es el fichero de configuracin principal - de Apache. Su ubicacin por defecto es - /usr/local/apache2/conf/httpd.conf, pero puede moverse - usando opciones de configuracin al compilar o al iniciar - Apache.
Consulte: Ficheros de - Configuracin
- -
Filtro
-
Un proceso que se aplica a la - informacin que es enviada o recibida por el servidor. Los - ficheros de entrada procesan la informacin enviada por un - cliente al servidor, mientras que los filtros de salida procesan la - informacin en el servidor antes de envirsela al - cliente. Por ejemplo, el filtro de salida INCLUDES - procesa documentos para Server Side Includes.
- Consulte: Filtros
- - - -
Firma Digital
-
Un bloque de - texto encriptado que verifica la validez de un certificado o de otro - fichero. Una Autoridad - Certificadora crea una firma generando un hash a partir de la - Clave Pblica que lleva incorporada en un - Certificado, despus encriptando el hash con su propia - Clave Privada. Solo las claves pblicas de las CAs - pueden desencriptar la firma, verificando que la CA ha autentificado a - la entidad de red propietaria del Certificado.
- Consulte: Encriptado SSL/TLS
- -
Handler
-
Es una representacin - interna de Apache de una accin a ser ejecutada cuando se llama a - un fichero. Generalmente, los ficheros tienen un handler (manejador) - implcito, basado en el tipo de fichero. Normalmente, todos los - ficheros son simplemente servidos por el servidor, pero sobre algunos - tipos de ficheros se ejecutan acciones complementarias. Por ejemplo, - el handler cgi-script designa los ficheros a ser - procesados como CGIs.
Consulte: Uso de Handlers en Apache
- -
Herramienta de extensin de - Apache. (apxs)
-
Es un script escrito en Perl que ayuda a compilar el cdigo - fuente de algunos mdulos para - convertirlos en Objetos Dinmicos Compartidos (DSOs) - y ayuda a instalarlos en el Servidor Web de Apache.
- Consulte: Manual de: apxs
- - - -
Hash
-
Algoritmo matemtico de un solo sentido e irreversible, que genera - una cadena de una determinada longitud de otra cadena de - cualquier tamao. Diferentes entradas darn diferentes hashes - (dependiendo de la funcin hash.) -
- - - - - -
Hosting Virtual
Se trata de - servir diferentes sitios web con una sola entidad de Apache. El - hosting virtual de IPs diferencia los sitios web basndose en sus - direcciones IP, mientras que el hosting virtual basado en - nombres usa solo el nombre del host y de esta manera puede alojar - muchos sitios web con la misma direccin IP.
Consulte: Documentacin sobre Hosting Virtual en - Apache
- - -
Identificador de Recursos - Uniforme (URI)
Una cadena de caracteres - compacta para identificar un recurso fsico o abstracto. Se - define formalmente en la RFC 2396. Los URIs que - se usan en world-wide web se refieren normalmente como URLs.
- - - - -
Indicador del Nombre del servidor - Server Name Indication (SNI)
-
Una funcin SSL que permite pasar el nombre de host del servidor deseado - en el mensaje inicial del protocolo de enlace SSL, para que el servidor web - pueda seleccionar la configuracin correcta del host virtual para usar en el - procesamiento del protocolo de enlace SSL. Se aadi a SSL - con las extensiones TLS en el RFC 3546.
- See: the SSL FAQ - and RFC 3546 -
- - - - -
Interfaz de Pasarela Comn. Common Gateway Interface (CGI)
-
Una definicin estndar para - un interfaz entre un servidor web y un programa externo que permite - hacer peticiones de servicio a los programas externos. Este interfaz - esta definido en el RFC-3875.
- Consulte: Contenido Dinmico con CGI -
- -
Localizador de Recursos - Uniforme (URL)
-
El nombre de un recurso - en Internet. Es la manera informal de decir lo que formalmente se - llama un Identificador de - Recursos Uniforme. Las URLs estn compuestas normalmente por - un esquema, tal como http o https, un nombre - de host, y una ruta. Una URL para esta pgina es - http://httpd.apache.org/docs/trunk/glossary.html.
- - -
Mdulo
-
Una parte independiente - de un programa. La mayor parte de la funcionalidad de Apache - est contenida en mdulos que pueden incluirse o excluirse. - Los mdulos que se compilan con el binario httpdde Apache se - llaman mdulos estticos, mientras que los que se - almacenan de forma separada y pueden ser cargados de forma opcional, - se llaman mdulos dinmicos o DSOs. - Los mdulos que estn incluidos por defecto de llaman - mdulos base. Hay muchos mdulos disponibles para - Apache que no se distribuyen con la tarball del - Servidor HTTP Apache. Estos mdulos son llamados - mdulos de terceros.
Consulte: ndice de Mdulos
- - -
Mtodo
-
En el contexto de HTTP, es una accin a ejecutar sobre un recurso, - especificado en la lneas de peticin por el cliente. - Algunos de los mtodos disponibles en HTTP son GET, - POST, y PUT.
- -
Mensaje Resumen (Message Digest)
-
Un hash de un - mensaje, el cual pude ser usado para verificar que el contenido del - mensaje no ha sido alterado durante la transmisin.
- Consulte: Encriptado SSL/TLS
- -
MIME-type
-
Una manera de describir - el tipo de documento a ser transmitido. Su nombre viene del hecho de - que su formato se toma de las Extensiones del "Multipurpose Internet - Mail". Consiste en dos componentes, uno principal y otro secundario, - separados por una barra. Algunos ejemplos son text/html, - image/gif, y application/octet-stream. En - HTTP, el tipo MIME se transmite en la cabecera - del Tipo Contenido.
Consulte: mod_mime
- -
Mdulo del Nmero Mgico - (MMN Module Magic - Number)
El mdulo del nmero - mgico es una constante definida en el cdigo - fuente de Apache que est asociado con la compatibilidad binaria - de los mdulos. Ese nmero cambia cuando cambian las - estructuras internas de Apache, las llamadas a funciones y otras - partes significativas de la interfaz de programacin de manera - que la compatibilidad binaria no puede garantizarse sin cambiarlo. Si - cambia el nmero mgico de mdulo, todos los - mdulos de terceros tienen que ser al menos recompilados, y - algunas veces, incluso hay que introducir ligeras modificaciones para - que funcionen con la nueva versin de Apache
- - -
Nombre de dominio - completamente qualificado (FQDN)
-
El - nombre nico de una entidad de red, que consiste en un nombre de - host y un nombre de dominio que puede traducirse a una direccin - IP. Por ejemplo, www es un nombre de host, - example.com es un nombre de dominio, y - www.example.com es un nombre de dominio completamente - qualificado.
- -
Objetos Dinmicos - Compartidos (DSO, dinamic shared objects)
-
Los Mdulos compilados de forma separada al - binario httpd de Apache se pueden cargar segn se necesiten.
Consulte: Soporte de Objetos Dinmicos - Compartidos
- - -
OpenSSL
-
El toolkit Open Source para SSL/TLS
- Ver: http://www.openssl.org/
- - -
Pass Phrase o frase de contrasea
-
La palabra o frase - que protege los archivos de clave privada. Evita que usuarios no - autorizados los encripten. Normalmente es solo la clave de - encriptado/desencriptado usada por los Algoritmos de - Cifrado.
Consulte: Encriptado - SSL/TLS
- -
Peticin de firma de - Certificado. (CSR)
-
Es la peticin a - una Autoridad Certificadora para - que firme un certificado an sin - firmar. La Autoridad Certificadora firma el Certificado con - la Clave Privada de su - certificado. Una vez que el CSR est firmado, se - convierte en un autntico certificado.
- Consulte: Encriptado SSL/TLS
- - - -
Protocolo de Transferencia de - Hipertexto (HTTP)
-
Es el protocolo de - transmisin estdar usado en la World Wide Web. Apache - implementa la versin 1.1 de este protocolo, al que se hace - referencia como HTTP/1.1 y definido por el RFC 2616.
- -
HTTPS
-
Protocolo de transferencia de - Hipertexto (Seguro), es el mecanismo de comunicacin encriptado - estndar en World Wide Web. En realidad es HTTP sobre SSL.
Consulte: Encriptado - SSL/TLS
- -
Proxy
Un servidor intermedio que se - pone entre el cliente y el servidor de origen. Acepta las - peticiones de los clientes, las transmite al servidor de origen, y - despus devuelve la respuesta del servidor de origen al - cliente. Si varios clientes piden el mismo contenido, el proxy sirve - el contenido desde su cach, en lugar de pedirlo cada vez que lo - necesita al servidor de origen, reduciendo con esto el tiempo de - respuesta.
Consulte: mod_proxy
- - -
Proxy Inverso
-
Es un servidor - proxy que se presenta al cliente como si fuera un - servidor de origen. Es til para esconder el - autntico servidor de origen a los clientes por cuestiones de - seguridad, o para equilibrar la carga.
- - -
SSL, Capa de Conexin Segura Secure Sockets Layer(SSL)
Es un protocolo creado por Netscape - Communications Corporation para la autenticacin en - comunicaciones en general y encriptado sobre redes TCP/IP. Su - aplicacin ms popular es en HTTPS, ejemplo.: el Protocolo de - Transferencia de Hipertexto (HTTP) sobre SSL.
Consulte: Encriptado SSL/TLS
- - -
SSLeay
La implementacin - original de la librera SSL/TLS desarrollada por Eric - A. Young
- - - -
Server Side Includes (SSI)
Una tcnica para incluir directivas de - proceso en archivos HTML.
Consulte: Introduccin a Server Side - Includes
- - - -
Sesin
Informacin del - contexto de una comunicacin en general.
- - -
Sistema Criptogrfico de Clave - Pblica
El estudio y aplicacin de sistemas de - encriptado asimtricos, que usa una clave para encriptar y otra - para desencriptar. Una clave de cada uno de estos tipos constituye un - par de claves. Tambin se llama Criptografa Asimtrica.
- Consulte: Encriptado SSL/TLS
- - -
Subconsulta
-
Apache proporciona una API de subconsultasd a los mdulos, - que permiten a otros sistemas de ficheros o paths de URL ser parcial o totalmente evaluados - por el servidor. Un ejemplo de los que usan esta API sera - DirectoryIndex, - mod_autoindex, y mod_include. -
- -
Tarball
Un grupo de ficheros - puestos en un solo paquete usando la utilidad tar. Las - distribuciones Apache se almacenan en ficheros comprimidos con tar o - con pkzip.
- -
Texto cifrado.
-
El resultado de - haber aplicado a un texto plano un algoritmo de cifrado.
Consultar: Encriptado SSL/TLS
- - - -
Texto plano
-
Un texto no encriptado.
- - -
Transport - Layer Security (TLS)
Es el sucesor del protocolo SSL, creado - por el "Internet Engineering Task Force" (IETF) para la - autentificacin en comunicaciones en general y encriptado sobre - redes TCP/IP. La versin 1 de TLS es casi idntica a la - versin 3 de SSL.
Consulte: Encriptado - SSL/TLS
- - -
Variable de Entorno (env-variable)
-
Variables que - gestionan el shell del sistema operativo y que se usan para guardar - informacin y para la comunicacin entre programas. Apache - tambin contiene variables internas que son referidas como - variables de entorno, pero que son almacenadas en las estructuras - internas de Apache, en lugar de en el entorno del shell.
- Consulte: Variables de entorno de Apache
- - -
X.509
Un esquema de certificado de - autentificacin recomendado por la International - Telecommunication Union (ITU-T) que se usa en la autentificacin - SSL/TLS.
Consulte: Encriptado SSL/TLS
- -
-
-
-

Idiomas disponibles:  de  | - en  | - es  | - fr  | - ja  | - ko  | - tr 

-
top

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
-
- \ No newline at end of file diff --git a/docs/manual/glossary.html.es.utf8 b/docs/manual/glossary.html.es.utf8 new file mode 100644 index 0000000000..31622a6512 --- /dev/null +++ b/docs/manual/glossary.html.es.utf8 @@ -0,0 +1,556 @@ + + + + + +Glosario - Servidor HTTP Apache Versin 2.5 + + + + + + +
+

Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

+

Versin 2.5 del Servidor HTTP Apache

+
+
<-
+

Glosario

+
+

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

+
+ +

ste glosario define las terminologas ms comunes + relacionada con Apache en particular, y con los servidores web en + general. En los enlaces que hay asociados a cada trmino se puede + encontrar informacin ms detallada de cada uno.

+
+
top
+
+

Definiciones

+
+
Algoritmo
+
Un proceso definido sin ambigedades o un conjunto de reglas + para solucionar un problema en un nmero finito de pasos. + Los algoritmos para encriptar se llaman + normalmente algoritmos de cifrado. +
+ + +
Algoritmo de cifrado, (Cipher).
+
Es un algoritmo o sistema de encriptado de informacin. + Ejemplos de estos algoritmos son DES, IDEA, RC4, etc.
+ Consulte: Encriptado SSL/TLS
+ +
Autenticacin.
+
La identificacin positiva de una entidad de red tal como un + servidor, un cliente, o un usuario.
+ Consulte: Autentificacin, Autorizacin, + y Control de Acceso
+ + +
Autoridad Certificadora. (CA)
Es una entidad externa de confianza cuyo fin + es firmar certificados para las entidades de red que ha autentificado + usando medios seguros. Otras entidades de red pueden verificar la + firma para comprobar que una Autoridad Certificadora ha autentificado + al poseedor del certificado.
Consulte: Encriptado + SSL/TLS
+ + +
Cabecera.
Es la parte de la + peticin y la respuesta HTTP que se + enva antes del contenido propiamente dicho, y que contiene + meta-informacin describiendo el contenido.
+ +
Certificado.
+
Una informacin que se almacena para autenticar entidades + de red tales como un servidor o un cliente. Un certificado + contiene piezas de informacin X.509 sobre su poseedor + (llamado sujeto) y sobre la Autoridad Certificadora + (llamada el emisor) que lo firma, ms la clave pblica del propietario y la firma de + la AC(Autoridad Certificadora). Las entidades de red verifican las firmas usando + certificados de las AC.
+ Consulte: Encriptado SSL/TLS +
+ + + +
Clave Pblica.
+
La clave disponible + pblicamente en un sistema + criptogrfico de Clave Pblica, usado para encriptar + mensajes destinados a su propietario y para desencriptar firmas hechas + por su propietario.
Consulte: Encriptado + SSL/TLS
+ + + +
Clave Privada.
+
La clave secreta + de un Sistema criptogrfico de + Clave Pblica, usada para desencriptar los mensajes entrantes + y firmar los salientes.
Consulte: Encriptado + SSL/TLS
+ + +
CONNECT
Un mtodo de HTTP para hacer proxy a canales de + datos sin usar HTTP. Puede usarse para encapsular otros protocolos, + tales como el protocolo SSL.
+ + + +
Contexto
Un rea en los + ficheros de configuracin + donde estn permitidos ciertos tipos de directivas.
+ Consulte: Trminos + usados para describir las directivas de Apache
+ + +
Control de Acceso.
+
La + restriccin en el acceso al entorno de una red. En el contexto de + Apache significa normalmente la restriccin en el acceso a + ciertas URLs.
+ Consulte: Autentificacin, Autorizacin, y + Control de Acceso
+ + +
Criptografa + Simtrica
El estudio y aplicacin de + Algoritmos de Cifrado que usan una sola clave secreta tanto + para cifrar como para descifrar.
Consulte: Encriptado SSL/TLS
+ + +
Directiva
+
Un comando de + configuracin que controla uno o ms aspectos del + comportamiento de Apache. Las directivas se ponen en el Fichero de Configuracin
+ Consulte: ndice de + Directivas
+ +
Directivas de + configuracin.
Consulte: Directivas
+ +
Entorno Portable de tiempo de ejecucin de Apache, (APR, Apache Portable Runtime)
+
Es un conjunto de libreras que proveen las interfaces bsicas + entre el servidor y el sistema operativo. El desarrollo de APR es + paralelo al del Servidor HTTP Apache, como un proyecto independiente. + Puedes visitar el proyecto en:
+ Apache Portable Runtime + Project +
+ +
Export-Crippled
+
Disminucin de la fortaleza criptogrfica (y seguridad) + para cumplir con las Regulaciones sobre Exportacin de la + Administracin de los Estados Unidos (EAR). El software + criptogrfico Export-crippled est limitado a una clave de + pequeo tamao, de tal manera que el texto cifrado + que se consigue con l, puede descifrarse por medio de fuerza bruta.
Consulte: Encriptado SSL/TLS
+ + +
Expresiones Regulares + (Regex)
Una forma de describir un patrn en un + texto - por ejemplo, "todas las palabras que empiezan con la letra "A" + o "todos los nmeros de telfono que contienen 10 + dgitos" o incluso "Todas las frases entre comas, y que no + contengan ninguna letra Q". Las Expresiones Regulares son tiles en + Apache porque permiten aplicar ciertos atributos a colecciones de + ficheros o recursos de una forma flexible - por ejemplo, todos los + archivos .gif y .jpg que estn en el directorio "imgenes" + podran ser escritos como "/images/.*(jpg|gif)$". + En los lugares donde expresiones regulares se utilizan para reemplazar + cadenas, las variables especiales $ 1 ... $ 9 contienen + referencias inversa las partes agrupadas (entre parntesis) + de la expresin coincidente. La variable especial $ 0 contiene + una referencia inversa a todo el ejemplar de la expresin. + Para escribir un smbolo de dolar literal en una sustitucin de + una cadena, se puede escapar usando "\". Histricamente, la variable & + se poda usar como un alias a $0 en algunos sitios. + Esto ya no esta soportado desde la versin 2.3.6. + Apache usa Expresiones Regulares compatibles con Perl gracias a la + librera PCRE. + Puedes encontrar ms documentacin sobre las expresiones regulares + de PCRE y su sintaxis en esa pgina o en la + Wikipedia.
+ + + +
Fichero de Configuracin.
+
Un fichero de texto que contiene Directivas que controlan la configuracin + de Apache.
Consulte: Ficheros de + Configuracin
+ + +
.htaccess
+
Un fichero de configuracin que se + pone dentro de la estructura de directorios del sitio web y aplica directivas de configuracin al directorio + en el que est y a sus subdirectorios. A pesar de su nombre, este + fichero puede contener cualquier tipo de directivas, no solo + directivas de control de acceso.
Consulte: Ficheros de Configuracin para ms informacin.
+ +
httpd.conf
+
Es el fichero de configuracin principal + de Apache. Su ubicacin por defecto es + /usr/local/apache2/conf/httpd.conf, pero puede moverse + usando opciones de configuracin al compilar o al iniciar + Apache.
Consulte: Ficheros de + Configuracin
+ +
Filtro
+
Un proceso que se aplica a la + informacin que es enviada o recibida por el servidor. Los + ficheros de entrada procesan la informacin enviada por un + cliente al servidor, mientras que los filtros de salida procesan la + informacin en el servidor antes de envirsela al + cliente. Por ejemplo, el filtro de salida INCLUDES + procesa documentos para Server Side Includes.
+ Consulte: Filtros
+ + + +
Firma Digital
+
Un bloque de + texto encriptado que verifica la validez de un certificado o de otro + fichero. Una Autoridad + Certificadora crea una firma generando un hash a partir de la + Clave Pblica que lleva incorporada en un + Certificado, despus encriptando el hash con su propia + Clave Privada. Solo las claves pblicas de las CAs + pueden desencriptar la firma, verificando que la CA ha autentificado a + la entidad de red propietaria del Certificado.
+ Consulte: Encriptado SSL/TLS
+ +
Handler
+
Es una representacin + interna de Apache de una accin a ser ejecutada cuando se llama a + un fichero. Generalmente, los ficheros tienen un handler (manejador) + implcito, basado en el tipo de fichero. Normalmente, todos los + ficheros son simplemente servidos por el servidor, pero sobre algunos + tipos de ficheros se ejecutan acciones complementarias. Por ejemplo, + el handler cgi-script designa los ficheros a ser + procesados como CGIs.
Consulte: Uso de Handlers en Apache
+ +
Herramienta de extensin de + Apache. (apxs)
+
Es un script escrito en Perl que ayuda a compilar el cdigo + fuente de algunos mdulos para + convertirlos en Objetos Dinmicos Compartidos (DSOs) + y ayuda a instalarlos en el Servidor Web de Apache.
+ Consulte: Manual de: apxs
+ + + +
Hash
+
Algoritmo matemtico de un solo sentido e irreversible, que genera + una cadena de una determinada longitud de otra cadena de + cualquier tamao. Diferentes entradas darn diferentes hashes + (dependiendo de la funcin hash.) +
+ + + + + +
Hosting Virtual
Se trata de + servir diferentes sitios web con una sola entidad de Apache. El + hosting virtual de IPs diferencia los sitios web basndose en sus + direcciones IP, mientras que el hosting virtual basado en + nombres usa solo el nombre del host y de esta manera puede alojar + muchos sitios web con la misma direccin IP.
Consulte: Documentacin sobre Hosting Virtual en + Apache
+ + +
Identificador de Recursos + Uniforme (URI)
Una cadena de caracteres + compacta para identificar un recurso fsico o abstracto. Se + define formalmente en la RFC 2396. Los URIs que + se usan en world-wide web se refieren normalmente como URLs.
+ + + + +
Indicador del Nombre del servidor + Server Name Indication (SNI)
+
Una funcin SSL que permite pasar el nombre de host del servidor deseado + en el mensaje inicial del protocolo de enlace SSL, para que el servidor web + pueda seleccionar la configuracin correcta del host virtual para usar en el + procesamiento del protocolo de enlace SSL. Se aadi a SSL + con las extensiones TLS en el RFC 3546.
+ See: the SSL FAQ + and RFC 3546 +
+ + + + +
Interfaz de Pasarela Comn. Common Gateway Interface (CGI)
+
Una definicin estndar para + un interfaz entre un servidor web y un programa externo que permite + hacer peticiones de servicio a los programas externos. Este interfaz + esta definido en el RFC-3875.
+ Consulte: Contenido Dinmico con CGI +
+ +
Localizador de Recursos + Uniforme (URL)
+
El nombre de un recurso + en Internet. Es la manera informal de decir lo que formalmente se + llama un Identificador de + Recursos Uniforme. Las URLs estn compuestas normalmente por + un esquema, tal como http o https, un nombre + de host, y una ruta. Una URL para esta pgina es + http://httpd.apache.org/docs/trunk/glossary.html.
+ + +
Mdulo
+
Una parte independiente + de un programa. La mayor parte de la funcionalidad de Apache + est contenida en mdulos que pueden incluirse o excluirse. + Los mdulos que se compilan con el binario httpdde Apache se + llaman mdulos estticos, mientras que los que se + almacenan de forma separada y pueden ser cargados de forma opcional, + se llaman mdulos dinmicos o DSOs. + Los mdulos que estn incluidos por defecto de llaman + mdulos base. Hay muchos mdulos disponibles para + Apache que no se distribuyen con la tarball del + Servidor HTTP Apache. Estos mdulos son llamados + mdulos de terceros.
Consulte: ndice de Mdulos
+ + +
Mtodo
+
En el contexto de HTTP, es una accin a ejecutar sobre un recurso, + especificado en la lneas de peticin por el cliente. + Algunos de los mtodos disponibles en HTTP son GET, + POST, y PUT.
+ +
Mensaje Resumen (Message Digest)
+
Un hash de un + mensaje, el cual pude ser usado para verificar que el contenido del + mensaje no ha sido alterado durante la transmisin.
+ Consulte: Encriptado SSL/TLS
+ +
MIME-type
+
Una manera de describir + el tipo de documento a ser transmitido. Su nombre viene del hecho de + que su formato se toma de las Extensiones del "Multipurpose Internet + Mail". Consiste en dos componentes, uno principal y otro secundario, + separados por una barra. Algunos ejemplos son text/html, + image/gif, y application/octet-stream. En + HTTP, el tipo MIME se transmite en la cabecera + del Tipo Contenido.
Consulte: mod_mime
+ +
Mdulo del Nmero Mgico + (MMN Module Magic + Number)
El mdulo del nmero + mgico es una constante definida en el cdigo + fuente de Apache que est asociado con la compatibilidad binaria + de los mdulos. Ese nmero cambia cuando cambian las + estructuras internas de Apache, las llamadas a funciones y otras + partes significativas de la interfaz de programacin de manera + que la compatibilidad binaria no puede garantizarse sin cambiarlo. Si + cambia el nmero mgico de mdulo, todos los + mdulos de terceros tienen que ser al menos recompilados, y + algunas veces, incluso hay que introducir ligeras modificaciones para + que funcionen con la nueva versin de Apache
+ + +
Nombre de dominio + completamente qualificado (FQDN)
+
El + nombre nico de una entidad de red, que consiste en un nombre de + host y un nombre de dominio que puede traducirse a una direccin + IP. Por ejemplo, www es un nombre de host, + example.com es un nombre de dominio, y + www.example.com es un nombre de dominio completamente + qualificado.
+ +
Objetos Dinmicos + Compartidos (DSO, dinamic shared objects)
+
Los Mdulos compilados de forma separada al + binario httpd de Apache se pueden cargar segn se necesiten.
Consulte: Soporte de Objetos Dinmicos + Compartidos
+ + +
OpenSSL
+
El toolkit Open Source para SSL/TLS
+ Ver: http://www.openssl.org/
+ + +
Pass Phrase o frase de contrasea
+
La palabra o frase + que protege los archivos de clave privada. Evita que usuarios no + autorizados los encripten. Normalmente es solo la clave de + encriptado/desencriptado usada por los Algoritmos de + Cifrado.
Consulte: Encriptado + SSL/TLS
+ +
Peticin de firma de + Certificado. (CSR)
+
Es la peticin a + una Autoridad Certificadora para + que firme un certificado an sin + firmar. La Autoridad Certificadora firma el Certificado con + la Clave Privada de su + certificado. Una vez que el CSR est firmado, se + convierte en un autntico certificado.
+ Consulte: Encriptado SSL/TLS
+ + + +
Protocolo de Transferencia de + Hipertexto (HTTP)
+
Es el protocolo de + transmisin estdar usado en la World Wide Web. Apache + implementa la versin 1.1 de este protocolo, al que se hace + referencia como HTTP/1.1 y definido por el RFC 2616.
+ +
HTTPS
+
Protocolo de transferencia de + Hipertexto (Seguro), es el mecanismo de comunicacin encriptado + estndar en World Wide Web. En realidad es HTTP sobre SSL.
Consulte: Encriptado + SSL/TLS
+ +
Proxy
Un servidor intermedio que se + pone entre el cliente y el servidor de origen. Acepta las + peticiones de los clientes, las transmite al servidor de origen, y + despus devuelve la respuesta del servidor de origen al + cliente. Si varios clientes piden el mismo contenido, el proxy sirve + el contenido desde su cach, en lugar de pedirlo cada vez que lo + necesita al servidor de origen, reduciendo con esto el tiempo de + respuesta.
Consulte: mod_proxy
+ + +
Proxy Inverso
+
Es un servidor + proxy que se presenta al cliente como si fuera un + servidor de origen. Es til para esconder el + autntico servidor de origen a los clientes por cuestiones de + seguridad, o para equilibrar la carga.
+ + +
SSL, Capa de Conexin Segura Secure Sockets Layer(SSL)
Es un protocolo creado por Netscape + Communications Corporation para la autenticacin en + comunicaciones en general y encriptado sobre redes TCP/IP. Su + aplicacin ms popular es en HTTPS, ejemplo.: el Protocolo de + Transferencia de Hipertexto (HTTP) sobre SSL.
Consulte: Encriptado SSL/TLS
+ + +
SSLeay
La implementacin + original de la librera SSL/TLS desarrollada por Eric + A. Young
+ + + +
Server Side Includes (SSI)
Una tcnica para incluir directivas de + proceso en archivos HTML.
Consulte: Introduccin a Server Side + Includes
+ + + +
Sesin
Informacin del + contexto de una comunicacin en general.
+ + +
Sistema Criptogrfico de Clave + Pblica
El estudio y aplicacin de sistemas de + encriptado asimtricos, que usa una clave para encriptar y otra + para desencriptar. Una clave de cada uno de estos tipos constituye un + par de claves. Tambin se llama Criptografa Asimtrica.
+ Consulte: Encriptado SSL/TLS
+ + +
Subconsulta
+
Apache proporciona una API de subconsultasd a los mdulos, + que permiten a otros sistemas de ficheros o paths de URL ser parcial o totalmente evaluados + por el servidor. Un ejemplo de los que usan esta API sera + DirectoryIndex, + mod_autoindex, y mod_include. +
+ +
Tarball
Un grupo de ficheros + puestos en un solo paquete usando la utilidad tar. Las + distribuciones Apache se almacenan en ficheros comprimidos con tar o + con pkzip.
+ +
Texto cifrado.
+
El resultado de + haber aplicado a un texto plano un algoritmo de cifrado.
Consultar: Encriptado SSL/TLS
+ + + +
Texto plano
+
Un texto no encriptado.
+ + +
Transport + Layer Security (TLS)
Es el sucesor del protocolo SSL, creado + por el "Internet Engineering Task Force" (IETF) para la + autentificacin en comunicaciones en general y encriptado sobre + redes TCP/IP. La versin 1 de TLS es casi idntica a la + versin 3 de SSL.
Consulte: Encriptado + SSL/TLS
+ + +
Variable de Entorno (env-variable)
+
Variables que + gestionan el shell del sistema operativo y que se usan para guardar + informacin y para la comunicacin entre programas. Apache + tambin contiene variables internas que son referidas como + variables de entorno, pero que son almacenadas en las estructuras + internas de Apache, en lugar de en el entorno del shell.
+ Consulte: Variables de entorno de Apache
+ + +
X.509
Un esquema de certificado de + autentificacin recomendado por la International + Telecommunication Union (ITU-T) que se usa en la autentificacin + SSL/TLS.
Consulte: Encriptado SSL/TLS
+ +
+
+
+

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

+
top

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/glossary.html.fr b/docs/manual/glossary.html.fr deleted file mode 100644 index 7441aef992..0000000000 --- a/docs/manual/glossary.html.fr +++ /dev/null @@ -1,619 +0,0 @@ - - - - - -Glossaire - Serveur HTTP Apache Version 2.5 - - - - - - -
-

Modules | Directives | FAQ | Glossaire | Plan du site

-

Serveur HTTP Apache Version 2.5

-
-
<-
-

Glossaire

-
-

Langues Disponibles:  de  | - en  | - es  | - fr  | - ja  | - ko  | - tr 

-
- -

Ce glossaire définit la terminologie courante relative à Apache en - particulier, et aux serveurs web en général. Vous trouverez plus - d'informations sur chaque concept dans les liens fournis.

-
-
top
-
-

Définitions

-
-
Algorithme
- -
Une formule sans ambiguité ou un jeu de règles destinées à - résoudre un problème en un nombre fini d'étapes. Les algorithmes de - chiffrement sont en général appelés - Ciphers. -
- -
Algorithme de chiffrement - (Cipher)
-
Un algorithme ou un système de chiffrement des données. - Quelques exemples : DES, IDEA, RC4, etc.
- Voir : chiffrement SSL/TLS -
- -
APR
-
Voir "Bibliothèques pour la portabilité d'Apache" -
- -
Archive Tar (Tarball)
-
Un paquetage de fichiers rassemblés dans une archive - à l'aide de l'utilitaire tar. - Les distributions d'Apache sont stockées dans des Archives Tar compressées - ou en utilisant pkzip. -
- -
Authentification
-
L'identification formelle d'une entité du réseau comme un serveur, un - client, ou un utilisateur.
- Voir : Authentification, Autorisation, et - contrôle d'accès -
- -
Autorité de Certification - (Certification Authority) - (CA)
-
Un tiers de confiance habilité à signer des certificats pour des entités - du réseau qu'il a authentifiées selon des critères basés sur la sécurité. - Les autres entités du réseau peuvent alors utiliser la signature pour - vérifier qu'une CA a authentifié le porteur du certificat.
- Voir : chiffrement SSL/TLS -
- -
Bibliothèques pour la portabilité d'Apache - (Apache Portable Runtime) (APR)
-
Un jeu de bibliothèques qui fournit la plupart des interfaces de base - entre le serveur et le système d'exploitation. APR est développé - parallèlement au serveur HTTP Apache comme projet indépendant.
- Voir : Apache Portable Runtime - Project -
- - -
Certificat (Certificate)
-
Un ensemble de données servant à authentifier des entités du - réseau comme un serveur ou un client. Un certificat contient des ensembles - d'informations X509 à propos de son propriétaire (appelé sujet/subject) - et de l'Autorité de Certification - (Certification Authority) ou CA signataire (appelée - le fournisseur/issuer), ainsi que la - clé publique (public - key) du propriétaire et la - signature de la CA. Les entités du réseau vérifient ces signatures - en utilisant les certificats des Autorités de Certification.
- Voir : chiffrement SSL/TLS -
- -
Chiffrement à Clé Publique - (Public Key Cryptography)
-
L'étude et l'application des systèmes de chiffrement asymétriques, - qui utilisent une clé pour le chiffrement et une autre pour le - déchiffrement. Les deux clés correspondantes constituent une paire de clés. - Appelé aussi chiffrement asymétrique. -
- Voir : chiffrement SSL/TLS -
- -
Clé Privée (Private Key)
-
La clé secrète dans un système de - chiffrement à clé publique, - utilisée pour déchiffrer les messages entrants et signer - les messages sortants.
- Voir : chiffrement SSL/TLS -
- -
Clé Publique (Public Key)
-
La clé accessible au public dans un système de Chiffrement à clé publique, - utilisée pour chiffrer les messages destinés uniquement à son - propriétaire et déchiffrer les signatures - faites par son propriétaire.
- Voir : chiffrement SSL/TLS -
- -
CONNECT
-
Une méthode HTTP pour encapsuler - des données brutes dans HTTP. Elle peut aussi être utilisée pour encapsuler - d'autres protocoles, comme le protocole SSL. -
- -
Contexte (Context)
-
Une portion des - fichiers de configuration dans laquelle certains types de - directives sont autorisés.
- Voir : Termes utilisés - pour décrire les directives d'Apache -
- -
Contrôle d'accès - (Access Control)
-
La restriction d'accès à des zones du réseau. Habituellement - dans un contexte Apache, - la restriction d'accès à certaines URLs.
- Voir : Authentification, Autorisation et - Contrôle d'accès -
- -
- Couche des Points de connexion Sécurisés - (Secure Sockets Layer) - (SSL)
-
Un protocole créé par Netscape Communications Corporation pour - l'authentification et le chiffrement généraux des communications dans les - réseaux TCP/IP. L'utilisation la plus connue est HTTPS, autrement dit - le Protocole de Transfert Hypertexte (HTTP) au dessus de SSL.
- Voir : chiffrement SSL/TLS -
- -
Sous-requête
-
Apache possède une API des sous-requêtes pour les modules qui - permettent l'évaluation complète ou partielle par le serveur de - chemins d'autres systèmes de fichiers ou d'URL. Par exemple, la - directive DirectoryIndex, - les modules mod_autoindex et - mod_include utilisent cette API. -
- -
- Cryptographie Symétrique (Symmetric Cryptography)
-
L'étude et l'application des Algorithmes de chiffrement qui - utilisent une clé secrète unique pour les opérations de chiffrement et de - déchiffrement.
- Voir : chiffrement SSL/TLS -
- - -
- Dégradé pour l'exportation - (Export-Crippled)
-
Diminué en terme de puissance cryptographique (et de sécurité) - afin de respecter les Règles de l'Administration des Exportations - des Etats-Unis (Export Administration Regulations ou EAR). - Les logiciels de cryptographie dégradés pour l'exportation sont limités - à une clé de petite taille, et produisent un - Texte crypté qui peut en général être décrypté - par force brute.
- Voir : chiffrement SSL/TLS -
- - -
Demande de signature de certificat - (Certificate Signing Request) - (CSR)
-
La soumission d'un certificat - non signé à une Autorité de - certification, qui le signe avec la Clé privée de leur - Certificat de CA. Une fois le CSR signé, il devient un vrai - certificat.
- Voir : chiffrement SSL/TLS -
- -
Directive
-
Une commande de configuration qui contrôle un ou plusieurs aspects du - comportement d'Apache. Les directives sont placées dans le Fichier de configuration
- Voir : Index des directives -
- -
Directive de configuration - (Configuration Directive)
-
Voir : Directive
- -
En-tête (Header)
-
La partie de la requête et de la réponse - HTTP qui est envoyée avant le contenu - proprement dit, et contient des méta-informations décrivant le contenu. -
- -
Expression Rationnelle - (Regular Expression) - (Regex)
-
Une méthode pour décrire un modèle sous forme de texte - par exemple, - "tous les mots qui commencent par la lettre A" ou "tous les numéros de - téléphone à 10 chiffres" ou encore "Toutes les phrases contenant 2 virgules, - et aucun Q majuscule". Les expressions rationnelles sont très utiles dans - Apache car elles vous permettent d'appliquer certains attributs à des - ensembles de fichiers ou ressources avec une grande flexibilité - - par exemple, tous les fichiers .gif et .jpg situés dans tout répertoire - nommé "images", pourraient être enregistrés comme - "/images/.*(jpg|gif)$". Lorsque l'on utilise des - expressions rationnelles pour la substitution de chaînes, les - variables spéciales $1 ... $9 contiennent des références arrières - vers les parties regroupées (entre parenthèses) de l'expression - qui correspond. La variable spéciale $0 contient une référence - arrière vers l'ensemble de l'expression qui correspond. Pour - insérer un caractère littéral "dollar" dans la chaîne de - remplacement, il faut l'échapper avec un anti-slash. Pour des - raisons historiques, la variable & peut être utilisée en tant - qu'alias de $0 dans certains cas, mais ceci n'est plus possible - depuis la version 2.3.6. Apache utilise les Expressions - Rationnelles Compatibles avec Perl fournies par la librairie PCRE. Vous trouverez plus - d'information à propos de la syntaxe des expressions rationnelles - PCRE sur ce site, ou dans le Wikipedia de la PCRE. -
- -
- Fichier de configuration - (Configuration File)
-
Un fichier texte contenant des - Directives - qui contrôlent la configuration d'Apache.
- Voir : Fichiers de configuration -
- -
Filtre (Filter)
-
Un traitement appliqué aux données envoyées ou reçues par le serveur. - Les filtres en entrée traitent les données envoyées au serveur par le - client, alors que les filtres en sortie traitent les documents sur le - serveur avant qu'ils soient envoyés au client. - Par exemple, le filtre en sortie - INCLUDES - traite les documents pour les - Server Side Includes (Inclusions côté Serveur) - .
- Voir : Filtres -
- -
Gestionnaire (Handler)
-
Une représentation interne à Apache de l'action à entreprendre - quand un fichier est appelé. En général, les fichiers ont des gestionnaires - implicites, basés sur le type de fichier. Normalement, tous les - fichiers sont directement servis par le serveur, mais certains - types de fichiers sont "gérés" séparément. Par exemple, le gestionnaire - cgi-script désigne les fichiers qui doivent être traités - comme CGIs.
- Voir : Utilisation des gestionnaires d'Apache -
- -
Hachage (Hash)
-
Un algorithme mathématique à sens unique, irréversible, générant une - chaîne de longueur fixe à partir d'une autre chaîne de longueur quelconque. - Des chaînes différentes en entrée vont normalement produire des chaînes - différentes en sortie (selon la fonction de hachage). -
- -
Hébergement Virtuel - (Virtual Hosting)
-
Servir des sites web multiples en utilisant une seule instance d'Apache. - Les Hôtes virtuels basés sur IP différencient les sites web en se - basant sur leur adresse IP, alors que les - Hôtes virtuels basés sur le nom utilisent uniquement le nom d'hôte - et peuvent en conséquence héberger de nombreux sites avec la même - adresse IP.
- Voir la Documentation des Hôtes Virtuels d'Apache -
- - -
.htaccess
-
Un fichier de configuration - placé à un certain niveau de l'arborescence du site web, et appliquant des - directives de configuration au - répertoire dans lequel il est placé, ainsi qu'à tous ses sous-répertoires. - En dépit de son nom, ce fichier peut contenir pratiquement tout type de - directive, et pas seulement des directives de contrôle d'accès.
- Voir : Fichiers de configuration -
- -
httpd.conf
-
Le fichier de configuration - principal d'Apache. Sa localisation par défaut est - /usr/local/apache2/conf/httpd.conf, mais ceci peut être - changé en utilisant des options de compilation ou d'exécution.
- Voir : Fichiers de configuration -
- -
HTTPS
-
Le Protocole de Transfert Hypertexte (Sécurisé), le mécanisme de - communication cryptée standard sur le World Wide Web. - Il s'agit en fait de HTTP au dessus de - SSL.
- Voir : chiffrement SSL/TLS -
- -
Identificateur de Ressource Uniformisé - (Uniform Resource Identifier) - (URI)
-
Une chaîne de caractères compacte servant à identifier une ressource - abstraite ou physique. Elle est formellement définie par la RFC 2396. Les URIs - utilisées sur le world-wide web sont souvent appelées URLs. -
- -
- Inclusions Côté Serveur - (Server Side Includes) (SSI) -
-
Une technique permettant d'englober des directives de traitement dans - des fichiers HTML.
- Voir : Introduction aux Inclusions Côté Serveur -
- -
Indication du nom du serveur (SNI)
-
Une fonctionnalité SSL permettant de spécifier le - nom du serveur désiré dans le message initial de la - négociation SSL, de façon à ce que le serveur web - puisse choisir la bonne configuration de serveur virtuel à - utiliser pendant le déroulement de la négociation SSL. - Cette fonctionnalité a été ajoutée - à SSL lorsque sont apparues les extensions TLS, RFC 3546.
- Voir la FAQ SSL - et la RFC 3546 -
- - - -
-Interface commune avec les programmes externes -(Common Gateway Interface) - (CGI)
-
La définition standard d'une interface entre un serveur web et un - programme externe pour permettre à ce dernier de traiter des requêtes. - Il existe une RFC - informationnelle qui en couvre les spécificités.
- Voir : Contenu dynamique avec CGI -
- - - -
-Localisation de Ressource Uniformisée -(Uniform Resource Locator) - (URL)
-
Le nom/adresse d'une ressource sur l'Internet. Il s'agit du terme - informel commun pour ce qui est formellement défini comme - Identificateur de Ressource Uniformisé. - Les URLs sont généralement construites selon un schéma, comme - http ou - https, un nom d'hôte, et un chemin. Une URL pour cette page - pourrait être - http://httpd.apache.org/docs/trunk/glossary.html. -
- - -
Mandataire (Proxy)
-
Un serveur intermédiaire qui se situe entre le client et le - serveur d'origine. - Il prend en compte les requêtes des clients, les transmet au serveur - d'origine, puis renvoie la réponse du serveur d'origine au client. - Si plusieurs clients demandent le même contenu, le mandataire peut l'extraire - de son cache, plutôt que le demander au serveur d'origine - à chaque fois, ce qui réduit le temps de réponse.
- Voir : mod_proxy -
- -
Mandataire inverse - (Reverse Proxy)
-
Un serveur mandataire qui est vu du client - comme un serveur d'origine. Ceci peut s'avérer utile pour - dissimuler le serveur d'origine réel au client pour des raisons de sécurité, - ou pour répartir la charge. -
- -
Méthode (Method)
-
Dans le contexte HTTP, une action à - effectuer sur une ressource spécifiée dans la ligne de requête - par le client. Parmi les méthodes disponibles dans HTTP, on trouve - GET, POST, - et PUT. -
- -
Module
-
Une partie indépendante d'un programme. De nombreuses fonctionnalités - d'Apache sont fournies par des modules que vous pouvez choisir d'inclure - ou d'exclure. Les modules qui sont compilés dans le binaire - httpd sont appelés modules statiques, alors - que les modules qui existent séparément et peuvent être chargés - optionnellement à l'exécution sont appelés - modules dynamiques ou DSOs. - Les modules qui sont inclus par défaut sont appelés - modules de base. De nombreux modules disponibles pour Apache - ne se trouvent pas dans l'archive - du Serveur HTTP Apache . Il sont appelés - modules tiers.
- Voir : Index des modules -
- -
Mot de Passe (Pass Phrase)
-
Le mot ou la phrase qui protège les fichiers de clés privées. - Il empêche les utilisateurs non autorisés de les déchiffrer. En général, - il s'agit simplement de la clé secrète de chiffrement/déchiffrement - utilisée pour les Algorithmes de chiffrement.
- Voir : chiffrement SSL/TLS -
- -
Nom de domaine entièrement qualifié - (Fully-Qualified Domain-Name) - (FQDN)
-
Le nom unique d'une entité du réseau, comprenant un nom d'hôte et un - nom de domaine qui peuvent être résolus en une adresse IP. Par exemple, - www est un nom d'hôte, example.com est un nom - de domaine, et www.example.com est un nom de domaine - entièrement qualifié. -
- -
- Nombre Magique des Modules - (Module Magic Number) - (MMN)
-
Le Nombre Magique des Modules est une constante définie dans le code - source d'Apache et associée à la compatibilité binaire des modules. - Sa valeur est modifiée quand des structures internes d'Apache, des appels - de fonctions et d'autres parties significatives de l'API sont modifiées - de telle façon que la compatibilité binaire ne peut plus être garantie. - En cas de changement de MMN, tous les modules tiers doivent être au - moins recompilés, et parfois même légèrement modifiés afin de pouvoir - fonctionner avec la nouvelle version d'Apache. -
- -
- Objet Dynamique Partagé (Dynamic Shared Object) - (DSO)
-
Modules compilés en dehors du binaire - Apache httpd et qui peuvent être - chargés à la demande.
- Voir : Support des objets dynamiques partagés -
- -
OpenSSL
-
L'ensemble d'outils Open Source pour SSL/TLS
- Voir http://www.openssl.org/# -
- -
- Outil de gestion des extensions Apache - (APache eXtension Tool) - (apxs)
-
Un script Perl qui aide à la compilation des sources de module sous forme d'Objets Dynamiques Partagés - (Dynamic Shared Objects ou - DSOs) et facilite leur installation - dans le serveur Web Apache.
- Voir : Page de manuel : apxs -
- -
Plein Texte (Plaintext)
-
Le texte non chiffré.
- - - -
Protocole de Transfert Hypertexte - (HyperText Transfer Protocol) - (HTTP)
-
Le protocole de transmission standard utilisé sur le World Wide Web. - Apache implémente la version 1.1 du protocole, référencée comme HTTP/1.1 et - définie par la - RFC 2616. -
- -
Résumé de message - (Message Digest)
-
Un hachage du message, qui peut être utilisé pour vérifier - que son contenu n'a pas été altéré durant le transfert.
- Voir : chiffrement SSL/TLS -
- -
- Sécurité de la couche Transport - (Transport Layer Security) - (TLS)
-
Le protocole successeur de SSL, créé par l'Internet Engineering Task - Force (IETF) pour l'authentification et le chiffrement généraux des - communications dans les réseaux TCP/IP. TLS version 1 est pratiquement - identique à SSL version 3.
- Voir : chiffrement SSL/TLS -
- -
Session
-
Les informations sur le contexte d'une communication en général.
- -
Signature numérique - (Digital Signature)
-
Un bloc de texte crypté qui valide un certificat ou un autre fichier. - Une Autorité de certification - crée une signature en générant une empreinte de la Clé publique - fournie avec le Certificat; la CA chiffre ensuite l'empreinte - avec sa propre Clé privée. Seule la clé publique de la CA - peut décrypter la signature, ce qui permet de vérifier que la CA a bien - authentifié l'entité du réseau qui possède le - Certificat.
- Voir : chiffrement SSL/TLS -
- -
SSLeay
-
La bibliothèque originelle d'implémentation de SSL/TLS développée par - Eric A. Young -
- -
Texte crypté -(Ciphertext)
-
Le résultat du passage d'un document - Plaintext (Plein texte) par un - Cipher.
- Voir : chiffrement SSL/TLS -
- -
Type MIME (MIME-type)
-
Une méthode pour décrire le type de document transmis. Son nom - vient du fait que son format est issu des Multipurpose - Internet Mail Extensions (Extensions Multi-usages de la - Messagerie par Internet) . Il comprend un type majeur et un type - mineur, séparés par un slash (barre oblique). On trouve - entre autres types text/html, - image/gif, et application/octet-stream. Dans - HTTP, le type MIME est transmis dans l' - en-tête Content-Type.
- Voir : mod_mime -
- - -
- Variable d'environnement - (Environment Variable) (env-variable)
-
Ce sont des variables nommées gérées par le shell du système - d'exploitation, et servant au stockage d'informations et à la - communication entre les programmes. Apache possède aussi des variables - internes considérées comme variables d'environnement, mais stockées dans - des structures internes à Apache, et non dans l'environnement - du shell.
- Voir : Les variables d'environnement dans Apache -
- -
X.509
-
Une norme de certificat d'authentification recommandée par l'International - Telecommunication Union (ITU-T) et utilisée pour - l'authentification SSL/TLS.
Voir : chiffrement SSL/TLS -
-
-
-
-

Langues Disponibles:  de  | - en  | - es  | - fr  | - ja  | - ko  | - tr 

-
top

Commentaires

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

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.5

+
+
<-
+

Glossaire

+
+

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

+
+ +

Ce glossaire définit la terminologie courante relative à Apache en + particulier, et aux serveurs web en général. Vous trouverez plus + d'informations sur chaque concept dans les liens fournis.

+
+
top
+
+

Définitions

+
+
Algorithme
+ +
Une formule sans ambiguité ou un jeu de règles destinées à + résoudre un problème en un nombre fini d'étapes. Les algorithmes de + chiffrement sont en général appelés + Ciphers. +
+ +
Algorithme de chiffrement + (Cipher)
+
Un algorithme ou un système de chiffrement des données. + Quelques exemples : DES, IDEA, RC4, etc.
+ Voir : chiffrement SSL/TLS +
+ +
APR
+
Voir "Bibliothèques pour la portabilité d'Apache" +
+ +
Archive Tar (Tarball)
+
Un paquetage de fichiers rassemblés dans une archive + à l'aide de l'utilitaire tar. + Les distributions d'Apache sont stockées dans des Archives Tar compressées + ou en utilisant pkzip. +
+ +
Authentification
+
L'identification formelle d'une entité du réseau comme un serveur, un + client, ou un utilisateur.
+ Voir : Authentification, Autorisation, et + contrôle d'accès +
+ +
Autorité de Certification + (Certification Authority) + (CA)
+
Un tiers de confiance habilité à signer des certificats pour des entités + du réseau qu'il a authentifiées selon des critères basés sur la sécurité. + Les autres entités du réseau peuvent alors utiliser la signature pour + vérifier qu'une CA a authentifié le porteur du certificat.
+ Voir : chiffrement SSL/TLS +
+ +
Bibliothèques pour la portabilité d'Apache + (Apache Portable Runtime) (APR)
+
Un jeu de bibliothèques qui fournit la plupart des interfaces de base + entre le serveur et le système d'exploitation. APR est développé + parallèlement au serveur HTTP Apache comme projet indépendant.
+ Voir : Apache Portable Runtime + Project +
+ + +
Certificat (Certificate)
+
Un ensemble de données servant à authentifier des entités du + réseau comme un serveur ou un client. Un certificat contient des ensembles + d'informations X509 à propos de son propriétaire (appelé sujet/subject) + et de l'Autorité de Certification + (Certification Authority) ou CA signataire (appelée + le fournisseur/issuer), ainsi que la + clé publique (public + key) du propriétaire et la + signature de la CA. Les entités du réseau vérifient ces signatures + en utilisant les certificats des Autorités de Certification.
+ Voir : chiffrement SSL/TLS +
+ +
Chiffrement à Clé Publique + (Public Key Cryptography)
+
L'étude et l'application des systèmes de chiffrement asymétriques, + qui utilisent une clé pour le chiffrement et une autre pour le + déchiffrement. Les deux clés correspondantes constituent une paire de clés. + Appelé aussi chiffrement asymétrique. +
+ Voir : chiffrement SSL/TLS +
+ +
Clé Privée (Private Key)
+
La clé secrète dans un système de + chiffrement à clé publique, + utilisée pour déchiffrer les messages entrants et signer + les messages sortants.
+ Voir : chiffrement SSL/TLS +
+ +
Clé Publique (Public Key)
+
La clé accessible au public dans un système de Chiffrement à clé publique, + utilisée pour chiffrer les messages destinés uniquement à son + propriétaire et déchiffrer les signatures + faites par son propriétaire.
+ Voir : chiffrement SSL/TLS +
+ +
CONNECT
+
Une méthode HTTP pour encapsuler + des données brutes dans HTTP. Elle peut aussi être utilisée pour encapsuler + d'autres protocoles, comme le protocole SSL. +
+ +
Contexte (Context)
+
Une portion des + fichiers de configuration dans laquelle certains types de + directives sont autorisés.
+ Voir : Termes utilisés + pour décrire les directives d'Apache +
+ +
Contrôle d'accès + (Access Control)
+
La restriction d'accès à des zones du réseau. Habituellement + dans un contexte Apache, + la restriction d'accès à certaines URLs.
+ Voir : Authentification, Autorisation et + Contrôle d'accès +
+ +
+ Couche des Points de connexion Sécurisés + (Secure Sockets Layer) + (SSL)
+
Un protocole créé par Netscape Communications Corporation pour + l'authentification et le chiffrement généraux des communications dans les + réseaux TCP/IP. L'utilisation la plus connue est HTTPS, autrement dit + le Protocole de Transfert Hypertexte (HTTP) au dessus de SSL.
+ Voir : chiffrement SSL/TLS +
+ +
Sous-requête
+
Apache possède une API des sous-requêtes pour les modules qui + permettent l'évaluation complète ou partielle par le serveur de + chemins d'autres systèmes de fichiers ou d'URL. Par exemple, la + directive DirectoryIndex, + les modules mod_autoindex et + mod_include utilisent cette API. +
+ +
+ Cryptographie Symétrique (Symmetric Cryptography)
+
L'étude et l'application des Algorithmes de chiffrement qui + utilisent une clé secrète unique pour les opérations de chiffrement et de + déchiffrement.
+ Voir : chiffrement SSL/TLS +
+ + +
+ Dégradé pour l'exportation + (Export-Crippled)
+
Diminué en terme de puissance cryptographique (et de sécurité) + afin de respecter les Règles de l'Administration des Exportations + des Etats-Unis (Export Administration Regulations ou EAR). + Les logiciels de cryptographie dégradés pour l'exportation sont limités + à une clé de petite taille, et produisent un + Texte crypté qui peut en général être décrypté + par force brute.
+ Voir : chiffrement SSL/TLS +
+ + +
Demande de signature de certificat + (Certificate Signing Request) + (CSR)
+
La soumission d'un certificat + non signé à une Autorité de + certification, qui le signe avec la Clé privée de leur + Certificat de CA. Une fois le CSR signé, il devient un vrai + certificat.
+ Voir : chiffrement SSL/TLS +
+ +
Directive
+
Une commande de configuration qui contrôle un ou plusieurs aspects du + comportement d'Apache. Les directives sont placées dans le Fichier de configuration
+ Voir : Index des directives +
+ +
Directive de configuration + (Configuration Directive)
+
Voir : Directive
+ +
En-tête (Header)
+
La partie de la requête et de la réponse + HTTP qui est envoyée avant le contenu + proprement dit, et contient des méta-informations décrivant le contenu. +
+ +
Expression Rationnelle + (Regular Expression) + (Regex)
+
Une méthode pour décrire un modèle sous forme de texte - par exemple, + "tous les mots qui commencent par la lettre A" ou "tous les numéros de + téléphone à 10 chiffres" ou encore "Toutes les phrases contenant 2 virgules, + et aucun Q majuscule". Les expressions rationnelles sont très utiles dans + Apache car elles vous permettent d'appliquer certains attributs à des + ensembles de fichiers ou ressources avec une grande flexibilité + - par exemple, tous les fichiers .gif et .jpg situés dans tout répertoire + nommé "images", pourraient être enregistrés comme + "/images/.*(jpg|gif)$". Lorsque l'on utilise des + expressions rationnelles pour la substitution de chaînes, les + variables spéciales $1 ... $9 contiennent des références arrières + vers les parties regroupées (entre parenthèses) de l'expression + qui correspond. La variable spéciale $0 contient une référence + arrière vers l'ensemble de l'expression qui correspond. Pour + insérer un caractère littéral "dollar" dans la chaîne de + remplacement, il faut l'échapper avec un anti-slash. Pour des + raisons historiques, la variable & peut être utilisée en tant + qu'alias de $0 dans certains cas, mais ceci n'est plus possible + depuis la version 2.3.6. Apache utilise les Expressions + Rationnelles Compatibles avec Perl fournies par la librairie PCRE. Vous trouverez plus + d'information à propos de la syntaxe des expressions rationnelles + PCRE sur ce site, ou dans le Wikipedia de la PCRE. +
+ +
+ Fichier de configuration + (Configuration File)
+
Un fichier texte contenant des + Directives + qui contrôlent la configuration d'Apache.
+ Voir : Fichiers de configuration +
+ +
Filtre (Filter)
+
Un traitement appliqué aux données envoyées ou reçues par le serveur. + Les filtres en entrée traitent les données envoyées au serveur par le + client, alors que les filtres en sortie traitent les documents sur le + serveur avant qu'ils soient envoyés au client. + Par exemple, le filtre en sortie + INCLUDES + traite les documents pour les + Server Side Includes (Inclusions côté Serveur) + .
+ Voir : Filtres +
+ +
Gestionnaire (Handler)
+
Une représentation interne à Apache de l'action à entreprendre + quand un fichier est appelé. En général, les fichiers ont des gestionnaires + implicites, basés sur le type de fichier. Normalement, tous les + fichiers sont directement servis par le serveur, mais certains + types de fichiers sont "gérés" séparément. Par exemple, le gestionnaire + cgi-script désigne les fichiers qui doivent être traités + comme CGIs.
+ Voir : Utilisation des gestionnaires d'Apache +
+ +
Hachage (Hash)
+
Un algorithme mathématique à sens unique, irréversible, générant une + chaîne de longueur fixe à partir d'une autre chaîne de longueur quelconque. + Des chaînes différentes en entrée vont normalement produire des chaînes + différentes en sortie (selon la fonction de hachage). +
+ +
Hébergement Virtuel + (Virtual Hosting)
+
Servir des sites web multiples en utilisant une seule instance d'Apache. + Les Hôtes virtuels basés sur IP différencient les sites web en se + basant sur leur adresse IP, alors que les + Hôtes virtuels basés sur le nom utilisent uniquement le nom d'hôte + et peuvent en conséquence héberger de nombreux sites avec la même + adresse IP.
+ Voir la Documentation des Hôtes Virtuels d'Apache +
+ + +
.htaccess
+
Un fichier de configuration + placé à un certain niveau de l'arborescence du site web, et appliquant des + directives de configuration au + répertoire dans lequel il est placé, ainsi qu'à tous ses sous-répertoires. + En dépit de son nom, ce fichier peut contenir pratiquement tout type de + directive, et pas seulement des directives de contrôle d'accès.
+ Voir : Fichiers de configuration +
+ +
httpd.conf
+
Le fichier de configuration + principal d'Apache. Sa localisation par défaut est + /usr/local/apache2/conf/httpd.conf, mais ceci peut être + changé en utilisant des options de compilation ou d'exécution.
+ Voir : Fichiers de configuration +
+ +
HTTPS
+
Le Protocole de Transfert Hypertexte (Sécurisé), le mécanisme de + communication cryptée standard sur le World Wide Web. + Il s'agit en fait de HTTP au dessus de + SSL.
+ Voir : chiffrement SSL/TLS +
+ +
Identificateur de Ressource Uniformisé + (Uniform Resource Identifier) + (URI)
+
Une chaîne de caractères compacte servant à identifier une ressource + abstraite ou physique. Elle est formellement définie par la RFC 2396. Les URIs + utilisées sur le world-wide web sont souvent appelées URLs. +
+ +
+ Inclusions Côté Serveur + (Server Side Includes) (SSI) +
+
Une technique permettant d'englober des directives de traitement dans + des fichiers HTML.
+ Voir : Introduction aux Inclusions Côté Serveur +
+ +
Indication du nom du serveur (SNI)
+
Une fonctionnalité SSL permettant de spécifier le + nom du serveur désiré dans le message initial de la + négociation SSL, de façon à ce que le serveur web + puisse choisir la bonne configuration de serveur virtuel à + utiliser pendant le déroulement de la négociation SSL. + Cette fonctionnalité a été ajoutée + à SSL lorsque sont apparues les extensions TLS, RFC 3546.
+ Voir la FAQ SSL + et la RFC 3546 +
+ + + +
+Interface commune avec les programmes externes +(Common Gateway Interface) + (CGI)
+
La définition standard d'une interface entre un serveur web et un + programme externe pour permettre à ce dernier de traiter des requêtes. + Il existe une RFC + informationnelle qui en couvre les spécificités.
+ Voir : Contenu dynamique avec CGI +
+ + + +
+Localisation de Ressource Uniformisée +(Uniform Resource Locator) + (URL)
+
Le nom/adresse d'une ressource sur l'Internet. Il s'agit du terme + informel commun pour ce qui est formellement défini comme + Identificateur de Ressource Uniformisé. + Les URLs sont généralement construites selon un schéma, comme + http ou + https, un nom d'hôte, et un chemin. Une URL pour cette page + pourrait être + http://httpd.apache.org/docs/trunk/glossary.html. +
+ + +
Mandataire (Proxy)
+
Un serveur intermédiaire qui se situe entre le client et le + serveur d'origine. + Il prend en compte les requêtes des clients, les transmet au serveur + d'origine, puis renvoie la réponse du serveur d'origine au client. + Si plusieurs clients demandent le même contenu, le mandataire peut l'extraire + de son cache, plutôt que le demander au serveur d'origine + à chaque fois, ce qui réduit le temps de réponse.
+ Voir : mod_proxy +
+ +
Mandataire inverse + (Reverse Proxy)
+
Un serveur mandataire qui est vu du client + comme un serveur d'origine. Ceci peut s'avérer utile pour + dissimuler le serveur d'origine réel au client pour des raisons de sécurité, + ou pour répartir la charge. +
+ +
Méthode (Method)
+
Dans le contexte HTTP, une action à + effectuer sur une ressource spécifiée dans la ligne de requête + par le client. Parmi les méthodes disponibles dans HTTP, on trouve + GET, POST, + et PUT. +
+ +
Module
+
Une partie indépendante d'un programme. De nombreuses fonctionnalités + d'Apache sont fournies par des modules que vous pouvez choisir d'inclure + ou d'exclure. Les modules qui sont compilés dans le binaire + httpd sont appelés modules statiques, alors + que les modules qui existent séparément et peuvent être chargés + optionnellement à l'exécution sont appelés + modules dynamiques ou DSOs. + Les modules qui sont inclus par défaut sont appelés + modules de base. De nombreux modules disponibles pour Apache + ne se trouvent pas dans l'archive + du Serveur HTTP Apache . Il sont appelés + modules tiers.
+ Voir : Index des modules +
+ +
Mot de Passe (Pass Phrase)
+
Le mot ou la phrase qui protège les fichiers de clés privées. + Il empêche les utilisateurs non autorisés de les déchiffrer. En général, + il s'agit simplement de la clé secrète de chiffrement/déchiffrement + utilisée pour les Algorithmes de chiffrement.
+ Voir : chiffrement SSL/TLS +
+ +
Nom de domaine entièrement qualifié + (Fully-Qualified Domain-Name) + (FQDN)
+
Le nom unique d'une entité du réseau, comprenant un nom d'hôte et un + nom de domaine qui peuvent être résolus en une adresse IP. Par exemple, + www est un nom d'hôte, example.com est un nom + de domaine, et www.example.com est un nom de domaine + entièrement qualifié. +
+ +
+ Nombre Magique des Modules + (Module Magic Number) + (MMN)
+
Le Nombre Magique des Modules est une constante définie dans le code + source d'Apache et associée à la compatibilité binaire des modules. + Sa valeur est modifiée quand des structures internes d'Apache, des appels + de fonctions et d'autres parties significatives de l'API sont modifiées + de telle façon que la compatibilité binaire ne peut plus être garantie. + En cas de changement de MMN, tous les modules tiers doivent être au + moins recompilés, et parfois même légèrement modifiés afin de pouvoir + fonctionner avec la nouvelle version d'Apache. +
+ +
+ Objet Dynamique Partagé (Dynamic Shared Object) + (DSO)
+
Modules compilés en dehors du binaire + Apache httpd et qui peuvent être + chargés à la demande.
+ Voir : Support des objets dynamiques partagés +
+ +
OpenSSL
+
L'ensemble d'outils Open Source pour SSL/TLS
+ Voir http://www.openssl.org/# +
+ +
+ Outil de gestion des extensions Apache + (APache eXtension Tool) + (apxs)
+
Un script Perl qui aide à la compilation des sources de module sous forme d'Objets Dynamiques Partagés + (Dynamic Shared Objects ou + DSOs) et facilite leur installation + dans le serveur Web Apache.
+ Voir : Page de manuel : apxs +
+ +
Plein Texte (Plaintext)
+
Le texte non chiffré.
+ + + +
Protocole de Transfert Hypertexte + (HyperText Transfer Protocol) + (HTTP)
+
Le protocole de transmission standard utilisé sur le World Wide Web. + Apache implémente la version 1.1 du protocole, référencée comme HTTP/1.1 et + définie par la + RFC 2616. +
+ +
Résumé de message + (Message Digest)
+
Un hachage du message, qui peut être utilisé pour vérifier + que son contenu n'a pas été altéré durant le transfert.
+ Voir : chiffrement SSL/TLS +
+ +
+ Sécurité de la couche Transport + (Transport Layer Security) + (TLS)
+
Le protocole successeur de SSL, créé par l'Internet Engineering Task + Force (IETF) pour l'authentification et le chiffrement généraux des + communications dans les réseaux TCP/IP. TLS version 1 est pratiquement + identique à SSL version 3.
+ Voir : chiffrement SSL/TLS +
+ +
Session
+
Les informations sur le contexte d'une communication en général.
+ +
Signature numérique + (Digital Signature)
+
Un bloc de texte crypté qui valide un certificat ou un autre fichier. + Une Autorité de certification + crée une signature en générant une empreinte de la Clé publique + fournie avec le Certificat; la CA chiffre ensuite l'empreinte + avec sa propre Clé privée. Seule la clé publique de la CA + peut décrypter la signature, ce qui permet de vérifier que la CA a bien + authentifié l'entité du réseau qui possède le + Certificat.
+ Voir : chiffrement SSL/TLS +
+ +
SSLeay
+
La bibliothèque originelle d'implémentation de SSL/TLS développée par + Eric A. Young +
+ +
Texte crypté +(Ciphertext)
+
Le résultat du passage d'un document + Plaintext (Plein texte) par un + Cipher.
+ Voir : chiffrement SSL/TLS +
+ +
Type MIME (MIME-type)
+
Une méthode pour décrire le type de document transmis. Son nom + vient du fait que son format est issu des Multipurpose + Internet Mail Extensions (Extensions Multi-usages de la + Messagerie par Internet) . Il comprend un type majeur et un type + mineur, séparés par un slash (barre oblique). On trouve + entre autres types text/html, + image/gif, et application/octet-stream. Dans + HTTP, le type MIME est transmis dans l' + en-tête Content-Type.
+ Voir : mod_mime +
+ + +
+ Variable d'environnement + (Environment Variable) (env-variable)
+
Ce sont des variables nommées gérées par le shell du système + d'exploitation, et servant au stockage d'informations et à la + communication entre les programmes. Apache possède aussi des variables + internes considérées comme variables d'environnement, mais stockées dans + des structures internes à Apache, et non dans l'environnement + du shell.
+ Voir : Les variables d'environnement dans Apache +
+ +
X.509
+
Une norme de certificat d'authentification recommandée par l'International + Telecommunication Union (ITU-T) et utilisée pour + l'authentification SSL/TLS.
Voir : chiffrement SSL/TLS +
+
+
+
+

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

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/handler.html b/docs/manual/handler.html index 9c6568d380..a600c55b62 100644 --- a/docs/manual/handler.html +++ b/docs/manual/handler.html @@ -6,7 +6,7 @@ Content-type: text/html; charset=ISO-8859-1 URI: handler.html.es Content-Language: es -Content-type: text/html; charset=ISO-8859-1 +Content-type: text/html; charset=UTF-8 URI: handler.html.fr Content-Language: fr diff --git a/docs/manual/handler.html.en b/docs/manual/handler.html.en index 69c5527ae1..7a64682f14 100644 --- a/docs/manual/handler.html.en +++ b/docs/manual/handler.html.en @@ -24,11 +24,11 @@ Apache > HTTP Server > Documentation > Version 2.5

Apache's Handler Use

Available Languages:  en  | - es  | - fr  | + es  | + fr  |  ja  |  ko  | - tr  | + tr  |  zh-cn 

@@ -149,11 +149,11 @@ AddHandler add-footer .html

Available Languages:  en  | - es  | - fr  | + es  | + fr  |  ja  |  ko  | - tr  | + tr  |  zh-cn 

top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
- - -
-

Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

-

Versin 2.5 del Servidor HTTP Apache

-
-
<-
-

Uso de los Handlers en Apache

-
-

Idiomas disponibles:  en  | - es  | - fr  | - ja  | - ko  | - tr  | - zh-cn 

-
- -

Este documento describe el uso de los Handlers en Apache.

-
- -
top
-
-

Qu es un Handler?

- -
Mdulos RelacionadosDirectivas Relacionadas
- - -

Un "handler" es una representacin interna de Apache de - una accin que se va a ejecutar cuando hay una llamada a un - fichero. Generalmente, los ficheros tienen handlers - implcitos, basados en el tipo de fichero de que se - trata. Normalmente, todos los ficheros son simplemente servidos - por el servidor, pero algunos tipos de ficheros se tratan de forma - diferente.

- -

Handlers pueden ser usados de manera explicita, - basndose en la extensin del fichero o en - la ubicacin en la que est, se pueden especificar handlers - sin tener en cuenta el tipo de fichero que se trate. Esto es - una ventaja por dos razones. Primero, es una solucin - ms elegante. Segundo, porque a un fichero se le pueden - asignar tanto un tipo como un handler. (Consulte - tambin la seccin Ficheros y extensiones - mltiples.)

- -

Los Handlers pueden tanto ser compilados con el servidor - como incluidos en un mdulo, o aadidos con la - directiva Action. Los - handlers que vienen incluidos en el core con el servidor de la distribucin - estndar de Apache son:

- -
    -
  • default-handler: Enva el fichero - usando el default_handler(), que es el handler - usado por defecto para tratar contenido - esttico. (core)
    • - -
  • send-as-is: Enva el fichero con - cabeceras HTTP tal y como es. (mod_asis)
    • - -
  • cgi-script: Trata el fichero como un sript - CGI. (mod_cgi)
    • - -
  • imap-file: Trata el fichero como un mapa de - imgenes. (mod_imagemap)
    • - -
  • server-info: Extrae la informacin de - configuracin del - servidor. (mod_info)
    • - -
  • server-status: Extrae el informe del estado - del servidor. (mod_status)
    • - -
  • type-map: Trata el fichero como una - correspondencia de tipos para la negociacin de contenidos. - (mod_negotiation)
    • -
-
top
-
-

Ejemplos

- - -

Modificar contenido esttico usando un script - CGI

- - -

Las siguientes directivas hacen que cuando haya una - peticin de ficheros con la extensin - html se lance el script CGI - footer.pl.

- -

- Action add-footer /cgi-bin/footer.pl
- AddHandler add-footer .html -

- -

En este caso, el script CGI es el responsable de enviar el - documento originalmente solicitado (contenido en la variable de - entorno PATH_TRANSLATED) y de hacer cualquier - modificacin o aadido deseado.

- - -

Archivos con cabeceras HTTP

- - -

Las siguientes directivas activan el handler - send-as-is, que se usa para ficheros que contienen - sus propias cabeceras HTTP. Todos los archivos en el directorio - /web/htdocs/asis/ sern procesados por el - handler send-as-is, sin tener en cuenta su - extension.

- - 
<Directory "/web/htdocs/asis">
-    SetHandler send-as-is
-</Directory>
- - - -
top
-
-

Nota para programadores

- - -

Para implementar las funcionalidades de los handlers, se ha - hecho un aadido a la API de - Apache que puede que quiera usar. Para ser ms - especficos, se ha aadido un nuevo registro a la - estructura request_rec:

- - 
char *handler
- - -

Si quiere que su mdulo llame a un handler , solo tiene - que aadir r->handler al nombre del handler - en cualquier momento antes de la fase invoke_handler - de la peticin. Los handlers se implementan siempre como se - haca antes, aunque usando el nombre del handler en vez de un - tipo de contenido. Aunque no es de obligado cumplimiento, la - convencin de nombres para los handlers es que se usen - palabras separadas por guiones, sin barras, de manera que no se - invada el media type name-space.

-
-
-

Idiomas disponibles:  en  | - es  | - fr  | - ja  | - ko  | - tr  | - zh-cn 

-
top

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
-
- \ No newline at end of file diff --git a/docs/manual/handler.html.es.utf8 b/docs/manual/handler.html.es.utf8 new file mode 100644 index 0000000000..d284f63476 --- /dev/null +++ b/docs/manual/handler.html.es.utf8 @@ -0,0 +1,195 @@ + + + + + +Uso de los Handlers en Apache - Servidor HTTP Apache Versin 2.5 + + + + + + +
+

Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

+

Versin 2.5 del Servidor HTTP Apache

+
+
<-
+

Uso de los Handlers en Apache

+
+

Idiomas disponibles:  en  | + es  | + fr  | + ja  | + ko  | + tr  | + zh-cn 

+
+ +

Este documento describe el uso de los Handlers en Apache.

+
+ +
top
+
+

Qu es un Handler?

+ +
Mdulos RelacionadosDirectivas Relacionadas
+ + +

Un "handler" es una representacin interna de Apache de + una accin que se va a ejecutar cuando hay una llamada a un + fichero. Generalmente, los ficheros tienen handlers + implcitos, basados en el tipo de fichero de que se + trata. Normalmente, todos los ficheros son simplemente servidos + por el servidor, pero algunos tipos de ficheros se tratan de forma + diferente.

+ +

Handlers pueden ser usados de manera explicita, + basndose en la extensin del fichero o en + la ubicacin en la que est, se pueden especificar handlers + sin tener en cuenta el tipo de fichero que se trate. Esto es + una ventaja por dos razones. Primero, es una solucin + ms elegante. Segundo, porque a un fichero se le pueden + asignar tanto un tipo como un handler. (Consulte + tambin la seccin Ficheros y extensiones + mltiples.)

+ +

Los Handlers pueden tanto ser compilados con el servidor + como incluidos en un mdulo, o aadidos con la + directiva Action. Los + handlers que vienen incluidos en el core con el servidor de la distribucin + estndar de Apache son:

+ +
    +
  • default-handler: Enva el fichero + usando el default_handler(), que es el handler + usado por defecto para tratar contenido + esttico. (core)
    • + +
  • send-as-is: Enva el fichero con + cabeceras HTTP tal y como es. (mod_asis)
    • + +
  • cgi-script: Trata el fichero como un sript + CGI. (mod_cgi)
    • + +
  • imap-file: Trata el fichero como un mapa de + imgenes. (mod_imagemap)
    • + +
  • server-info: Extrae la informacin de + configuracin del + servidor. (mod_info)
    • + +
  • server-status: Extrae el informe del estado + del servidor. (mod_status)
    • + +
  • type-map: Trata el fichero como una + correspondencia de tipos para la negociacin de contenidos. + (mod_negotiation)
    • +
+
top
+
+

Ejemplos

+ + +

Modificar contenido esttico usando un script + CGI

+ + +

Las siguientes directivas hacen que cuando haya una + peticin de ficheros con la extensin + html se lance el script CGI + footer.pl.

+ +

+ Action add-footer /cgi-bin/footer.pl
+ AddHandler add-footer .html +

+ +

En este caso, el script CGI es el responsable de enviar el + documento originalmente solicitado (contenido en la variable de + entorno PATH_TRANSLATED) y de hacer cualquier + modificacin o aadido deseado.

+ + +

Archivos con cabeceras HTTP

+ + +

Las siguientes directivas activan el handler + send-as-is, que se usa para ficheros que contienen + sus propias cabeceras HTTP. Todos los archivos en el directorio + /web/htdocs/asis/ sern procesados por el + handler send-as-is, sin tener en cuenta su + extension.

+ + 
<Directory "/web/htdocs/asis">
+    SetHandler send-as-is
+</Directory>
+ + + +
top
+
+

Nota para programadores

+ + +

Para implementar las funcionalidades de los handlers, se ha + hecho un aadido a la API de + Apache que puede que quiera usar. Para ser ms + especficos, se ha aadido un nuevo registro a la + estructura request_rec:

+ + 
char *handler
+ + +

Si quiere que su mdulo llame a un handler , solo tiene + que aadir r->handler al nombre del handler + en cualquier momento antes de la fase invoke_handler + de la peticin. Los handlers se implementan siempre como se + haca antes, aunque usando el nombre del handler en vez de un + tipo de contenido. Aunque no es de obligado cumplimiento, la + convencin de nombres para los handlers es que se usen + palabras separadas por guiones, sin barras, de manera que no se + invada el media type name-space.

+
+
+

Idiomas disponibles:  en  | + es  | + fr  | + ja  | + ko  | + tr  | + zh-cn 

+
top

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/handler.html.fr b/docs/manual/handler.html.fr deleted file mode 100644 index e048c0631a..0000000000 --- a/docs/manual/handler.html.fr +++ /dev/null @@ -1,188 +0,0 @@ - - - - - -Utilisation des gestionnaires d'Apache (handlers) - Serveur HTTP Apache Version 2.5 - - - - - - -
-

Modules | Directives | FAQ | Glossaire | Plan du site

-

Serveur HTTP Apache Version 2.5

-
-
<-
-

Utilisation des gestionnaires d'Apache (handlers)

-
-

Langues Disponibles:  en  | - es  | - fr  | - ja  | - ko  | - tr  | - zh-cn 

-
- -

Ce document décrit l'utilisation des gestionnaires d'Apache (handlers).

-
- -
top
-
-

Qu'est-ce qu'un gestionnaire ?

- -
Modules ApparentésDirectives Apparentées
- - -

Un "gestionnaire" est une représentation interne à Apache de l'action - qui doit être entreprise quand un fichier est appelé. En général, les - fichiers ont des gestionnaires implicites, basés sur le type du fichier. - Normalement, tous les fichiers sont traités simplement par le serveur, - mais certains types de fichiers sont "gérés" séparément.

- -

Les gestionnaires peuvent aussi être configurés explicitement, - soit en fonction des extensions des noms de fichier, soit en fonction - du chemin du fichier, - sans faire référence au type de fichier. Ceci a le double avantage d'être - une solution plus élégante, et aussi d'autoriser à associer à la fois - un type et un gestionnaire avec un fichier. (Voir aussi Fichiers avec extensions - multiples.)

- -

Les gestionnaires peuvent être soit partie intégrante - du serveur ou inclus dans un module, soit ajoutés à l'aide de la directive - Action. Les gestionnaires - intégrés dans la distribution standard se présentent comme suit :

- -
    -
  • default-handler: envoie le fichier en utilisant - le default_handler(), qui est le gestionnaire utilisé par - défaut pour traiter les contenus statiques. (core)
    • - -
  • send-as-is: envoie les fichiers avec en-têtes HTTP - tels quels. (mod_asis)
    • - -
  • cgi-script: traite le fichier comme un - script CGI. (mod_cgi)
    • - -
  • imap-file: Traite le fichier comme un ensemble - de règles de descriptions d'images (imagemap). - (mod_imagemap)
    • - -
  • server-info: Extrait des informations sur la - configuration du serveur. (mod_info)
    • - -
  • server-status: Rédige un rapport sur le statut - du serveur. (mod_status)
    • - -
  • type-map: Traite le fichier comme une description - de type pour la négociation du contenu. - (mod_negotiation)
    • -
-
top
-
-

Exemples

- - -

Modification d'un contenu statique à l'aide d'un script CGI

- - -

Les directives suivantes vont faire en sorte que les requêtes pour - des fichiers possédant une extension html déclenchent - l'exécution du script CGI footer.pl.

- - 
Action add-footer /cgi-bin/footer.pl
-AddHandler add-footer .html
- - -

À ce moment-là, le script CGI se charge d'envoyer le document - initialement demandé (référencé par la variable d'environnement - PATH_TRANSLATED) et d'effectuer tous ajout ou modification - voulus.

- - -

Fichiers avec en-têtes HTTP

- - -

Les directives suivantes vont activer le gestionnaire - send-as-is, qui est utilisé pour les fichiers qui possèdent - leurs propres en-têtes HTTP. Tous les fichiers situés dans le répertoire - /web/htdocs/asis/ seront traités par le gestionnaire - send-as-is, sans tenir compte de l'extension - de leur nom de fichier.

- - 
<Directory "/web/htdocs/asis">
-    SetHandler send-as-is
-</Directory>
- - - -
top
-
-

Note du développeur

- - -

Pour implémenter la fonctionnalité des gestionnaires, l' - API Apache a fait l'objet d'un ajout - que vous pourriez être amené à utiliser. - - Plus précisément, un nouvel enregistrement a été ajouté à la structure - request_rec :

- - 
char *handler
- - -

Si vous voulez que votre module déclenche l'utilisation d'un - gestionnaire, il vous suffit de définir r->handler avec - le nom du gestionnaire à n'importe quel moment avant l'étape - invoke_handler - de la requête. Les gestionnaires sont implémentés comme auparavant, - quoique l'on utilise le nom du gestionnaire à la place d'un type - de contenu. Bien que ce ne soit pas obligatoire, la convention de nommage - des gestionnaires stipule l'utilisation d'un mot composé séparé par des - tirets, sans slashes, afin de ne pas interférer avec l'espace de nommage - des types de média.

-
-
-

Langues Disponibles:  en  | - es  | - fr  | - ja  | - ko  | - tr  | - zh-cn 

-
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
-
- \ No newline at end of file diff --git a/docs/manual/handler.html.fr.utf8 b/docs/manual/handler.html.fr.utf8 new file mode 100644 index 0000000000..e048c0631a --- /dev/null +++ b/docs/manual/handler.html.fr.utf8 @@ -0,0 +1,188 @@ + + + + + +Utilisation des gestionnaires d'Apache (handlers) - Serveur HTTP Apache Version 2.5 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.5

+
+
<-
+

Utilisation des gestionnaires d'Apache (handlers)

+
+

Langues Disponibles:  en  | + es  | + fr  | + ja  | + ko  | + tr  | + zh-cn 

+
+ +

Ce document décrit l'utilisation des gestionnaires d'Apache (handlers).

+
+ +
top
+
+

Qu'est-ce qu'un gestionnaire ?

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

Un "gestionnaire" est une représentation interne à Apache de l'action + qui doit être entreprise quand un fichier est appelé. En général, les + fichiers ont des gestionnaires implicites, basés sur le type du fichier. + Normalement, tous les fichiers sont traités simplement par le serveur, + mais certains types de fichiers sont "gérés" séparément.

+ +

Les gestionnaires peuvent aussi être configurés explicitement, + soit en fonction des extensions des noms de fichier, soit en fonction + du chemin du fichier, + sans faire référence au type de fichier. Ceci a le double avantage d'être + une solution plus élégante, et aussi d'autoriser à associer à la fois + un type et un gestionnaire avec un fichier. (Voir aussi Fichiers avec extensions + multiples.)

+ +

Les gestionnaires peuvent être soit partie intégrante + du serveur ou inclus dans un module, soit ajoutés à l'aide de la directive + Action. Les gestionnaires + intégrés dans la distribution standard se présentent comme suit :

+ +
    +
  • default-handler: envoie le fichier en utilisant + le default_handler(), qui est le gestionnaire utilisé par + défaut pour traiter les contenus statiques. (core)
    • + +
  • send-as-is: envoie les fichiers avec en-têtes HTTP + tels quels. (mod_asis)
    • + +
  • cgi-script: traite le fichier comme un + script CGI. (mod_cgi)
    • + +
  • imap-file: Traite le fichier comme un ensemble + de règles de descriptions d'images (imagemap). + (mod_imagemap)
    • + +
  • server-info: Extrait des informations sur la + configuration du serveur. (mod_info)
    • + +
  • server-status: Rédige un rapport sur le statut + du serveur. (mod_status)
    • + +
  • type-map: Traite le fichier comme une description + de type pour la négociation du contenu. + (mod_negotiation)
    • +
+
top
+
+

Exemples

+ + +

Modification d'un contenu statique à l'aide d'un script CGI

+ + +

Les directives suivantes vont faire en sorte que les requêtes pour + des fichiers possédant une extension html déclenchent + l'exécution du script CGI footer.pl.

+ + 
Action add-footer /cgi-bin/footer.pl
+AddHandler add-footer .html
+ + +

À ce moment-là, le script CGI se charge d'envoyer le document + initialement demandé (référencé par la variable d'environnement + PATH_TRANSLATED) et d'effectuer tous ajout ou modification + voulus.

+ + +

Fichiers avec en-têtes HTTP

+ + +

Les directives suivantes vont activer le gestionnaire + send-as-is, qui est utilisé pour les fichiers qui possèdent + leurs propres en-têtes HTTP. Tous les fichiers situés dans le répertoire + /web/htdocs/asis/ seront traités par le gestionnaire + send-as-is, sans tenir compte de l'extension + de leur nom de fichier.

+ + 
<Directory "/web/htdocs/asis">
+    SetHandler send-as-is
+</Directory>
+ + + +
top
+
+

Note du développeur

+ + +

Pour implémenter la fonctionnalité des gestionnaires, l' + API Apache a fait l'objet d'un ajout + que vous pourriez être amené à utiliser. + + Plus précisément, un nouvel enregistrement a été ajouté à la structure + request_rec :

+ + 
char *handler
+ + +

Si vous voulez que votre module déclenche l'utilisation d'un + gestionnaire, il vous suffit de définir r->handler avec + le nom du gestionnaire à n'importe quel moment avant l'étape + invoke_handler + de la requête. Les gestionnaires sont implémentés comme auparavant, + quoique l'on utilise le nom du gestionnaire à la place d'un type + de contenu. Bien que ce ne soit pas obligatoire, la convention de nommage + des gestionnaires stipule l'utilisation d'un mot composé séparé par des + tirets, sans slashes, afin de ne pas interférer avec l'espace de nommage + des types de média.

+
+
+

Langues Disponibles:  en  | + es  | + fr  | + ja  | + ko  | + tr  | + zh-cn 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/access.html b/docs/manual/howto/access.html index 1915a70d6b..ae2f834100 100644 --- a/docs/manual/howto/access.html +++ b/docs/manual/howto/access.html @@ -6,7 +6,7 @@ Content-type: text/html; charset=ISO-8859-1 URI: access.html.es Content-Language: es -Content-type: text/html; charset=ISO-8859-1 +Content-type: text/html; charset=UTF-8 URI: access.html.fr Content-Language: fr diff --git a/docs/manual/howto/access.html.en b/docs/manual/howto/access.html.en index 1d71b58002..bc80567287 100644 --- a/docs/manual/howto/access.html.en +++ b/docs/manual/howto/access.html.en @@ -24,8 +24,8 @@ Apache > HTTP Server > Documentation > Version 2.5 > How-To / Tutorials

Access Control

Available Languages:  en  | - es  | - fr 

+ es  | + fr 

Access control refers to any means of controlling access to any @@ -201,8 +201,8 @@ RewriteRule "^/fridge" "-" [F]

Available Languages:  en  | - es  | - fr 

+ es  | + fr 

top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
- - -
-

Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

-

Versin 2.5 del Servidor HTTP Apache

-
-
<-
-

Control de Acceso

-
-

Idiomas disponibles:  en  | - es  | - fr 

-
- -

El control de acceso, hace referencia a todos los medios que proporcionan - una forma de controlar el acceso a cualquier recurso. Esta parte est - separada de autenticacin y autorizacin.

-
- -
top
-
-

Mdulos y Directivas relacionados

- -

El control de acceso puede efectuarse mediante diferentes mdulos. Los - ms importantes de stos son mod_authz_core y - mod_authz_host. Tambin se habla en este documento de - el control de acceso usando el mdulo mod_rewrite.

- -
top
-
-

Control de Acceso por host

-

- Si lo que se quiere es restringir algunas zonas del sitio web, basndonos - en la direccin del visitante, esto puede ser realizado de manera - fcil con el mdulo mod_authz_host. -

- -

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

- -

- Las directivas Allow, - Deny, y - Order, - proporcionadas por mod_access_compat, estn obsoletas y - sern quitadas en futuras versiones. Deber evitar su uso, y tambin - los tutoriales desactualizaos que recomienden su uso. -

- -

El uso de estas directivas es:

- - - 
Require host address 

-Require ip ip.address
-
- - -

En la primera lnea, address es el FQDN de un nombre de - dominio (o un nombre parcial del dominio); puede proporcionar mltiples - direcciones o nombres de dominio, si se desea. -

- -

En la segunda lnea, ip.address es la direccin IP, una - direccin IP parcial, una red con su mscara, o una especificacin red/nnn - CIDR. Pueden usarse tanto IPV4 como IPV6.

- -

Consulte tambin la - documentacin de mod_authz_host para otros ejemplos de esta sintaxis. -

- -

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

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

Los visitantes que vengan desde la IP que se configura (10.252.46.165) - no tendrn acceso al contenido que cubre esta directiva. Si en cambio, lo que se - tiene es el nombre de la mquina, en vez de la IP, podrs usar:

- - 
Require not host host.example.com
-
- - -

Y, Si lo que se quiere es bloquear el acceso desde dominio especifico, - podrs especificar parte de una direccin o nombre de dominio:

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

Uso de las directivas RequireAll, RequireAny, y RequireNone pueden ser usadas - para forzar requisitos ms complejos.

- -
top
-
-

Control de acceso por variables arbitrarias.

- -

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

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

Usando la sintaxis de Require - expr , esto tambin puede ser escrito de la siguiente forma: -

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

Advertencia:

-

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

-
- -

Vea tambin la pgina de expresiones - para una mayor aclaracin de que sintaxis tienen las expresiones y que - variables estn disponibles.

- -
top
-
-

Control de acceso con mod_rewrite

- -

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

- -

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

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

Esto devolver una respuesta de error 403 Forbidden para cualquier peticin - despus de las 8pm y antes de las 7am. Esta tcnica puede ser usada para cualquier - criterio que desee usar. Tambin puede redireccionar, o incluso reescribir estas - peticiones, si se prefiere ese enfoque. -

- -

La directiva <If>, - aadida en la 2.4, sustituye muchas cosas que mod_rewrite - tradicionalmente sola hacer, y deber comprobar estas antes de recurrir a -

- -
top
-
-

Ms informacin

- -

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

- -

Tambin, deber leer la documentacin de mod_authz_core - para ejemplos de combinaciones de mltiples requisitos de acceso y especificar - cmo interactan. -

- -

Vea tambin los howtos de Authenticacin y Autorizacin -

-
-
-

Idiomas disponibles:  en  | - es  | - fr 

-
top

Comentarios

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

Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

+

Versin 2.5 del Servidor HTTP Apache

+
+
<-
+

Control de Acceso

+
+

Idiomas disponibles:  en  | + es  | + fr 

+
+ +

El control de acceso, hace referencia a todos los medios que proporcionan + una forma de controlar el acceso a cualquier recurso. Esta parte est + separada de autenticacin y autorizacin.

+
+ +
top
+
+

Mdulos y Directivas relacionados

+ +

El control de acceso puede efectuarse mediante diferentes mdulos. Los + ms importantes de stos son mod_authz_core y + mod_authz_host. Tambin se habla en este documento de + el control de acceso usando el mdulo mod_rewrite.

+ +
top
+
+

Control de Acceso por host

+

+ Si lo que se quiere es restringir algunas zonas del sitio web, basndonos + en la direccin del visitante, esto puede ser realizado de manera + fcil con el mdulo mod_authz_host. +

+ +

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

+ +

+ Las directivas Allow, + Deny, y + Order, + proporcionadas por mod_access_compat, estn obsoletas y + sern quitadas en futuras versiones. Deber evitar su uso, y tambin + los tutoriales desactualizaos que recomienden su uso. +

+ +

El uso de estas directivas es:

+ + + 
Require host address 

+Require ip ip.address
+
+ + +

En la primera lnea, address es el FQDN de un nombre de + dominio (o un nombre parcial del dominio); puede proporcionar mltiples + direcciones o nombres de dominio, si se desea. +

+ +

En la segunda lnea, ip.address es la direccin IP, una + direccin IP parcial, una red con su mscara, o una especificacin red/nnn + CIDR. Pueden usarse tanto IPV4 como IPV6.

+ +

Consulte tambin la + documentacin de mod_authz_host para otros ejemplos de esta sintaxis. +

+ +

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

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

Los visitantes que vengan desde la IP que se configura (10.252.46.165) + no tendrn acceso al contenido que cubre esta directiva. Si en cambio, lo que se + tiene es el nombre de la mquina, en vez de la IP, podrs usar:

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

Y, Si lo que se quiere es bloquear el acceso desde dominio especifico, + podrs especificar parte de una direccin o nombre de dominio:

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

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

+ +
top
+
+

Control de acceso por variables arbitrarias.

+ +

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

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

Usando la sintaxis de Require + expr , esto tambin puede ser escrito de la siguiente forma: +

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

Advertencia:

+

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

+
+ +

Vea tambin la pgina de expresiones + para una mayor aclaracin de que sintaxis tienen las expresiones y que + variables estn disponibles.

+ +
top
+
+

Control de acceso con mod_rewrite

+ +

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

+ +

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

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

Esto devolver una respuesta de error 403 Forbidden para cualquier peticin + despus de las 8pm y antes de las 7am. Esta tcnica puede ser usada para cualquier + criterio que desee usar. Tambin puede redireccionar, o incluso reescribir estas + peticiones, si se prefiere ese enfoque. +

+ +

La directiva <If>, + aadida en la 2.4, sustituye muchas cosas que mod_rewrite + tradicionalmente sola hacer, y deber comprobar estas antes de recurrir a +

+ +
top
+
+

Ms informacin

+ +

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

+ +

Tambin, deber leer la documentacin de mod_authz_core + para ejemplos de combinaciones de mltiples requisitos de acceso y especificar + cmo interactan. +

+ +

Vea tambin los howtos de Authenticacin y Autorizacin +

+
+
+

Idiomas disponibles:  en  | + es  | + fr 

+
top

Comentarios

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

Modules | Directives | FAQ | Glossaire | Plan du site

-

Serveur HTTP Apache Version 2.5

-
-
<-
-

Contrôle d'accès

-
-

Langues Disponibles:  en  | - es  | - fr 

-
- -

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

-
- -
top
-
-

Modules et directives concernés

- -

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

- -
top
-
-

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

-

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

- -

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

- -

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

- -

Les directives Require s'utilisent comme suit :

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

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

- -

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

- -

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

- -

Vous pouvez insérer le mot-clé not pour inverser un - critère particulier. Notez que le mot not réalise la - négation sur la valeur, et ne peut pas être utilisé seul pour autoriser - ou interdire une requête, car non vrai ne - veut pas ici forcément dire faux. Ainsi, pour interdire la - visite d'une page à l'aide d'une négation, le bloc doit contenir un - élément, qui sera évalué à l'une des valeurs vrai ou faux. - Par exemple, si quelqu'un est en train de - spamer votre forum, vous pouvez ajouter cette ligne pour lui refuser - l'accès :

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

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

- - 
Require not host host.example.com
- - -

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

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

Les directives RequireAll, RequireAny, et RequireNone ouvrent le champ à des - critères d'accès plus complexes.

- -
top
-
-

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

- -

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

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

En utilisant la syntaxe expr de la directive - Require, l'exemple - précédent peut aussi s'écrire :

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

Avertissement :

-

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

-
- -

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

- -
top
-
-

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

- -

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

- -

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

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

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

- -

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

- -
top
-
-

Informations complémentaires

- -

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

- -

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

- -

Voir aussi le How-To Authentification and - autorisation.

-
-
-

Langues Disponibles:  en  | - es  | - fr 

-
top

Commentaires

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

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.5

+
+
<-
+

Contrôle d'accès

+
+

Langues Disponibles:  en  | + es  | + fr 

+
+ +

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

+
+ +
top
+
+

Modules et directives concernés

+ +

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

+ +
top
+
+

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

+

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

+ +

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

+ +

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

+ +

Les directives Require s'utilisent comme suit :

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

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

+ +

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

+ +

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

+ +

Vous pouvez insérer le mot-clé not pour inverser un + critère particulier. Notez que le mot not réalise la + négation sur la valeur, et ne peut pas être utilisé seul pour autoriser + ou interdire une requête, car non vrai ne + veut pas ici forcément dire faux. Ainsi, pour interdire la + visite d'une page à l'aide d'une négation, le bloc doit contenir un + élément, qui sera évalué à l'une des valeurs vrai ou faux. + Par exemple, si quelqu'un est en train de + spamer votre forum, vous pouvez ajouter cette ligne pour lui refuser + l'accès :

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

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

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

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

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

Les directives RequireAll, RequireAny, et RequireNone ouvrent le champ à des + critères d'accès plus complexes.

+ +
top
+
+

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

+ +

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

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

En utilisant la syntaxe expr de la directive + Require, l'exemple + précédent peut aussi s'écrire :

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

Avertissement :

+

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

+
+ +

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

+ +
top
+
+

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

+ +

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

+ +

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

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

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

+ +

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

+ +
top
+
+

Informations complémentaires

+ +

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

+ +

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

+ +

Voir aussi le How-To Authentification and + autorisation.

+
+
+

Langues Disponibles:  en  | + es  | + fr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/auth.html b/docs/manual/howto/auth.html index 1bf414bffd..02a5b92e94 100644 --- a/docs/manual/howto/auth.html +++ b/docs/manual/howto/auth.html @@ -6,7 +6,7 @@ Content-type: text/html; charset=ISO-8859-1 URI: auth.html.es Content-Language: es -Content-type: text/html; charset=ISO-8859-1 +Content-type: text/html; charset=UTF-8 URI: auth.html.fr Content-Language: fr diff --git a/docs/manual/howto/auth.html.en b/docs/manual/howto/auth.html.en index c729088a49..7a8b21bdd5 100644 --- a/docs/manual/howto/auth.html.en +++ b/docs/manual/howto/auth.html.en @@ -24,11 +24,11 @@ Apache > HTTP Server > Documentation > Version 2.5 > How-To / Tutorials

Authentication and Authorization

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

+ tr 

Authentication is any process by which you verify that @@ -614,11 +614,11 @@ Require group GroupName

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

+ tr 

top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
- - -
-

Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

-

Versin 2.5 del Servidor HTTP Apache

-
-
<-
-

Autenticacin y Autorizacin

-
-

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

-
- -

Autenticacin es cualquier proceso por el cul se verifica que uno es - quien dice ser. Autorizacin es cualquier proceso en el cul cualquiera - est permitido a estar donde se quiera, o tener informacin la cul se - quiera tener. -

- -

Para informacin de control de acceso de forma genrica visiteHow to de Control de Acceso.

-
- -
top
-
-

Mdulos y Directivas Relacionados

- -

Hay tres tipos de mdulos involucrados en los procesos de la autenticacin - y autorizacin. Normalmente debers escoger al menos un mdulo de cada grupo.

- - - -

A parte de stos mdulos, tambin estn - mod_authn_core y - mod_authz_core. stos mdulos implementan las directivas - esenciales que son el centro de todos los mdulos de autenticacin.

- -

El mdulo mod_authnz_ldap es tanto un proveedor de - autenticacin como de autorizacin. El mdulo - mod_authz_host proporciona autorizacin y control de acceso - basado en el nombre del Host, la direccin IP o caractersticas de la propia - peticin, pero no es parte del sistema proveedor de - autenticacin. Para tener compatibilidad inversa con el mod_access, - hay un nuevo modulo llamado mod_access_compat.

- -

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

- -
top
-
-

Introduccin

-

Si se tiene informacin en nuestra pgina web que sea informacin - sensible o pensada para un grupo reducido de usuarios/personas, - las tcnicas que se describen en este manual, le servirn - de ayuda para asegurarse de que las personas que ven esas pginas sean - las personas que uno quiere.

- -

Este artculo cubre la parte "estndar" de cmo proteger partes de un - sitio web que muchos usarn.

- -

Nota:

-

Si de verdad es necesario que tus datos estn en un sitio seguro, - considera usar mod_ssl como mtodo de autenticacin adicional a cualquier forma de autenticacin.

-
-
top
-
-

Los Prerequisitos

-

Las directivas que se usan en este artculo necesitaran ponerse ya sea - en el fichero de configuracin principal del servidor ( tpicamente en - la seccin - <Directory> de httpd.conf ), o - en cada uno de los ficheros de configuraciones del propio directorio - (los archivos .htaccess).

- -

Si planea usar los ficheros .htaccess , necesitars - tener en la configuracin global del servidor, una configuracin que permita - poner directivas de autenticacin en estos ficheros. Esto se hace con la - directiva AllowOverride, la cual especifica - que directivas, en su caso, pueden ser puestas en cada fichero de configuracin - por directorio.

- -

Ya que estamos hablando aqu de autenticacin, necesitars una directiva - AllowOverride como la siguiente: -

- - 
AllowOverride AuthConfig
- - -

O, si solo se van a poner las directivas directamente en la configuracin - principal del servidor, debers tener, claro est, permisos de escritura - en el archivo.

- -

Y necesitars saber un poco de como est estructurado el rbol de - directorios de tu servidor, para poder saber donde se encuentran algunos - archivos. Esto no debera ser una tarea difcil, an as intentaremos - dejarlo claro llegado el momento de comentar dicho aspecto.

- -

Tambin debers de asegurarte de que los mdulos - mod_authn_core y mod_authz_core - han sido incorporados, o aadidos a la hora de compilar en tu binario httpd o - cargados mediante el archivo de configuracin httpd.conf. Estos - dos mdulos proporcionan directivas bsicas y funcionalidades que son crticas - para la configuracin y uso de autenticacin y autorizacin en el servidor web.

-
top
-
-

Conseguir que funcione

-

Aqu est lo bsico de cmo proteger con contrasea un directorio en tu - servidor.

- -

Primero, necesitars crear un fichero de contrasea. Dependiendo de que - proveedor de autenticacin se haya elegido, se har de una forma u otra. Para empezar, - usaremos un fichero de contrasea de tipo texto.

- -

Este fichero deber estar en un sitio que no se pueda tener acceso desde - la web. Esto tambin implica que nadie pueda descargarse el fichero de - contraseas. Por ejemplo, si tus documentos estn guardados fuera de - /usr/local/apache/htdocs, querrs poner tu archivo de contraseas en - /usr/local/apache/passwd.

- -

Para crear el fichero de contraseas, usa la utilidad - htpasswd que viene con Apache. Esta herramienta se - encuentra en el directorio /bin en donde sea que se ha - instalado el Apache. Si ha instalado Apache desde un paquete de terceros, - puede ser que se encuentre en su ruta de ejecucin.

- -

Para crear el fichero, escribiremos:

- -

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

- -

htpasswd te preguntar por una contrasea, y despus - te pedir que la vuelvas a escribir para confirmarla:

- -

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

- -

Si htpasswd no est en tu variable de entorno "path" del - sistema, por supuesto debers escribir la ruta absoluta del ejecutable para - poder hacer que se ejecute. En una instalacin por defecto, est en: - /usr/local/apache2/bin/htpasswd

- -

Lo prximo que necesitas, ser configurar el servidor para que pida una - contrasea y as decirle al servidor que usuarios estn autorizados a acceder. - Puedes hacer esto ya sea editando el fichero httpd.conf - de configuracin o usando in fichero .htaccess. Por ejemplo, - si quieres proteger el directorio - /usr/local/apache/htdocs/secret, puedes usar las siguientes - directivas, ya sea en el fichero .htaccess localizado en - following directives, either placed in the file - /usr/local/apache/htdocs/secret/.htaccess, o - en la configuracin global del servidor httpd.conf dentro de la - seccin <Directory - "/usr/local/apache/htdocs/secret"> , como se muestra a continuacin:

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

Vamos a explicar cada una de las directivas individualmente. - La directiva AuthType selecciona el mtodo - que se usa para autenticar al usuario. El mtodo ms comn es - Basic, y ste es el mtodo que implementa - mod_auth_basic. Es muy importante ser consciente, - de que la autenticacin bsica, enva las contraseas desde el cliente - al servidor sin cifrar. - Este mtodo por tanto, no debe ser utilizado para proteger datos muy sensibles, - a no ser que, este mtodo de autenticacin bsica, sea acompaado del mdulo - mod_ssl. - Apache soporta otro mtodo ms de autenticacin que es del tipo - AuthType Digest. Este mtodo, es implementado por el mdulo mod_auth_digest y con el se pretenda crear una autenticacin ms - segura. Este ya no es el caso, ya que la conexin deber realizarse con mod_ssl en su lugar. -

- -

La directiva AuthName - establece el Realm para ser usado en la autenticacin. El - Realm tiene dos funciones principales. - La primera, el cliente presenta a menudo esta informacin al usuario como - parte del cuadro de dilogo de contrasea. La segunda, que es utilizado por - el cliente para determinar qu contrasea enviar a para una determinada zona - de autenticacin.

- -

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

- -

La directiva AuthBasicProvider es, - en este caso, opcional, ya que file es el valor por defecto - para esta directiva. Debers usar esta directiva si estas usando otro medio - diferente para la autenticacin, como por ejemplo - mod_authn_dbm o mod_authn_dbd.

- -

La directiva AuthUserFile - establece el path al fichero de contraseas que acabamos de crear con el - comando htpasswd. Si tiene un nmero muy grande de usuarios, - puede ser realmente lento el buscar el usuario en ese fichero de texto plano - para autenticar a los usuarios en cada peticin. - Apache tambin tiene la habilidad de almacenar informacin de usuarios en - unos ficheros de rpido acceso a modo de base de datos. - El mdulo mod_authn_dbm proporciona la directiva AuthDBMUserFile. Estos ficheros pueden ser creados y - manipulados con el programa dbmmanage y htdbm. - Muchos otros mtodos de autenticacin as como otras opciones, estn disponibles en - mdulos de terceros - Base de datos de Mdulos disponibles.

- -

Finalmente, la directiva Require - proporciona la parte del proceso de autorizacin estableciendo el o los - usuarios que se les est permitido acceder a una regin del servidor. - En la prxima seccin, discutiremos las diferentes vas de utilizar la - directiva Require.

-
top
-
-

Dejar que ms de una persona - entre

-

Las directivas mencionadas arriba slo permiten a una persona - (especialmente con un usuario que en ej ejemplo es rbowen) - en el directorio. En la mayora de los casos, se querr permitir el acceso - a ms de una persona. Aqu es donde la directiva - AuthGroupFile entra en juego.

- -

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

- -

- GroupName: rbowen dpitts sungo rshersey -

- -

Bsicamente eso es la lista de miembros los cuales estn en un mismo fichero - de grupo en una sola linea separados por espacios.

- -

Para aadir un usuario a tu fichero de contraseas existente teclee:

- -

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

- -

Te responder lo mismo que anteriormente, pero se aadir al fichero - existente en vez de crear uno nuevo. (Es decir el flag -c ser - el que haga que se genere un nuevo - fichero de contraseas).

- -

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

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

Ahora, cualquiera que est listado en el grupo GroupName, - y tiene una entrada en el fichero de contraseas, se les - permitir el acceso, si introducen su contrasea correctamente.

- -

Hay otra manera de dejar entrar a varios usuarios, que es menos especfica. - En lugar de crear un archivo de grupo, slo puede utilizar la siguiente - directiva:

- - 
Require valid-user
- - -

Usando sto en vez de la lnea Require user rbowen - permitir a cualquier persona acceder, la cul aparece en el archivo de - contraseas, y que introduzca correctamente su contrasea. Incluso puede - emular el comportamiento del grupo aqu, slo manteniendo un fichero de - contraseas independiente para cada grupo. La ventaja de este enfoque es - que Apache slo tiene que comprobar un archivo, en lugar de dos. La desventaja - es que se tiene que mantener un montn de ficheros de contrasea de grupo, y - recuerde hacer referencia al fichero correcto en la directiva - AuthUserFile.

-
top
-
-

Posibles Problemas

-

Debido a la forma en que se especifica la autenticacin bsica, - su nombre de usuario y la contrasea deben ser verificados cada vez - que se solicita un documento desde el servidor. Esto es, incluso si  - se  vuelve a cargar la misma pgina, y para cada imagen de la pgina (si -    provienen de un directorio protegido). Como se puede imaginar, esto -    ralentiza las cosas un poco. La cantidad que ralentiza las cosas es - proporcional al tamao del archivo de contraseas, porque tiene que - abrir ese archivo, recorrer lista de usuarios hasta que llega a su nombre. - Y tiene que hacer esto cada vez que se carga una pgina.

- -

Una consecuencia de esto, es que hay un limite prctico de cuantos - usuarios puedes introducir en el fichero de contraseas. Este lmite - variar dependiendo de la mquina en la que tengas el servidor, - pero puedes notar ralentizaciones en cuanto se metan cientos de entradas, - y por lo tanto consideraremos entonces otro mtodo de autenticacin - en ese momento. -

-
top
-
-

Mtodo alternativo de almacenamiento de las - contraseas

- -

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

- -

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

- -

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

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

Hay otras opciones disponibles. Consulta la documentacin de - mod_authn_dbm para ms detalles.

-
top
-
-

Uso de mltiples proveedores

- -

Con la introduccin de la nueva autenticacin basada en un proveedor y - una arquitectura de autorizacin, ya no estaremos restringidos a un nico - mtodo de autenticacin o autorizacin. De hecho, cualquier nmero de - los proveedores pueden ser mezclados y emparejados para ofrecerle - exactamente el esquema que se adapte a sus necesidades. - En el siguiente ejemplo, veremos como ambos proveedores tanto el fichero - como el LDAP son usados en la autenticacin: -

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

En este ejemplo el fichero, que acta como proveedor, intentar autenticar - primero al usuario. Si no puede autenticar al usuario, el proveedor del LDAP - ser llamado para que realice la autenticacin. - Esto permite al mbito de autenticacin ser amplio, si su organizacin - implementa ms de un tipo de almacn de autenticacin. - Otros escenarios de autenticacin y autorizacin pueden incluir la - mezcla de un tipo de autenticacin con un tipo diferente de autorizacin. - Por ejemplo, autenticar contra un fichero de contraseas pero autorizando - dicho acceso mediante el directorio del LDAP.

- -

As como mltiples mtodos y proveedores de autenticacin pueden - ser implementados, tambin pueden usarse mltiples formas de - autorizacin. - En este ejemplo ambos ficheros de autorizacin de grupo as como - autorizacin de grupo mediante LDAP va a ser usado: -

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

Para llevar la autorizacin un poco ms lejos, las directivas - de autorizacin de contenedores tales como - <RequireAll> - and - <RequireAny> - nos permiten aplicar una lgica de en qu orden se manejar la autorizacin dependiendo - de la configuracin y controlada a travs de ella. - Mire tambin Contenedores de - Autorizacin para ejemplos de cmo pueden ser aplicados.

- -
top
-
-

Ms all de la Autorizacin

- -

El modo en que la autorizacin puede ser aplicada es ahora mucho ms flexible - que us solo chequeo contra un almacn de datos (contraseas). Ordenando la - lgica y escoger la forma en que la autorizacin es realizada, ahora es posible -

- -

Aplicando la lgica y ordenacin

-

Controlar el cmo y en qu orden se va a aplicar la autorizacin ha - sido un misterio en el pasado. En Apache 2.2 un proveedor del - mecanismo de autenticacin fue introducido para disociar el proceso actual - de autenticacin y soportar funcionalidad. - Uno de los beneficios secundarios fue que los proveedores de autenticacin - podan ser configurados y llamados en un orden especifico que no dependieran - en el orden de carga del propio modulo. - Este proveedor de dicho mecanismo, ha sido introducido en la autorizacin - tambin. Lo que esto significa es que la directiva - Require - no slo especifica que mtodo de autorizacin deber ser usado, si no - tambin especifica el orden en que van a ser llamados. Mltiples - mtodos de autorizacin son llamados en el mismo orden en que la directiva - Require aparece en la - configuracin. -

- -

- Con la Introduccin del contenedor de directivas de autorizacin tales como - <RequireAll> - y - <RequireAny>, - La configuracin tambin tiene control sobre cundo se llaman a los mtodos - de autorizacin y qu criterios determinan cundo se concede el acceso. - Vease - Contenedores de autorizacin - Para un ejemplo de cmo pueden ser utilizados para expresar una lgica - ms compleja de autorizacin. -

- -

- Por defecto todas las directivas - Require - son manejadas como si estuvieran contenidas en una directiva - <RequireAny>. - En otras palabras, Si alguno de los mtodos de autorizacin - especificados tiene xito, se concede la autorizacin. -

- - - -

Uso de los proveedores de autorizacin para - el control de acceso

- -

- La autenticacin de nombre de usuario y contrasea es slo parte - de toda la historia que conlleva el proceso. Frecuentemente quiere - dar acceso a la gente en base a algo ms que lo que son. - Algo como de donde vienen. -

- -

- Los proveedores de autorizacin all, - env, host y ip - te permiten denegar o permitir el acceso basndose en otros - criterios como el nombre de la mquina o la IP de la mquina que - realiza la consulta para un documento. -

- -

- El uso de estos proveedores se especifica a travs de la directiva - Require. - La directiva registra los proveedores de autorizacin que sern llamados - durante la solicitud de la fase del proceso de autorizacin. Por ejemplo: -

- - 
Require ip address
-
- - -

- Donde address es una direccin IP (o una direccin IP parcial) - o bien: -

- - 
Require host domain_name
-
- - -

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

- -

- Por ejemplo, si alguien enva spam a su tabln de mensajes y desea - mantenerlos alejados, podra hacer lo siguiente:

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

- Visitantes que vengan desde esa IP no sern capaces de ver el contenido - que cubre esta directiva. Si, en cambio, lo que se tiene es el nombre de - la mquina, en vez de la direccin IP, podra usar: -

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

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

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

- Usando <RequireAll> - con mltiples directivas <Require>, cada una negada con un not, - Slo permitir el acceso, si todas las condiciones negadas son verdaderas. - En otras palabras, el acceso ser bloqueado, si cualquiera de las condiciones - negadas fallara. -

- - - -

Compatibilidad de Control de Acceso con versiones - anteriores

- -

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

- -

Nota:

-

- Las directivas proporcionadas por mod_access_compat - han quedado obsoletas por mod_authz_host. Mezclar - directivas antiguas como - Order, - Allow - Deny con las nuevas - como - Require - es tcnicamente posible pero desaconsejable. El mdulo - mod_access_compat se cre para soportar configuraciones - que contuvieran slo directivas antiguas para facilitar la actualizacin - a la versin 2.4. - Por favor revise la documentacin de - actualizacin para ms informacin al - respecto. -

-
- - -
top
-
-

Cache de Autenticacin

-

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

-

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

-
top
-
-

Ms informacin

- -

- Tambin debera leer la documentacin para - mod_auth_basic y mod_authz_host - la cul contiene ms informacin de como funciona todo esto. - La directiva <AuthnProviderAlias> puede tambin ayudar - a la hora de simplificar ciertas configuraciones de autenticacin. -

- -

- Los diferentes algoritmos de cifrado que estn soportados por Apache - para la autenticacin se explican en - Cifrado de Contraseas. -

- -

- Y tal vez quiera ojear la documentacin de "how to" - Control de Acceso donde se mencionan temas - relacionados.

- -
-
-

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

-
top

Comentarios

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

Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

+

Versin 2.5 del Servidor HTTP Apache

+
+
<-
+

Autenticacin y Autorizacin

+
+

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

+
+ +

Autenticacin es cualquier proceso por el cul se verifica que uno es + quien dice ser. Autorizacin es cualquier proceso en el cul cualquiera + est permitido a estar donde se quiera, o tener informacin la cul se + quiera tener. +

+ +

Para informacin de control de acceso de forma genrica visiteHow to de Control de Acceso.

+
+ +
top
+
+

Mdulos y Directivas Relacionados

+ +

Hay tres tipos de mdulos involucrados en los procesos de la autenticacin + y autorizacin. Normalmente debers escoger al menos un mdulo de cada grupo.

+ + + +

A parte de stos mdulos, tambin estn + mod_authn_core y + mod_authz_core. stos mdulos implementan las directivas + esenciales que son el centro de todos los mdulos de autenticacin.

+ +

El mdulo mod_authnz_ldap es tanto un proveedor de + autenticacin como de autorizacin. El mdulo + mod_authz_host proporciona autorizacin y control de acceso + basado en el nombre del Host, la direccin IP o caractersticas de la propia + peticin, pero no es parte del sistema proveedor de + autenticacin. Para tener compatibilidad inversa con el mod_access, + hay un nuevo modulo llamado mod_access_compat.

+ +

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

+ +
top
+
+

Introduccin

+

Si se tiene informacin en nuestra pgina web que sea informacin + sensible o pensada para un grupo reducido de usuarios/personas, + las tcnicas que se describen en este manual, le servirn + de ayuda para asegurarse de que las personas que ven esas pginas sean + las personas que uno quiere.

+ +

Este artculo cubre la parte "estndar" de cmo proteger partes de un + sitio web que muchos usarn.

+ +

Nota:

+

Si de verdad es necesario que tus datos estn en un sitio seguro, + considera usar mod_ssl como mtodo de autenticacin adicional a cualquier forma de autenticacin.

+
+
top
+
+

Los Prerequisitos

+

Las directivas que se usan en este artculo necesitaran ponerse ya sea + en el fichero de configuracin principal del servidor ( tpicamente en + la seccin + <Directory> de httpd.conf ), o + en cada uno de los ficheros de configuraciones del propio directorio + (los archivos .htaccess).

+ +

Si planea usar los ficheros .htaccess , necesitars + tener en la configuracin global del servidor, una configuracin que permita + poner directivas de autenticacin en estos ficheros. Esto se hace con la + directiva AllowOverride, la cual especifica + que directivas, en su caso, pueden ser puestas en cada fichero de configuracin + por directorio.

+ +

Ya que estamos hablando aqu de autenticacin, necesitars una directiva + AllowOverride como la siguiente: +

+ + 
AllowOverride AuthConfig
+ + +

O, si solo se van a poner las directivas directamente en la configuracin + principal del servidor, debers tener, claro est, permisos de escritura + en el archivo.

+ +

Y necesitars saber un poco de como est estructurado el rbol de + directorios de tu servidor, para poder saber donde se encuentran algunos + archivos. Esto no debera ser una tarea difcil, an as intentaremos + dejarlo claro llegado el momento de comentar dicho aspecto.

+ +

Tambin debers de asegurarte de que los mdulos + mod_authn_core y mod_authz_core + han sido incorporados, o aadidos a la hora de compilar en tu binario httpd o + cargados mediante el archivo de configuracin httpd.conf. Estos + dos mdulos proporcionan directivas bsicas y funcionalidades que son crticas + para la configuracin y uso de autenticacin y autorizacin en el servidor web.

+
top
+
+

Conseguir que funcione

+

Aqu est lo bsico de cmo proteger con contrasea un directorio en tu + servidor.

+ +

Primero, necesitars crear un fichero de contrasea. Dependiendo de que + proveedor de autenticacin se haya elegido, se har de una forma u otra. Para empezar, + usaremos un fichero de contrasea de tipo texto.

+ +

Este fichero deber estar en un sitio que no se pueda tener acceso desde + la web. Esto tambin implica que nadie pueda descargarse el fichero de + contraseas. Por ejemplo, si tus documentos estn guardados fuera de + /usr/local/apache/htdocs, querrs poner tu archivo de contraseas en + /usr/local/apache/passwd.

+ +

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

+ +

Para crear el fichero, escribiremos:

+ +

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

+ +

htpasswd te preguntar por una contrasea, y despus + te pedir que la vuelvas a escribir para confirmarla:

+ +

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

+ +

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

+ +

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

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

Vamos a explicar cada una de las directivas individualmente. + La directiva AuthType selecciona el mtodo + que se usa para autenticar al usuario. El mtodo ms comn es + Basic, y ste es el mtodo que implementa + mod_auth_basic. Es muy importante ser consciente, + de que la autenticacin bsica, enva las contraseas desde el cliente + al servidor sin cifrar. + Este mtodo por tanto, no debe ser utilizado para proteger datos muy sensibles, + a no ser que, este mtodo de autenticacin bsica, sea acompaado del mdulo + mod_ssl. + Apache soporta otro mtodo ms de autenticacin que es del tipo + AuthType Digest. Este mtodo, es implementado por el mdulo mod_auth_digest y con el se pretenda crear una autenticacin ms + segura. Este ya no es el caso, ya que la conexin deber realizarse con mod_ssl en su lugar. +

+ +

La directiva AuthName + establece el Realm para ser usado en la autenticacin. El + Realm tiene dos funciones principales. + La primera, el cliente presenta a menudo esta informacin al usuario como + parte del cuadro de dilogo de contrasea. La segunda, que es utilizado por + el cliente para determinar qu contrasea enviar a para una determinada zona + de autenticacin.

+ +

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

+ +

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

+ +

La directiva AuthUserFile + establece el path al fichero de contraseas que acabamos de crear con el + comando htpasswd. Si tiene un nmero muy grande de usuarios, + puede ser realmente lento el buscar el usuario en ese fichero de texto plano + para autenticar a los usuarios en cada peticin. + Apache tambin tiene la habilidad de almacenar informacin de usuarios en + unos ficheros de rpido acceso a modo de base de datos. + El mdulo mod_authn_dbm proporciona la directiva AuthDBMUserFile. Estos ficheros pueden ser creados y + manipulados con el programa dbmmanage y htdbm. + Muchos otros mtodos de autenticacin as como otras opciones, estn disponibles en + mdulos de terceros + Base de datos de Mdulos disponibles.

+ +

Finalmente, la directiva Require + proporciona la parte del proceso de autorizacin estableciendo el o los + usuarios que se les est permitido acceder a una regin del servidor. + En la prxima seccin, discutiremos las diferentes vas de utilizar la + directiva Require.

+
top
+
+

Dejar que ms de una persona + entre

+

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

+ +

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

+ +

+ GroupName: rbowen dpitts sungo rshersey +

+ +

Bsicamente eso es la lista de miembros los cuales estn en un mismo fichero + de grupo en una sola linea separados por espacios.

+ +

Para aadir un usuario a tu fichero de contraseas existente teclee:

+ +

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

+ +

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

+ +

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

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

Ahora, cualquiera que est listado en el grupo GroupName, + y tiene una entrada en el fichero de contraseas, se les + permitir el acceso, si introducen su contrasea correctamente.

+ +

Hay otra manera de dejar entrar a varios usuarios, que es menos especfica. + En lugar de crear un archivo de grupo, slo puede utilizar la siguiente + directiva:

+ + 
Require valid-user
+ + +

Usando sto en vez de la lnea Require user rbowen + permitir a cualquier persona acceder, la cul aparece en el archivo de + contraseas, y que introduzca correctamente su contrasea. Incluso puede + emular el comportamiento del grupo aqu, slo manteniendo un fichero de + contraseas independiente para cada grupo. La ventaja de este enfoque es + que Apache slo tiene que comprobar un archivo, en lugar de dos. La desventaja + es que se tiene que mantener un montn de ficheros de contrasea de grupo, y + recuerde hacer referencia al fichero correcto en la directiva + AuthUserFile.

+
top
+
+

Posibles Problemas

+

Debido a la forma en que se especifica la autenticacin bsica, + su nombre de usuario y la contrasea deben ser verificados cada vez + que se solicita un documento desde el servidor. Esto es, incluso si  + se  vuelve a cargar la misma pgina, y para cada imagen de la pgina (si +    provienen de un directorio protegido). Como se puede imaginar, esto +    ralentiza las cosas un poco. La cantidad que ralentiza las cosas es + proporcional al tamao del archivo de contraseas, porque tiene que + abrir ese archivo, recorrer lista de usuarios hasta que llega a su nombre. + Y tiene que hacer esto cada vez que se carga una pgina.

+ +

Una consecuencia de esto, es que hay un limite prctico de cuantos + usuarios puedes introducir en el fichero de contraseas. Este lmite + variar dependiendo de la mquina en la que tengas el servidor, + pero puedes notar ralentizaciones en cuanto se metan cientos de entradas, + y por lo tanto consideraremos entonces otro mtodo de autenticacin + en ese momento. +

+
top
+
+

Mtodo alternativo de almacenamiento de las + contraseas

+ +

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

+ +

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

+ +

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

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

Hay otras opciones disponibles. Consulta la documentacin de + mod_authn_dbm para ms detalles.

+
top
+
+

Uso de mltiples proveedores

+ +

Con la introduccin de la nueva autenticacin basada en un proveedor y + una arquitectura de autorizacin, ya no estaremos restringidos a un nico + mtodo de autenticacin o autorizacin. De hecho, cualquier nmero de + los proveedores pueden ser mezclados y emparejados para ofrecerle + exactamente el esquema que se adapte a sus necesidades. + En el siguiente ejemplo, veremos como ambos proveedores tanto el fichero + como el LDAP son usados en la autenticacin: +

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

En este ejemplo el fichero, que acta como proveedor, intentar autenticar + primero al usuario. Si no puede autenticar al usuario, el proveedor del LDAP + ser llamado para que realice la autenticacin. + Esto permite al mbito de autenticacin ser amplio, si su organizacin + implementa ms de un tipo de almacn de autenticacin. + Otros escenarios de autenticacin y autorizacin pueden incluir la + mezcla de un tipo de autenticacin con un tipo diferente de autorizacin. + Por ejemplo, autenticar contra un fichero de contraseas pero autorizando + dicho acceso mediante el directorio del LDAP.

+ +

As como mltiples mtodos y proveedores de autenticacin pueden + ser implementados, tambin pueden usarse mltiples formas de + autorizacin. + En este ejemplo ambos ficheros de autorizacin de grupo as como + autorizacin de grupo mediante LDAP va a ser usado: +

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

Para llevar la autorizacin un poco ms lejos, las directivas + de autorizacin de contenedores tales como + <RequireAll> + and + <RequireAny> + nos permiten aplicar una lgica de en qu orden se manejar la autorizacin dependiendo + de la configuracin y controlada a travs de ella. + Mire tambin Contenedores de + Autorizacin para ejemplos de cmo pueden ser aplicados.

+ +
top
+
+

Ms all de la Autorizacin

+ +

El modo en que la autorizacin puede ser aplicada es ahora mucho ms flexible + que us solo chequeo contra un almacn de datos (contraseas). Ordenando la + lgica y escoger la forma en que la autorizacin es realizada, ahora es posible +

+ +

Aplicando la lgica y ordenacin

+

Controlar el cmo y en qu orden se va a aplicar la autorizacin ha + sido un misterio en el pasado. En Apache 2.2 un proveedor del + mecanismo de autenticacin fue introducido para disociar el proceso actual + de autenticacin y soportar funcionalidad. + Uno de los beneficios secundarios fue que los proveedores de autenticacin + podan ser configurados y llamados en un orden especifico que no dependieran + en el orden de carga del propio modulo. + Este proveedor de dicho mecanismo, ha sido introducido en la autorizacin + tambin. Lo que esto significa es que la directiva + Require + no slo especifica que mtodo de autorizacin deber ser usado, si no + tambin especifica el orden en que van a ser llamados. Mltiples + mtodos de autorizacin son llamados en el mismo orden en que la directiva + Require aparece en la + configuracin. +

+ +

+ Con la Introduccin del contenedor de directivas de autorizacin tales como + <RequireAll> + y + <RequireAny>, + La configuracin tambin tiene control sobre cundo se llaman a los mtodos + de autorizacin y qu criterios determinan cundo se concede el acceso. + Vease + Contenedores de autorizacin + Para un ejemplo de cmo pueden ser utilizados para expresar una lgica + ms compleja de autorizacin. +

+ +

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

+ + + +

Uso de los proveedores de autorizacin para + el control de acceso

+ +

+ La autenticacin de nombre de usuario y contrasea es slo parte + de toda la historia que conlleva el proceso. Frecuentemente quiere + dar acceso a la gente en base a algo ms que lo que son. + Algo como de donde vienen. +

+ +

+ Los proveedores de autorizacin all, + env, host y ip + te permiten denegar o permitir el acceso basndose en otros + criterios como el nombre de la mquina o la IP de la mquina que + realiza la consulta para un documento. +

+ +

+ El uso de estos proveedores se especifica a travs de la directiva + Require. + La directiva registra los proveedores de autorizacin que sern llamados + durante la solicitud de la fase del proceso de autorizacin. Por ejemplo: +

+ + 
Require ip address
+
+ + +

+ Donde address es una direccin IP (o una direccin IP parcial) + o bien: +

+ + 
Require host domain_name
+
+ + +

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

+ +

+ Por ejemplo, si alguien enva spam a su tabln de mensajes y desea + mantenerlos alejados, podra hacer lo siguiente:

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

+ Visitantes que vengan desde esa IP no sern capaces de ver el contenido + que cubre esta directiva. Si, en cambio, lo que se tiene es el nombre de + la mquina, en vez de la direccin IP, podra usar: +

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

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

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

+ Usando <RequireAll> + con mltiples directivas <Require>, cada una negada con un not, + Slo permitir el acceso, si todas las condiciones negadas son verdaderas. + En otras palabras, el acceso ser bloqueado, si cualquiera de las condiciones + negadas fallara. +

+ + + +

Compatibilidad de Control de Acceso con versiones + anteriores

+ +

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

+ +

Nota:

+

+ Las directivas proporcionadas por mod_access_compat + han quedado obsoletas por mod_authz_host. Mezclar + directivas antiguas como + Order, + Allow + Deny con las nuevas + como + Require + es tcnicamente posible pero desaconsejable. El mdulo + mod_access_compat se cre para soportar configuraciones + que contuvieran slo directivas antiguas para facilitar la actualizacin + a la versin 2.4. + Por favor revise la documentacin de + actualizacin para ms informacin al + respecto. +

+
+ + +
top
+
+

Cache de Autenticacin

+

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

+

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

+
top
+
+

Ms informacin

+ +

+ Tambin debera leer la documentacin para + mod_auth_basic y mod_authz_host + la cul contiene ms informacin de como funciona todo esto. + La directiva <AuthnProviderAlias> puede tambin ayudar + a la hora de simplificar ciertas configuraciones de autenticacin. +

+ +

+ Los diferentes algoritmos de cifrado que estn soportados por Apache + para la autenticacin se explican en + Cifrado de Contraseas. +

+ +

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

+ +
+
+

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

+
top

Comentarios

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

Modules | Directives | FAQ | Glossaire | Plan du site

-

Serveur HTTP Apache Version 2.5

-
-
<-
-

Authentification et autorisation

-
-

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

-
- -

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

- -

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

-
- -
top
-
-

Modules et directives concernés

- -

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

- - - -

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

- -

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

- -

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

- -
top
-
-

Introduction

-

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

- -

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

- -

Note :

-

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

-
-
top
-
-

Les prérequis

-

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

- -

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

- -

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

- - 
AllowOverride AuthConfig
- - -

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

- -

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

- -

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

-
top
-
-

Mise en oeuvre

-

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

- -

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

- -

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

- -

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

- -

Pour créer le fichier, tapez :

- -

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

- -

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

- -

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

- -

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

- -

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

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

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

- -

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

- -

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

- -

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

- -

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

- -

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

-
top
-
-

Autorisation d'accès à -plusieurs personnes

-

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

- -

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

- -

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

- -

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

- -

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

- -

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

- -

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

- -

Maintenant, vous devez modifier votre fichier - .htaccess comme suit :

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

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

- -

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

- - 
Require valid-user
- - -

Le remplacement de la ligne Require user rbowen par - la ligne Require valid-user autorisera l'accès à - quiconque possédant une entrée dans le fichier password, et ayant - tapé le bon mot de passe. Vous pouvez même simuler le comportement - des groupes en associant un fichier de mots de passe différent pour - chaque groupe. L'avantage de cette approche réside dans le fait - qu'Apache ne doit consulter qu'un fichier au lieu de deux. Par - contre, vous devez maintenir un nombre plus ou moins important de - fichiers de mots de passe, et vous assurer de faire référence au bon - fichier dans la directive AuthUserFile.

-
top
-
-

Problèmes possibles

-

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

- -

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

-
top
-
-

Autre méthode de stockage des mots de -passe

- -

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

- -

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

- -

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

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

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

-
top
-
-

Utilisation de plusieurs fournisseurs -d'authentification

- -

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

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

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

- -

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

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

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

- -
top
-
-

Pour aller plus loin qu'une simple -autorisation

- -

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

- -

Appliquer logique et - ordonnancement

-

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

- -

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

- -

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

- - - -

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

-

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

- -

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

- -

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

- - 
Require ip address
- - -

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

- - 
Require host domain_name
- - -

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

- -

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

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

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

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

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

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

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

- - - -

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

-

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

- -

Note

-

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

-
- - -
top
-
-

Mise en cache de l'authentification

-

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

-

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

-
top
-
-

Pour aller plus loin . . .

-

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

- -

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

- -

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

- -
-
-

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

-
top

Commentaires

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

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.5

+
+
<-
+

Authentification et autorisation

+
+

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

+
+ +

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

+ +

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

+
+ +
top
+
+

Modules et directives concernés

+ +

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

+ + + +

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

+ +

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

+ +

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

+ +
top
+
+

Introduction

+

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

+ +

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

+ +

Note :

+

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

+
+
top
+
+

Les prérequis

+

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

+ +

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

+ +

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

+ + 
AllowOverride AuthConfig
+ + +

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

+ +

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

+ +

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

+
top
+
+

Mise en oeuvre

+

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

+ +

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

+ +

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

+ +

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

+ +

Pour créer le fichier, tapez :

+ +

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

+ +

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

+ +

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

+ +

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

+ +

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

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

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

+ +

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

+ +

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

+ +

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

+ +

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

+ +

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

+
top
+
+

Autorisation d'accès à +plusieurs personnes

+

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

+ +

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

+ +

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

+ +

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

+ +

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

+ +

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

+ +

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

+ +

Maintenant, vous devez modifier votre fichier + .htaccess comme suit :

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

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

+ +

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

+ + 
Require valid-user
+ + +

Le remplacement de la ligne Require user rbowen par + la ligne Require valid-user autorisera l'accès à + quiconque possédant une entrée dans le fichier password, et ayant + tapé le bon mot de passe. Vous pouvez même simuler le comportement + des groupes en associant un fichier de mots de passe différent pour + chaque groupe. L'avantage de cette approche réside dans le fait + qu'Apache ne doit consulter qu'un fichier au lieu de deux. Par + contre, vous devez maintenir un nombre plus ou moins important de + fichiers de mots de passe, et vous assurer de faire référence au bon + fichier dans la directive AuthUserFile.

+
top
+
+

Problèmes possibles

+

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

+ +

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

+
top
+
+

Autre méthode de stockage des mots de +passe

+ +

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

+ +

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

+ +

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

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

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

+
top
+
+

Utilisation de plusieurs fournisseurs +d'authentification

+ +

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

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

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

+ +

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

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

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

+ +
top
+
+

Pour aller plus loin qu'une simple +autorisation

+ +

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

+ +

Appliquer logique et + ordonnancement

+

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

+ +

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

+ +

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

+ + + +

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

+

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

+ +

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

+ +

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

+ + 
Require ip address
+ + +

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

+ + 
Require host domain_name
+ + +

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

+ +

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

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

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

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

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

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

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

+ + + +

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

+

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

+ +

Note

+

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

+
+ + +
top
+
+

Mise en cache de l'authentification

+

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

+

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

+
top
+
+

Pour aller plus loin . . .

+

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

+ +

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

+ +

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

+ +
+
+

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

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/cgi.html b/docs/manual/howto/cgi.html index 9abb158457..98673fb3b8 100644 --- a/docs/manual/howto/cgi.html +++ b/docs/manual/howto/cgi.html @@ -6,7 +6,7 @@ Content-type: text/html; charset=ISO-8859-1 URI: cgi.html.es Content-Language: es -Content-type: text/html; charset=ISO-8859-1 +Content-type: text/html; charset=UTF-8 URI: cgi.html.fr Content-Language: fr diff --git a/docs/manual/howto/cgi.html.en b/docs/manual/howto/cgi.html.en index 5dc0544bee..77db1cfc78 100644 --- a/docs/manual/howto/cgi.html.en +++ b/docs/manual/howto/cgi.html.en @@ -24,8 +24,8 @@ Apache > HTTP Server > Documentation > Version 2.5 > How-To / Tutorials

Apache Tutorial: Dynamic Content with CGI

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

@@ -570,8 +570,8 @@ foreach my $key (keys %ENV) {

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

top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
diff --git a/docs/manual/howto/cgi.html.es b/docs/manual/howto/cgi.html.es deleted file mode 100644 index e83b4f9235..0000000000 --- a/docs/manual/howto/cgi.html.es +++ /dev/null @@ -1,615 +0,0 @@ - - - - - -Tutorial de Apache: Contenido Dinmico con CGI - Servidor HTTP Apache Versin 2.5 - - - - - - -
-

Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

-

Versin 2.5 del Servidor HTTP Apache

-
-
<-
-

Tutorial de Apache: Contenido Dinmico con CGI

-
-

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

-
-
- -
top
-
-

Introduccin

- -
Mdulos RelacionadosDirectivas Relacionadas
- -

CGI (Common Gateway Interface) es un mtodo por el cual - un servidor web puede interactuar con programas externos de - generacin de contenido, a ellos nos referimos comnmente como - programas CGI o scripts CGI. Es el mtodo ms comn y sencillo de - mostrar contenido dinmico en su sitio web. Este documento es una - introduccin para configurar CGI en su servidor web Apache, y de - iniciacin para escribir programas CGI.

-
top
-
-

Configurando Apache para permitir CGI

- - -

Para conseguir que sus programas CGI funcionen correctamente, - deber configurar Apache para que permita la ejecucin de CGI. Hay - distintas formas de hacerlo.

- -
Nota: Si Apache ha sido compilado con soporte - de mdulos compartidos, necesitar que el mdulo de CGI est cargado; - en su httpd.conf tiene que asegurarse de que la directiva - LoadModule - no ha sido comentada. Una directiva configurada correctamente sera as: - - 
LoadModule cgid_module modules/mod_cgid.so
- - - En Windows, o si usa un mpm que no es multihilo, como prefork, una - directiva configurada correctamente podra definirse as: - - 
LoadModule cgi_module modules/mod_cgi.so
-
- -

ScriptAlias

- - -

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

- -

La directiva - ScriptAlias se puede - definir as:

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

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

- -

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

- - -

CGI fuera de directorios ScriptAlias

- - -

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

- -

Hay dos pasos a seguir para permitir la ejecucin CGI en directorios - seleccionados de manera arbitraria. Primero, el handler - cgi-script debe estar activado usando la directiva - AddHandler o la directiva - SetHandler. Segundo, el parmetro - ExecCGI debe estar definido en la directiva - Options.

- - -

Usando Options de manera explcita para permitir ejecucin de - CGI

- - -

Puede usar la directiva - Options, en el archivo de - configuracin principal para especificar que se permite la ejecucin - de CGI en un directorio en particular:

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

Esta directiva de aqu arriba le indica a Apache que debe - permitir la ejecucin de archivos CGI. Tambin necesitar indicarle - al servidor que los archivos son archivos CGI. La directiva - AddHandler le indica al - servidor que debe tratar a todos los archivos con la extensin - cgi o pl como programas CGI:

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

Ficheros .htaccess

- - -

El tutorial .htaccess - ensea como activar programas CGI si no tienes acceso a - httpd.conf.

- - -

Directorios de Usuario

- - -

Para permitir la ejecucin de programas CGI para cualquier - archivo que acabe en .cgi en directorios de usuario, - puedes usar la siguiente configuracin:

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

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

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

Escribiendo un programa CGI

- - -

Hay dos diferencias principales entre programacin ``regular'' y - programacin en CGI.

- -

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

- -

- Content-type: text/html -

- -

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

- -

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

- - -

Su primer programa CGI

- - -

A continuacin podr ver un ejemplo de programa CGI que muestra - una lnea de texto en su navegador. Escriba lo siguiente, - gurdelo en un archivo con el nombre first.pl, y - pngalo en su directorio cgi-bin.

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

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

- -

Si lo abre con su navegador favorito y le dice que solicite la - direccin

- -

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

- -

o donde quiera que pusiera el archivo, ver una lnea - Hola, Mundo. aparecern la ventana del navegador. No es - muy emocionante, pero una vez que consiga que funcione podr hacer - lo mismo con casi cualquier programa.

- -
top
-
-

Pero todava no funciona!

- - -

Hay 4 cosas bsicas que puede llegar a ver en su navegador cuando - intenta acceder a un programa CGI desde la web:

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

Permisos de Fichero

- - -

Recuerde que el servidor no se ejecuta con su usuario. Es decir, - cuando el servidor arranca, est funcionando con un usuario sin - privilegios, generalmente el usuario nobody, o - www-data, as que necesitar permisos extra para - ejecutar los archivos de los que usted es dueo. Generalmente, - el mtodo para dar permisos suficientes para que se pueda - ejecutar con nobody es dar permisos de ejecucin a - todo el mundo en el fichero:

- -

- chmod a+x first.pl -

- -

Adems, si su programa lee desde o escribe a cualquier otro/s - archivo/s, esos archivos necesitarn tener los permisos correctos - para permitir esas acciones.

- - - -

Informacin de Ruta y Entorno

- - -

Cuando ejecuta un programa desde la lnea de comandos, usted tiene - cierta informacin que se le pasa a la shell sin que usted se - percate de ello. Por ejemplo, usted tiene un PATH, - que le indica a la shell dnde debe buscar archivos a los que usted - hace referencia.

- -

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

- -

Una manifestacin comn de esto es la ruta del intrprete del - script (a menudo perl) indicado en la primera lnea - de su programa CGI, que parecer algo como:

- - 
#!/usr/bin/perl
- - -

Asegrese de que ste es de hecho el path de su intrprete.

-
- Cuando edita scripts CGI en Windows, los caracteres de retorno de - carro podran aadirse a la lnea donde se especifica el intrprete. - Asegrese de que los archivos se transfieren al servidor en modo - ASCII. Fallar en esto puede acabar con avisos del tipo "Command not - found" del Sistema Operativo, debido a que ste no reconoce los - caracteres de final de lnea interpretados como parte del nombre - de fichero del intrprete. -
- - -

Faltan Variables de Entorno

- - -

Si su programa CGI depende de variables de entorno no estndar, necesitar - asegurarse de que Apache pasa esas variables.

- -

Cuando no encuentra ciertas cabeceras HTTP del entorno, asegrese - de que estn formateadas segn el - RFC 2616, - seccin 4.2: Nombres de Cabeceras deben empezar con una letra, - seguida solo de letras, nmeros o guin. Cualquier cabecera - que no cumpla esta regla ser ignorada de manera silenciosa.

- - - -

Errores de Programa

- - -

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

- -

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

- -

(No llame al intrprete de perl. La consola y Apache - tienen que poder encontrar el intrprete usando lnea - lnea de informacin en la primera - lnea del script.)

- -

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

- - -

Log de Errores

- - -

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

- - -

Suexec

- - -

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

- -

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

- -

A menos que comprenda suxec perfectamente, no debera usarlo. - Para desactivar suexec, basta con eliminar el binario - suexec al que apunta SUEXEC_BIN y - reiniciar el servidor. Si despus de leer sobre - suexec todava quiere usarlo, entonces - ejecute suexec -V para encontrar la ubicacin del - fichero log de suexec, y use ese log para encontrar que poltica no - est cumpliendo.

- -
top
-
-

Qu ocurre entre bastidores?

- - -

En cuanto tenga conocimiento avanzado de programacin CGI, le ser - til comprender ms de lo que ocurre entre bastidores. - Especficamente, cmo el navegador y el servidor se comunican el uno - con el otro. Porque aunque est muy bien escribir un programa que - diga "Hola, Mundo.", no tiene una gran utilidad.

- -

Variables de Entorno

- - -

Las variables de entorno son valores que estn ah cuando - usa el ordenador. Son cosas tiles como el path (donde su ordenador - busca el archivo especfico que se lanza cuando usted escribe un - comando), su nombre de usuario, el tipo de terminal que usa, etc. - Para una lista completa de la variables de entorno normales que se - se usan en su da a da escriba env en la lnea de - comandos.

- -

Durante la transaccin CGI, el servidor y el navegador tambin - configuran variables de entorno, y as pueden comunicarse entre - ellos. Cosas como el tipo de navegador (Netscape, IE, Lynx), el tipo - de servidor (Apache, IIS, WebSite), el nombre del programa CGI que - se est ejecutando, etc.

- -

Estas variables estn disponibles para el programador de CGI, y son - la mitad de la historia de la comunicacin cliente-servidor. La - lista completa de las variables necesarias se encuentra en - el RFC de Common Gateway - Interface.

- -

Este sencillo programa CGI en Perl mostrar todas las variables - de entorno que se estn pasando entre el cliente y el navegador. Dos - programas similares estn incluidos en el directorio - cgi-bin de la distribucin de Apache. Tenga en cuenta - que algunas variables son necesarias mientras que otras son - opcionales, as que es posible que vea algunas variables que no - estn en la lista oficial. Adicionalmente, Apache aporta distintas - maneras diferentes para que pueda - aadir sus variables de entorno a las - bsicas que se proveen por defecto.

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

STDIN y STDOUT

- - -

Otra comunicacin entre el servidor y el cliente ocurre en la - entrada estndar (STDIN) y la salida estndar - (STDOUT). En el contexto normal de cada da, - STDIN es la entrada con el teclado, o un fichero que se - le da a un programa para que acte sobre l, y STDOUT - generalmente es la consola o la pantalla.

- -

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

- -

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

- -

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

- -

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

- -

Su programa es el responsable de convertir esa cadena de - caracteres en informacin til. Afortunadamente, hay libreras y - mdulos disponibles que ayudan a procesar la informacin, as como a - gestionar los distintos aspectos de su programa CGI.

- -
top
-
-

Mdulos/libreras CGI

- - -

Cuando escribe programas CGI, debera considerar usar una librera de - cdigo, o mdulo, para hacer todo el trabajo ms arduo por usted. - Esto lleva a tener menos errores y un desarrollo de cdigo ms - rpido.

- -

Si est escribiendo un programa CGI en Perl, existen mdulos - disponibles en CPAN. El mdulo ms - conocido para este propsito es CGI.pm. Quizs quiera - considerar CGI::Lite, que implementa una funcionalidad - mnima, que es todo lo que se necesita en la mayora de los programas.

- -

Si est escribiendo programas CGI en C, hay varidad de opciones. Una - de estas es la librera CGIC, de - http://www.boutell.com/cgic/. -

-
top
-
-

Para ms informacin

- - -

La especificacin actual de CGI est disponible en el - RFC de Common Gateway - Interface.

- -

Cuando enve una pregunta sobre un problema de CGI, o bien a una - lista de correo, o a un grupo de noticias, asegrese de que facilita suficiente - informacin de lo que ha ocurrido, de lo que espera que ocurra, y de - lo que est ocurriendo en su lugar que es diferente, el servidor que - est ejecutando, en qu lenguaje CGI est hecho su programa, y si es - posible, el cdigo que falla. Esto har encontrar el problema mucho ms - fcil.

- -

Tenga en cuenta que las preguntas sobre problemas CGI - nunca deberan enviarse a la base de datos de bugs de - bugs de Apache a menos que est seguro de haber encontrado un - problema en el cdigo fuente de Apache.

-
-
-

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

-
top

Comentarios

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

Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

+

Versin 2.5 del Servidor HTTP Apache

+
+
<-
+

Tutorial de Apache: Contenido Dinmico con CGI

+
+

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

+
+
+ +
top
+
+

Introduccin

+ +
Mdulos RelacionadosDirectivas Relacionadas
+ +

CGI (Common Gateway Interface) es un mtodo por el cual + un servidor web puede interactuar con programas externos de + generacin de contenido, a ellos nos referimos comnmente como + programas CGI o scripts CGI. Es el mtodo ms comn y sencillo de + mostrar contenido dinmico en su sitio web. Este documento es una + introduccin para configurar CGI en su servidor web Apache, y de + iniciacin para escribir programas CGI.

+
top
+
+

Configurando Apache para permitir CGI

+ + +

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

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

ScriptAlias

+ + +

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

+ +

La directiva + ScriptAlias se puede + definir as:

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

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

+ +

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

+ + +

CGI fuera de directorios ScriptAlias

+ + +

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

+ +

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

+ + +

Usando Options de manera explcita para permitir ejecucin de + CGI

+ + +

Puede usar la directiva + Options, en el archivo de + configuracin principal para especificar que se permite la ejecucin + de CGI en un directorio en particular:

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

Esta directiva de aqu arriba le indica a Apache que debe + permitir la ejecucin de archivos CGI. Tambin necesitar indicarle + al servidor que los archivos son archivos CGI. La directiva + AddHandler le indica al + servidor que debe tratar a todos los archivos con la extensin + cgi o pl como programas CGI:

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

Ficheros .htaccess

+ + +

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

+ + +

Directorios de Usuario

+ + +

Para permitir la ejecucin de programas CGI para cualquier + archivo que acabe en .cgi en directorios de usuario, + puedes usar la siguiente configuracin:

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

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

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

Escribiendo un programa CGI

+ + +

Hay dos diferencias principales entre programacin ``regular'' y + programacin en CGI.

+ +

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

+ +

+ Content-type: text/html +

+ +

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

+ +

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

+ + +

Su primer programa CGI

+ + +

A continuacin podr ver un ejemplo de programa CGI que muestra + una lnea de texto en su navegador. Escriba lo siguiente, + gurdelo en un archivo con el nombre first.pl, y + pngalo en su directorio cgi-bin.

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

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

+ +

Si lo abre con su navegador favorito y le dice que solicite la + direccin

+ +

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

+ +

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

+ +
top
+
+

Pero todava no funciona!

+ + +

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

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

Permisos de Fichero

+ + +

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

+ +

+ chmod a+x first.pl +

+ +

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

+ + + +

Informacin de Ruta y Entorno

+ + +

Cuando ejecuta un programa desde la lnea de comandos, usted tiene + cierta informacin que se le pasa a la shell sin que usted se + percate de ello. Por ejemplo, usted tiene un PATH, + que le indica a la shell dnde debe buscar archivos a los que usted + hace referencia.

+ +

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

+ +

Una manifestacin comn de esto es la ruta del intrprete del + script (a menudo perl) indicado en la primera lnea + de su programa CGI, que parecer algo como:

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

Asegrese de que ste es de hecho el path de su intrprete.

+
+ Cuando edita scripts CGI en Windows, los caracteres de retorno de + carro podran aadirse a la lnea donde se especifica el intrprete. + Asegrese de que los archivos se transfieren al servidor en modo + ASCII. Fallar en esto puede acabar con avisos del tipo "Command not + found" del Sistema Operativo, debido a que ste no reconoce los + caracteres de final de lnea interpretados como parte del nombre + de fichero del intrprete. +
+ + +

Faltan Variables de Entorno

+ + +

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

+ +

Cuando no encuentra ciertas cabeceras HTTP del entorno, asegrese + de que estn formateadas segn el + RFC 2616, + seccin 4.2: Nombres de Cabeceras deben empezar con una letra, + seguida solo de letras, nmeros o guin. Cualquier cabecera + que no cumpla esta regla ser ignorada de manera silenciosa.

+ + + +

Errores de Programa

+ + +

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

+ +

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

+ +

(No llame al intrprete de perl. La consola y Apache + tienen que poder encontrar el intrprete usando lnea + lnea de informacin en la primera + lnea del script.)

+ +

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

+ + +

Log de Errores

+ + +

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

+ + +

Suexec

+ + +

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

+ +

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

+ +

A menos que comprenda suxec perfectamente, no debera usarlo. + Para desactivar suexec, basta con eliminar el binario + suexec al que apunta SUEXEC_BIN y + reiniciar el servidor. Si despus de leer sobre + suexec todava quiere usarlo, entonces + ejecute suexec -V para encontrar la ubicacin del + fichero log de suexec, y use ese log para encontrar que poltica no + est cumpliendo.

+ +
top
+
+

Qu ocurre entre bastidores?

+ + +

En cuanto tenga conocimiento avanzado de programacin CGI, le ser + til comprender ms de lo que ocurre entre bastidores. + Especficamente, cmo el navegador y el servidor se comunican el uno + con el otro. Porque aunque est muy bien escribir un programa que + diga "Hola, Mundo.", no tiene una gran utilidad.

+ +

Variables de Entorno

+ + +

Las variables de entorno son valores que estn ah cuando + usa el ordenador. Son cosas tiles como el path (donde su ordenador + busca el archivo especfico que se lanza cuando usted escribe un + comando), su nombre de usuario, el tipo de terminal que usa, etc. + Para una lista completa de la variables de entorno normales que se + se usan en su da a da escriba env en la lnea de + comandos.

+ +

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

+ +

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

+ +

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

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

STDIN y STDOUT

+ + +

Otra comunicacin entre el servidor y el cliente ocurre en la + entrada estndar (STDIN) y la salida estndar + (STDOUT). En el contexto normal de cada da, + STDIN es la entrada con el teclado, o un fichero que se + le da a un programa para que acte sobre l, y STDOUT + generalmente es la consola o la pantalla.

+ +

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

+ +

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

+ +

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

+ +

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

+ +

Su programa es el responsable de convertir esa cadena de + caracteres en informacin til. Afortunadamente, hay libreras y + mdulos disponibles que ayudan a procesar la informacin, as como a + gestionar los distintos aspectos de su programa CGI.

+ +
top
+
+

Mdulos/libreras CGI

+ + +

Cuando escribe programas CGI, debera considerar usar una librera de + cdigo, o mdulo, para hacer todo el trabajo ms arduo por usted. + Esto lleva a tener menos errores y un desarrollo de cdigo ms + rpido.

+ +

Si est escribiendo un programa CGI en Perl, existen mdulos + disponibles en CPAN. El mdulo ms + conocido para este propsito es CGI.pm. Quizs quiera + considerar CGI::Lite, que implementa una funcionalidad + mnima, que es todo lo que se necesita en la mayora de los programas.

+ +

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

+
top
+
+

Para ms informacin

+ + +

La especificacin actual de CGI est disponible en el + RFC de Common Gateway + Interface.

+ +

Cuando enve una pregunta sobre un problema de CGI, o bien a una + lista de correo, o a un grupo de noticias, asegrese de que facilita suficiente + informacin de lo que ha ocurrido, de lo que espera que ocurra, y de + lo que est ocurriendo en su lugar que es diferente, el servidor que + est ejecutando, en qu lenguaje CGI est hecho su programa, y si es + posible, el cdigo que falla. Esto har encontrar el problema mucho ms + fcil.

+ +

Tenga en cuenta que las preguntas sobre problemas CGI + nunca deberan enviarse a la base de datos de bugs de + bugs de Apache a menos que est seguro de haber encontrado un + problema en el cdigo fuente de Apache.

+
+
+

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

+
top

Comentarios

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

Modules | Directives | FAQ | Glossaire | Plan du site

-

Serveur HTTP Apache Version 2.5

-
-
<-
-

Tutoriel Apache : Contenu dynamique basé sur CGI

-
-

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

-
-
- -
top
-
-

Introduction

- - -
Modules ApparentésDirectives Apparentées
- -

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

-
top
-
-

Configurer Apache pour autoriser CGI

- - -

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

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

ScriptAlias

- - -

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

- -

La directive ScriptAlias se présente comme suit - :

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

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

- -

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

- - -

CGI en dehors des répertoires ScripAlias

- - -

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

- -

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

- - -

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

- - -

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

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

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

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

Fichiers .htaccess

- - -

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

- - -

Répertoires utilisateurs

- - -

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

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

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

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

Ecrire un programme CGI

- - -

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

- -

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

- -

- Content-type: text/html -

- -

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

- -

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

- -

Votre premier programme CGI

- - -

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

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

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

- -

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

- -

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

- -

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

- -
top
-
-

Mais ça ne marche toujours pas !

- - -

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

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

Droits des fichiers

- - -

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

- -

- chmod a+x premier.pl -

- -

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

- - - -

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

- - -

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

- -

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

- -

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

- - 
#!/usr/bin/perl
- - -

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

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

Variables d'environnement manquantes

- - -

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

- -

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

- - - -

Erreurs inhérentes au programme

- - -

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

- -

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

- -

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

- -

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

- - -

Journalisation des erreurs

- - -

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

- - -

Suexec

- - -

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

- -

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

- -

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

- -
top
-
-

Que se passe-t-il en coulisse

- - -

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

- -

Variables d'environnement

- - -

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

- -

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

- -

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

- -

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

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

STDIN et STDOUT

- - -

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

- -

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

- -

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

- -

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

- -

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

- -

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

- -
top
-
-

Bibliothèques et modules CGI

- - -

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

- -

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

- -

Si vous écrivez des programmes CGI en C, vous disposez de - nombreuses options. L'une d'elles est la bibliothèque - CGIC de http://www.boutell.com/cgic/.

-
top
-
-

Pour plus d'informations

- - -

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

- -

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

- -

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

-
-
-

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

-
top

Commentaires

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

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.5

+
+
<-
+

Tutoriel Apache : Contenu dynamique basé sur CGI

+
+

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

+
+
+ +
top
+
+

Introduction

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

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

+
top
+
+

Configurer Apache pour autoriser CGI

+ + +

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

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

ScriptAlias

+ + +

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

+ +

La directive ScriptAlias se présente comme suit + :

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

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

+ +

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

+ + +

CGI en dehors des répertoires ScripAlias

+ + +

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

+ +

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

+ + +

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

+ + +

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

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

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

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

Fichiers .htaccess

+ + +

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

+ + +

Répertoires utilisateurs

+ + +

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

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

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

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

Ecrire un programme CGI

+ + +

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

+ +

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

+ +

+ Content-type: text/html +

+ +

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

+ +

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

+ +

Votre premier programme CGI

+ + +

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

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

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

+ +

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

+ +

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

+ +

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

+ +
top
+
+

Mais ça ne marche toujours pas !

+ + +

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

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

Droits des fichiers

+ + +

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

+ +

+ chmod a+x premier.pl +

+ +

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

+ + + +

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

+ + +

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

+ +

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

+ +

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

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

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

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

Variables d'environnement manquantes

+ + +

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

+ +

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

+ + + +

Erreurs inhérentes au programme

+ + +

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

+ +

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

+ +

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

+ +

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

+ + +

Journalisation des erreurs

+ + +

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

+ + +

Suexec

+ + +

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

+ +

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

+ +

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

+ +
top
+
+

Que se passe-t-il en coulisse

+ + +

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

+ +

Variables d'environnement

+ + +

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

+ +

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

+ +

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

+ +

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

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

STDIN et STDOUT

+ + +

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

+ +

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

+ +

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

+ +

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

+ +

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

+ +

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

+ +
top
+
+

Bibliothèques et modules CGI

+ + +

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

+ +

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

+ +

Si vous écrivez des programmes CGI en C, vous disposez de + nombreuses options. L'une d'elles est la bibliothèque + CGIC de http://www.boutell.com/cgic/.

+
top
+
+

Pour plus d'informations

+ + +

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

+ +

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

+ +

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

+
+
+

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

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/encrypt.html b/docs/manual/howto/encrypt.html index 94305ee459..64897134b7 100644 --- a/docs/manual/howto/encrypt.html +++ b/docs/manual/howto/encrypt.html @@ -6,4 +6,4 @@ Content-type: text/html; charset=ISO-8859-1 URI: encrypt.html.es Content-Language: es -Content-type: text/html; charset=ISO-8859-1 +Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/howto/encrypt.html.en b/docs/manual/howto/encrypt.html.en index 5440c1aca5..4b339cb6b4 100644 --- a/docs/manual/howto/encrypt.html.en +++ b/docs/manual/howto/encrypt.html.en @@ -24,7 +24,7 @@ Apache > HTTP Server > Documentation > Version 2.5 > How-To / Tutorials

How to Encrypt Your Traffic

Available Languages:  en  | - es 

+ es 

This is the how to guide for making your Apache httpd use encryption to transfer @@ -174,7 +174,7 @@

Available Languages:  en  | - es 

+ es 

top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
- - -
-

Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

-

Versin 2.5 del Servidor HTTP Apache

-
-
<-
-

Como Cifrar su Trfico

-
-

Idiomas disponibles:  en  | - es 

-
- -

En esta gua se explica cmo hacer que su servidor HTTPD Apache - use un cifrado para transferir datos entre el servidor y sus visitantes. En vez - de usar enlaces http:, usar del tipohttps:, si todo - est configurado correctamente, toda persona que visite su web, tendr ms - privacidad y proteccin.

-

Este manual est pensado para aquellos que no estn muy familiarizados con - SSL/TLS y cifrados, junto con toda la jerga tcnica incomprensible (Estamos - bromeando, este tema es bastante importante, con - serios expertos en el tema, y problemas reales que resolver - pero s, suena a - jerga tcnica incomprensible para todos aquellos que no hayan tratado con esto). - Personas que han escuchado que su servidor http: no es del todo seguro a dia de - hoy. Que los espas y los malos estn escuchando. Que incluso las empresas - legtimas estn insertando datos en sus pginas web y vendiendo perfiles de - visitantes. -

-

En esta gua nos centraremos en ayudarle para migrar su servidor httpd, para - que deje de servir enlaces va http: y los sirva va - https: ones, without you becoming a SSL expert first. You might - get fascinated by all this crypto things and study it more and become a real - expert. But you also might not, run a reasonably secure web server nevertheless - and do other things good for mankind with your time.

You - will get a rough idea what roles these mysterious things called "certificate" - and "private key" play and how they are used to let your visitors be sure - they are talking to your server. You will not be told how - this works, just how it is used: it's basically about passports.

-
- -
top
-
-

Pequea introduccin a Certificados e.j: Pasaporte de Internet

- - -

The TLS protocol (formerly known as SSL) is a - way a client and a server can talk to each other without anyone else - listening, or better understanding a thing. It is what your browser uses when - you open a https: link.

In addition to having a private conversation - with a server, your browser also needs to know that it really talks to the - server - and not someone else acting like it. That, next to the encryption, is - the other part of the TLS protocol.

In order to do that, your server - does not only need the software for TLS, e.g. the mod_ssl module, but some sort of identity - proof on the Internet. This is commonly referred to as a certificate. - Basically, everyone has the same mod_ssl and can encrypt, but only your have - your certificate and with that, you are you.

A certificate - is the digital equivalent of a passport. It contains two things: a stamp of - approval from the people issuing the passport and a reference to your digital - fingerprints, e.g. what is called a private key in encryption terms. -

When you configure your Apache httpd for https: links, you need to - give it the certificate and the private key. If you never give the key to - anyone else, only you will be able to prove to visitors that the certificate - belongs to you. That way, a browser talking to your server a second time will - be sure that it is indeed the very same server it talked to before.

- But how does it know that it is the real server, the first time it starts - talking to someone? Here, the digital rubber stamping comes into play. The - rubber stamp is done by someone else, using her own private key. That person - has also a certificate, e.g. her own passport. The browser can make sure that - this passport is based on the same key that was used to rubber stamp your - server passport. Now, instead of making sure that your passport is correct, it - must make sure that the passport of the person that says your - passport is correct, is correct.

And that passport is also rubber - stamped digitally, by someone else with a key and a certificate. So the - browser only needs to make sure that that one is correct that says it - is correct to trust the one that says your server is correct. This trusting - game can go to a few or many levels (usually less than 5).

In the - end, the browser will encounter a passport that is stamped by its own key. - It's a Gloria Gaynor certificate that says "I am what I am!". The browser then - either trust this Gloria or not. If not, your server is also not trusted. - Otherwise, it is. Simple.

The trust check for the Gloria Gaynors of - the Internet is easy: your browser (or your operating system) comes with list - of Gloria passports to trust, pre-installed. If it sees a Gloria certificate, - it is either in this list or not to be trusted.

This whole thing - works as long as everyone keeps his private keys to himself. Anyone copying - such a key can impersonate the key owner. And if the owner can rubber stamp - passports, the impersonator can also do that. And all the passports stamped by - an impersonator, all those certificates will look 100% valid, - indistinguishable from the "real" ones.

So, this trust model works, - but it has its limits. That is why browser makers are so keen on having the - correct Gloria Gaynor lists and threaten to expel anyone from it that is - careless with her keys.

top
-
-

Comprar un Certificado

Bueno, pueds - comprar uno. Hay muchas compaias vendiando pasaportes de Internet como - servicio. En esta lista de - Mozilla, podrs encontrar todas las compaias en las que el navegador - Firefox confa. Escoge una, visita su pagina web y te diran los diferentes - precios, y como hacer para comprobar tu identidad y quien dices ser quien - eres, y as podrn generar tu pasaporte con confianza.

- - They all have their own methods, also depending on what kind of passport you -apply for, and it's probably some sort of click web interface in a browser. -They may send you an email that you need to answer or do something else. In -the end, they will show you how to generate your own, unique private key and -issue you a stamped passport matching it.

You then place -the key in one file, the certificate in another. Put these on your server, make -sure that only a trusted user can read the key file and add it to your httpd -configuration. This is extensively covered in the SSL How-To.

-
top
-
-

Get a Free Certificate

Hay tambin - compaias que ofrecen certificados gratuitos para servidores web. La pionera - en esto es Let's Encrypt que es un - servicio de la organizacin sin nimo de lucro (ISRG) Internet - Security Research Group , para "reducir las barreras financieras, - tecnolgicas y de educacin, para securizar las comunicaciones en Internet." -

No slo ofrencen certificados gratuitos, tambin han desaarrollado - una interfz que puede ser usada en su Apache Httpd para obtener uno. Aqu es - donde mod_md entra en juego.

(zoom - out the camera on how to configure mod_md and virtual host...)

-
-

Idiomas disponibles:  en  | - es 

-
top

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
-
- \ No newline at end of file diff --git a/docs/manual/howto/encrypt.html.es.utf8 b/docs/manual/howto/encrypt.html.es.utf8 new file mode 100644 index 0000000000..c4f3565a5a --- /dev/null +++ b/docs/manual/howto/encrypt.html.es.utf8 @@ -0,0 +1,168 @@ + + + + + +Como Cifrar su Trfico - Servidor HTTP Apache Versin 2.5 + + + + + + +
+

Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

+

Versin 2.5 del Servidor HTTP Apache

+
+
<-
+

Como Cifrar su Trfico

+
+

Idiomas disponibles:  en  | + es 

+
+ +

En esta gua se explica cmo hacer que su servidor HTTPD Apache + use un cifrado para transferir datos entre el servidor y sus visitantes. En vez + de usar enlaces http:, usar del tipohttps:, si todo + est configurado correctamente, toda persona que visite su web, tendr ms + privacidad y proteccin.

+

Este manual est pensado para aquellos que no estn muy familiarizados con + SSL/TLS y cifrados, junto con toda la jerga tcnica incomprensible (Estamos + bromeando, este tema es bastante importante, con + serios expertos en el tema, y problemas reales que resolver - pero s, suena a + jerga tcnica incomprensible para todos aquellos que no hayan tratado con esto). + Personas que han escuchado que su servidor http: no es del todo seguro a dia de + hoy. Que los espas y los malos estn escuchando. Que incluso las empresas + legtimas estn insertando datos en sus pginas web y vendiendo perfiles de + visitantes. +

+

En esta gua nos centraremos en ayudarle para migrar su servidor httpd, para + que deje de servir enlaces va http: y los sirva va + https: ones, without you becoming a SSL expert first. You might + get fascinated by all this crypto things and study it more and become a real + expert. But you also might not, run a reasonably secure web server nevertheless + and do other things good for mankind with your time.

You + will get a rough idea what roles these mysterious things called "certificate" + and "private key" play and how they are used to let your visitors be sure + they are talking to your server. You will not be told how + this works, just how it is used: it's basically about passports.

+
+ +
top
+
+

Pequea introduccin a Certificados e.j: Pasaporte de Internet

+ + +

The TLS protocol (formerly known as SSL) is a + way a client and a server can talk to each other without anyone else + listening, or better understanding a thing. It is what your browser uses when + you open a https: link.

In addition to having a private conversation + with a server, your browser also needs to know that it really talks to the + server - and not someone else acting like it. That, next to the encryption, is + the other part of the TLS protocol.

In order to do that, your server + does not only need the software for TLS, e.g. the mod_ssl module, but some sort of identity + proof on the Internet. This is commonly referred to as a certificate. + Basically, everyone has the same mod_ssl and can encrypt, but only your have + your certificate and with that, you are you.

A certificate + is the digital equivalent of a passport. It contains two things: a stamp of + approval from the people issuing the passport and a reference to your digital + fingerprints, e.g. what is called a private key in encryption terms. +

When you configure your Apache httpd for https: links, you need to + give it the certificate and the private key. If you never give the key to + anyone else, only you will be able to prove to visitors that the certificate + belongs to you. That way, a browser talking to your server a second time will + be sure that it is indeed the very same server it talked to before.

+ But how does it know that it is the real server, the first time it starts + talking to someone? Here, the digital rubber stamping comes into play. The + rubber stamp is done by someone else, using her own private key. That person + has also a certificate, e.g. her own passport. The browser can make sure that + this passport is based on the same key that was used to rubber stamp your + server passport. Now, instead of making sure that your passport is correct, it + must make sure that the passport of the person that says your + passport is correct, is correct.

And that passport is also rubber + stamped digitally, by someone else with a key and a certificate. So the + browser only needs to make sure that that one is correct that says it + is correct to trust the one that says your server is correct. This trusting + game can go to a few or many levels (usually less than 5).

In the + end, the browser will encounter a passport that is stamped by its own key. + It's a Gloria Gaynor certificate that says "I am what I am!". The browser then + either trust this Gloria or not. If not, your server is also not trusted. + Otherwise, it is. Simple.

The trust check for the Gloria Gaynors of + the Internet is easy: your browser (or your operating system) comes with list + of Gloria passports to trust, pre-installed. If it sees a Gloria certificate, + it is either in this list or not to be trusted.

This whole thing + works as long as everyone keeps his private keys to himself. Anyone copying + such a key can impersonate the key owner. And if the owner can rubber stamp + passports, the impersonator can also do that. And all the passports stamped by + an impersonator, all those certificates will look 100% valid, + indistinguishable from the "real" ones.

So, this trust model works, + but it has its limits. That is why browser makers are so keen on having the + correct Gloria Gaynor lists and threaten to expel anyone from it that is + careless with her keys.

top
+
+

Comprar un Certificado

Bueno, pueds + comprar uno. Hay muchas compaias vendiando pasaportes de Internet como + servicio. En esta lista de + Mozilla, podrs encontrar todas las compaias en las que el navegador + Firefox confa. Escoge una, visita su pagina web y te diran los diferentes + precios, y como hacer para comprobar tu identidad y quien dices ser quien + eres, y as podrn generar tu pasaporte con confianza.

+ + They all have their own methods, also depending on what kind of passport you +apply for, and it's probably some sort of click web interface in a browser. +They may send you an email that you need to answer or do something else. In +the end, they will show you how to generate your own, unique private key and +issue you a stamped passport matching it.

You then place +the key in one file, the certificate in another. Put these on your server, make +sure that only a trusted user can read the key file and add it to your httpd +configuration. This is extensively covered in the SSL How-To.

+
top
+
+

Get a Free Certificate

Hay tambin + compaias que ofrecen certificados gratuitos para servidores web. La pionera + en esto es Let's Encrypt que es un + servicio de la organizacin sin nimo de lucro (ISRG) Internet + Security Research Group , para "reducir las barreras financieras, + tecnolgicas y de educacin, para securizar las comunicaciones en Internet." +

No slo ofrencen certificados gratuitos, tambin han desaarrollado + una interfz que puede ser usada en su Apache Httpd para obtener uno. Aqu es + donde mod_md entra en juego.

(zoom + out the camera on how to configure mod_md and virtual host...)

+
+

Idiomas disponibles:  en  | + es 

+
top

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/htaccess.html b/docs/manual/howto/htaccess.html index b3d6aedc13..f49462cd25 100644 --- a/docs/manual/howto/htaccess.html +++ b/docs/manual/howto/htaccess.html @@ -6,7 +6,7 @@ Content-type: text/html; charset=ISO-8859-1 URI: htaccess.html.es Content-Language: es -Content-type: text/html; charset=ISO-8859-1 +Content-type: text/html; charset=UTF-8 URI: htaccess.html.fr Content-Language: fr diff --git a/docs/manual/howto/htaccess.html.en b/docs/manual/howto/htaccess.html.en index 9214745234..070d8eca25 100644 --- a/docs/manual/howto/htaccess.html.en +++ b/docs/manual/howto/htaccess.html.en @@ -24,11 +24,11 @@ Apache > HTTP Server > Documentation > Version 2.5 > How-To / Tutorials

Apache HTTP Server Tutorial: .htaccess files

Available Languages:  en  | - es  | - fr  | + es  | + fr  |  ja  |  ko  | - pt-br 

+ pt-br 

.htaccess files provide a way to make configuration @@ -433,11 +433,11 @@ SetHandler cgi-script

Available Languages:  en  | - es  | - fr  | + es  | + fr  |  ja  |  ko  | - pt-br 

+ pt-br 

top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
- - -
-

Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

-

Versin 2.5 del Servidor HTTP Apache

-
-
<-
-

Tutorial del Servidor Apache HTTP: Ficheros .htaccess

-
-

Idiomas disponibles:  en  | - es  | - fr  | - ja  | - ko  | - pt-br 

-
- -

Los ficheros .htaccess facilitan una forma de realizar - cambios en la configuracin en contexto directorio.

-
- -
top
-
-

Ficheros .htaccess

-
Mdulos RelacionadosDirectivas Relacionadas
- -
Debera evitar usar ficheros .htaccess completamente si - tiene acceso al fichero de configuracin principal de httpd. Usar ficheros - .htaccess ralentiza su servidor Apache http. Cualquier - directiva que pueda incluir en un fichero .htaccess - estar mejor configurada dentro de una seccin - Directory, tendr el mismo efecto y - mejor rendimiento.
-
top
-
-

Qu son/Cmo usarlos

- - -

Los ficheros .htaccess (o "ficheros de configuracin - distribuida") facilitan una forma de realizar cambios en la configuracin - en contexto directorio. Un fichero, que contiene una o ms directivas, se - coloca en un documento especfico de un directorio, y estas directivas - aplican a ese directorio y todos sus subdirectorios.

- -

Nota:

-

Si quiere llamar a su fichero .htaccess de otra manera, - puede cambiar el nombre del fichero usando la directiva AccessFileName. Por ejemplo, si usted prefiere - llamar al fichero .config, entonces puede poner lo siguiente - en el fichero de configuracin de su servidor:

- - 
AccessFileName ".config"
- -
- -

Generalmente, los ficheros .htaccess usan la misma sintxis - que los ficheros de la configuracin - principal. Lo que puede utilizar en estos ficheros lo determina la - directiva AllowOverride. Esta directiva - especifica, en categoras, qu directivas tendrn efecto si se encuentran en - un fichero .htaccess. Si se permite una directiva en un fichero - .htaccess, la documentacin para esa directiva contendr una - seccin Override, especificando qu valor debe ir en - AllowOverride para que se permita esa - directiva.

- -

Por ejemplo, si busca en la documentacin la directiva AddDefaultCharset, encontrar que se permite en - ficheros .htaccess. (Vea la lnea de Contexto en el sumario de - la directiva.) La lnea Override muestra - FileInfo. De este modo, debe tener al menos - AllowOverride FileInfo para que esta directiva se aplique en - ficheros .htaccess.

- -

Ejemplo:

- - - - - - - - - -
Context:server config, virtual host, directory, .htaccess
Override:FileInfo
- -

Si no est seguro de cundo, una directiva en concreto, se puede usar en un - fichero .htaccess, consulte la documentacin para esa directiva, - y compruebe la lnea Context buscando ".htaccess".

-
top
-
-

Cuando (no) usar ficheros .htaccess

- -

Generalmente, solo debera usar ficheros .htaccess cuando no - tiene acceso al fichero principal de configuracin del servidor. Hay, por - ejemplo, una creencia errnea de que la autenticacin de usuario debera - hacerse siempre dentro de ficheros .htaccess, y, ms recientemente, otra creencia errnea de que las directivas de - mod_rewrite deben ir en ficheros .htaccess. - Esto sencillamente no es el caso. Puede poner las configuraciones de - autenticacin de usuario en la configuracin principal del servidor, y esto - es de hecho, el mtodo preferido de configurar Apache. Del mismo modo, las - directivas mod_rewrite funcionan mejor, en muchos sentidos, en - el fichero de configuracin principal del servidor.

- -

Los ficheros .htaccess deberan usarse cuando su proveedor - de contenidos le permite hacer modificaciones de configuracin - en contexto directorio, pero usted no tiene acceso de root en el servidor. - En el caso de que el administrador no est dispuesto a hacer cambios - frecuentes en la configuracin, puede que sea necesario permitir a usuarios - individuales realizar estos cambios de configuracin en ficheros - .htaccess por ellos mismos. Lo cual ocurre a menudo, por - ejemplo, en casos donde los ISP estn albergando mltiples sitios web de - usuario en una sola mquina, y quieren que sus usuarios tengan la - posibilidad de modificar sus configuraciones.

- -

Aun as, generalmente, el uso de ficheros .htaccess debera - evitarse cuando sea posible. Cualquier configuracin que considerara poner - en un fichero .htaccess, puede usarse con la misma efectividad - en una seccin <Directory> en el fichero de configuracin - del servidor.

- -

Hay dos razones para evitar el uso de ficheros .htaccess.

- -

La primera es el rendimiento. Cuando AllowOverride - est configurado para permitir el uso de ficheros .htaccess, - httpd buscar ficheros .htaccess en cada directorio. As, - permitiendo ficheros .htaccess provoca una prdida de - rendimiento, incluso aunque no los use! Adems, los ficheros - .htaccess se cargan cada vez que se solicita un documento.

- -

Adems tenga en cuenta que httpd debe buscar ficheros - .htaccess en todos los directorios de mayor jerarqua, - para poder terner la lista completa de directivas que debe aplicar. (Vea - la seccin sobre Cmo se aplican las directivas.) As, si - se solicita un fichero de un directorio /www/htdocs/example, - httpd debe buscar los siguientes ficheros:

- -

- /.htaccess
- /www/.htaccess
- /www/htdocs/.htaccess
- /www/htdocs/example/.htaccess -

- -

De esta manera, por cada acceso a un fichero de ese directorio, hay 4 - accesos adicionales al sistema de ficheros, incluso si ninguno de esos - ficheros est presente. (Tenga en cuenta que este caso solo se dara si los - ficheros .htaccess estn activados en /, que - generalmente no es el caso.).

- -

En el caso de las directivas RewriteRule, en el contexto de - .htaccess estas expresiones regulares deben recompilarse con - cada solicitud a ese directorio, cuando en el contexto de configuracin del - servidor solo se compilan una vez y se cachean. Adicionalmente, las reglas - en s mismas son ms complicadas, puesto que uno debe sortear las - restricciones que vienen acompaadas del contexto directorio y - mod_rewrite. Consulte la Gua de Rewrite para un mayor - detalle sobre este tema.

- -

La segunda consideracin es de seguridad. Estar permitiendo que usuarios - modifiquen la configuracin del servidor, lo cual puede dar lugar a cambios sobre los que usted no tendr ningn control. Medite profundamente si debe - dar a sus usuarios ese privilegio. Adems tenga en cuenta que dar a los usuarios menos privilegios de los que necesitan dar lugar a ms peticiones - de soporte. Asegrese de que le indica a sus usuarios claramente el nivel de privilegios que les est dando. Especificando exactamente cmo ha - configurado AllowOverride, e invteles - a revisar la documentacin relacionada, lo cual le ahorrar - bastantes confusiones ms adelante.

- -

Tenga en cuenta que esto es equivalente por completo a poner un fichero - .htaccess en un directorio /www/htdocs/example - con una directiva, y poner la misma directiva en una seccin - Directory <Directory "/www/htdocs/example"> en su - configuracin principal del servidor:

- -

Fichero .htaccess en /www/htdocs/example:

- -

Contenido de fichero .htaccess en - /www/htdocs/example

AddType text/example ".exm"
-
- -

Seccin de su fichero httpd.conf

<Directory "/www/htdocs/example">
-    AddType text/example ".exm"
-</Directory>
-
- -

Aun as, poniendo sta en el fichero de configuracin dar como resultado - una menor prdida de rendimiento, y como la configuracin se carga una vez - cuando el httpd arranca, en lugar de cada vez que se solicita un fichero.

- -

El uso de ficheros .htaccess puede desactivarse por completo - configurando la directiva AllowOverride - a none:

- - 
AllowOverride None
- -
top
-
-

How directives are applied

- -

Las directivas de configuracin que se encuentran en el fichero - .htaccess se aplican al directorio en el que el fichero - .htaccess se encuentra, y a todos sus subdirectorios. Sin - embargo, es importante recordar que puede haber otros ficheros - .htaccess en directorios previos. Las directivas se aplican en - el orden en el que se encuentran. Por lo tanto, un fichero - .htaccess puede sobrescribir directivas que se encuentran - en ficheros .htaccess que se encuentran en directorios previos - del rbol de directorios. Y estos, en cambio, pueden haber sobrescrito - directivas que se encontraban ms arriba, o en el fichero principal de - configuracin del servidor mismo.

- -

Ejemplo:

- -

En el directorio /www/htdocs/example1 tenemos un fichero - .htaccess que contiene lo siguiente:

- - 
Options +ExecCGI
- - -

(Nota: debe terner "AllowOverride Options" configurado para - permitir el uso de la directiva "Options" en ficheros - .htaccess files.)

- -

En el directorio /www/htdocs/example1/example2 tenemos un - fichero .htaccess que contiene:

- - 
Options Includes
- - -

Por este segundo fichero .htaccess, en el directorio - /www/htdocs/example1/example2, la ejecucin de CGI execution no - est permitida, porque solo se ha definido Options Includes, - que sobrescribe completamente una configuracin previa que se pudiera haber - definido.

- -

Incorporando el .htaccess en los ficheros de - configuracin principal

- -

Como se ha comentado en la documentacin en las Secciones de Configuracin, los ficheros - .htaccess pueden sobrescribir las secciones <Directory> por el directorio - correspondiente, pero se sobrescribirn por otros tipos de secciones de - configuracin de los ficheros de configuracin principal. Este hecho se - puede usar para forzar ciertas configuraciones, incluso en presencia - de una configuracin laxa de - AllowOverride. Por ejemplo, para - prevenir la ejecucin de un script mientras se permite cualquier otra cosa - en .htaccess puede usar:

- - 
<Directory "/www/htdocs">
-    AllowOverride All
-</Directory>
-
-<Location "/">
-    Options +IncludesNoExec -ExecCGI
-</Location>
- - -
Este ejemplo asume que su DocumentRoot es /www/htdocs.
- - -
top
-
-

Ejemplo de Autenticacin

- -

Si salt directamente a esta parte del documento para averiguar como - hacer la autenticacin, es important que tenga en cuenta una cosa. Hay una - creencia errnea de que necesita usar ficheros .htaccess para - configurar autenticacin con contrasea. Este no es el caso. Colocar las - directivas de autenticacin en una seccin - <Directory>, en su fichero - de configuracin principal, es el mtodo recomendado para configurar esto, - y los ficheros .htaccess deberan usarse solamente si no tiene - acceso al fichero de configuracin principal del servidor. Vea ms arriba una explicacin de cuando debera y cuando no - debera usar ficheros .htaccess.

- -

Dicho esto, si todava cree que debe usar el fichero - .htaccess, podr ver que una configuracin como la que sigue - podra servirle.

- -

Contenido del fichero .htaccess:

- - 
AuthType Basic
-AuthName "Password Required"
-AuthUserFile "/www/passwords/password.file"
-AuthGroupFile "/www/passwords/group.file"
-Require group admins
- - -

Tenga en cuenta que AllowOverride AuthConfig debe estar - habilitado para que estas directivas tengan algn efecto.

- -

Por favor vea el tutorial de autenticacin para - una explicacin ms completa de la autenticacin y la autorizacin.

-
top
-
-

Ejemplo de Server Side Includes

- -

Otro uso comn de ficheros .htaccess es activar Server Side - Includes para un directorio en particular. Esto puede hacerse - con las siguientes directivas de configuracin, colocadas en un fichero - .htaccess y el directorio deseado:

- - 
Options +Includes
-AddType text/html "shtml"
-AddHandler server-parsed shtml
- - -

Tenga en cuenta que AllowOverride Options y - AllowOverride FileInfo deben estar activadas para que estas - directivas tengan efecto.

- -

Por favor vea el tutorial de SSI para una - explicacin ms completa de server-side includes.

-
top
-
-

Reglas de Rewrite en ficheros .htaccess

-

Cuando use RewriteRule en - ficheros .htaccess, tenga en cuenta que el contexto - directorio cambia las cosas un poco. En concreto, las reglas son - relativas al directorio actual, en lugar de serlo de la peticin de URI - solicitada originalmente. - Considere los siguientes ejemplos:

- -
# En httpd.conf
-RewriteRule "^/images/(.+)\.jpg" "/images/$1.png"
-
-# En .htaccess en el directorio raz
-RewriteRule "^images/(.+)\.jpg" "images/$1.png"
-
-# En .htaccess en images/
-RewriteRule "^(.+)\.jpg" "$1.png"
- - -

En un .htaccess en cualquier directorio del DocumentRoot, la - barra ("/") inicial se elimina del valor facilitado a RewriteRule, y en el subdirectorio - images, se elimina /images/ tambin de este valor. - As, su expresin regular necesita omitir tambin esa parte.

- -

Consulte la documentacin de mod_rewrite para - ms detalles al usar mod_rewrite.

- -
top
-
-

Ejemplo de CGI

- -

Finalmente, puede que quiera usar un fichero .htaccess para - permitir la ejecucin de programas CGI en un directorio en particular. Esto - se puede implementar con la siguiente configuracin:

- - 
Options +ExecCGI
-AddHandler cgi-script "cgi" "pl"
- - -

Alternativamente, si quiere considerar como programas CGI todos los - ficheros de un directorio concreto, esto se puede conseguir con la siguiente - configuracin:

- - 
Options +ExecCGI
-SetHandler cgi-script
- - -

Tenga en cuenta que AllowOverride Options y - AllowOverride FileInfo deben estar ambas activadas para que - estas directivas tengan efecto.

- -

Por favor vea el tutorial CGI para mayor detalle - sobre programacin y configuracin de CGI.

- -
top
-
-

Resolucin de problemas

- -

Cuando pone directivas en un fichero .htaccess y no obtiene - el efecto deseado hay una serie de cosas que pueden haber ido mal.

- -

El problema ms comn es que AllowOverride - no est configurada para que sus directivas puedan surtir - efecto. Asegrese de que no tiene AllowOverride None - configurado para el directorio en cuestin. Una buena forma de probar esto - es poner "basura" en su fichero .htaccess y recargar la pgina. - Si no se genera un error en el servidor, casi seguro que tiene configurado - AllowOverride None.

- -

Si, por otro lado, obtiene errores de servidor al intentar acceder a - documentos, compruebe el log de errores de httpd. Seguramente le indiquen - que la directiva en uso en su fichero .htaccess no est - permitida.

- -

- [Fri Sep 17 18:43:16 2010] [alert] [client 192.168.200.51] /var/www/html/.htaccess: DirectoryIndex not allowed here -

- -

Esto indicar que o bien ha usado una directiva que no se permite nunca - en ficheros .htaccess, o que simplementa no tiene - AllowOverride configurado - a un nivel suficiente para la directiva que ha usado. Consulte la - documentacin para esa directiva en particular para determinar cual es el - caso.

- -

Alternativamente, puede que le indique que hay un error de sintaxis en - el uso de la propia directiva.

- -

- [Sat Aug 09 16:22:34 2008] [alert] [client 192.168.200.51] /var/www/html/.htaccess: RewriteCond: bad flag delimiters -

- -

En este caso, el mensaje de error debera ser especfico para el error de - sintaxis concreto que ha cometido.

- -
-
-

Idiomas disponibles:  en  | - es  | - fr  | - ja  | - ko  | - pt-br 

-
top

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
-
- \ No newline at end of file diff --git a/docs/manual/howto/htaccess.html.es.utf8 b/docs/manual/howto/htaccess.html.es.utf8 new file mode 100644 index 0000000000..bc0c5bf405 --- /dev/null +++ b/docs/manual/howto/htaccess.html.es.utf8 @@ -0,0 +1,464 @@ + + + + + +Tutorial del Servidor Apache HTTP: Ficheros .htaccess - Servidor HTTP Apache Versin 2.5 + + + + + + +
+

Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

+

Versin 2.5 del Servidor HTTP Apache

+
+
<-
+

Tutorial del Servidor Apache HTTP: Ficheros .htaccess

+
+

Idiomas disponibles:  en  | + es  | + fr  | + ja  | + ko  | + pt-br 

+
+ +

Los ficheros .htaccess facilitan una forma de realizar + cambios en la configuracin en contexto directorio.

+
+ +
top
+
+

Ficheros .htaccess

+
Mdulos RelacionadosDirectivas Relacionadas
+ +
Debera evitar usar ficheros .htaccess completamente si + tiene acceso al fichero de configuracin principal de httpd. Usar ficheros + .htaccess ralentiza su servidor Apache http. Cualquier + directiva que pueda incluir en un fichero .htaccess + estar mejor configurada dentro de una seccin + Directory, tendr el mismo efecto y + mejor rendimiento.
+
top
+
+

Qu son/Cmo usarlos

+ + +

Los ficheros .htaccess (o "ficheros de configuracin + distribuida") facilitan una forma de realizar cambios en la configuracin + en contexto directorio. Un fichero, que contiene una o ms directivas, se + coloca en un documento especfico de un directorio, y estas directivas + aplican a ese directorio y todos sus subdirectorios.

+ +

Nota:

+

Si quiere llamar a su fichero .htaccess de otra manera, + puede cambiar el nombre del fichero usando la directiva AccessFileName. Por ejemplo, si usted prefiere + llamar al fichero .config, entonces puede poner lo siguiente + en el fichero de configuracin de su servidor:

+ + 
AccessFileName ".config"
+ +
+ +

Generalmente, los ficheros .htaccess usan la misma sintxis + que los ficheros de la configuracin + principal. Lo que puede utilizar en estos ficheros lo determina la + directiva AllowOverride. Esta directiva + especifica, en categoras, qu directivas tendrn efecto si se encuentran en + un fichero .htaccess. Si se permite una directiva en un fichero + .htaccess, la documentacin para esa directiva contendr una + seccin Override, especificando qu valor debe ir en + AllowOverride para que se permita esa + directiva.

+ +

Por ejemplo, si busca en la documentacin la directiva AddDefaultCharset, encontrar que se permite en + ficheros .htaccess. (Vea la lnea de Contexto en el sumario de + la directiva.) La lnea Override muestra + FileInfo. De este modo, debe tener al menos + AllowOverride FileInfo para que esta directiva se aplique en + ficheros .htaccess.

+ +

Ejemplo:

+ + + + + + + + + +
Context:server config, virtual host, directory, .htaccess
Override:FileInfo
+ +

Si no est seguro de cundo, una directiva en concreto, se puede usar en un + fichero .htaccess, consulte la documentacin para esa directiva, + y compruebe la lnea Context buscando ".htaccess".

+
top
+
+

Cuando (no) usar ficheros .htaccess

+ +

Generalmente, solo debera usar ficheros .htaccess cuando no + tiene acceso al fichero principal de configuracin del servidor. Hay, por + ejemplo, una creencia errnea de que la autenticacin de usuario debera + hacerse siempre dentro de ficheros .htaccess, y, ms recientemente, otra creencia errnea de que las directivas de + mod_rewrite deben ir en ficheros .htaccess. + Esto sencillamente no es el caso. Puede poner las configuraciones de + autenticacin de usuario en la configuracin principal del servidor, y esto + es de hecho, el mtodo preferido de configurar Apache. Del mismo modo, las + directivas mod_rewrite funcionan mejor, en muchos sentidos, en + el fichero de configuracin principal del servidor.

+ +

Los ficheros .htaccess deberan usarse cuando su proveedor + de contenidos le permite hacer modificaciones de configuracin + en contexto directorio, pero usted no tiene acceso de root en el servidor. + En el caso de que el administrador no est dispuesto a hacer cambios + frecuentes en la configuracin, puede que sea necesario permitir a usuarios + individuales realizar estos cambios de configuracin en ficheros + .htaccess por ellos mismos. Lo cual ocurre a menudo, por + ejemplo, en casos donde los ISP estn albergando mltiples sitios web de + usuario en una sola mquina, y quieren que sus usuarios tengan la + posibilidad de modificar sus configuraciones.

+ +

Aun as, generalmente, el uso de ficheros .htaccess debera + evitarse cuando sea posible. Cualquier configuracin que considerara poner + en un fichero .htaccess, puede usarse con la misma efectividad + en una seccin <Directory> en el fichero de configuracin + del servidor.

+ +

Hay dos razones para evitar el uso de ficheros .htaccess.

+ +

La primera es el rendimiento. Cuando AllowOverride + est configurado para permitir el uso de ficheros .htaccess, + httpd buscar ficheros .htaccess en cada directorio. As, + permitiendo ficheros .htaccess provoca una prdida de + rendimiento, incluso aunque no los use! Adems, los ficheros + .htaccess se cargan cada vez que se solicita un documento.

+ +

Adems tenga en cuenta que httpd debe buscar ficheros + .htaccess en todos los directorios de mayor jerarqua, + para poder terner la lista completa de directivas que debe aplicar. (Vea + la seccin sobre Cmo se aplican las directivas.) As, si + se solicita un fichero de un directorio /www/htdocs/example, + httpd debe buscar los siguientes ficheros:

+ +

+ /.htaccess
+ /www/.htaccess
+ /www/htdocs/.htaccess
+ /www/htdocs/example/.htaccess +

+ +

De esta manera, por cada acceso a un fichero de ese directorio, hay 4 + accesos adicionales al sistema de ficheros, incluso si ninguno de esos + ficheros est presente. (Tenga en cuenta que este caso solo se dara si los + ficheros .htaccess estn activados en /, que + generalmente no es el caso.).

+ +

En el caso de las directivas RewriteRule, en el contexto de + .htaccess estas expresiones regulares deben recompilarse con + cada solicitud a ese directorio, cuando en el contexto de configuracin del + servidor solo se compilan una vez y se cachean. Adicionalmente, las reglas + en s mismas son ms complicadas, puesto que uno debe sortear las + restricciones que vienen acompaadas del contexto directorio y + mod_rewrite. Consulte la Gua de Rewrite para un mayor + detalle sobre este tema.

+ +

La segunda consideracin es de seguridad. Estar permitiendo que usuarios + modifiquen la configuracin del servidor, lo cual puede dar lugar a cambios sobre los que usted no tendr ningn control. Medite profundamente si debe + dar a sus usuarios ese privilegio. Adems tenga en cuenta que dar a los usuarios menos privilegios de los que necesitan dar lugar a ms peticiones + de soporte. Asegrese de que le indica a sus usuarios claramente el nivel de privilegios que les est dando. Especificando exactamente cmo ha + configurado AllowOverride, e invteles + a revisar la documentacin relacionada, lo cual le ahorrar + bastantes confusiones ms adelante.

+ +

Tenga en cuenta que esto es equivalente por completo a poner un fichero + .htaccess en un directorio /www/htdocs/example + con una directiva, y poner la misma directiva en una seccin + Directory <Directory "/www/htdocs/example"> en su + configuracin principal del servidor:

+ +

Fichero .htaccess en /www/htdocs/example:

+ +

Contenido de fichero .htaccess en + /www/htdocs/example

AddType text/example ".exm"
+
+ +

Seccin de su fichero httpd.conf

<Directory "/www/htdocs/example">
+    AddType text/example ".exm"
+</Directory>
+
+ +

Aun as, poniendo sta en el fichero de configuracin dar como resultado + una menor prdida de rendimiento, y como la configuracin se carga una vez + cuando el httpd arranca, en lugar de cada vez que se solicita un fichero.

+ +

El uso de ficheros .htaccess puede desactivarse por completo + configurando la directiva AllowOverride + a none:

+ + 
AllowOverride None
+ +
top
+
+

How directives are applied

+ +

Las directivas de configuracin que se encuentran en el fichero + .htaccess se aplican al directorio en el que el fichero + .htaccess se encuentra, y a todos sus subdirectorios. Sin + embargo, es importante recordar que puede haber otros ficheros + .htaccess en directorios previos. Las directivas se aplican en + el orden en el que se encuentran. Por lo tanto, un fichero + .htaccess puede sobrescribir directivas que se encuentran + en ficheros .htaccess que se encuentran en directorios previos + del rbol de directorios. Y estos, en cambio, pueden haber sobrescrito + directivas que se encontraban ms arriba, o en el fichero principal de + configuracin del servidor mismo.

+ +

Ejemplo:

+ +

En el directorio /www/htdocs/example1 tenemos un fichero + .htaccess que contiene lo siguiente:

+ + 
Options +ExecCGI
+ + +

(Nota: debe terner "AllowOverride Options" configurado para + permitir el uso de la directiva "Options" en ficheros + .htaccess files.)

+ +

En el directorio /www/htdocs/example1/example2 tenemos un + fichero .htaccess que contiene:

+ + 
Options Includes
+ + +

Por este segundo fichero .htaccess, en el directorio + /www/htdocs/example1/example2, la ejecucin de CGI execution no + est permitida, porque solo se ha definido Options Includes, + que sobrescribe completamente una configuracin previa que se pudiera haber + definido.

+ +

Incorporando el .htaccess en los ficheros de + configuracin principal

+ +

Como se ha comentado en la documentacin en las Secciones de Configuracin, los ficheros + .htaccess pueden sobrescribir las secciones <Directory> por el directorio + correspondiente, pero se sobrescribirn por otros tipos de secciones de + configuracin de los ficheros de configuracin principal. Este hecho se + puede usar para forzar ciertas configuraciones, incluso en presencia + de una configuracin laxa de + AllowOverride. Por ejemplo, para + prevenir la ejecucin de un script mientras se permite cualquier otra cosa + en .htaccess puede usar:

+ + 
<Directory "/www/htdocs">
+    AllowOverride All
+</Directory>
+
+<Location "/">
+    Options +IncludesNoExec -ExecCGI
+</Location>
+ + +
Este ejemplo asume que su DocumentRoot es /www/htdocs.
+ + +
top
+
+

Ejemplo de Autenticacin

+ +

Si salt directamente a esta parte del documento para averiguar como + hacer la autenticacin, es important que tenga en cuenta una cosa. Hay una + creencia errnea de que necesita usar ficheros .htaccess para + configurar autenticacin con contrasea. Este no es el caso. Colocar las + directivas de autenticacin en una seccin + <Directory>, en su fichero + de configuracin principal, es el mtodo recomendado para configurar esto, + y los ficheros .htaccess deberan usarse solamente si no tiene + acceso al fichero de configuracin principal del servidor. Vea ms arriba una explicacin de cuando debera y cuando no + debera usar ficheros .htaccess.

+ +

Dicho esto, si todava cree que debe usar el fichero + .htaccess, podr ver que una configuracin como la que sigue + podra servirle.

+ +

Contenido del fichero .htaccess:

+ + 
AuthType Basic
+AuthName "Password Required"
+AuthUserFile "/www/passwords/password.file"
+AuthGroupFile "/www/passwords/group.file"
+Require group admins
+ + +

Tenga en cuenta que AllowOverride AuthConfig debe estar + habilitado para que estas directivas tengan algn efecto.

+ +

Por favor vea el tutorial de autenticacin para + una explicacin ms completa de la autenticacin y la autorizacin.

+
top
+
+

Ejemplo de Server Side Includes

+ +

Otro uso comn de ficheros .htaccess es activar Server Side + Includes para un directorio en particular. Esto puede hacerse + con las siguientes directivas de configuracin, colocadas en un fichero + .htaccess y el directorio deseado:

+ + 
Options +Includes
+AddType text/html "shtml"
+AddHandler server-parsed shtml
+ + +

Tenga en cuenta que AllowOverride Options y + AllowOverride FileInfo deben estar activadas para que estas + directivas tengan efecto.

+ +

Por favor vea el tutorial de SSI para una + explicacin ms completa de server-side includes.

+
top
+
+

Reglas de Rewrite en ficheros .htaccess

+

Cuando use RewriteRule en + ficheros .htaccess, tenga en cuenta que el contexto + directorio cambia las cosas un poco. En concreto, las reglas son + relativas al directorio actual, en lugar de serlo de la peticin de URI + solicitada originalmente. + Considere los siguientes ejemplos:

+ +
# En httpd.conf
+RewriteRule "^/images/(.+)\.jpg" "/images/$1.png"
+
+# En .htaccess en el directorio raz
+RewriteRule "^images/(.+)\.jpg" "images/$1.png"
+
+# En .htaccess en images/
+RewriteRule "^(.+)\.jpg" "$1.png"
+ + +

En un .htaccess en cualquier directorio del DocumentRoot, la + barra ("/") inicial se elimina del valor facilitado a RewriteRule, y en el subdirectorio + images, se elimina /images/ tambin de este valor. + As, su expresin regular necesita omitir tambin esa parte.

+ +

Consulte la documentacin de mod_rewrite para + ms detalles al usar mod_rewrite.

+ +
top
+
+

Ejemplo de CGI

+ +

Finalmente, puede que quiera usar un fichero .htaccess para + permitir la ejecucin de programas CGI en un directorio en particular. Esto + se puede implementar con la siguiente configuracin:

+ + 
Options +ExecCGI
+AddHandler cgi-script "cgi" "pl"
+ + +

Alternativamente, si quiere considerar como programas CGI todos los + ficheros de un directorio concreto, esto se puede conseguir con la siguiente + configuracin:

+ + 
Options +ExecCGI
+SetHandler cgi-script
+ + +

Tenga en cuenta que AllowOverride Options y + AllowOverride FileInfo deben estar ambas activadas para que + estas directivas tengan efecto.

+ +

Por favor vea el tutorial CGI para mayor detalle + sobre programacin y configuracin de CGI.

+ +
top
+
+

Resolucin de problemas

+ +

Cuando pone directivas en un fichero .htaccess y no obtiene + el efecto deseado hay una serie de cosas que pueden haber ido mal.

+ +

El problema ms comn es que AllowOverride + no est configurada para que sus directivas puedan surtir + efecto. Asegrese de que no tiene AllowOverride None + configurado para el directorio en cuestin. Una buena forma de probar esto + es poner "basura" en su fichero .htaccess y recargar la pgina. + Si no se genera un error en el servidor, casi seguro que tiene configurado + AllowOverride None.

+ +

Si, por otro lado, obtiene errores de servidor al intentar acceder a + documentos, compruebe el log de errores de httpd. Seguramente le indiquen + que la directiva en uso en su fichero .htaccess no est + permitida.

+ +

+ [Fri Sep 17 18:43:16 2010] [alert] [client 192.168.200.51] /var/www/html/.htaccess: DirectoryIndex not allowed here +

+ +

Esto indicar que o bien ha usado una directiva que no se permite nunca + en ficheros .htaccess, o que simplementa no tiene + AllowOverride configurado + a un nivel suficiente para la directiva que ha usado. Consulte la + documentacin para esa directiva en particular para determinar cual es el + caso.

+ +

Alternativamente, puede que le indique que hay un error de sintaxis en + el uso de la propia directiva.

+ +

+ [Sat Aug 09 16:22:34 2008] [alert] [client 192.168.200.51] /var/www/html/.htaccess: RewriteCond: bad flag delimiters +

+ +

En este caso, el mensaje de error debera ser especfico para el error de + sintaxis concreto que ha cometido.

+ +
+
+

Idiomas disponibles:  en  | + es  | + fr  | + ja  | + ko  | + pt-br 

+
top

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/htaccess.html.fr b/docs/manual/howto/htaccess.html.fr deleted file mode 100644 index 07af471ec8..0000000000 --- a/docs/manual/howto/htaccess.html.fr +++ /dev/null @@ -1,512 +0,0 @@ - - - - - -Tutoriel du serveur HTTP Apache : fichiers .htaccess - Serveur HTTP Apache Version 2.5 - - - - - - -
-

Modules | Directives | FAQ | Glossaire | Plan du site

-

Serveur HTTP Apache Version 2.5

-
-
<-
-

Tutoriel du serveur HTTP Apache : fichiers .htaccess

-
-

Langues Disponibles:  en  | - es  | - fr  | - ja  | - ko  | - pt-br 

-
- -

Les fichiers .htaccess fournissent une méthode pour -modifier la configuration du serveur au niveau de chaque répertoire.

-
- -
top
-
-

Fichiers .htaccess

- -
Modules ApparentésDirectives Apparentées
-
Les fichiers .htaccess ne doivent être utilisés - que si vous n'avez pas accès au fichier de configuration du serveur - principal. L'utilisation des fichiers .htaccess - ralentit le fonctionnement de votre serveur HTTP Apache. Il est toujours - préférable de définir les directives que vous pouvez inclure dans un - fichier .htaccess dans une section Directory, car elles produiront le - même effet avec de meilleures performances.
-
top
-
-

Que sont ce fichiers, comment les utiliser ?

- - -

Les fichiers .htaccess (ou "fichiers de - configuration distribués") fournissent une méthode pour modifier la - configuration du serveur au niveau d'un répertoire. Un fichier, - contenant une ou plusieurs directives de configuration, est placé - dans un répertoire de documents particulier, et ses directives - s'appliquent à ce répertoire et à tous ses sous-répertoires.

- -

Note :

-

Si vous voulez donner un autre nom à votre fichier - .htaccess, vous pouvez le faire en utilisant la - directive AccessFileName. Par - exemple, si vous préférez nommer votre fichier - .config, vous pouvez mettre ceci dans le fichier de - configuration de votre serveur :

- - 
AccessFileName ".config"
- -
- -

En général, les fichiers .htaccess utilisent la même - syntaxe que les fichiers de - configuration principaux. Ce que vous pouvez mettre dans ces - fichier est déterminé par la directive AllowOverride. Cette directive spécifie, - sous forme de catégories, quelles directives seront traitées si - elles se trouvent dans un fichier .htaccess. Si une - directive est permise dans un fichier .htaccess file, - la documentation de cette directive contiendra une section Override, - spécifiant quelle valeur doit prendre AllowOverride pour que cette directive - soit traitée.

- -

Par exemple, si vous regardez la documentation de la directive - AddDefaultCharset, vous verrez - que cette dernière est permise dans les fichiers - .htaccess (Voir la ligne de contexte dans le résumé de - la directive). La ligne Override indique - FileInfo. Vous devez donc avoir au moins - AllowOverride FileInfo pour que cette directive soit - traitée dans les fichiers .htaccess.

- -

Exemple :

- - - - - - - - - -
Contexte :configuration du serveur, serveur virtuel, directory, .htaccess
Override:FileInfo
- -

Si vous n'êtes pas sûr qu'une directive particulière soit permise - dans un fichier .htaccess, lisez la documentation de - cette directive, et consultez la ligne de contexte pour - ".htaccess".

-
top
-
-

Quand doit-on (ne doit-on pas) utiliser - les fichiers .htaccess ?

- -

En principe, vous ne devriez utiliser les fichiers - .htaccess que lorsque vous n'avez pas accès au fichier de - configuration du serveur principal. Par exemple, la fausse - idée - selon laquelle l'authentification de l'utilisateur devrait toujours - être faite dans les fichiers .htaccess est très - répandue. Il est aussi souvent avancé, ces dernières - années, que les directives de mod_rewrite doivent - être définies dans les fichiers .htaccess. Ceci est - tout simplement faux. Vous pouvez configurer - l'authentification des utilisateurs au niveau de la configuration du - serveur principal, et c'est en fait cette méthode qui doit être - privilégiée. De même, les directives de - mod_rewrite fonctionneront mieux, à de nombreux égards, - dans le contexte du serveur principal.

- -

Les fichiers .htaccess ne devraient être utilisés - que dans le cas où les fournisseurs de contenu ont besoin de - modifier la configuration du serveur au niveau d'un répertoire, mais - ne possèdent pas l'accès root sur le système du serveur. Si - l'administrateur du serveur ne souhaite pas effectuer des - modifications de configuration incessantes, il peut être intéressant - de permettre aux utilisateurs isolés d'effectuer eux-mêmes ces - modifications par le biais de fichiers .htaccess. Ceci - est particulièrement vrai dans le cas où le fournisseur d'accès à - Internet héberge de nombreux sites d'utilisateurs sur un seul - serveur, et souhaite que ces utilisateurs puissent modifier - eux-mêmes leurs configurations.

- -

Cependant et d'une manière générale, il vaut mieux éviter - d'utiliser les fichiers .htaccess. Tout élément de - configuration que vous pourriez vouloir mettre dans un fichier - .htaccess, peut aussi être mis, et avec la même - efficacité, dans une section <Directory> du fichier de configuration de - votre serveur principal.

- -

Il y a deux raisons principales d'éviter l'utilisation des - fichiers .htaccess.

- -

La première est liée aux performances. Lorsque la directive - AllowOverride est définie de - façon à autoriser l'utilisation des fichiers .htaccess, - httpd va rechercher leur présence dans chaque répertoire. Ainsi, - permettre l'utilisation des fichiers .htaccess est déjà - en soi une cause de dégradation des performances, que vous utilisiez - effectivement ces fichiers ou non ! De plus, le fichier - .htaccess est chargé en mémoire chaque fois qu'un - document fait l'objet d'une requête.

- -

Notez aussi que httpd doit rechercher les fichiers - .htaccess dans tous les répertoires de niveau - supérieur, afin de rassembler toutes les directives qui s'appliquent - au répertoire courant (Voir la section comment sont - appliquées les directives). Ainsi, si un fichier fait l'objet - d'une requête à partir d'un répertoire - /www/htdocs/exemple, httpd doit rechercher les - fichiers suivants :

- -

- /.htaccess
- /www/.htaccess
- /www/htdocs/.htaccess
- /www/htdocs/exemple/.htaccess -

- -

En conséquence, chaque accès à un fichier de ce répertoire - nécessite 4 accès au système de fichiers supplémentaires pour - rechercher des fichiers .htaccess, même si - aucun de ces fichiers n'est présent. Notez que cet exemple ne peut - se produire que si les fichiers .htaccess ont été - autorisés pour le répertoire /, ce qui est rarement le - cas.

- -

La seconde raison d'éviter l'utilisation des fichiers - .htaccess est liée à la sécurité. Si vous permettez aux - utilisateurs de modifier la configuration du serveur, il peut en - résulter des conséquences sur lesquelles vous n'aurez aucun - contrôle. Réfléchissez bien avant de donner ce privilège à vos - utilisateurs. Notez aussi que ne pas donner aux utilisateurs les - privilèges dont ils ont besoin va entraîner une augmentation des - demandes de support technique. Assurez-vous d'avoir informé - clairement vos utilisateurs du niveau de privilèges que vous leur - avez attribué. Indiquer exactement comment vous avez défini la - directive AllowOverride et - diriger les utilisateurs vers la documentation correspondante vous - évitera bien des confusions ultérieures.

- -

Notez que mettre un fichier .htaccess contenant une - directive dans un répertoire /www/htdocs/exemple - revient exactement au même que mettre la même directive dans une - section Directory <Directory "/www/htdocs/exemple"> - du fichier de configuration de votre serveur principal :

- -

Fichier .htaccess dans - /www/htdocs/exemple :

- -

Contenu du fichier .htaccess dans - /www/htdocs/exemple

AddType text/example ".exm"
-
- -

Section de votre fichier - httpd.conf

<Directory "/www/htdocs/example">
-    AddType text/example ".exm"
-</Directory>
-
- -

Cependant, la perte de performances sera moindre si vous - définissez cette directive dans la configuration de - votre serveur principal, car cette dernière ne sera chargée qu'une - seule fois au moment du démarrage du serveur, alors qu'elle le sera - à chaque accès dans le cas d'un fichier .htaccess.

- -

L'utilisation des fichiers .htaccess peut être - entièrement désactivée en définissant la directive AllowOverride à none :

- - 
AllowOverride None
- -
top
-
-

Comment sont appliquées les directives ?

- -

Les directives de configuration situées dans un fichier - .htaccess s'appliquent au répertoire dans lequel ce - fichier .htaccess se trouve, ainsi qu'à tous ses - sous-répertoires. Cependant, il est important de garder à l'esprit - qu'il peut y avoir des fichiers .htaccess dans les - répertoires de niveau supérieur. Les directives sont appliquées - selon l'ordre dans lequel elles sont rencontrées. Ainsi, les - directives d'un fichier .htaccess situé dans un - répertoire particulier peuvent écraser les directives se trouvant - dans des fichiers .htaccess situés à un niveau - supérieur dans l'arborescence des répertoires. Et ces dernières - peuvent elles-mêmes avoir écrasé des directives d'un fichier - .htaccess situé à un niveau encore plus haut, ou dans - le fichier de configuration du serveur principal.

- -

Exemple :

- -

Dans le répertoire /www/htdocs/exemple1 se trouve un - fichier .htaccess contenant ce qui suit :

- - 
Options +ExecCGI
- - -

Note : "AllowOverride Options" doit être présent - pour permettre l'utilisation de la directive "Options" dans les fichiers - .htaccess.

- -

Dans le répertoire /www/htdocs/exemple1/exemple2 se - trouve un fichier .htaccess contenant ce qui suit - :

- - 
Options Includes
- - -

Ainsi, à cause de ce second fichier .htaccess du - répertoire /www/htdocs/exemple1/exemple2, l'exécution - des CGI est interdite, car la dernière définition d'options - Options Includes écrase toute autre définition - d'options d'un fichier .htaccess situé dans un - répertoire de niveau supérieur.

- -

Interactions entre les fichiers .htaccess - et les fichiers de configuration du serveur principal

- -

Comme indiqué dans la documentation sur les Sections de configuration, les fichiers - .htaccess peuvent écraser les directives des sections - <Directory> pour - le répertoire correspondant, mais peuvent eux-mêmes être écrasés - par d'autres types de sections des fichiers de la - configuration principale. Cette possibilité peut s'avérer utile pour - forcer certaines configurations, même en cas de présence de l'option - libérale AllowOverride. Par - exemple, pour interdire l'exécution de scripts en autorisant la - définition de toute autre option dans les fichiers - .htaccess, vous pouvez utiliser :

- - 
<Directory "/www/htdocs">
-    AllowOverride All
-</Directory>
-
-<Location "/">
-    Options +IncludesNoExec -ExecCGI
-</Location>
- - -
Dans cet exemple, on considère que le chemin défini par la - directive DocumentRoot est - /www/htdocs.
- - -
top
-
-

Exemple d'authentification

- -

Si vous accédez directement à ce point du document pour apprendre - à effectuer une authentification, il est important de noter ceci. Il - existe une fausse idée selon laquelle il serait nécessaire - d'utiliser les fichiers .htaccess pour implémenter - l'authentification par mot de passe. Ceci est tout simplement faux. - Pour y parvenir, il est préférable de mettre les directives - d'authentification dans une section <Directory> du fichier de configuration de - votre serveur principal, et les fichiers .htaccess ne - devraient être utilisés que dans le cas où vous n'avez pas accès au - fichier de configuration du serveur principal. Voir ci-dessus pour savoir dans quels cas vous devez ou - ne devez pas utiliser les fichiers .htaccess.

- -

Ceci étant dit, si vous pensez que vous devez quand-même utiliser - un fichier .htaccess, vous pouvez utiliser la - configuration suivante :

- -

Contenu du fichier .htaccess :

- - 
AuthType Basic
-AuthName "Password Required"
-AuthUserFile "/www/passwords/password.file"
-AuthGroupFile "/www/passwords/group.file"
-Require group admins
- - -

Notez que AllowOverride AuthConfig doit être présent - pour que ces directives produisent leur effet.

- -

Vous pouvez vous référer au tutoriel sur - l'authentification pour une description plus détaillée de - l'authentification et de l'autorisation.

-
top
-
-

Exemple d'Inclusion Côté Serveur (Server Side -Includes - SSI)

- -

Les fichiers .htaccess sont aussi couramment - utilisés pour activer les SSI pour un répertoire particulier. Pour y - parvenir, on utilise les directives de configuration suivantes, - placées dans un fichier .htaccess enregistré dans le - répertoire considéré :

- - 
Options +Includes
-AddType text/html "shtml"
-AddHandler server-parsed shtml
- - -

Notez que AllowOverride Options et AllowOverride - FileInfo doivent être tous les deux présents pour que ces - directives puissent produire leur effet.

- -

Vous pouvez vous référer au tutoriel SSI - pour une description plus détaillée des SSI.

-
top
-
-

Les règles de réécriture dans les fichiers .htaccess

-

Sivous utilisez des directives RewriteRule dans un fichier -.htaccess, gardez à l'esprit que les choses sont légèrement -différentes dans un contexte de répertoire. En particulier, les règles -sont relatives au répertoire courant, et non à l'URI original. Considérez -les exemples suivants :

- -
# Dans httpd.conf
-RewriteRule "^/images/(.+)\.jpg" "/images/$1.png"
-
-# Dans un fichier .htaccess situé dans le répertoire racine de vos
-# documents
-RewriteRule "^images/(.+)\.jpg" "images/$1.png"
-
-# Dans un fichier .htaccess situé dans le répertoire images/
-RewriteRule "^(.+)\.jpg" "$1.png"
- - -

On voit que si le fichier .htaccess se situe à la racine -de vos documents, le slash de tête est supprimé de la valeur de -remplacement spécifiée pour la règle RewriteRule, et que si le fichier -.htaccess se situe dans le répertoire images, -la chaîne /images/ disparaît de cette même valeur de -remplacement. Il doit donc en être de même dans votre expression -rationnelle.

- -

Veuillez vous référer à cette documentation -pour une étude détaillée de l'utilisation du module -mod_rewrite.

- -
top
-
-

Exemple de CGI

- -

En fin de compte, vous avez décidé d'utiliser un fichier - .htaccess pour permettre l'exécution des programmes CGI - dans un répertoire particulier. Pour y parvenir, vous pouvez - utiliser la configuration suivante :

- - 
Options +ExecCGI
-AddHandler cgi-script "cgi" "pl"
- - -

Alternativement, si vous souhaitez que tous les fichiers d'un - répertoire donné soient considérés comme des programmes CGI, vous - pouvez utiliser la configuration suivante :

- - 
Options +ExecCGI
-SetHandler cgi-script
- - -

Notez que AllowOverride Options et AllowOverride - FileInfo doivent être tous les deux présents pour que ces - directives puissent produire leur effet.

- -

Vous pouvez vous référer au tutoriel CGI - pour une description plus détaillée de la configuration et de la - proprammation CGI.

- -
top
-
-

Résolution des problèmes

- -

De nombreuses raisons peuvent être à l'origine du fait que - les directives que vous avez mises dans un fichier - .htaccess ne produisent pas l'effet désiré.

- -

Le plus souvent, le problème vient du fait que la définition de - la directive AllowOverride - ne permet pas l'activation des directives de votre fichier - .htaccess. Vérifiez si une directive - AllowOverride None n'affecte pas le répertoire où se - trouve votre fichier. Un bon test consiste à mettre des directives - dont la syntaxe est erronée dans votre ficher .htaccess - et de recharger la page. Si aucune erreur n'est générée par le - serveur, il est pratiquement certain qu'une directive - AllowOverride None affecte votre répertoire.

- -

Par contre, si vous obtenez des erreurs de serveur lorsque vous - tentez d'accéder à des documents, consultez votre journal des - erreurs de httpd. Il vous indiquera probablement que la directive - utilisée dans votre fichier .htaccess n'est pas - permise.

- -

- [Fri Sep 17 18:43:16 2010] [alert] [client 192.168.200.51] /var/www/html/.htaccess: DirectoryIndex not allowed here -

-

Cela signifie soit que vous utilisez une directive qui n'est - jamais permise dans les fichiers .htaccess, soit - que vous n'avez tout simplement pas défini la directive - AllowOverride à un niveau - suffisant pour la directive que vous utilisez. Consultez la - documentation de cette directive pour déterminer quel cas - s'applique.

- -

Le journal des erreurs peut aussi vous signaler une erreur de - syntaxe dans l'usage de la directive elle-même.

- -

- [Sat Aug 09 16:22:34 2008] [alert] [client 192.168.200.51] /var/www/html/.htaccess: RewriteCond: bad flag delimiters -

- -

Dans ce cas, le message d'erreur sera spécifique à l'erreur - de syntaxe que vous avez commise.

-
-
-

Langues Disponibles:  en  | - es  | - fr  | - ja  | - ko  | - pt-br 

-
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
-
- \ No newline at end of file diff --git a/docs/manual/howto/htaccess.html.fr.utf8 b/docs/manual/howto/htaccess.html.fr.utf8 new file mode 100644 index 0000000000..07af471ec8 --- /dev/null +++ b/docs/manual/howto/htaccess.html.fr.utf8 @@ -0,0 +1,512 @@ + + + + + +Tutoriel du serveur HTTP Apache : fichiers .htaccess - Serveur HTTP Apache Version 2.5 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.5

+
+
<-
+

Tutoriel du serveur HTTP Apache : fichiers .htaccess

+
+

Langues Disponibles:  en  | + es  | + fr  | + ja  | + ko  | + pt-br 

+
+ +

Les fichiers .htaccess fournissent une méthode pour +modifier la configuration du serveur au niveau de chaque répertoire.

+
+ +
top
+
+

Fichiers .htaccess

+ +
Modules ApparentésDirectives Apparentées
+
Les fichiers .htaccess ne doivent être utilisés + que si vous n'avez pas accès au fichier de configuration du serveur + principal. L'utilisation des fichiers .htaccess + ralentit le fonctionnement de votre serveur HTTP Apache. Il est toujours + préférable de définir les directives que vous pouvez inclure dans un + fichier .htaccess dans une section Directory, car elles produiront le + même effet avec de meilleures performances.
+
top
+
+

Que sont ce fichiers, comment les utiliser ?

+ + +

Les fichiers .htaccess (ou "fichiers de + configuration distribués") fournissent une méthode pour modifier la + configuration du serveur au niveau d'un répertoire. Un fichier, + contenant une ou plusieurs directives de configuration, est placé + dans un répertoire de documents particulier, et ses directives + s'appliquent à ce répertoire et à tous ses sous-répertoires.

+ +

Note :

+

Si vous voulez donner un autre nom à votre fichier + .htaccess, vous pouvez le faire en utilisant la + directive AccessFileName. Par + exemple, si vous préférez nommer votre fichier + .config, vous pouvez mettre ceci dans le fichier de + configuration de votre serveur :

+ + 
AccessFileName ".config"
+ +
+ +

En général, les fichiers .htaccess utilisent la même + syntaxe que les fichiers de + configuration principaux. Ce que vous pouvez mettre dans ces + fichier est déterminé par la directive AllowOverride. Cette directive spécifie, + sous forme de catégories, quelles directives seront traitées si + elles se trouvent dans un fichier .htaccess. Si une + directive est permise dans un fichier .htaccess file, + la documentation de cette directive contiendra une section Override, + spécifiant quelle valeur doit prendre AllowOverride pour que cette directive + soit traitée.

+ +

Par exemple, si vous regardez la documentation de la directive + AddDefaultCharset, vous verrez + que cette dernière est permise dans les fichiers + .htaccess (Voir la ligne de contexte dans le résumé de + la directive). La ligne Override indique + FileInfo. Vous devez donc avoir au moins + AllowOverride FileInfo pour que cette directive soit + traitée dans les fichiers .htaccess.

+ +

Exemple :

+ + + + + + + + + +
Contexte :configuration du serveur, serveur virtuel, directory, .htaccess
Override:FileInfo
+ +

Si vous n'êtes pas sûr qu'une directive particulière soit permise + dans un fichier .htaccess, lisez la documentation de + cette directive, et consultez la ligne de contexte pour + ".htaccess".

+
top
+
+

Quand doit-on (ne doit-on pas) utiliser + les fichiers .htaccess ?

+ +

En principe, vous ne devriez utiliser les fichiers + .htaccess que lorsque vous n'avez pas accès au fichier de + configuration du serveur principal. Par exemple, la fausse + idée + selon laquelle l'authentification de l'utilisateur devrait toujours + être faite dans les fichiers .htaccess est très + répandue. Il est aussi souvent avancé, ces dernières + années, que les directives de mod_rewrite doivent + être définies dans les fichiers .htaccess. Ceci est + tout simplement faux. Vous pouvez configurer + l'authentification des utilisateurs au niveau de la configuration du + serveur principal, et c'est en fait cette méthode qui doit être + privilégiée. De même, les directives de + mod_rewrite fonctionneront mieux, à de nombreux égards, + dans le contexte du serveur principal.

+ +

Les fichiers .htaccess ne devraient être utilisés + que dans le cas où les fournisseurs de contenu ont besoin de + modifier la configuration du serveur au niveau d'un répertoire, mais + ne possèdent pas l'accès root sur le système du serveur. Si + l'administrateur du serveur ne souhaite pas effectuer des + modifications de configuration incessantes, il peut être intéressant + de permettre aux utilisateurs isolés d'effectuer eux-mêmes ces + modifications par le biais de fichiers .htaccess. Ceci + est particulièrement vrai dans le cas où le fournisseur d'accès à + Internet héberge de nombreux sites d'utilisateurs sur un seul + serveur, et souhaite que ces utilisateurs puissent modifier + eux-mêmes leurs configurations.

+ +

Cependant et d'une manière générale, il vaut mieux éviter + d'utiliser les fichiers .htaccess. Tout élément de + configuration que vous pourriez vouloir mettre dans un fichier + .htaccess, peut aussi être mis, et avec la même + efficacité, dans une section <Directory> du fichier de configuration de + votre serveur principal.

+ +

Il y a deux raisons principales d'éviter l'utilisation des + fichiers .htaccess.

+ +

La première est liée aux performances. Lorsque la directive + AllowOverride est définie de + façon à autoriser l'utilisation des fichiers .htaccess, + httpd va rechercher leur présence dans chaque répertoire. Ainsi, + permettre l'utilisation des fichiers .htaccess est déjà + en soi une cause de dégradation des performances, que vous utilisiez + effectivement ces fichiers ou non ! De plus, le fichier + .htaccess est chargé en mémoire chaque fois qu'un + document fait l'objet d'une requête.

+ +

Notez aussi que httpd doit rechercher les fichiers + .htaccess dans tous les répertoires de niveau + supérieur, afin de rassembler toutes les directives qui s'appliquent + au répertoire courant (Voir la section comment sont + appliquées les directives). Ainsi, si un fichier fait l'objet + d'une requête à partir d'un répertoire + /www/htdocs/exemple, httpd doit rechercher les + fichiers suivants :

+ +

+ /.htaccess
+ /www/.htaccess
+ /www/htdocs/.htaccess
+ /www/htdocs/exemple/.htaccess +

+ +

En conséquence, chaque accès à un fichier de ce répertoire + nécessite 4 accès au système de fichiers supplémentaires pour + rechercher des fichiers .htaccess, même si + aucun de ces fichiers n'est présent. Notez que cet exemple ne peut + se produire que si les fichiers .htaccess ont été + autorisés pour le répertoire /, ce qui est rarement le + cas.

+ +

La seconde raison d'éviter l'utilisation des fichiers + .htaccess est liée à la sécurité. Si vous permettez aux + utilisateurs de modifier la configuration du serveur, il peut en + résulter des conséquences sur lesquelles vous n'aurez aucun + contrôle. Réfléchissez bien avant de donner ce privilège à vos + utilisateurs. Notez aussi que ne pas donner aux utilisateurs les + privilèges dont ils ont besoin va entraîner une augmentation des + demandes de support technique. Assurez-vous d'avoir informé + clairement vos utilisateurs du niveau de privilèges que vous leur + avez attribué. Indiquer exactement comment vous avez défini la + directive AllowOverride et + diriger les utilisateurs vers la documentation correspondante vous + évitera bien des confusions ultérieures.

+ +

Notez que mettre un fichier .htaccess contenant une + directive dans un répertoire /www/htdocs/exemple + revient exactement au même que mettre la même directive dans une + section Directory <Directory "/www/htdocs/exemple"> + du fichier de configuration de votre serveur principal :

+ +

Fichier .htaccess dans + /www/htdocs/exemple :

+ +

Contenu du fichier .htaccess dans + /www/htdocs/exemple

AddType text/example ".exm"
+
+ +

Section de votre fichier + httpd.conf

<Directory "/www/htdocs/example">
+    AddType text/example ".exm"
+</Directory>
+
+ +

Cependant, la perte de performances sera moindre si vous + définissez cette directive dans la configuration de + votre serveur principal, car cette dernière ne sera chargée qu'une + seule fois au moment du démarrage du serveur, alors qu'elle le sera + à chaque accès dans le cas d'un fichier .htaccess.

+ +

L'utilisation des fichiers .htaccess peut être + entièrement désactivée en définissant la directive AllowOverride à none :

+ + 
AllowOverride None
+ +
top
+
+

Comment sont appliquées les directives ?

+ +

Les directives de configuration situées dans un fichier + .htaccess s'appliquent au répertoire dans lequel ce + fichier .htaccess se trouve, ainsi qu'à tous ses + sous-répertoires. Cependant, il est important de garder à l'esprit + qu'il peut y avoir des fichiers .htaccess dans les + répertoires de niveau supérieur. Les directives sont appliquées + selon l'ordre dans lequel elles sont rencontrées. Ainsi, les + directives d'un fichier .htaccess situé dans un + répertoire particulier peuvent écraser les directives se trouvant + dans des fichiers .htaccess situés à un niveau + supérieur dans l'arborescence des répertoires. Et ces dernières + peuvent elles-mêmes avoir écrasé des directives d'un fichier + .htaccess situé à un niveau encore plus haut, ou dans + le fichier de configuration du serveur principal.

+ +

Exemple :

+ +

Dans le répertoire /www/htdocs/exemple1 se trouve un + fichier .htaccess contenant ce qui suit :

+ + 
Options +ExecCGI
+ + +

Note : "AllowOverride Options" doit être présent + pour permettre l'utilisation de la directive "Options" dans les fichiers + .htaccess.

+ +

Dans le répertoire /www/htdocs/exemple1/exemple2 se + trouve un fichier .htaccess contenant ce qui suit + :

+ + 
Options Includes
+ + +

Ainsi, à cause de ce second fichier .htaccess du + répertoire /www/htdocs/exemple1/exemple2, l'exécution + des CGI est interdite, car la dernière définition d'options + Options Includes écrase toute autre définition + d'options d'un fichier .htaccess situé dans un + répertoire de niveau supérieur.

+ +

Interactions entre les fichiers .htaccess + et les fichiers de configuration du serveur principal

+ +

Comme indiqué dans la documentation sur les Sections de configuration, les fichiers + .htaccess peuvent écraser les directives des sections + <Directory> pour + le répertoire correspondant, mais peuvent eux-mêmes être écrasés + par d'autres types de sections des fichiers de la + configuration principale. Cette possibilité peut s'avérer utile pour + forcer certaines configurations, même en cas de présence de l'option + libérale AllowOverride. Par + exemple, pour interdire l'exécution de scripts en autorisant la + définition de toute autre option dans les fichiers + .htaccess, vous pouvez utiliser :

+ + 
<Directory "/www/htdocs">
+    AllowOverride All
+</Directory>
+
+<Location "/">
+    Options +IncludesNoExec -ExecCGI
+</Location>
+ + +
Dans cet exemple, on considère que le chemin défini par la + directive DocumentRoot est + /www/htdocs.
+ + +
top
+
+

Exemple d'authentification

+ +

Si vous accédez directement à ce point du document pour apprendre + à effectuer une authentification, il est important de noter ceci. Il + existe une fausse idée selon laquelle il serait nécessaire + d'utiliser les fichiers .htaccess pour implémenter + l'authentification par mot de passe. Ceci est tout simplement faux. + Pour y parvenir, il est préférable de mettre les directives + d'authentification dans une section <Directory> du fichier de configuration de + votre serveur principal, et les fichiers .htaccess ne + devraient être utilisés que dans le cas où vous n'avez pas accès au + fichier de configuration du serveur principal. Voir ci-dessus pour savoir dans quels cas vous devez ou + ne devez pas utiliser les fichiers .htaccess.

+ +

Ceci étant dit, si vous pensez que vous devez quand-même utiliser + un fichier .htaccess, vous pouvez utiliser la + configuration suivante :

+ +

Contenu du fichier .htaccess :

+ + 
AuthType Basic
+AuthName "Password Required"
+AuthUserFile "/www/passwords/password.file"
+AuthGroupFile "/www/passwords/group.file"
+Require group admins
+ + +

Notez que AllowOverride AuthConfig doit être présent + pour que ces directives produisent leur effet.

+ +

Vous pouvez vous référer au tutoriel sur + l'authentification pour une description plus détaillée de + l'authentification et de l'autorisation.

+
top
+
+

Exemple d'Inclusion Côté Serveur (Server Side +Includes - SSI)

+ +

Les fichiers .htaccess sont aussi couramment + utilisés pour activer les SSI pour un répertoire particulier. Pour y + parvenir, on utilise les directives de configuration suivantes, + placées dans un fichier .htaccess enregistré dans le + répertoire considéré :

+ + 
Options +Includes
+AddType text/html "shtml"
+AddHandler server-parsed shtml
+ + +

Notez que AllowOverride Options et AllowOverride + FileInfo doivent être tous les deux présents pour que ces + directives puissent produire leur effet.

+ +

Vous pouvez vous référer au tutoriel SSI + pour une description plus détaillée des SSI.

+
top
+
+

Les règles de réécriture dans les fichiers .htaccess

+

Sivous utilisez des directives RewriteRule dans un fichier +.htaccess, gardez à l'esprit que les choses sont légèrement +différentes dans un contexte de répertoire. En particulier, les règles +sont relatives au répertoire courant, et non à l'URI original. Considérez +les exemples suivants :

+ +
# Dans httpd.conf
+RewriteRule "^/images/(.+)\.jpg" "/images/$1.png"
+
+# Dans un fichier .htaccess situé dans le répertoire racine de vos
+# documents
+RewriteRule "^images/(.+)\.jpg" "images/$1.png"
+
+# Dans un fichier .htaccess situé dans le répertoire images/
+RewriteRule "^(.+)\.jpg" "$1.png"
+ + +

On voit que si le fichier .htaccess se situe à la racine +de vos documents, le slash de tête est supprimé de la valeur de +remplacement spécifiée pour la règle RewriteRule, et que si le fichier +.htaccess se situe dans le répertoire images, +la chaîne /images/ disparaît de cette même valeur de +remplacement. Il doit donc en être de même dans votre expression +rationnelle.

+ +

Veuillez vous référer à cette documentation +pour une étude détaillée de l'utilisation du module +mod_rewrite.

+ +
top
+
+

Exemple de CGI

+ +

En fin de compte, vous avez décidé d'utiliser un fichier + .htaccess pour permettre l'exécution des programmes CGI + dans un répertoire particulier. Pour y parvenir, vous pouvez + utiliser la configuration suivante :

+ + 
Options +ExecCGI
+AddHandler cgi-script "cgi" "pl"
+ + +

Alternativement, si vous souhaitez que tous les fichiers d'un + répertoire donné soient considérés comme des programmes CGI, vous + pouvez utiliser la configuration suivante :

+ + 
Options +ExecCGI
+SetHandler cgi-script
+ + +

Notez que AllowOverride Options et AllowOverride + FileInfo doivent être tous les deux présents pour que ces + directives puissent produire leur effet.

+ +

Vous pouvez vous référer au tutoriel CGI + pour une description plus détaillée de la configuration et de la + proprammation CGI.

+ +
top
+
+

Résolution des problèmes

+ +

De nombreuses raisons peuvent être à l'origine du fait que + les directives que vous avez mises dans un fichier + .htaccess ne produisent pas l'effet désiré.

+ +

Le plus souvent, le problème vient du fait que la définition de + la directive AllowOverride + ne permet pas l'activation des directives de votre fichier + .htaccess. Vérifiez si une directive + AllowOverride None n'affecte pas le répertoire où se + trouve votre fichier. Un bon test consiste à mettre des directives + dont la syntaxe est erronée dans votre ficher .htaccess + et de recharger la page. Si aucune erreur n'est générée par le + serveur, il est pratiquement certain qu'une directive + AllowOverride None affecte votre répertoire.

+ +

Par contre, si vous obtenez des erreurs de serveur lorsque vous + tentez d'accéder à des documents, consultez votre journal des + erreurs de httpd. Il vous indiquera probablement que la directive + utilisée dans votre fichier .htaccess n'est pas + permise.

+ +

+ [Fri Sep 17 18:43:16 2010] [alert] [client 192.168.200.51] /var/www/html/.htaccess: DirectoryIndex not allowed here +

+

Cela signifie soit que vous utilisez une directive qui n'est + jamais permise dans les fichiers .htaccess, soit + que vous n'avez tout simplement pas défini la directive + AllowOverride à un niveau + suffisant pour la directive que vous utilisez. Consultez la + documentation de cette directive pour déterminer quel cas + s'applique.

+ +

Le journal des erreurs peut aussi vous signaler une erreur de + syntaxe dans l'usage de la directive elle-même.

+ +

+ [Sat Aug 09 16:22:34 2008] [alert] [client 192.168.200.51] /var/www/html/.htaccess: RewriteCond: bad flag delimiters +

+ +

Dans ce cas, le message d'erreur sera spécifique à l'erreur + de syntaxe que vous avez commise.

+
+
+

Langues Disponibles:  en  | + es  | + fr  | + ja  | + ko  | + pt-br 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/http2.html b/docs/manual/howto/http2.html index 4add469445..6457333793 100644 --- a/docs/manual/howto/http2.html +++ b/docs/manual/howto/http2.html @@ -6,7 +6,7 @@ Content-type: text/html; charset=ISO-8859-1 URI: http2.html.es Content-Language: es -Content-type: text/html; charset=ISO-8859-1 +Content-type: text/html; charset=UTF-8 URI: http2.html.fr Content-Language: fr diff --git a/docs/manual/howto/http2.html.en b/docs/manual/howto/http2.html.en index ca86b7b948..63fafc15b4 100644 --- a/docs/manual/howto/http2.html.en +++ b/docs/manual/howto/http2.html.en @@ -24,8 +24,8 @@ Apache > HTTP Server > Documentation > Version 2.5 > How-To / Tutorials

HTTP/2 guide

Available Languages:  en  | - es  | - fr 

+ es  | + fr 

This is the howto guide for the HTTP/2 implementation in Apache httpd. This @@ -317,8 +317,8 @@

Available Languages:  en  | - es  | - fr 

+ es  | + fr 

top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
- - -
-

Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

-

Versin 2.5 del Servidor HTTP Apache

-
-
<-
-

Gua HTTP/2

-
-

Idiomas disponibles:  en  | - es  | - fr 

-
- -

- Esta es la gua para configurar HTTP/2 en Apache httpd. sta caracterstica - est lista en producin as que es de esperar que las interfaces - y las directivas se mantengan consistentes en cada verin. -

-
- -
top
-
-

El protocolo HTTP/2

- - -

HTTP/2 es la evolucin del protocolo de la capa de aplicacin con ms - xito, HTTP. Se centra en hacer un uso ms eficiente de los recursos de red. - No cambia la caracterstica fundamental de HTTP, la semntica. Todava hay - olicitudes, respuestas, cabeceras y todo los elementos tpicos de HTTP/1. As - que, si ya conoce HTTP/1, tambin conoce el 95% de HTTP/2.

- -

Se ha escrito mucho sobre HTTP/2 y de cmo funciona. La norma ms - estndar es, por supuesto, su - RFC 7540 - ( tambin disponible en un - formato ms legible, YMMV). As que, ah encontrar toda la especificacin - del protocolo.

- -

Pero, como con todos los RFC, no es ideal como primera lectura. Es mejor - entender primero qu se quiere hacer y despus leer el RFC sobre - cmo hacerlo. Un documento mucho mejor con el que empezar es - http2 explicado - por Daniel Stenberg, el autor de curl. - Tambin est disponible cada vez en un mayor nmero lenguajes!

- -

Si le parece demasiado largo, o no lo ha leido, hay algunos trminos - y elementos a tener en cuenta cuando lea este documento:

-
    -
  • HTTP/2 es un protocolo binario, al contrario que - HTTP 1.1 que es texto plano. La intencin para HTTP 1.1 es que sea - legible (por ejemplo capturando el trfico de red) mientras que para - HTTP/2 no. Ms informacin en el FAQ oficial - Por qu es - binario HTTP/2?
    • - -
  • h2 es HTTP/2 sobre TLS (negociacin de protocolo a - travs de ALPN).
    • - -
  • h2c es HTTP/2 sobre TCP.
    • - -
  • Un frame es la unidad ms pequea de comunicacin - dentro de una conexin HTTP/2, que consiste en una cabecera y una secuencia - de octetos de longitud variable estructurada de acuerdo con el tipo de - frame. Ms informacin en la documentacin oficial - Seccin de - Capa de Frame.
    • - -
  • Un stream es un flujo bidireccional de frames dentro - de una conexin HTTP/2. El concepto correspondiente en HTTP 1.1 es un - intercambio de mensajes de solicitud/respuesta. Ms informacin en la - documentacin oficial - Seccin Capa - de Stream.
    • - -
  • - HTTP/2 es capaz de llevar mltiples streams de datos - sobre la misma conexin TCP, evitando la clsica solicitud lenta - "head-of-line blocking" de HTTP 1.1 y evitando generar mltiples conexiones - TCP para cada solicitud/respuesta (KeepAlive parche el problema en - HTTP 1.1 pero no lo resolvi completamente). -
    • -
-
top
-
-

HTTP/2 en Apache httpd

- - -

- El protocolo HTTP/2 se implementa con su propio mdulo httpd, llamado - acertadamente mod_http2. Incluye el set completo de - caractersticas descritas por el RFC 7540 y soporta HTTP/2 sobre texto - plano (http:), as como conexiones seguras (https:). La variante de texto - plano se llama 'h2c', la segura 'h2'. Para - h2c permite el modo direct - y el Upgrade: a travs de una solicitud inicial HTTP/1. -

- -

- Una caracterstica de HTTP/2 que ofrece capacidades nuevas para - desarrolladores de web es Server Push. Vea esa seccin - para saber como su aplicacin web puede hacer uso de ella. -

-
top
-
-

Compilar httpd con soporte HTTP/2

- - -

- mod_http2 usa la librera - nghttp2como su implementacin base. Para compilar - mod_http2 necesita al menos la versin 1.2.1 de - libnghttp2 instalada en su sistema. -

- -

- Cuando usted ejecuta ./configure en el cdigo fuente de - Apache HTTPD, necesita indicarle '--enable-http2' como una - opcin adicional para activar la compilacin de este mdulo. Si su - libnghttp2 est ubicado en una ruta no habitual (cualquiera que - sea en su sistema operativo), puede indicar su ubicacin con - '--with-nghttp2=<path>' para ./configure. -

- -

Aunque puede que eso sirva para la mayora, habr quien prefiera un nghttp2 compilado estticamente para este mdulo. Para ellos existe la opcin --enable-nghttp2-staticlib-deps. Funciona de manera muy similar a como uno debe enlazar openssl estticamente para mod_ssl.

- -

Hablando de SSL, necesita estar al tanto de que la mayora de los navegadores hablan HTTP/2 solo con URLs https:. As que necesita un servidor con soporte SSL. Pero no solo eso, necesitar una librera SSL que de soporte a la extensin ALPN. Si usa OpenSSL, necesita al menos la versin 1.0.2.

-
top
-
-

Configuracin bsica

- - -

Cuando tiene un httpd compilado con mod_http2 necesita una configuracin bsica para activarlo. Lo primero, como con cualquier otro mdulo de Apache, es que necesita cargarlo:

- - 
LoadModule http2_module modules/mod_http2.so
- - -

La segunda directiva que necesita aadir a la configuracin de su servidor es:

- - 
Protocols h2 http/1.1
- - -

Esto permite h2, la variante segura, para ser el protocolo preferido de las conexiones en su servidor. Cuando quiera habilitar todas las variantes de HTTP/2, entonces simplemente configure:

- - 
Protocols h2 h2c http/1.1
- - -

Dependiendo de dnde pone esta directiva, afecta a todas las conexiones o solo a las de ciertos host virtuales. La puede anidar, como en:

- - 
Protocols http/1.1
-<VirtualHost ...>
-    ServerName test.example.org
-    Protocols h2 http/1.1
-</VirtualHost>
- - -

Esto solo permite HTTP/1, excepto conexiones SSL hacia test.example.org que ofrecen HTTP/2.

- -

Escoger un SSLCipherSuite seguro

-

Es necesario configurar SSLCipherSuite con una suite segura de cifrado TLS. La versin actual de mod_http2 no fuerza ningn cifrado pero la mayora de los clientes si lo hacen. Encaminar un navegador hacia un servidor con h2 activado con una suite inapropiada de cifrados forzar al navegador a rehusar e intentar conectar por HTTP 1.1. Esto es un error comn cuando se configura httpd con HTTP/2 por primera vez, as que por favor tenga en cuenta que debe evitar largas sesiones de depuracin! Si quiere estar seguro de la suite de cifrados que escoja, por favor evite los listados en la Lista Negra de TLS para HTTP/2.

-
- -

El orden de los protocolos mencionados tambin es relevante. Por defecto, el primero es el protocolo preferido. Cuando un cliente ofrece mltiples opciones, la que est ms a la izquierda ser la escogida. En

- 
Protocols http/1.1 h2
- - -

el protocolo preferido es HTTP/1 y siempre ser seleccionado a menos que el cliente slo soporte h2. Puesto que queremos hablar HTTP/2 con clientes que lo soporten, el orden correcto es:

- - 
Protocols h2 h2c http/1.1
- - -

Hay algo ms respecto al orden: el cliente tambin tiene sus propias preferencias. Si quiere, puede configurar su servidor para seleccionar el protocolo preferido por el cliente:

- - 
ProtocolsHonorOrder Off
- - -

Hace que el orden en que usted escribi los Protocols sea irrelevante y slo el orden de preferencia del cliente ser decisorio.

- -

Una ltima cosa: cuando usted configura los protocolos no se comprueba si son correctos o estn bien escritos. Puede mencionar protocolos que no existen, as que no hay necesidad de proteger Protocols con ningn <IfModule> de comprobacin.

- -

Para ms consejos avanzados de configuracin, vea la - seccin de mdulos sobre dimensionamiento y - como gestionar multiples hosts con el mismo certificado.

-
top
-
-

Configuracin MPM

- - -

HTTP/2 est soportado en todos los mdulos de multi-proceso que se ofrecen con httpd. Aun as, si usa el mpm prefork, habr restricciones severas.

- -

En prefork, mod_http2 solo procesar una solicitud cada vez por conexin. Pero los clientes, como los navegadores, enviarn muchas solicitudes al mismo tiempo. Si una de ellas tarda mucho en procesarse (o hace un sondeo que dura ms de la cuenta), las otras solicitudes se quedarn atascadas.

- -

mod_http2 no evitar este lmite por defecto. El motivo es que prefork hoy en da solo se escoge si ejecuta motores de proceso que no estn preparados para multi-hilo, p.ej. fallar con ms de una solicitud.

- -

Si su configuracin lo soporta, hoy en da event es el mejor mpm que puede usar.

- -

Si realmente est obligado a usar prefork y quiere multiples solicitudes, puede configurar la directiva H2MinWorkers para hacerlo posible. Sin embargo, si esto falla, es bajo su cuenta y riesgo.

-
top
-
-

Clientes

- - -

Casi todos los navegadores modernos dan soporte a HTTP/2, pero solo en conexiones SSL: Firefox (v43), Chrome (v45), Safari (since v9), iOS Safari (v9), Opera (v35), Chrome para Android (v49) e Internet Explorer (v11 en Windows10) (Fuente).

- -

Otros clientes, as cmo otros servidores, estn listados en la - wiki de Implementaciones, entre ellos, implementaciones para c, c++, common lisp, dart, erlang, haskell, java, nodejs, php, python, perl, ruby, rust, scala y swift.

- -

Muchos de las implementaciones de clientes que no son navegadores soportan HTTP/2 sobre texto plano, h2c. La ms verstil es curl.

-
top
-
-

Herramientas tiles para depurar HTTP/2

- - -

La primera herramienta a mencionar es por supuesto curl. Por favor asegrese de que su versin soporta HTTP/2 comprobando sus Caractersticas:

- 
    $ curl -V
-    curl 7.45.0 (x86_64-apple-darwin15.0.0) libcurl/7.45.0 OpenSSL/1.0.2d zlib/1.2.8 nghttp2/1.3.4
-    Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 [...] 
-    Features: IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP HTTP2
-
- -

Notas sobre Mac OS homebrew

- brew install curl --with-openssl --with-nghttp2 -
-

Y para una inspeccin en gran profundidad wireshark.

-

El paquete nghttp2 tambin incluye clientes, tales como:

-
    -
  • nghttp - - util para visualizar la frames de HTTP/2 y tener una mejor idea de como funciona el protocolo.
    • -
  • h2load - til para hacer un stress-test de su servidor.
    • -
- -

Chrome ofrece logs detallados de HTTP/2 en sus conexiones a travs de la pgina especial de net-internals. Tambin hay una extensin interesante para Chrome y Firefox con la que visualizar cuando su navegador usa HTTP/2.

-
top
-
-

Server Push

- - -

El protocolo HTTP/2 permite al servidor hacer PUSH de respuestas a un cliente que nunca las solicit. El tono de la conversacin es: "Aqu tiene una solicitud que nunca envi y la respuesta llegar pronto..."

- -

Pero hay restricciones: el cliente puede deshabilitar esta caracterstica y el servidor entonces solo podr hacer PUSH en una solicitud que hizo previamente del cliente.

- -

La intencin es permitir al servidor enviar recursos que el cliente seguramente vaya a necesitar, p. ej. un recurso css o javascript que pertenece a una pgina html que el cliente solicit, un grupo de imgenes a las que se hace referencia en un css, etc.

- -

La ventaja para el cliente es que ahorra tiempo para solicitudes que pueden tardar desde unos pocos milisegundos a medio segundo, dependiendo de la distancia entre el cliente y el servidor. La desventaja es que el cliente puede recibir cosas que ya tiene en su cache. Por supuesto que HTTP/2 soporta cancelacin previa de tales solicitudes, pero aun as se malgastan recursos.

- -

Resumiendo: no hay una estrategia mejor sobre cmo usar esta caracterstica de HTTP/2 y todo el mundo est experimentando con ella. As que, cmo experimenta usted con ella en Apache httpd?

- -

mod_http2 busca e inspecciona las cabeceras de respuesta - Link con cierto formato:

- - 
Link </xxx.css>;rel=preload, </xxx.js>; rel=preload
- - -

- Si la conexin soporta PUSH, estos dos recursos se enviarn al cliente. - Como desarrollador web, puede configurar estas cabeceras o bien - directamente en la respuesta de su aplicacin o configurar su servidor con: -

- - 
<Location /xxx.html>
-    Header add Link "</xxx.css>;rel=preload"
-    Header add Link "</xxx.js>;rel=preload"
-</Location>
- - -

Si quiere usar enlaces con preload sin activar un PUSH, puede - usar el parmetro nopush, como en:

- - 
Link </xxx.css>;rel=preload;nopush
- - -

o puede desactivar PUSH para su servidor por completo con la directiva

- - 
H2Push Off
- - -

Y hay ms:

- -

- El mdulo mantiene un registro de lo que se ha enviado con PUSH para cada - conexin (hashes de URLs, bsicamente) y no har PUSH del mismo recurso dos - veces. Cuando la conexin se cierra, la informacin es descartada. -

- -

- Hay gente pensando cmo un cliente puede decirle al servidor lo que ya - tiene, para evitar los PUSH de esos elementos, pero eso algo muy - experimental ahora mismo. -

- -

Otro borrador experimental que ha sido implementado en - mod_http2 es el Campo de Cabecera - Accept-Push-Policy en la que un cliente puede, para cada solicitud, definir - qu tipo de PUSH acepta.

- -

- Puede que PUSH no siempre lance la peticion/respuesta/funcionamiento que - uno espera. Hay varios estudios sobre este tema en internet, que explican - el beneficio y las debilidades de como diferentes funcionalidades del - cliente y de la red influyen en el resultado. - Por Ejemplo, que un servidor haga "PUSH" de recursos, no significa que el - navegador vaya a usar dichos datos. -

-

- Lo ms importante que influye en la respuesta que se enva, es la solicitud - que se simul. La url de solicitud de un PUSH es dada por la aplicacin, - pero de donde vienen las cabeceras de la peticin? por ejemplo si el PUSH - pide una cabecera accept-language y si es as, con qu valor? -

-

Httpd mirar la peticin original (la que origin el PUSH) y copiar las - siguientes cabeceras a las peticiones PUSH: - user-agent, accept, accept-encoding, - accept-language, cache-control. -

-

- Todas las otras cabeceras son ignorados. Las cookies tampoco sern copiadas. - Impulsar los recursos que requieren una cookie para estar presente no - funcionar. Esto puede ser una cuestin de debate. Pero a menos que esto se - discuta ms claramente con el navegador, evitemos el exceso de precaucin y - no expongamos las cookies donde podran o no ser visibles. -

- -
top
-
-

"Early Hints"

- - -

Una alternativa de "Pushear" recursos es mandar una cabecera - Link al cliente antes que la respuesta est lista. Esto usa - una caracteristica de HTTP que se llama "Early Hints" y est descrita en - la RFC 8297.

-

Para poder usar esto, necesita habilitarlo explicitamente en el servidor - via

- - 
H2EarlyHints on
- - -

(No est habilitado por defecto ya q ue algunos navegadores ms antiguos - se caen con dichas respuestas.) -

- -

si esta funcionalidad esta activada, puede usar la directiva - H2PushResource para que lance - "Early hints" y recursos mediante push: -

- 
<Location /xxx.html>
-    H2PushResource /xxx.css
-    H2PushResource /xxx.js
-</Location>
- -

- Esto lanzar una respuesta "103 Early Hints" a un cliente - tan pronto como el servidor comience a procesar la solicitud. - Esto puede ser mucho antes que en el momento en que se determinaron los - primeros encabezados de respuesta, dependiendo de su aplicacin web. -

- -

- Si la directiva H2Push est - habilitada, esto comenzar el PUSH justo despus de la respuesta 103. - Sin embargo, si la directiva H2Push est dehabilitada, la respuesta 103 se le enviar al cliente. -

-
-
-

Idiomas disponibles:  en  | - es  | - fr 

-
top

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
-
- \ No newline at end of file diff --git a/docs/manual/howto/http2.html.es.utf8 b/docs/manual/howto/http2.html.es.utf8 new file mode 100644 index 0000000000..653042a0a5 --- /dev/null +++ b/docs/manual/howto/http2.html.es.utf8 @@ -0,0 +1,417 @@ + + + + + +Gua HTTP/2 - Servidor HTTP Apache Versin 2.5 + + + + + + +
+

Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

+

Versin 2.5 del Servidor HTTP Apache

+
+
<-
+

Gua HTTP/2

+
+

Idiomas disponibles:  en  | + es  | + fr 

+
+ +

+ Esta es la gua para configurar HTTP/2 en Apache httpd. sta caracterstica + est lista en producin as que es de esperar que las interfaces + y las directivas se mantengan consistentes en cada verin. +

+
+ +
top
+
+

El protocolo HTTP/2

+ + +

HTTP/2 es la evolucin del protocolo de la capa de aplicacin con ms + xito, HTTP. Se centra en hacer un uso ms eficiente de los recursos de red. + No cambia la caracterstica fundamental de HTTP, la semntica. Todava hay + olicitudes, respuestas, cabeceras y todo los elementos tpicos de HTTP/1. As + que, si ya conoce HTTP/1, tambin conoce el 95% de HTTP/2.

+ +

Se ha escrito mucho sobre HTTP/2 y de cmo funciona. La norma ms + estndar es, por supuesto, su + RFC 7540 + ( tambin disponible en un + formato ms legible, YMMV). As que, ah encontrar toda la especificacin + del protocolo.

+ +

Pero, como con todos los RFC, no es ideal como primera lectura. Es mejor + entender primero qu se quiere hacer y despus leer el RFC sobre + cmo hacerlo. Un documento mucho mejor con el que empezar es + http2 explicado + por Daniel Stenberg, el autor de curl. + Tambin est disponible cada vez en un mayor nmero lenguajes!

+ +

Si le parece demasiado largo, o no lo ha leido, hay algunos trminos + y elementos a tener en cuenta cuando lea este documento:

+
    +
  • HTTP/2 es un protocolo binario, al contrario que + HTTP 1.1 que es texto plano. La intencin para HTTP 1.1 es que sea + legible (por ejemplo capturando el trfico de red) mientras que para + HTTP/2 no. Ms informacin en el FAQ oficial + Por qu es + binario HTTP/2?
    • + +
  • h2 es HTTP/2 sobre TLS (negociacin de protocolo a + travs de ALPN).
    • + +
  • h2c es HTTP/2 sobre TCP.
    • + +
  • Un frame es la unidad ms pequea de comunicacin + dentro de una conexin HTTP/2, que consiste en una cabecera y una secuencia + de octetos de longitud variable estructurada de acuerdo con el tipo de + frame. Ms informacin en la documentacin oficial + Seccin de + Capa de Frame.
    • + +
  • Un stream es un flujo bidireccional de frames dentro + de una conexin HTTP/2. El concepto correspondiente en HTTP 1.1 es un + intercambio de mensajes de solicitud/respuesta. Ms informacin en la + documentacin oficial + Seccin Capa + de Stream.
    • + +
  • + HTTP/2 es capaz de llevar mltiples streams de datos + sobre la misma conexin TCP, evitando la clsica solicitud lenta + "head-of-line blocking" de HTTP 1.1 y evitando generar mltiples conexiones + TCP para cada solicitud/respuesta (KeepAlive parche el problema en + HTTP 1.1 pero no lo resolvi completamente). +
    • +
+
top
+
+

HTTP/2 en Apache httpd

+ + +

+ El protocolo HTTP/2 se implementa con su propio mdulo httpd, llamado + acertadamente mod_http2. Incluye el set completo de + caractersticas descritas por el RFC 7540 y soporta HTTP/2 sobre texto + plano (http:), as como conexiones seguras (https:). La variante de texto + plano se llama 'h2c', la segura 'h2'. Para + h2c permite el modo direct + y el Upgrade: a travs de una solicitud inicial HTTP/1. +

+ +

+ Una caracterstica de HTTP/2 que ofrece capacidades nuevas para + desarrolladores de web es Server Push. Vea esa seccin + para saber como su aplicacin web puede hacer uso de ella. +

+
top
+
+

Compilar httpd con soporte HTTP/2

+ + +

+ mod_http2 usa la librera + nghttp2como su implementacin base. Para compilar + mod_http2 necesita al menos la versin 1.2.1 de + libnghttp2 instalada en su sistema. +

+ +

+ Cuando usted ejecuta ./configure en el cdigo fuente de + Apache HTTPD, necesita indicarle '--enable-http2' como una + opcin adicional para activar la compilacin de este mdulo. Si su + libnghttp2 est ubicado en una ruta no habitual (cualquiera que + sea en su sistema operativo), puede indicar su ubicacin con + '--with-nghttp2=<path>' para ./configure. +

+ +

Aunque puede que eso sirva para la mayora, habr quien prefiera un nghttp2 compilado estticamente para este mdulo. Para ellos existe la opcin --enable-nghttp2-staticlib-deps. Funciona de manera muy similar a como uno debe enlazar openssl estticamente para mod_ssl.

+ +

Hablando de SSL, necesita estar al tanto de que la mayora de los navegadores hablan HTTP/2 solo con URLs https:. As que necesita un servidor con soporte SSL. Pero no solo eso, necesitar una librera SSL que de soporte a la extensin ALPN. Si usa OpenSSL, necesita al menos la versin 1.0.2.

+
top
+
+

Configuracin bsica

+ + +

Cuando tiene un httpd compilado con mod_http2 necesita una configuracin bsica para activarlo. Lo primero, como con cualquier otro mdulo de Apache, es que necesita cargarlo:

+ + 
LoadModule http2_module modules/mod_http2.so
+ + +

La segunda directiva que necesita aadir a la configuracin de su servidor es:

+ + 
Protocols h2 http/1.1
+ + +

Esto permite h2, la variante segura, para ser el protocolo preferido de las conexiones en su servidor. Cuando quiera habilitar todas las variantes de HTTP/2, entonces simplemente configure:

+ + 
Protocols h2 h2c http/1.1
+ + +

Dependiendo de dnde pone esta directiva, afecta a todas las conexiones o solo a las de ciertos host virtuales. La puede anidar, como en:

+ + 
Protocols http/1.1
+<VirtualHost ...>
+    ServerName test.example.org
+    Protocols h2 http/1.1
+</VirtualHost>
+ + +

Esto solo permite HTTP/1, excepto conexiones SSL hacia test.example.org que ofrecen HTTP/2.

+ +

Escoger un SSLCipherSuite seguro

+

Es necesario configurar SSLCipherSuite con una suite segura de cifrado TLS. La versin actual de mod_http2 no fuerza ningn cifrado pero la mayora de los clientes si lo hacen. Encaminar un navegador hacia un servidor con h2 activado con una suite inapropiada de cifrados forzar al navegador a rehusar e intentar conectar por HTTP 1.1. Esto es un error comn cuando se configura httpd con HTTP/2 por primera vez, as que por favor tenga en cuenta que debe evitar largas sesiones de depuracin! Si quiere estar seguro de la suite de cifrados que escoja, por favor evite los listados en la Lista Negra de TLS para HTTP/2.

+
+ +

El orden de los protocolos mencionados tambin es relevante. Por defecto, el primero es el protocolo preferido. Cuando un cliente ofrece mltiples opciones, la que est ms a la izquierda ser la escogida. En

+ 
Protocols http/1.1 h2
+ + +

el protocolo preferido es HTTP/1 y siempre ser seleccionado a menos que el cliente slo soporte h2. Puesto que queremos hablar HTTP/2 con clientes que lo soporten, el orden correcto es:

+ + 
Protocols h2 h2c http/1.1
+ + +

Hay algo ms respecto al orden: el cliente tambin tiene sus propias preferencias. Si quiere, puede configurar su servidor para seleccionar el protocolo preferido por el cliente:

+ + 
ProtocolsHonorOrder Off
+ + +

Hace que el orden en que usted escribi los Protocols sea irrelevante y slo el orden de preferencia del cliente ser decisorio.

+ +

Una ltima cosa: cuando usted configura los protocolos no se comprueba si son correctos o estn bien escritos. Puede mencionar protocolos que no existen, as que no hay necesidad de proteger Protocols con ningn <IfModule> de comprobacin.

+ +

Para ms consejos avanzados de configuracin, vea la + seccin de mdulos sobre dimensionamiento y + como gestionar multiples hosts con el mismo certificado.

+
top
+
+

Configuracin MPM

+ + +

HTTP/2 est soportado en todos los mdulos de multi-proceso que se ofrecen con httpd. Aun as, si usa el mpm prefork, habr restricciones severas.

+ +

En prefork, mod_http2 solo procesar una solicitud cada vez por conexin. Pero los clientes, como los navegadores, enviarn muchas solicitudes al mismo tiempo. Si una de ellas tarda mucho en procesarse (o hace un sondeo que dura ms de la cuenta), las otras solicitudes se quedarn atascadas.

+ +

mod_http2 no evitar este lmite por defecto. El motivo es que prefork hoy en da solo se escoge si ejecuta motores de proceso que no estn preparados para multi-hilo, p.ej. fallar con ms de una solicitud.

+ +

Si su configuracin lo soporta, hoy en da event es el mejor mpm que puede usar.

+ +

Si realmente est obligado a usar prefork y quiere multiples solicitudes, puede configurar la directiva H2MinWorkers para hacerlo posible. Sin embargo, si esto falla, es bajo su cuenta y riesgo.

+
top
+
+

Clientes

+ + +

Casi todos los navegadores modernos dan soporte a HTTP/2, pero solo en conexiones SSL: Firefox (v43), Chrome (v45), Safari (since v9), iOS Safari (v9), Opera (v35), Chrome para Android (v49) e Internet Explorer (v11 en Windows10) (Fuente).

+ +

Otros clientes, as cmo otros servidores, estn listados en la + wiki de Implementaciones, entre ellos, implementaciones para c, c++, common lisp, dart, erlang, haskell, java, nodejs, php, python, perl, ruby, rust, scala y swift.

+ +

Muchos de las implementaciones de clientes que no son navegadores soportan HTTP/2 sobre texto plano, h2c. La ms verstil es curl.

+
top
+
+

Herramientas tiles para depurar HTTP/2

+ + +

La primera herramienta a mencionar es por supuesto curl. Por favor asegrese de que su versin soporta HTTP/2 comprobando sus Caractersticas:

+ 
    $ curl -V
+    curl 7.45.0 (x86_64-apple-darwin15.0.0) libcurl/7.45.0 OpenSSL/1.0.2d zlib/1.2.8 nghttp2/1.3.4
+    Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 [...] 
+    Features: IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP HTTP2
+
+ +

Notas sobre Mac OS homebrew

+ brew install curl --with-openssl --with-nghttp2 +
+

Y para una inspeccin en gran profundidad wireshark.

+

El paquete nghttp2 tambin incluye clientes, tales como:

+
    +
  • nghttp + - util para visualizar la frames de HTTP/2 y tener una mejor idea de como funciona el protocolo.
    • +
  • h2load - til para hacer un stress-test de su servidor.
    • +
+ +

Chrome ofrece logs detallados de HTTP/2 en sus conexiones a travs de la pgina especial de net-internals. Tambin hay una extensin interesante para Chrome y Firefox con la que visualizar cuando su navegador usa HTTP/2.

+
top
+
+

Server Push

+ + +

El protocolo HTTP/2 permite al servidor hacer PUSH de respuestas a un cliente que nunca las solicit. El tono de la conversacin es: "Aqu tiene una solicitud que nunca envi y la respuesta llegar pronto..."

+ +

Pero hay restricciones: el cliente puede deshabilitar esta caracterstica y el servidor entonces solo podr hacer PUSH en una solicitud que hizo previamente del cliente.

+ +

La intencin es permitir al servidor enviar recursos que el cliente seguramente vaya a necesitar, p. ej. un recurso css o javascript que pertenece a una pgina html que el cliente solicit, un grupo de imgenes a las que se hace referencia en un css, etc.

+ +

La ventaja para el cliente es que ahorra tiempo para solicitudes que pueden tardar desde unos pocos milisegundos a medio segundo, dependiendo de la distancia entre el cliente y el servidor. La desventaja es que el cliente puede recibir cosas que ya tiene en su cache. Por supuesto que HTTP/2 soporta cancelacin previa de tales solicitudes, pero aun as se malgastan recursos.

+ +

Resumiendo: no hay una estrategia mejor sobre cmo usar esta caracterstica de HTTP/2 y todo el mundo est experimentando con ella. As que, cmo experimenta usted con ella en Apache httpd?

+ +

mod_http2 busca e inspecciona las cabeceras de respuesta + Link con cierto formato:

+ + 
Link </xxx.css>;rel=preload, </xxx.js>; rel=preload
+ + +

+ Si la conexin soporta PUSH, estos dos recursos se enviarn al cliente. + Como desarrollador web, puede configurar estas cabeceras o bien + directamente en la respuesta de su aplicacin o configurar su servidor con: +

+ + 
<Location /xxx.html>
+    Header add Link "</xxx.css>;rel=preload"
+    Header add Link "</xxx.js>;rel=preload"
+</Location>
+ + +

Si quiere usar enlaces con preload sin activar un PUSH, puede + usar el parmetro nopush, como en:

+ + 
Link </xxx.css>;rel=preload;nopush
+ + +

o puede desactivar PUSH para su servidor por completo con la directiva

+ + 
H2Push Off
+ + +

Y hay ms:

+ +

+ El mdulo mantiene un registro de lo que se ha enviado con PUSH para cada + conexin (hashes de URLs, bsicamente) y no har PUSH del mismo recurso dos + veces. Cuando la conexin se cierra, la informacin es descartada. +

+ +

+ Hay gente pensando cmo un cliente puede decirle al servidor lo que ya + tiene, para evitar los PUSH de esos elementos, pero eso algo muy + experimental ahora mismo. +

+ +

Otro borrador experimental que ha sido implementado en + mod_http2 es el Campo de Cabecera + Accept-Push-Policy en la que un cliente puede, para cada solicitud, definir + qu tipo de PUSH acepta.

+ +

+ Puede que PUSH no siempre lance la peticion/respuesta/funcionamiento que + uno espera. Hay varios estudios sobre este tema en internet, que explican + el beneficio y las debilidades de como diferentes funcionalidades del + cliente y de la red influyen en el resultado. + Por Ejemplo, que un servidor haga "PUSH" de recursos, no significa que el + navegador vaya a usar dichos datos. +

+

+ Lo ms importante que influye en la respuesta que se enva, es la solicitud + que se simul. La url de solicitud de un PUSH es dada por la aplicacin, + pero de donde vienen las cabeceras de la peticin? por ejemplo si el PUSH + pide una cabecera accept-language y si es as, con qu valor? +

+

Httpd mirar la peticin original (la que origin el PUSH) y copiar las + siguientes cabeceras a las peticiones PUSH: + user-agent, accept, accept-encoding, + accept-language, cache-control. +

+

+ Todas las otras cabeceras son ignorados. Las cookies tampoco sern copiadas. + Impulsar los recursos que requieren una cookie para estar presente no + funcionar. Esto puede ser una cuestin de debate. Pero a menos que esto se + discuta ms claramente con el navegador, evitemos el exceso de precaucin y + no expongamos las cookies donde podran o no ser visibles. +

+ +
top
+
+

"Early Hints"

+ + +

Una alternativa de "Pushear" recursos es mandar una cabecera + Link al cliente antes que la respuesta est lista. Esto usa + una caracteristica de HTTP que se llama "Early Hints" y est descrita en + la RFC 8297.

+

Para poder usar esto, necesita habilitarlo explicitamente en el servidor + via

+ + 
H2EarlyHints on
+ + +

(No est habilitado por defecto ya q ue algunos navegadores ms antiguos + se caen con dichas respuestas.) +

+ +

si esta funcionalidad esta activada, puede usar la directiva + H2PushResource para que lance + "Early hints" y recursos mediante push: +

+ 
<Location /xxx.html>
+    H2PushResource /xxx.css
+    H2PushResource /xxx.js
+</Location>
+ +

+ Esto lanzar una respuesta "103 Early Hints" a un cliente + tan pronto como el servidor comience a procesar la solicitud. + Esto puede ser mucho antes que en el momento en que se determinaron los + primeros encabezados de respuesta, dependiendo de su aplicacin web. +

+ +

+ Si la directiva H2Push est + habilitada, esto comenzar el PUSH justo despus de la respuesta 103. + Sin embargo, si la directiva H2Push est dehabilitada, la respuesta 103 se le enviar al cliente. +

+
+
+

Idiomas disponibles:  en  | + es  | + fr 

+
top

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/http2.html.fr b/docs/manual/howto/http2.html.fr deleted file mode 100644 index 89dae8866a..0000000000 --- a/docs/manual/howto/http2.html.fr +++ /dev/null @@ -1,429 +0,0 @@ - - - - - -Guide HTTP/2 - Serveur HTTP Apache Version 2.5 - - - - - - -
-

Modules | Directives | FAQ | Glossaire | Plan du site

-

Serveur HTTP Apache Version 2.5

-
-
<-
-

Guide HTTP/2

-
-

Langues Disponibles:  en  | - es  | - fr 

-
- -

Ce document est le guide de l'utilisateur de l'implémentation de HTTP/2 - dans Apache httpd. Cette fonctionnalité en est au stade - de production, et les interfaces et directives devraient donc être - dorénavant relativement stables. -

-
- -
top
-
-

Le protocole HTTP/2

- -

HTTP/2 est une évolution du protocole de la couche application le plus - utilisé au monde, HTTP. Cette évolution permet en particulier une utilisation - plus efficace des ressources réseau. Il ne modifie pas les aspects - fondamentaux de HTTP (sa sémantique). Entre autres, il y a toujours des - requêtes, des réponses et des en-têtes. Par conséquent, si vous connaissez - HTTP/1, vous connaissez déjà 95% de HTTP/2.

-

Beaucoup a déjà été écrit à propos de HTTP/2 et de son fonctionnement. La - documentation la plus officielle est bien entendu sa RFC 7540 (ou cette version au format plus - lisible). Vous trouverez ici une description des rouages de HTTP/2 dans - leurs moindres détails.

-

Le premier document à lire lorsqu'on ne connaît pas un mécanisme n'est - cependant pas sa RFC. Il est préférable de comprendre tout d'abord ce - que ce mécanisme est censé faire, et seulement ensuite de lire sa RFC - pour comprendre comment il fonctionne. http2 explained de Daniel Stenberg - (l'auteur de curl) - est un bien meilleur document pour démarrer l'étude de HTTP/2. En outre, de - nouveaux langages s'ajoutent régulièrement à sa liste de traductions - disponibles !

-

Si vous n'avez pas envie de le lire parce que vous le trouvez trop long, - voici certains pièges à éviter et nouveaux termes à connaître avant de lire - ce document :

-
    -
  • A la différence de HTTP/1 qui est en texte pur, HTTP/2 est un - protocole binaire, et alors que le premier est lisible par - un humain (par exemple pour sniffer le trafic réseau), le second ne - l'est pas. Voir la FAQ - officielle pour plus de détails.
    • -
  • h2 correspond à HTTP/2 sur TLS (négociation de - protocole via ALPN).
    • -
  • h2c correspond à HTTP/2 sur TCP.
    • -
  • Une frame ou trame est la plus petite unité de - communication au sein d'une connexion HTTP/2 et comporte une en-tête et - une séquence d'octets de longueur variable dont la structure correspond - au type de trame. Voir la section - correspondante de la documentation officielle pour plus de - détails.
    • -
  • Un stream est un flux bidirectionnel de frames au - sein d'une connexion HTTP/2. La notion correspondante dans HTTP/1 est un - échange de messages de type requête et réponse. Voir la section - correspondante de la documentation officielle pour plus de détails.
    • -
  • HTTP/2 peut gérer plusieurs streams de données sur - la même connexion TCP, ce qui permet d'éviter le point de blocage - classique de HTTP/1 pour les requêtes lentes, et de ne pas avoir à - ouvrir de nouvelles connexions TCP pour chaque requête/réponse (les - connexions persistantes ou KeepAlive avaient contourné le problème dans - HTTP/1 mais ne l'avaient pas entièrement résolu)
    • -
-
top
-
-

HTTP/2 dans Apache httpd

- -

Le protocole HTTP/2 est implémenté dans Apache httpd via un module - propre, pertinemment nommé mod_http2. Ce - module implémente toutes les fonctionnalités décrites par la RFC 7540 et - supporte les connexions en texte pur (http:), ou sécurisées (https:). - La variante texte pur se nomme 'h2c', et la variante sécurisée - 'h2'. h2c peut être en mode direct ou - Upgrade: via une requête initiale en HTTP/1.

-

Server Push est une nouvelle fonctionnalité offerte - aux développeurs web par HTTP/2. La section correspondante de ce document - vous indiquera comment votre application peut en tirer parti.

-
top
-
-

Compilation de httpd avec le support de HTTP/2

- -

mod_http2 se base sur la bibliothèque - de nghttp2 pour son implémentation. Pour - pouvoir compiler mod_http2, libnghttp2 version - 1.2.1. ou supérieure doit être installée dans votre système.

-

Pour déclencher la compilation de mod_http2, vous devez - ajouter l'argument '--enable-http2' au script - ./configure que vous exécutez à la racine de l'arborescence des - sources de httpd. Si libnghttp2 est installée dans un - répertoire non connu du chemin de vos bibliothèques, vous devez indiquer ce - répertoire au script ./configure via l'argument - '--with-nghttp2=<path>'.

-

Alors que cette méthode de compilation conviendra à la plupart, certains - préféreront lier statiquement nghttp2 à ce module. Pour ce - faire, utilisez l'argument --enable-nghttp2-staticlib-deps. - Cette méthode est pratiquement la même que celle utilisée pour lier - statiquement openssl à mod_ssl.

-

En parlant de SSL, vous devez savoir que la plupart des navigateurs ne - communiqueront en HTTP/2 que sur des URLs sécurisées de type - https: ; votre serveur doit donc supporter SSL. Mais de plus, - votre bibliothèque SSL devra supporter l'extension ALPN. Enfin, - si la bibliothèque que vous utilisez est OpenSSL, sa version devra être - 1.0.2. ou supérieure.

-
top
-
-

Configuration de base

- - -

Maintenant que vous disposez d'un binaire httpd compilé avec le - module mod_http2, l'activation de ce dernier nécessite un - minimum de configuration supplémentaire. En premier lieu, comme pour tout - module Apache, vous devez le charger :

- 
LoadModule http2_module modules/mod_http2.so
- - -

La seconde directive que vous devez ajouter à votre fichier de - configuration est

- 
Protocols h2 http/1.1
- -

Ceci permet de définir h2, la variante sécurisée, comme le protocole - préféré pour les connexions à votre serveur. Si vous souhaitez que toutes les - variantes soient disponibles, utilisez la directive suivante :

- 
Protocols h2 h2c http/1.1
- -

Selon l'endroit où vous placez cette directive, elle affectera l'ensemble - de votre serveur, ou seulement un ou plusieurs serveurs virtuels. Vous - pouvez aussi l'imbriquer comme dans l'exemple suivant :

- 
Protocols http/1.1
-<VirtualHost ...>
-    ServerName test.example.org
-    Protocols h2 http/1.1
-</VirtualHost>
- - -

Seules les connexions en HTTP/1 seront alors permises, sauf pour le serveur - virtuel test.example.org qui acceptera aussi les connexions SSL - en HTTP/2.

-

Utilisez une chaîne d'algorithmes de chiffrement forte

-

La directive SSLCipherSuite doit - être définie avec une chaîne d'algorithmes de chiffrement TLS forte. Même si - la version actuelle de mod_http2 n'impose pas d'algorithmes de chiffrement - particuliers, la plupart des clients le font. Faire pointer un navigateur - vers un serveur où h2 est activé avec une chaîne d'algorithmes - de chiffrement inappropriée entraînera un rejet et une retrogradation vers - HTTP 1.1. C'est une erreur que l'on fait couramment lorsqu'on configure - httpd pour HTTP/2 pour la première fois ; donc gardez la à l'esprit si vous - voulez éviter de longues sessions de débogage ! Si vous voulez être sûr de - définir une chaîne d'algorithmes de chiffrement appropriée, évitez ceux qui - sont listés dans la blacklist TLS HTTP/2 - .

-
-

L'ordre des protocoles indiqués est aussi important. Par défaut, le - premier sera le protocole préféré. Lorsqu'un client offre plusieurs choix, - c'est le plus à gauche qui sera sélectionné. Dans

- 
Protocols http/1.1 h2
- -

le protocole préféré sera HTTP/1 et il sera toujours sélectionné sauf si - un client ne supporte que h2. Comme nous souhaitons communiquer en - HTTP/2 avec les clients qui le supportent, la meilleure définition de la - directive est

- 
Protocols h2 h2c http/1.1
- - -

Toujours à propos de l'ordre des protocoles, le client a lui aussi ses - propres préférences en la matière. À ce titre, si vous le souhaitez, vous - pouvez configurer votre serveur pour qu'il sélectionne non plus son - protocole préféré, mais au contraire le protocole préféré - du client :

- 
ProtocolsHonorOrder Off
- -

Avec cette directive, l'ordre des protocoles que vous avez - défini devient caduque et seul l'ordre défini par le client sera pris en - compte.

-

Une dernière chose : les protocoles que vous définissez ne sont pas - vérifiés quant à leurs validité ou orthographe. Vous pouvez très bien - définir des protocoles qui n'existent pas, et il n'est donc pas nécessaire - de filtrer le contenu de la directive Protocols avec des vérifications de type - <IfModule>.

-

Pour des conseils plus avancés à propos de la configuration, voir la Documentation de mod_http2, et en particulier - la section à propos de la consommation supplémentaire de - ressources, ainsi que la section expliquant comment gérer les serveurs multiples avec certificat - commun.

-
top
-
-

Configuration du MPM

- - -

Tous les modules multiprocessus (MPM) fournis avec httpd supportent - HTTP/2. Cependant, si vous utilisez le MPM prefork, vous allez - faire face à de sévères restrictions.

-

Avec le MPM prefork, mod_http2 ne traitera - qu'une requête à la fois par connexion alors que les clients tels que les - navigateurs internet envoient de nombreuses requêtes au même moment. Si - l'une d'entre elles est longue à traiter (ou implique une longue - interrogation), les autres requêtes seront mises en attente.

-

Par défaut, mod_http2 ne passe pas outre cette limitation pour - la simple et bonne raison que le MPM prefork n'est aujourd'hui - choisi que si vous exécutez des moteurs de traitement qui ne sont pas préparés - pour le multithreading (par exemple qui se crashent lorsque plusieurs - requêtes arrivent).

-

Si votre plateforme et votre installation de httpd le supportent, la - meilleur solution consiste actuellement à utiliser le MPM - event. -

-

Si vous n'avez pas d'autre choix que d'utiliser le MPM - prefork, mais souhaitez tout de même traiter plusieurs requêtes - simultanément, vous pouvez jouer avec la directive H2MinWorkers, sans garantie que cela - fonctionne.

-
top
-
-

Clients

- -

La plupart des navigateurs modernes supportent HTTP/2, mais seulement sur - des connexions SSL : Firefox v43, Chrome v45, Safari v9, iOS Safari v9, - Opera v35, Chrome pour Android v49 et - Internet Explorer v11 sous Windows10 (selon cette source).

-

D'autres clients et serveurs sont listés dans le wiki des - implémentations ; entre autres des implémentations pour c, c++, common - lisp, dart, erlang, haskell, java, nodejs, php, python, perl, ruby, rust, - scala et swift.

-

De nombreuses implémentations clientes autres que les navigateurs - supportent HTTP/2 en texte pur, h2c. L'une des plus efficaces d'entre elles - est curl.

-
top
-
-

Outils efficaces pour déboguer HTTP/2

- -

Le premier d'entre eux est bien entendu curl. Assurez-vous au préalable que votre - version supporte HTTP/2 en vérifiant ses Fonctionnalités :

- 
    $ curl -V
-    curl 7.45.0 (x86_64-apple-darwin15.0.0) libcurl/7.45.0 OpenSSL/1.0.2d zlib/1.2.8 nghttp2/1.3.4
-    Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 [...]
-    Features: IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP HTTP2
-
- -

homebrew sous Mac OS :

- brew install curl --with-openssl --with-nghttp2 -
-

Pour une inspection en profondeur : wireshark.

-

Le paquet nghttp2 inclut aussi des - outils comme :

-
    -
  • nghttp - - permet de visualiser les trames HTTP/2 et ainsi de se faire une meilleure - idée du protocole.
    • -
  • h2load - - permet de tester votre serveur dans des conditions extremes.
    • -
-

Chrome fournit des journaux détaillés des connexions HTTP/2 via la page - special net-internals page. Il y - a aussi cette extension intéressante pour Chrome - et Firefox - qui permet d'indiquer que votre navigateur utilise HTTP/2.

-
top
-
-

Push serveur

- -

Le protocole HTTP/2 permet au serveur de proposer (PUSH) des réponses - pour lesquelles le client n'a rien demandé. La communication autour de ces - réponses est du style : "voici une requête que vous n'avez jamais - envoyée, et la réponse vous parviendra bientôt tout de même ..."

-

Il y a cependant des conditions : le client peut désactiver cette - fonctionnalité et le serveur ne pourra alors lui proposer des réponses que - pour les requêtes qu'il a effectivement envoyées.

-

Cette fonctionnalité a pour but de permettre au serveur d'envoyer au - client des ressources dont il va probablement avoir besoin : par exemple une - ressource css ou javascript appartenant à une page html que le client a - demandée, un jeu d'images référencé par un css, etc...

-

Cette anticipation a pour avantage de permettre au client d'économiser le - temps qu'il lui aurait fallu pour envoyer une requête, quelques - millisecondes à une demi-seconde en fonction de l'éloignement du serveur. - Elle a cependant pour inconvénient d'imposer au client le téléchargement de - ressources qu'il possède peut-être déjà dans son cache. Bien entendu, HTTP/2 - permet d'annuler prématurément de telles requêtes, mais des ressources sont - tout de même gaspillées.

-

En résumé : il n'existe pas encore de stratégie efficace pour faire le - meilleur usage de cette fonctionnalité de HTTP/2 et tout le monde en est - encore au stade de l'expérimentation. À ce titre, voici des conseils pour - procéder vous-même à ces expérimentations :

-

mod_http2 inspecte l'en-tête de la réponse et recherche les - en-têtes Link sous un certain format :

- 
Link </xxx.css>;rel=preload, </xxx.js>; rel=preload
- -

Si la connexion supporte PUSH, ces deux ressources seront envoyées au - client. En tant que développeur web vous pouvez définir ces en-têtes soit - directement au niveau de la réponse de votre application, soit en - configurant votre serveur via

- 
<Location /xxx.html>
-    Header add Link "</xxx.css>;rel=preload"
-    Header add Link "</xxx.js>;rel=preload"
-</Location>
- -

Si vous souhaitez utiliser des liens preload sans déclencher - de PUSH, vous pouvez utiliser le paramètre nopush comme suit :

- 
Link </xxx.css>;rel=preload;nopush
- -

Vous pouvez aussi désactiver les PUSHes pour l'ensemble de votre - serveur via la directive

- 
H2Push Off
- -

À savoir aussi :

-

Le module maintient un journal des ressources ayant fait l'objet d'un - PUSH pour chaque connexion (en général des condensés hash des URLs), et - n'effectuera pas deux fois un PUSH pour la même ressource. Cependant, - lorsque la connexion est fermée, le journal de ses PUSHes est supprimé.

-

Certains développeurs planchent sur la manière de permettre au client - d'informer le serveur des ressources qu'il possède déjà dans son cache afin - d'éviter les PUSHes pour ces dernières, mais ceci n'en est actuellement qu'à - un stade très expérimental.

-

L' - en-tête Accept-Push-Policy est un autre dispositif expérimental - implémenté dans mod_http2 ; il permet au client de définir pour - chaque requête quels genres de PUSHes il accepte.

- - -

- La fonctionnalité PUSH n'apportera pas toujours le gain de performances dans - l'obtention de réponses aux requêtes. Vous trouverez plusieurs études sur ce - sujet sur internet qui en expliquent les avantages et inconvénients et - comment les particularités des clients et du réseau en influencent le - fonctionnement. Par exemple, le seul fait que le serveur PUSHes une - ressource n'implique pas forcément que le navigateur l'utilisera.

-

Ce qui influence le plus la réponse PUSHed, c'est la requête qui a été - simulée. En effet, l'URL de la requête pour un PUSH est fournie par - l'application, mais d'où viennent les en-têtes ? Par exemple, La requête - PUSH requiert-elle un en-tête accept-language et si oui, quelle - sera sa valeur ?

-

httpd va consulter la requête originale (celle qui a déclenché le PUSH) - et copier les en-têtes suivants vers la requête PUSH : - user-agent, accept, accept-encoding, - accept-language et cache-control.

-

Tous les autres en-têtes sont ignorés. Les cookies eux non plus ne seront - pas copiés. PUSHer des ressources qui requièrent la présence d'un cookie ne - fonctionnera pas. Ceci peut être sujet à débat, mais tant que ce ne sera pas - clairement discuté avec les navigateurs, restons prudents et évitons - d'exposer les cookies là où ils ne sont pas censés être visibles.

-
top
-
-

Suggestions précoces

- -

A l'instar des ressources PUSHées, une autre méthode consiste à envoyer - des en-têtes Link au client avant même que la réponse ne soit - prête. Cette méthode utilise la fonctionnalité appelée "Suggestions - précoces" (Early Hints) décrite dans la RFC 8297.

-

Pour utiliser cette fonctionnalité, vous devez l'activer explicitement - sur le serveur via :

- 
H2EarlyHints on
- -

Elle n'est en effet pas activée par défaut car certains navigateurs - anciens perdent pied avec de telles réponses.

-

Une fois cette fonctionnalité activée, vous pouvez utiliser la directive - H2PushResource pour déclencher les - suggestions précoces et les PUSHes de ressources :

- 
<Location /xxx.html>
-    H2PushResource /xxx.css
-    H2PushResource /xxx.js
-</Location>
- -

Le serveur enverra alors au client une réponse "103 Early - Hints" dès qu'il commencera à traiter la requête. Selon - votre application web, cet envoi peut intervenir beaucoup plus tôt que le - moment où les premiers en-têtes de réponse auront été déterminés.

-

Si H2Push est activé, ceci - déclenchera aussi le PUSH juste après la réponse 103. Mais si H2Push n'est pas activé, la réponse 103 sera - quand-même envoyée au client.

-
-
-

Langues Disponibles:  en  | - es  | - fr 

-
top

Commentaires

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

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.5

+
+
<-
+

Guide HTTP/2

+
+

Langues Disponibles:  en  | + es  | + fr 

+
+ +

Ce document est le guide de l'utilisateur de l'implémentation de HTTP/2 + dans Apache httpd. Cette fonctionnalité en est au stade + de production, et les interfaces et directives devraient donc être + dorénavant relativement stables. +

+
+ +
top
+
+

Le protocole HTTP/2

+ +

HTTP/2 est une évolution du protocole de la couche application le plus + utilisé au monde, HTTP. Cette évolution permet en particulier une utilisation + plus efficace des ressources réseau. Il ne modifie pas les aspects + fondamentaux de HTTP (sa sémantique). Entre autres, il y a toujours des + requêtes, des réponses et des en-têtes. Par conséquent, si vous connaissez + HTTP/1, vous connaissez déjà 95% de HTTP/2.

+

Beaucoup a déjà été écrit à propos de HTTP/2 et de son fonctionnement. La + documentation la plus officielle est bien entendu sa RFC 7540 (ou cette version au format plus + lisible). Vous trouverez ici une description des rouages de HTTP/2 dans + leurs moindres détails.

+

Le premier document à lire lorsqu'on ne connaît pas un mécanisme n'est + cependant pas sa RFC. Il est préférable de comprendre tout d'abord ce + que ce mécanisme est censé faire, et seulement ensuite de lire sa RFC + pour comprendre comment il fonctionne. http2 explained de Daniel Stenberg + (l'auteur de curl) + est un bien meilleur document pour démarrer l'étude de HTTP/2. En outre, de + nouveaux langages s'ajoutent régulièrement à sa liste de traductions + disponibles !

+

Si vous n'avez pas envie de le lire parce que vous le trouvez trop long, + voici certains pièges à éviter et nouveaux termes à connaître avant de lire + ce document :

+
    +
  • A la différence de HTTP/1 qui est en texte pur, HTTP/2 est un + protocole binaire, et alors que le premier est lisible par + un humain (par exemple pour sniffer le trafic réseau), le second ne + l'est pas. Voir la FAQ + officielle pour plus de détails.
    • +
  • h2 correspond à HTTP/2 sur TLS (négociation de + protocole via ALPN).
    • +
  • h2c correspond à HTTP/2 sur TCP.
    • +
  • Une frame ou trame est la plus petite unité de + communication au sein d'une connexion HTTP/2 et comporte une en-tête et + une séquence d'octets de longueur variable dont la structure correspond + au type de trame. Voir la section + correspondante de la documentation officielle pour plus de + détails.
    • +
  • Un stream est un flux bidirectionnel de frames au + sein d'une connexion HTTP/2. La notion correspondante dans HTTP/1 est un + échange de messages de type requête et réponse. Voir la section + correspondante de la documentation officielle pour plus de détails.
    • +
  • HTTP/2 peut gérer plusieurs streams de données sur + la même connexion TCP, ce qui permet d'éviter le point de blocage + classique de HTTP/1 pour les requêtes lentes, et de ne pas avoir à + ouvrir de nouvelles connexions TCP pour chaque requête/réponse (les + connexions persistantes ou KeepAlive avaient contourné le problème dans + HTTP/1 mais ne l'avaient pas entièrement résolu)
    • +
+
top
+
+

HTTP/2 dans Apache httpd

+ +

Le protocole HTTP/2 est implémenté dans Apache httpd via un module + propre, pertinemment nommé mod_http2. Ce + module implémente toutes les fonctionnalités décrites par la RFC 7540 et + supporte les connexions en texte pur (http:), ou sécurisées (https:). + La variante texte pur se nomme 'h2c', et la variante sécurisée + 'h2'. h2c peut être en mode direct ou + Upgrade: via une requête initiale en HTTP/1.

+

Server Push est une nouvelle fonctionnalité offerte + aux développeurs web par HTTP/2. La section correspondante de ce document + vous indiquera comment votre application peut en tirer parti.

+
top
+
+

Compilation de httpd avec le support de HTTP/2

+ +

mod_http2 se base sur la bibliothèque + de nghttp2 pour son implémentation. Pour + pouvoir compiler mod_http2, libnghttp2 version + 1.2.1. ou supérieure doit être installée dans votre système.

+

Pour déclencher la compilation de mod_http2, vous devez + ajouter l'argument '--enable-http2' au script + ./configure que vous exécutez à la racine de l'arborescence des + sources de httpd. Si libnghttp2 est installée dans un + répertoire non connu du chemin de vos bibliothèques, vous devez indiquer ce + répertoire au script ./configure via l'argument + '--with-nghttp2=<path>'.

+

Alors que cette méthode de compilation conviendra à la plupart, certains + préféreront lier statiquement nghttp2 à ce module. Pour ce + faire, utilisez l'argument --enable-nghttp2-staticlib-deps. + Cette méthode est pratiquement la même que celle utilisée pour lier + statiquement openssl à mod_ssl.

+

En parlant de SSL, vous devez savoir que la plupart des navigateurs ne + communiqueront en HTTP/2 que sur des URLs sécurisées de type + https: ; votre serveur doit donc supporter SSL. Mais de plus, + votre bibliothèque SSL devra supporter l'extension ALPN. Enfin, + si la bibliothèque que vous utilisez est OpenSSL, sa version devra être + 1.0.2. ou supérieure.

+
top
+
+

Configuration de base

+ + +

Maintenant que vous disposez d'un binaire httpd compilé avec le + module mod_http2, l'activation de ce dernier nécessite un + minimum de configuration supplémentaire. En premier lieu, comme pour tout + module Apache, vous devez le charger :

+ 
LoadModule http2_module modules/mod_http2.so
+ + +

La seconde directive que vous devez ajouter à votre fichier de + configuration est

+ 
Protocols h2 http/1.1
+ +

Ceci permet de définir h2, la variante sécurisée, comme le protocole + préféré pour les connexions à votre serveur. Si vous souhaitez que toutes les + variantes soient disponibles, utilisez la directive suivante :

+ 
Protocols h2 h2c http/1.1
+ +

Selon l'endroit où vous placez cette directive, elle affectera l'ensemble + de votre serveur, ou seulement un ou plusieurs serveurs virtuels. Vous + pouvez aussi l'imbriquer comme dans l'exemple suivant :

+ 
Protocols http/1.1
+<VirtualHost ...>
+    ServerName test.example.org
+    Protocols h2 http/1.1
+</VirtualHost>
+ + +

Seules les connexions en HTTP/1 seront alors permises, sauf pour le serveur + virtuel test.example.org qui acceptera aussi les connexions SSL + en HTTP/2.

+

Utilisez une chaîne d'algorithmes de chiffrement forte

+

La directive SSLCipherSuite doit + être définie avec une chaîne d'algorithmes de chiffrement TLS forte. Même si + la version actuelle de mod_http2 n'impose pas d'algorithmes de chiffrement + particuliers, la plupart des clients le font. Faire pointer un navigateur + vers un serveur où h2 est activé avec une chaîne d'algorithmes + de chiffrement inappropriée entraînera un rejet et une retrogradation vers + HTTP 1.1. C'est une erreur que l'on fait couramment lorsqu'on configure + httpd pour HTTP/2 pour la première fois ; donc gardez la à l'esprit si vous + voulez éviter de longues sessions de débogage ! Si vous voulez être sûr de + définir une chaîne d'algorithmes de chiffrement appropriée, évitez ceux qui + sont listés dans la blacklist TLS HTTP/2 + .

+
+

L'ordre des protocoles indiqués est aussi important. Par défaut, le + premier sera le protocole préféré. Lorsqu'un client offre plusieurs choix, + c'est le plus à gauche qui sera sélectionné. Dans

+ 
Protocols http/1.1 h2
+ +

le protocole préféré sera HTTP/1 et il sera toujours sélectionné sauf si + un client ne supporte que h2. Comme nous souhaitons communiquer en + HTTP/2 avec les clients qui le supportent, la meilleure définition de la + directive est

+ 
Protocols h2 h2c http/1.1
+ + +

Toujours à propos de l'ordre des protocoles, le client a lui aussi ses + propres préférences en la matière. À ce titre, si vous le souhaitez, vous + pouvez configurer votre serveur pour qu'il sélectionne non plus son + protocole préféré, mais au contraire le protocole préféré + du client :

+ 
ProtocolsHonorOrder Off
+ +

Avec cette directive, l'ordre des protocoles que vous avez + défini devient caduque et seul l'ordre défini par le client sera pris en + compte.

+

Une dernière chose : les protocoles que vous définissez ne sont pas + vérifiés quant à leurs validité ou orthographe. Vous pouvez très bien + définir des protocoles qui n'existent pas, et il n'est donc pas nécessaire + de filtrer le contenu de la directive Protocols avec des vérifications de type + <IfModule>.

+

Pour des conseils plus avancés à propos de la configuration, voir la Documentation de mod_http2, et en particulier + la section à propos de la consommation supplémentaire de + ressources, ainsi que la section expliquant comment gérer les serveurs multiples avec certificat + commun.

+
top
+
+

Configuration du MPM

+ + +

Tous les modules multiprocessus (MPM) fournis avec httpd supportent + HTTP/2. Cependant, si vous utilisez le MPM prefork, vous allez + faire face à de sévères restrictions.

+

Avec le MPM prefork, mod_http2 ne traitera + qu'une requête à la fois par connexion alors que les clients tels que les + navigateurs internet envoient de nombreuses requêtes au même moment. Si + l'une d'entre elles est longue à traiter (ou implique une longue + interrogation), les autres requêtes seront mises en attente.

+

Par défaut, mod_http2 ne passe pas outre cette limitation pour + la simple et bonne raison que le MPM prefork n'est aujourd'hui + choisi que si vous exécutez des moteurs de traitement qui ne sont pas préparés + pour le multithreading (par exemple qui se crashent lorsque plusieurs + requêtes arrivent).

+

Si votre plateforme et votre installation de httpd le supportent, la + meilleur solution consiste actuellement à utiliser le MPM + event. +

+

Si vous n'avez pas d'autre choix que d'utiliser le MPM + prefork, mais souhaitez tout de même traiter plusieurs requêtes + simultanément, vous pouvez jouer avec la directive H2MinWorkers, sans garantie que cela + fonctionne.

+
top
+
+

Clients

+ +

La plupart des navigateurs modernes supportent HTTP/2, mais seulement sur + des connexions SSL : Firefox v43, Chrome v45, Safari v9, iOS Safari v9, + Opera v35, Chrome pour Android v49 et + Internet Explorer v11 sous Windows10 (selon cette source).

+

D'autres clients et serveurs sont listés dans le wiki des + implémentations ; entre autres des implémentations pour c, c++, common + lisp, dart, erlang, haskell, java, nodejs, php, python, perl, ruby, rust, + scala et swift.

+

De nombreuses implémentations clientes autres que les navigateurs + supportent HTTP/2 en texte pur, h2c. L'une des plus efficaces d'entre elles + est curl.

+
top
+
+

Outils efficaces pour déboguer HTTP/2

+ +

Le premier d'entre eux est bien entendu curl. Assurez-vous au préalable que votre + version supporte HTTP/2 en vérifiant ses Fonctionnalités :

+ 
    $ curl -V
+    curl 7.45.0 (x86_64-apple-darwin15.0.0) libcurl/7.45.0 OpenSSL/1.0.2d zlib/1.2.8 nghttp2/1.3.4
+    Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 [...]
+    Features: IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP HTTP2
+
+ +

homebrew sous Mac OS :

+ brew install curl --with-openssl --with-nghttp2 +
+

Pour une inspection en profondeur : wireshark.

+

Le paquet nghttp2 inclut aussi des + outils comme :

+
    +
  • nghttp + - permet de visualiser les trames HTTP/2 et ainsi de se faire une meilleure + idée du protocole.
    • +
  • h2load - + permet de tester votre serveur dans des conditions extremes.
    • +
+

Chrome fournit des journaux détaillés des connexions HTTP/2 via la page + special net-internals page. Il y + a aussi cette extension intéressante pour Chrome + et Firefox + qui permet d'indiquer que votre navigateur utilise HTTP/2.

+
top
+
+

Push serveur

+ +

Le protocole HTTP/2 permet au serveur de proposer (PUSH) des réponses + pour lesquelles le client n'a rien demandé. La communication autour de ces + réponses est du style : "voici une requête que vous n'avez jamais + envoyée, et la réponse vous parviendra bientôt tout de même ..."

+

Il y a cependant des conditions : le client peut désactiver cette + fonctionnalité et le serveur ne pourra alors lui proposer des réponses que + pour les requêtes qu'il a effectivement envoyées.

+

Cette fonctionnalité a pour but de permettre au serveur d'envoyer au + client des ressources dont il va probablement avoir besoin : par exemple une + ressource css ou javascript appartenant à une page html que le client a + demandée, un jeu d'images référencé par un css, etc...

+

Cette anticipation a pour avantage de permettre au client d'économiser le + temps qu'il lui aurait fallu pour envoyer une requête, quelques + millisecondes à une demi-seconde en fonction de l'éloignement du serveur. + Elle a cependant pour inconvénient d'imposer au client le téléchargement de + ressources qu'il possède peut-être déjà dans son cache. Bien entendu, HTTP/2 + permet d'annuler prématurément de telles requêtes, mais des ressources sont + tout de même gaspillées.

+

En résumé : il n'existe pas encore de stratégie efficace pour faire le + meilleur usage de cette fonctionnalité de HTTP/2 et tout le monde en est + encore au stade de l'expérimentation. À ce titre, voici des conseils pour + procéder vous-même à ces expérimentations :

+

mod_http2 inspecte l'en-tête de la réponse et recherche les + en-têtes Link sous un certain format :

+ 
Link </xxx.css>;rel=preload, </xxx.js>; rel=preload
+ +

Si la connexion supporte PUSH, ces deux ressources seront envoyées au + client. En tant que développeur web vous pouvez définir ces en-têtes soit + directement au niveau de la réponse de votre application, soit en + configurant votre serveur via

+ 
<Location /xxx.html>
+    Header add Link "</xxx.css>;rel=preload"
+    Header add Link "</xxx.js>;rel=preload"
+</Location>
+ +

Si vous souhaitez utiliser des liens preload sans déclencher + de PUSH, vous pouvez utiliser le paramètre nopush comme suit :

+ 
Link </xxx.css>;rel=preload;nopush
+ +

Vous pouvez aussi désactiver les PUSHes pour l'ensemble de votre + serveur via la directive

+ 
H2Push Off
+ +

À savoir aussi :

+

Le module maintient un journal des ressources ayant fait l'objet d'un + PUSH pour chaque connexion (en général des condensés hash des URLs), et + n'effectuera pas deux fois un PUSH pour la même ressource. Cependant, + lorsque la connexion est fermée, le journal de ses PUSHes est supprimé.

+

Certains développeurs planchent sur la manière de permettre au client + d'informer le serveur des ressources qu'il possède déjà dans son cache afin + d'éviter les PUSHes pour ces dernières, mais ceci n'en est actuellement qu'à + un stade très expérimental.

+

L' + en-tête Accept-Push-Policy est un autre dispositif expérimental + implémenté dans mod_http2 ; il permet au client de définir pour + chaque requête quels genres de PUSHes il accepte.

+ + +

+ La fonctionnalité PUSH n'apportera pas toujours le gain de performances dans + l'obtention de réponses aux requêtes. Vous trouverez plusieurs études sur ce + sujet sur internet qui en expliquent les avantages et inconvénients et + comment les particularités des clients et du réseau en influencent le + fonctionnement. Par exemple, le seul fait que le serveur PUSHes une + ressource n'implique pas forcément que le navigateur l'utilisera.

+

Ce qui influence le plus la réponse PUSHed, c'est la requête qui a été + simulée. En effet, l'URL de la requête pour un PUSH est fournie par + l'application, mais d'où viennent les en-têtes ? Par exemple, La requête + PUSH requiert-elle un en-tête accept-language et si oui, quelle + sera sa valeur ?

+

httpd va consulter la requête originale (celle qui a déclenché le PUSH) + et copier les en-têtes suivants vers la requête PUSH : + user-agent, accept, accept-encoding, + accept-language et cache-control.

+

Tous les autres en-têtes sont ignorés. Les cookies eux non plus ne seront + pas copiés. PUSHer des ressources qui requièrent la présence d'un cookie ne + fonctionnera pas. Ceci peut être sujet à débat, mais tant que ce ne sera pas + clairement discuté avec les navigateurs, restons prudents et évitons + d'exposer les cookies là où ils ne sont pas censés être visibles.

+
top
+
+

Suggestions précoces

+ +

A l'instar des ressources PUSHées, une autre méthode consiste à envoyer + des en-têtes Link au client avant même que la réponse ne soit + prête. Cette méthode utilise la fonctionnalité appelée "Suggestions + précoces" (Early Hints) décrite dans la RFC 8297.

+

Pour utiliser cette fonctionnalité, vous devez l'activer explicitement + sur le serveur via :

+ 
H2EarlyHints on
+ +

Elle n'est en effet pas activée par défaut car certains navigateurs + anciens perdent pied avec de telles réponses.

+

Une fois cette fonctionnalité activée, vous pouvez utiliser la directive + H2PushResource pour déclencher les + suggestions précoces et les PUSHes de ressources :

+ 
<Location /xxx.html>
+    H2PushResource /xxx.css
+    H2PushResource /xxx.js
+</Location>
+ +

Le serveur enverra alors au client une réponse "103 Early + Hints" dès qu'il commencera à traiter la requête. Selon + votre application web, cet envoi peut intervenir beaucoup plus tôt que le + moment où les premiers en-têtes de réponse auront été déterminés.

+

Si H2Push est activé, ceci + déclenchera aussi le PUSH juste après la réponse 103. Mais si H2Push n'est pas activé, la réponse 103 sera + quand-même envoyée au client.

+
+
+

Langues Disponibles:  en  | + es  | + fr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/index.html b/docs/manual/howto/index.html index cf3f7a73a3..fcbe46d6c6 100644 --- a/docs/manual/howto/index.html +++ b/docs/manual/howto/index.html @@ -6,7 +6,7 @@ Content-type: text/html; charset=ISO-8859-1 URI: index.html.es Content-Language: es -Content-type: text/html; charset=ISO-8859-1 +Content-type: text/html; charset=UTF-8 URI: index.html.fr Content-Language: fr diff --git a/docs/manual/howto/index.html.en b/docs/manual/howto/index.html.en index 9e74760fd8..870ebb297f 100644 --- a/docs/manual/howto/index.html.en +++ b/docs/manual/howto/index.html.en @@ -24,8 +24,8 @@ Apache > HTTP Server > Documentation > Version 2.5

How-To / Tutorials

Available Languages:  en  | - es  | - fr  | + es  | + fr  |  ja  |  ko  |  zh-cn 

@@ -155,8 +155,8 @@

Available Languages:  en  | - es  | - fr  | + es  | + fr  |  ja  |  ko  |  zh-cn 

diff --git a/docs/manual/howto/index.html.es b/docs/manual/howto/index.html.es deleted file mode 100644 index 20f067508e..0000000000 --- a/docs/manual/howto/index.html.es +++ /dev/null @@ -1,174 +0,0 @@ - - - - - -How-To / Tutoriales - Servidor HTTP Apache Versin 2.5 - - - - - - -
-

Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

-

Versin 2.5 del Servidor HTTP Apache

-
-
<-
-

How-To / Tutoriales

-
-

Idiomas disponibles:  en  | - es  | - fr  | - ja  | - ko  | - zh-cn 

-
-
-
top
-
-

How-To / Tutoriales

- - - -
-
Autenticacin y Autorizacin
-
-

Autenticacin es un proceso en el cual se verifica - que alguien es quien afirma ser. Autorizacin es cualquier - proceso en el que se permite a alguien acceder donde quiere ir, - o a obtener la informacin que desea tener.

- -

Ver: Autenticacin, Autorizacin

-
-
- -
-
Control de Acceso
-
-

Control de acceso hace referencia al proceso de restringir, o - garantizar el acceso a un recurso en base a un criterio arbitrario. - Esto se puede conseguir de distintas formas.

- -

Ver: Control de Acceso

-
-
- -
-
Contenido Dinmico con CGI
-
-

El CGI (Common Gateway Interface) es un mtodo por el cual - un servidor web puede interactuar con programas externos de - generacin de contenido, a ellos nos referimos comnmente como - programas CGI o scripts CGI. Es un mtodo sencillo para mostrar - contenido dinmico en tu sitio web. Este documento es una - introduccin para configurar CGI en tu servidor web Apache, y de - inicio para escribir programas CGI.

- -

Ver: CGI: Contenido Dinmico

-
-
- -
-
Ficheros .htaccess
-
-

Los ficheros .htaccess facilitan una forma de - hacer configuraciones por-directorio. Un archivo, que - contiene una o ms directivas de configuracin, se coloca en un - directorio especfico y las directivas especificadas solo aplican - sobre ese directorio y los subdirectorios del mismo.

- -

Ver: .htaccess files

-
-
- -
-
HTTP/2 con httpd
-
-

HTTP/2 es la evolucin del protocolo de capa de aplicacin ms conocido, HTTP. - Se centra en hacer un uso ms eficiente de los recursos de red sin cambiar la - semntica de HTTP. Esta gua explica como se implementa HTTP/2 en httpd, - mostrando buenas prcticas y consejos de configuracin bsica. -

- -

Ver: Gua HTTP/2

-
-
- - -
-
Introduccin a los SSI
-
-

Los SSI (Server Side Includes) son directivas que se colocan - en las pginas HTML, y son evaluadas por el servidor mientras - ste las sirve. Le permiten aadir contenido generado - dinmicamente a una pgina HTML existente, sin tener que servir - la pgina entera a travs de un programa CGI u otro mtodo - dinmico.

- -

Ver: Server Side Includes (SSI)

-
-
- -
-
Directorios web Por-usuario
-
-

En sistemas con mltiples usuarios, cada usuario puede tener - su directorio "home" compartido usando la directiva - UserDir. Aquellos - que visiten la URL http://example.com/~username/ - obtendrn contenido del directorio del usuario "username" - que se encuentra en el directorio "home" del sistema.

- -

Ver: - Directorios Web de Usuario (public_html)

-
-
- -
-
Gua de Proxy Inverso
-
-

Apache httpd ofrece muchas posibilidades como proxy inverso. Usando la - directiva ProxyPass as como - BalancerMember puede crear - sofisticadas configuraciones de proxy inverso que proveen de alta - disponibilidad, balanceo de carga, clustering basado en la nube y - reconfiguracin dinmica en caliente.

- -

Ver: Gua de Proxy Inverso

-
-
- -
-
Reescritura de URLS utilizando mod_rewrite
-
-

Reescribir URLs (o no) con - mod_rewrite suele ser algo que se pregunta mucho en nuestras lista - de correo y canales IRC. Le hemos dedicado a este tema - una seccin entera en nuestra documentacin de recetas y "how-tos". -

-
-
- -
-
-

Idiomas disponibles:  en  | - es  | - fr  | - ja  | - ko  | - zh-cn 

-
- \ No newline at end of file diff --git a/docs/manual/howto/index.html.es.utf8 b/docs/manual/howto/index.html.es.utf8 new file mode 100644 index 0000000000..20f067508e --- /dev/null +++ b/docs/manual/howto/index.html.es.utf8 @@ -0,0 +1,174 @@ + + + + + +How-To / Tutoriales - Servidor HTTP Apache Versin 2.5 + + + + + + +
+

Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

+

Versin 2.5 del Servidor HTTP Apache

+
+
<-
+

How-To / Tutoriales

+
+

Idiomas disponibles:  en  | + es  | + fr  | + ja  | + ko  | + zh-cn 

+
+
+
top
+
+

How-To / Tutoriales

+ + + +
+
Autenticacin y Autorizacin
+
+

Autenticacin es un proceso en el cual se verifica + que alguien es quien afirma ser. Autorizacin es cualquier + proceso en el que se permite a alguien acceder donde quiere ir, + o a obtener la informacin que desea tener.

+ +

Ver: Autenticacin, Autorizacin

+
+
+ +
+
Control de Acceso
+
+

Control de acceso hace referencia al proceso de restringir, o + garantizar el acceso a un recurso en base a un criterio arbitrario. + Esto se puede conseguir de distintas formas.

+ +

Ver: Control de Acceso

+
+
+ +
+
Contenido Dinmico con CGI
+
+

El CGI (Common Gateway Interface) es un mtodo por el cual + un servidor web puede interactuar con programas externos de + generacin de contenido, a ellos nos referimos comnmente como + programas CGI o scripts CGI. Es un mtodo sencillo para mostrar + contenido dinmico en tu sitio web. Este documento es una + introduccin para configurar CGI en tu servidor web Apache, y de + inicio para escribir programas CGI.

+ +

Ver: CGI: Contenido Dinmico

+
+
+ +
+
Ficheros .htaccess
+
+

Los ficheros .htaccess facilitan una forma de + hacer configuraciones por-directorio. Un archivo, que + contiene una o ms directivas de configuracin, se coloca en un + directorio especfico y las directivas especificadas solo aplican + sobre ese directorio y los subdirectorios del mismo.

+ +

Ver: .htaccess files

+
+
+ +
+
HTTP/2 con httpd
+
+

HTTP/2 es la evolucin del protocolo de capa de aplicacin ms conocido, HTTP. + Se centra en hacer un uso ms eficiente de los recursos de red sin cambiar la + semntica de HTTP. Esta gua explica como se implementa HTTP/2 en httpd, + mostrando buenas prcticas y consejos de configuracin bsica. +

+ +

Ver: Gua HTTP/2

+
+
+ + +
+
Introduccin a los SSI
+
+

Los SSI (Server Side Includes) son directivas que se colocan + en las pginas HTML, y son evaluadas por el servidor mientras + ste las sirve. Le permiten aadir contenido generado + dinmicamente a una pgina HTML existente, sin tener que servir + la pgina entera a travs de un programa CGI u otro mtodo + dinmico.

+ +

Ver: Server Side Includes (SSI)

+
+
+ +
+
Directorios web Por-usuario
+
+

En sistemas con mltiples usuarios, cada usuario puede tener + su directorio "home" compartido usando la directiva + UserDir. Aquellos + que visiten la URL http://example.com/~username/ + obtendrn contenido del directorio del usuario "username" + que se encuentra en el directorio "home" del sistema.

+ +

Ver: + Directorios Web de Usuario (public_html)

+
+
+ +
+
Gua de Proxy Inverso
+
+

Apache httpd ofrece muchas posibilidades como proxy inverso. Usando la + directiva ProxyPass as como + BalancerMember puede crear + sofisticadas configuraciones de proxy inverso que proveen de alta + disponibilidad, balanceo de carga, clustering basado en la nube y + reconfiguracin dinmica en caliente.

+ +

Ver: Gua de Proxy Inverso

+
+
+ +
+
Reescritura de URLS utilizando mod_rewrite
+
+

Reescribir URLs (o no) con + mod_rewrite suele ser algo que se pregunta mucho en nuestras lista + de correo y canales IRC. Le hemos dedicado a este tema + una seccin entera en nuestra documentacin de recetas y "how-tos". +

+
+
+ +
+
+

Idiomas disponibles:  en  | + es  | + fr  | + ja  | + ko  | + zh-cn 

+
+ \ No newline at end of file diff --git a/docs/manual/howto/index.html.fr b/docs/manual/howto/index.html.fr deleted file mode 100644 index 19f761e14c..0000000000 --- a/docs/manual/howto/index.html.fr +++ /dev/null @@ -1,180 +0,0 @@ - - - - - -How-To / Tutoriels - Serveur HTTP Apache Version 2.5 - - - - - - -
-

Modules | Directives | FAQ | Glossaire | Plan du site

-

Serveur HTTP Apache Version 2.5

-
-
<-
-

How-To / Tutoriels

-
-

Langues Disponibles:  en  | - es  | - fr  | - ja  | - ko  | - zh-cn 

-
-
-
top
-
-

How-To / Tutoriels

- - - -
-
Authentification et autorisation
-
-

L'authentification représente tout processus par lequel vous - vérifiez si quelqu'un correspond bien à l'identité qu'il - déclare posséder. L'autorisation représente tout processus - permettant de savoir si une personne est autorisée à aller là où - elle veut aller, ou à obtenir les informations qu'elle demande.

- -

Voir Authentification, Autorisation

-
-
- -
-
Contrôle d'accès
-
-

Le contrôle d'accès se réfère au processus permettant - d'interdire ou d'accorder l'accès à une ressource en fonction de - certains critères, et il existe de nombreuses façons d'y - parvenir.

- -

Voir Contrôle d'accès

-
-
- -
-
Contenu dynamique avec CGI
-
-

L'Interface Passerelle Commune CGI (Common Gateway Interface) - définit pour le serveur web une méthode d'interaction avec des - programmes externes générateurs de contenu, souvent nommés - programmes CGI ou scripts CGI. Il s'agit d'une méthode - simple permettant d'ajouter du contenu - dynamique à votre site web. Ce document se veut une introduction - à la configuration de CGI sur votre serveur web Apache et à - l'écriture de programmes CGI.

- -

Voir CGI : contenu dynamique

-
-
- -
-
Fichiers .htaccess
-
-

Les fichiers .htaccess permettent de modifier la - configuration du serveur au niveau de chaque répertoire. À cet - effet, un fichier est placé dans un répertoire particulier du site - web, et les directives de configuration qu'il contient s'appliquent à ce - répertoire et à tous ses sous-répertoires.

- -

Voir Fichiers .htaccess

-
-
- -
-
HTTP/2 avec httpd
-
-

HTTP/2 est une évolution du protocole de la couche application le plus - connu au monde, HTTP. Les efforts se sont concentrés sur une amélioration - de l'efficacité de l'utilisation des ressources réseau sans modifier la - sémantique de HTTP. Ce guide explique la manière dont HTTP/2 est - implémenté dans httpd, donne des conseils pour une configuration de base - ainsi qu'une liste de recommandations. -

- -

Voir le guide HTTP/2

-
-
- - -
-
Introduction au Inclusions côté Serveur (Server Side Includes - ou SSI)
-
-

Les SSI sont des directives que l'on place dans des pages - HTML, et qui sont évaluées par le serveur lorsque ces pages sont - servies. Elles vous permettent d'ajouter du contenu généré - dynamiquement à une page HTML existante, sans avoir à servir - l'intégralité de la page via un programme CGI, ou toute autre - technologie dynamique.

- -

Voir Server Side Includes (SSI)

-
-
- -
-
Répertoires web de l'utilisateur
-
-

Sur les systèmes multi-utilisateurs, vous pouvez laisser - chaque utilisateur disposer d'un site web dans son répertoire home - via la directive UserDir. Les visiteurs de l'URL - http://example.com/~nom-utilisateur/ vont recevoir - du contenu situé dans le répertoire home de l'utilisateur - "nom-utilisateur", et dans le sous-répertoire - spécifié par la directive UserDir.

- -

Voir Répertoires web des utilisateurs (public_html)

-
-
- -
-
Mandataires inverses
-
-

Apache httpd possède des fonctionnalités évoluées de serveur - mandataire inverse via ses directives ProxyPass et BalancerMember qui permettent - d'implémenter un système de mandataire inverse sophistiqué garantissant - une haute disponibilité, une répartition et une réattribution de charge, - un regroupement de serveurs en grappe (clustering) basé sur le cloud et - une reconfiguration dynamique à la volée.

- -

Voir le Guide de configuration des - mandataires inverses

-
-
- -
-
Réécriture d'URLs avec mod_rewrite
-
-

La réécriture d'URLs avec (ou sans) mod_rewrite devient - l'une des questions les plus fréquentes posées dans nos listes de - diffusion et nos canaux IRC. C'est pourquoi nous avons dédié une section entière de notre documentation à des - howtos et recettes sur ce sujet.

-
-
- -
-
-

Langues Disponibles:  en  | - es  | - fr  | - ja  | - ko  | - zh-cn 

-
- \ No newline at end of file diff --git a/docs/manual/howto/index.html.fr.utf8 b/docs/manual/howto/index.html.fr.utf8 new file mode 100644 index 0000000000..19f761e14c --- /dev/null +++ b/docs/manual/howto/index.html.fr.utf8 @@ -0,0 +1,180 @@ + + + + + +How-To / Tutoriels - Serveur HTTP Apache Version 2.5 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.5

+
+
<-
+

How-To / Tutoriels

+
+

Langues Disponibles:  en  | + es  | + fr  | + ja  | + ko  | + zh-cn 

+
+
+
top
+
+

How-To / Tutoriels

+ + + +
+
Authentification et autorisation
+
+

L'authentification représente tout processus par lequel vous + vérifiez si quelqu'un correspond bien à l'identité qu'il + déclare posséder. L'autorisation représente tout processus + permettant de savoir si une personne est autorisée à aller là où + elle veut aller, ou à obtenir les informations qu'elle demande.

+ +

Voir Authentification, Autorisation

+
+
+ +
+
Contrôle d'accès
+
+

Le contrôle d'accès se réfère au processus permettant + d'interdire ou d'accorder l'accès à une ressource en fonction de + certains critères, et il existe de nombreuses façons d'y + parvenir.

+ +

Voir Contrôle d'accès

+
+
+ +
+
Contenu dynamique avec CGI
+
+

L'Interface Passerelle Commune CGI (Common Gateway Interface) + définit pour le serveur web une méthode d'interaction avec des + programmes externes générateurs de contenu, souvent nommés + programmes CGI ou scripts CGI. Il s'agit d'une méthode + simple permettant d'ajouter du contenu + dynamique à votre site web. Ce document se veut une introduction + à la configuration de CGI sur votre serveur web Apache et à + l'écriture de programmes CGI.

+ +

Voir CGI : contenu dynamique

+
+
+ +
+
Fichiers .htaccess
+
+

Les fichiers .htaccess permettent de modifier la + configuration du serveur au niveau de chaque répertoire. À cet + effet, un fichier est placé dans un répertoire particulier du site + web, et les directives de configuration qu'il contient s'appliquent à ce + répertoire et à tous ses sous-répertoires.

+ +

Voir Fichiers .htaccess

+
+
+ +
+
HTTP/2 avec httpd
+
+

HTTP/2 est une évolution du protocole de la couche application le plus + connu au monde, HTTP. Les efforts se sont concentrés sur une amélioration + de l'efficacité de l'utilisation des ressources réseau sans modifier la + sémantique de HTTP. Ce guide explique la manière dont HTTP/2 est + implémenté dans httpd, donne des conseils pour une configuration de base + ainsi qu'une liste de recommandations. +

+ +

Voir le guide HTTP/2

+
+
+ + +
+
Introduction au Inclusions côté Serveur (Server Side Includes + ou SSI)
+
+

Les SSI sont des directives que l'on place dans des pages + HTML, et qui sont évaluées par le serveur lorsque ces pages sont + servies. Elles vous permettent d'ajouter du contenu généré + dynamiquement à une page HTML existante, sans avoir à servir + l'intégralité de la page via un programme CGI, ou toute autre + technologie dynamique.

+ +

Voir Server Side Includes (SSI)

+
+
+ +
+
Répertoires web de l'utilisateur
+
+

Sur les systèmes multi-utilisateurs, vous pouvez laisser + chaque utilisateur disposer d'un site web dans son répertoire home + via la directive UserDir. Les visiteurs de l'URL + http://example.com/~nom-utilisateur/ vont recevoir + du contenu situé dans le répertoire home de l'utilisateur + "nom-utilisateur", et dans le sous-répertoire + spécifié par la directive UserDir.

+ +

Voir Répertoires web des utilisateurs (public_html)

+
+
+ +
+
Mandataires inverses
+
+

Apache httpd possède des fonctionnalités évoluées de serveur + mandataire inverse via ses directives ProxyPass et BalancerMember qui permettent + d'implémenter un système de mandataire inverse sophistiqué garantissant + une haute disponibilité, une répartition et une réattribution de charge, + un regroupement de serveurs en grappe (clustering) basé sur le cloud et + une reconfiguration dynamique à la volée.

+ +

Voir le Guide de configuration des + mandataires inverses

+
+
+ +
+
Réécriture d'URLs avec mod_rewrite
+
+

La réécriture d'URLs avec (ou sans) mod_rewrite devient + l'une des questions les plus fréquentes posées dans nos listes de + diffusion et nos canaux IRC. C'est pourquoi nous avons dédié une section entière de notre documentation à des + howtos et recettes sur ce sujet.

+
+
+ +
+
+

Langues Disponibles:  en  | + es  | + fr  | + ja  | + ko  | + zh-cn 

+
+ \ No newline at end of file diff --git a/docs/manual/howto/public_html.html b/docs/manual/howto/public_html.html index bf86808d5e..999552ee41 100644 --- a/docs/manual/howto/public_html.html +++ b/docs/manual/howto/public_html.html @@ -6,7 +6,7 @@ Content-type: text/html; charset=ISO-8859-1 URI: public_html.html.es Content-Language: es -Content-type: text/html; charset=ISO-8859-1 +Content-type: text/html; charset=UTF-8 URI: public_html.html.fr Content-Language: fr diff --git a/docs/manual/howto/public_html.html.en b/docs/manual/howto/public_html.html.en index 5b4a62d10c..fdd2c7cad8 100644 --- a/docs/manual/howto/public_html.html.en +++ b/docs/manual/howto/public_html.html.en @@ -24,11 +24,11 @@ Apache > HTTP Server > Documentation > Version 2.5 > How-To / Tutorials

Per-user web directories

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

+ tr 

On systems with multiple users, each user can be permitted to have a @@ -186,11 +186,11 @@ UserDir enabled rbowen krietz

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

+ tr 

top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
- - -
-

Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

-

Versin 2.5 del Servidor HTTP Apache

-
-
<-
-

Directorios web por usuario

-
-

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

-
- -

En sistemas con mltiples usuarios, cada usuario puede tener un website - en su directorio home usando la directiva UserDir. Los visitantes de una URL - http://example.com/~username/ recibirn el contenido del - directorio home del usuario "username", en el subdirectorio - especificado por la directiva UserDir.

- -

Tenga en cuenta que, por defecto, el acceso a estos directorios - NO est activado. Puede permitir acceso cuando usa - UserDir quitando el comentario de la lnea:

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

En el fichero por defecto de configuracin conf/httpd.conf, - y adaptando el fichero httpd-userdir.conf segn sea necesario, - o incluyendo las directivas apropiadas en un bloque - <Directory> dentro del fichero - principal de configuracin.

-
- -
top
-
-

Directorios web por usuario

- -
Mdulos RelacionadosDirectivas Relacionadas
-
top
-
-

Configurando la ruta del fichero con UserDir

- - -

La directiva UserDir - especifica un directorio del que cargar contenido por usuario. Esta directiva - puede tener muchas formas distintas.

- -

Si se especifica una ruta que no empieza con una barra ("/"), se asume que - va a ser una ruta de directorio relativa al directorio home del usuario - especificado. Dada sta configuracin:

- - 
UserDir public_html
- - -

La URL http://example.com/~rbowen/file.html se traducir en - la ruta del fichero /home/rbowen/public_html/file.html

- -

Si la ruta que se especifica comienza con una barra ("/"), la ruta del - directorio se construir usando esa ruta, ms el usuario especificado en la - configuracin:

- - 
UserDir /var/html
- - -

La URL http://example.com/~rbowen/file.html se traducir en - la ruta del fichero /var/html/rbowen/file.html

- -

Si se especifica una ruta que contiene un asterisco (*), se usar una ruta - en la que el asterisco se reemplaza con el nombre de usuario. Dada sta configuracin:

- - 
UserDir /var/www/*/docs
- - -

La URL http://example.com/~rbowen/file.html se traducir en - la ruta del fichero /var/www/rbowen/docs/file.html

- -

Tambin se pueden configurar mltiples directorios o rutas de directorios.

- - 
UserDir public_html /var/html
- - -

Para la URL http://example.com/~rbowen/file.html, - Apache buscar ~rbowen. Si no lo encuentra, Apache buscar - rbowen en /var/html. Si lo encuentra, la URL de ms - arriba se traducir en la ruta del fichero - /var/html/rbowen/file.html

- -
top
-
-

Redirigiendo a URLs externas

- -

La directiva UserDir puede - usarse para redirigir solcitudes de directorios de usuario a URLs externas.

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

El ejemplo de aqu arriba redirigir una solicitud para - http://example.com/~bob/abc.html hacia - http://example.org/users/bob/abc.html.

-
top
-
-

Restringiendo qu usuarios pueden usar esta caracterstica

- - -

Usando la sintaxis que se muestra en la documentacin de UserDir, usted - puede restringir a qu usuarios se les permite usar esta funcionalidad:

- - 
UserDir disabled root jro fish
- - -

La configuracin de aqu arriba permitir a todos los usuarios excepto a - los que se listan con la declaracin disabled. Usted puede, - del mismo modo, deshabilitar esta caracterstica para todos excepto algunos - usuarios usando una configuracin como la siguiente:

- - 
UserDir disabled
-UserDir enabled rbowen krietz
- - -

Vea la documentacin de UserDir para ms - ejemplos.

- -
top
-
-

Activando un directorio cgi para cada usuario

- - -

Para dar a cada usuario su propio directorio cgi-bin, puede usar una directiva - <Directory> - para activar cgi en un subdirectorio en particular del directorio home del usuario.

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

Entonces, asumiendo que UserDir est configurado con la - declaracin public_html, un programa cgi example.cgi - podra cargarse de ese directorio as:

- -

- http://example.com/~rbowen/cgi-bin/example.cgi -

- -
top
-
-

Permitiendo a usuarios cambiar la configuracin

- - -

Si quiere permitir que usuarios modifiquen la configuracin del servidor en - su espacio web, necesitarn usar ficheros .htaccess para hacer - estos cambios. Asegrese de tener configurado AllowOverride con un valor suficiente que permita a - los usuarios modificar las directivas que quiera permitir. - Vea el tutorial de .htaccess para obtener detalles adicionales sobre cmo funciona.

- -
-
-

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

-
top

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
-
- \ No newline at end of file diff --git a/docs/manual/howto/public_html.html.es.utf8 b/docs/manual/howto/public_html.html.es.utf8 new file mode 100644 index 0000000000..8f616f33c3 --- /dev/null +++ b/docs/manual/howto/public_html.html.es.utf8 @@ -0,0 +1,216 @@ + + + + + +Directorios web por usuario - Servidor HTTP Apache Versin 2.5 + + + + + + +
+

Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

+

Versin 2.5 del Servidor HTTP Apache

+
+
<-
+

Directorios web por usuario

+
+

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

+
+ +

En sistemas con mltiples usuarios, cada usuario puede tener un website + en su directorio home usando la directiva UserDir. Los visitantes de una URL + http://example.com/~username/ recibirn el contenido del + directorio home del usuario "username", en el subdirectorio + especificado por la directiva UserDir.

+ +

Tenga en cuenta que, por defecto, el acceso a estos directorios + NO est activado. Puede permitir acceso cuando usa + UserDir quitando el comentario de la lnea:

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

En el fichero por defecto de configuracin conf/httpd.conf, + y adaptando el fichero httpd-userdir.conf segn sea necesario, + o incluyendo las directivas apropiadas en un bloque + <Directory> dentro del fichero + principal de configuracin.

+
+ +
top
+
+

Directorios web por usuario

+ +
Mdulos RelacionadosDirectivas Relacionadas
+
top
+
+

Configurando la ruta del fichero con UserDir

+ + +

La directiva UserDir + especifica un directorio del que cargar contenido por usuario. Esta directiva + puede tener muchas formas distintas.

+ +

Si se especifica una ruta que no empieza con una barra ("/"), se asume que + va a ser una ruta de directorio relativa al directorio home del usuario + especificado. Dada sta configuracin:

+ + 
UserDir public_html
+ + +

La URL http://example.com/~rbowen/file.html se traducir en + la ruta del fichero /home/rbowen/public_html/file.html

+ +

Si la ruta que se especifica comienza con una barra ("/"), la ruta del + directorio se construir usando esa ruta, ms el usuario especificado en la + configuracin:

+ + 
UserDir /var/html
+ + +

La URL http://example.com/~rbowen/file.html se traducir en + la ruta del fichero /var/html/rbowen/file.html

+ +

Si se especifica una ruta que contiene un asterisco (*), se usar una ruta + en la que el asterisco se reemplaza con el nombre de usuario. Dada sta configuracin:

+ + 
UserDir /var/www/*/docs
+ + +

La URL http://example.com/~rbowen/file.html se traducir en + la ruta del fichero /var/www/rbowen/docs/file.html

+ +

Tambin se pueden configurar mltiples directorios o rutas de directorios.

+ + 
UserDir public_html /var/html
+ + +

Para la URL http://example.com/~rbowen/file.html, + Apache buscar ~rbowen. Si no lo encuentra, Apache buscar + rbowen en /var/html. Si lo encuentra, la URL de ms + arriba se traducir en la ruta del fichero + /var/html/rbowen/file.html

+ +
top
+
+

Redirigiendo a URLs externas

+ +

La directiva UserDir puede + usarse para redirigir solcitudes de directorios de usuario a URLs externas.

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

El ejemplo de aqu arriba redirigir una solicitud para + http://example.com/~bob/abc.html hacia + http://example.org/users/bob/abc.html.

+
top
+
+

Restringiendo qu usuarios pueden usar esta caracterstica

+ + +

Usando la sintaxis que se muestra en la documentacin de UserDir, usted + puede restringir a qu usuarios se les permite usar esta funcionalidad:

+ + 
UserDir disabled root jro fish
+ + +

La configuracin de aqu arriba permitir a todos los usuarios excepto a + los que se listan con la declaracin disabled. Usted puede, + del mismo modo, deshabilitar esta caracterstica para todos excepto algunos + usuarios usando una configuracin como la siguiente:

+ + 
UserDir disabled
+UserDir enabled rbowen krietz
+ + +

Vea la documentacin de UserDir para ms + ejemplos.

+ +
top
+
+

Activando un directorio cgi para cada usuario

+ + +

Para dar a cada usuario su propio directorio cgi-bin, puede usar una directiva + <Directory> + para activar cgi en un subdirectorio en particular del directorio home del usuario.

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

Entonces, asumiendo que UserDir est configurado con la + declaracin public_html, un programa cgi example.cgi + podra cargarse de ese directorio as:

+ +

+ http://example.com/~rbowen/cgi-bin/example.cgi +

+ +
top
+
+

Permitiendo a usuarios cambiar la configuracin

+ + +

Si quiere permitir que usuarios modifiquen la configuracin del servidor en + su espacio web, necesitarn usar ficheros .htaccess para hacer + estos cambios. Asegrese de tener configurado AllowOverride con un valor suficiente que permita a + los usuarios modificar las directivas que quiera permitir. + Vea el tutorial de .htaccess para obtener detalles adicionales sobre cmo funciona.

+ +
+
+

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

+
top

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/public_html.html.fr b/docs/manual/howto/public_html.html.fr deleted file mode 100644 index 671be7154c..0000000000 --- a/docs/manual/howto/public_html.html.fr +++ /dev/null @@ -1,235 +0,0 @@ - - - - - -Répertoires web utilisateurs - Serveur HTTP Apache Version 2.5 - - - - - - -
-

Modules | Directives | FAQ | Glossaire | Plan du site

-

Serveur HTTP Apache Version 2.5

-
-
<-
-

Répertoires web utilisateurs

-
-

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

-
- -

Sur les systèmes multi-utilisateurs, on peut permettre à chaque -utilisateur d'avoir un site web dans son répertoire home à l'aide de la -directive UserDir. Les -visiteurs de l'URL http://example.com/~nom_utilisateur/ -recevront un contenu situé dans le répertoire home de l'utilisateur -"nom_utilisateur", et dans le sous-répertoire spécifié par -la directive UserDir.

-

Notez que par défaut, l'accès à ces répertoires n'est -pas permis. Vous pouvez en permettre l'accès à l'aide -de la directive UserDir en -décommentant la ligne :

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

dans le fichier de configuration par défaut - conf/httpd.conf, et en adaptant le - fichier httpd-userdir.conf selon vos besoins, ou en - incluant les directives appropriées dans une section - <Directory> du fichier de - configuration principal.

-
- -
top
-
-

Répertoires web utilisateurs

- -
Modules ApparentésDirectives Apparentées
-
top
-
-

Définition du chemin des fichiers avec UserDir

- - -

La directive UserDir - permet de spécifier un répertoire à partir duquel le contenu de - l'utilisateur pourra être chargé. Elle peut revêtir plusieurs - formes.

- -

Si le chemin spécifié ne commence pas par un slash, il sera - interprété comme chemin relatif au répertoire home de l'utilisateur - considéré. Par exemple, avec cette configuration :

- - 
UserDir public_html
- - -

l'URL http://example.com/~rbowen/fichier.html - correspondra au chemin fichier - /home/rbowen/public_html/fichier.html

- -

Si le chemin spécifié commence par un slash, le chemin du fichier - sera construit en utilisant ce chemin, suivi du nom de l'utilisateur - considéré. Par exemple, avec cette configuration :

- - 
UserDir /var/html
- - -

l'URL http://example.com/~rbowen/fichier.html - correspondra au chemin fichier - /var/html/rbowen/fichier.html

- -

Si le chemin spécifié contient un astérisque (*), ce dernier sera - remplacé par le nom de l'utilisateur dans le chemin du fichier - correspondant. Par exemple, avec cette configuration :

- - 
UserDir /var/www/*/docs
- - -

l'URL http://example.com/~rbowen/fichier.html - correspondra au chemin fichier - /var/www/rbowen/docs/fichier.html

- -

On peut aussi définir plusieurs répertoires ou chemins de - répertoires.

- - 
UserDir public_html /var/html
- - -

Avec l'URL http://example.com/~rbowen/fichier.html, - Apache va rechercher ~rbowen. S'il ne le trouve pas, - Apache va rechercher rbowen dans - /var/html. S'il le trouve, l'URL ci-dessus correspondra - au chemin fichier /var/html/rbowen/file.html

- -
top
-
-

Redirection vers des URLs externes

- -

On peut utiliser la directive UserDir pour rediriger les requêtes - relatives aux répertoires utilisateurs vers des URLs externes.

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

L'exemple ci-dessus va rediriger une requête pour - http://example.com/~bob/abc.html vers - http://exemple.org/users/bob/abc.html.

-
top
-
-

Définition de la liste des utilisateurs autorisés à utiliser - cette fonctionnalité

- - -

En suivant la syntaxe décrite dans la documentation de UserDir, - vous pouvez définir quels utilisateurs sont autorisés à utiliser - cette fonctionnalité :

- - 
UserDir disabled root jro fish
- - -

La configuration ci-dessus va autoriser l'utilisation de la - fonctionnalité pour tous les utilisateurs, à l'exception de ceux - listés à la suite de l'argument disabled. De même, vous - pouvez interdire l'utilisation de la fonctionnalité à tous les - utilisateurs sauf certains d'entre eux en utilisant une - configuration du style :

- - 
UserDir disabled
-UserDir enabled rbowen krietz
- - -

Vous trouverez d'autres exemples dans la documentation de - UserDir.

- -
top
-
-

Définition d'un répertoire CGI pour chaque utilisateur

- - -

Afin de réserver un répertoire cgi-bin pour chaque utilisateur, - vous pouvez utiliser une section <Directory> pour activer CGI dans un - sous-répertoire particulier d'un répertoire home utilisateur.

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

Avec la configuration ci-dessus, et en supposant que - UserDir est défini à public_html, un - programme CGI exemple.cgi pourra être chargé depuis ce - répertoire en passant par l'URL :

- -

- http://example.com/~rbowen/cgi-bin/exemple.cgi -

- -
top
-
-

Permettre aux utilisateurs de modifier la - configuration

- - -

Si vous voulez que vos utilisateurs puissent modifier la - configuration du serveur pour ce qui concerne leur espace web, ils - devront utiliser des fichiers .htaccess pour effectuer - ces modifications. Assurez-vous d'avoir défini la directive - AllowOverride à une valeur - appropriée pour les directives dont vous voulez permettre la - modification aux utilisateurs. Voir le tutoriel .htaccess pour plus de détails sur - la manière dont tout ceci fonctionne.

- -
-
-

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

-
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
-
- \ No newline at end of file diff --git a/docs/manual/howto/public_html.html.fr.utf8 b/docs/manual/howto/public_html.html.fr.utf8 new file mode 100644 index 0000000000..671be7154c --- /dev/null +++ b/docs/manual/howto/public_html.html.fr.utf8 @@ -0,0 +1,235 @@ + + + + + +Répertoires web utilisateurs - Serveur HTTP Apache Version 2.5 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.5

+
+
<-
+

Répertoires web utilisateurs

+
+

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

+
+ +

Sur les systèmes multi-utilisateurs, on peut permettre à chaque +utilisateur d'avoir un site web dans son répertoire home à l'aide de la +directive UserDir. Les +visiteurs de l'URL http://example.com/~nom_utilisateur/ +recevront un contenu situé dans le répertoire home de l'utilisateur +"nom_utilisateur", et dans le sous-répertoire spécifié par +la directive UserDir.

+

Notez que par défaut, l'accès à ces répertoires n'est +pas permis. Vous pouvez en permettre l'accès à l'aide +de la directive UserDir en +décommentant la ligne :

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

dans le fichier de configuration par défaut + conf/httpd.conf, et en adaptant le + fichier httpd-userdir.conf selon vos besoins, ou en + incluant les directives appropriées dans une section + <Directory> du fichier de + configuration principal.

+
+ +
top
+
+

Répertoires web utilisateurs

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

Définition du chemin des fichiers avec UserDir

+ + +

La directive UserDir + permet de spécifier un répertoire à partir duquel le contenu de + l'utilisateur pourra être chargé. Elle peut revêtir plusieurs + formes.

+ +

Si le chemin spécifié ne commence pas par un slash, il sera + interprété comme chemin relatif au répertoire home de l'utilisateur + considéré. Par exemple, avec cette configuration :

+ + 
UserDir public_html
+ + +

l'URL http://example.com/~rbowen/fichier.html + correspondra au chemin fichier + /home/rbowen/public_html/fichier.html

+ +

Si le chemin spécifié commence par un slash, le chemin du fichier + sera construit en utilisant ce chemin, suivi du nom de l'utilisateur + considéré. Par exemple, avec cette configuration :

+ + 
UserDir /var/html
+ + +

l'URL http://example.com/~rbowen/fichier.html + correspondra au chemin fichier + /var/html/rbowen/fichier.html

+ +

Si le chemin spécifié contient un astérisque (*), ce dernier sera + remplacé par le nom de l'utilisateur dans le chemin du fichier + correspondant. Par exemple, avec cette configuration :

+ + 
UserDir /var/www/*/docs
+ + +

l'URL http://example.com/~rbowen/fichier.html + correspondra au chemin fichier + /var/www/rbowen/docs/fichier.html

+ +

On peut aussi définir plusieurs répertoires ou chemins de + répertoires.

+ + 
UserDir public_html /var/html
+ + +

Avec l'URL http://example.com/~rbowen/fichier.html, + Apache va rechercher ~rbowen. S'il ne le trouve pas, + Apache va rechercher rbowen dans + /var/html. S'il le trouve, l'URL ci-dessus correspondra + au chemin fichier /var/html/rbowen/file.html

+ +
top
+
+

Redirection vers des URLs externes

+ +

On peut utiliser la directive UserDir pour rediriger les requêtes + relatives aux répertoires utilisateurs vers des URLs externes.

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

L'exemple ci-dessus va rediriger une requête pour + http://example.com/~bob/abc.html vers + http://exemple.org/users/bob/abc.html.

+
top
+
+

Définition de la liste des utilisateurs autorisés à utiliser + cette fonctionnalité

+ + +

En suivant la syntaxe décrite dans la documentation de UserDir, + vous pouvez définir quels utilisateurs sont autorisés à utiliser + cette fonctionnalité :

+ + 
UserDir disabled root jro fish
+ + +

La configuration ci-dessus va autoriser l'utilisation de la + fonctionnalité pour tous les utilisateurs, à l'exception de ceux + listés à la suite de l'argument disabled. De même, vous + pouvez interdire l'utilisation de la fonctionnalité à tous les + utilisateurs sauf certains d'entre eux en utilisant une + configuration du style :

+ + 
UserDir disabled
+UserDir enabled rbowen krietz
+ + +

Vous trouverez d'autres exemples dans la documentation de + UserDir.

+ +
top
+
+

Définition d'un répertoire CGI pour chaque utilisateur

+ + +

Afin de réserver un répertoire cgi-bin pour chaque utilisateur, + vous pouvez utiliser une section <Directory> pour activer CGI dans un + sous-répertoire particulier d'un répertoire home utilisateur.

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

Avec la configuration ci-dessus, et en supposant que + UserDir est défini à public_html, un + programme CGI exemple.cgi pourra être chargé depuis ce + répertoire en passant par l'URL :

+ +

+ http://example.com/~rbowen/cgi-bin/exemple.cgi +

+ +
top
+
+

Permettre aux utilisateurs de modifier la + configuration

+ + +

Si vous voulez que vos utilisateurs puissent modifier la + configuration du serveur pour ce qui concerne leur espace web, ils + devront utiliser des fichiers .htaccess pour effectuer + ces modifications. Assurez-vous d'avoir défini la directive + AllowOverride à une valeur + appropriée pour les directives dont vous voulez permettre la + modification aux utilisateurs. Voir le tutoriel .htaccess pour plus de détails sur + la manière dont tout ceci fonctionne.

+ +
+
+

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

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/reverse_proxy.html b/docs/manual/howto/reverse_proxy.html index 4ace055cc0..4f9eb4910e 100644 --- a/docs/manual/howto/reverse_proxy.html +++ b/docs/manual/howto/reverse_proxy.html @@ -6,7 +6,7 @@ Content-type: text/html; charset=ISO-8859-1 URI: reverse_proxy.html.es Content-Language: es -Content-type: text/html; charset=ISO-8859-1 +Content-type: text/html; charset=UTF-8 URI: reverse_proxy.html.fr Content-Language: fr diff --git a/docs/manual/howto/reverse_proxy.html.en b/docs/manual/howto/reverse_proxy.html.en index 2517b16f5f..2bce4696de 100644 --- a/docs/manual/howto/reverse_proxy.html.en +++ b/docs/manual/howto/reverse_proxy.html.en @@ -24,8 +24,8 @@ Apache > HTTP Server > Documentation > Version 2.5 > How-To / Tutorials

Reverse Proxy Guide

Available Languages:  en  | - es  | - fr 

+ es  | + fr 

In addition to being a "basic" web server, and providing static and @@ -333,8 +333,8 @@ ProxyPassReverse "/images/" "balancer://myset/"

Available Languages:  en  | - es  | - fr 

+ es  | + fr 

top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
- - -
-

Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

-

Versin 2.5 del Servidor HTTP Apache

-
-
<-
-

Gua de Proxy Inverso

-
-

Idiomas disponibles:  en  | - es  | - fr 

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

Adems de ser un servidor web "bsico", y proveer contenido esttico y - dinmico a los usuarios finales, Apache HTTPD (al igual que la mayora de - servidores http) puede tambin actuar como proxy inverso, tambin conocido - como "servidor de paso" o gateway. -

- -

En tales escenarios, el propio httpd no genera contenido o aloja datos, - en su lugar el contenido se obtiene de uno o varios servidores backend, que - normalmente no tienen conexin directa con redes externas. Cuando httpd - recibe una peticin de un cliente, se hace proxy de esta peticin - a uno de estos servidores backend, que gestiona la peticin, genera el - contenido y entonces enva este contenido de vuelta a httpd, que - entonces genera la respuesta HTTP definitiva que se enva de vuelta al cliente. -

- -

Existen muchas razones para usar esta implementacin, pero generalmente - las razones tpicas se deben a seguridad, alta disponibilidad, balanceo - de carga, y centralizacin de autenticacin/autorizacin. Es crtico en - estas implementaciones que la arquitectura y el diseo de la infraestructura - de los backend (esos servidores que son los que acaban gestionando las peticiones) - estn aislados y protegidos del exterior; en cuanto al cliente se refiere, - el proxy inverso s la nica fuente de todo el contenido.

- -

Ejemplo de implementacin tpica:

-

reverse-proxy-arch

- -
- -
top
-
-

Proxy Inverso

- -
Mdulos RelacionadosDirectivas Relacionadas
-
top
-
-

Proxy inverso sencillo

- - -

- La directiva ProxyPass - especifica el mapeo de peticiones entrantes al servidor backend (o un cluster - de servidores conocido como grupo de Balanceo). El ejemplo - ms sencillo hace proxy de todas las solicitudes ("/") a un solo backend: -

- - 
ProxyPass "/"  "http://www.example.com/"
- - -

- Para asegurarse de ello y que las cabeceras Location: - generadas en el backend se modifican para apuntar al proxy inverso, - en lugar del propio backend, la directiva - ProxyPassReverse suele ser necesaria a menudo: -

- - 
ProxyPass "/"  "http://www.example.com/"
-ProxyPassReverse "/"  "http://www.example.com/"
- - -

Slo se har proxy de ciertas URIs, como se muestra en este ejemplo:

- - 
ProxyPass "/images/"  "http://www.example.com/"
-ProxyPassReverse "/images/"  "http://www.example.com/"
- - -

En este ejemplo, se har proxy al backend especificado, - de cualquier solicitud que comience con la ruta /images/, si - no se gestionarn localmente. -

-
top
-
-

Clusters y Balanceadores

- - -

- Aunque los ejemplos de ms arriba son tiles, tienen la deficiencia en la - que si el backend se cae, o recibe mucha carga, hacer proxy de esas solicitudes - no aporta grandes beneficios. Lo que se necesita es la habilidad de definir un - grupo de servidores backend que puedan gestionar esas peticiones y que el proxy - inverso pueda balancear la carga y aplicar la tolerancia a fallos entre los backend. - A veces a este grupo se le llama cluster, pero el trmino para Apache httpd - es balanceador. Se puede definir un balanceador usando las directivas - <Proxy> and - BalancerMember como se muestra - a continuacin: -

- - 
<Proxy balancer://myset>
-    BalancerMember http://www2.example.com:8080
-    BalancerMember http://www3.example.com:8080
-    ProxySet lbmethod=bytraffic
-</Proxy>
-
-ProxyPass "/images/"  "balancer://myset/"
-ProxyPassReverse "/images/"  "balancer://myset/"
- - -

- El esquema balancer:// es lo que le dice a httpd que estamos - generando un grupo de balanceo, con el nombre myset. Incluye 2 - servidores backend, que httpd llama BalancerMember. En este caso, - se har proxy inverso de cualquier peticin para /images/ - hacia uno de los dos backend. - La directiva ProxySet especifica que - el Balanceador myset usa un algoritmo que balancea basado en los - bytes de entrada/salida (I/O). -

- -

Informacin adicional

-

- Tambin se refiere a los Miembros del Balanceador BalancerMember - como workers (trabajadores). -

-
- -
top
-
-

Configuracin de Balanceador y BalancerMember

- - -

- Puede ajustar numerosos parmetros de los balanceadores - y los workers definindolos a travs de la directiva - ProxyPass. Por ejemplo, - asumiendo que quisiramos que http://www3.example.com:8080 gestionara - 3 veces ms trfico con un "timeout" de 1 segundo, ajustaramos la configuracin como sigue: -

- - 
<Proxy balancer://myset>
-    BalancerMember http://www2.example.com:8080
-    BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
-    ProxySet lbmethod=bytraffic
-</Proxy>
-
-ProxyPass "/images/"  "balancer://myset/"
-ProxyPassReverse "/images/"  "balancer://myset/"
- - -
top
-
-

Tolerancia a fallos

- - -

- Puede tambin ajustar varios escenarios de tolerancia a fallos, detallando - qu workers, e incluso balanceadores, deberan usarse en tales casos. - Por ejemplo, la siguiente configuracin implementa dos casos de tolerancia - a fallos: En el primero, slo se enva trfico a - http://hstandby.example.com:8080 si todos los dems workers en - el balanceador myset no estn disponibles. Si ese worker tampoco est - disponible, slo entonces los workers de http://bkup1.example.com:8080 - y http://bkup2.example.com:8080 sern incluidos en la rotacin: -

- - 
<Proxy balancer://myset>
-    BalancerMember http://www2.example.com:8080
-    BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
-    BalancerMember http://hstandby.example.com:8080 status=+H
-    BalancerMember http://bkup1.example.com:8080 lbset=1
-    BalancerMember http://bkup2.example.com:8080 lbset=1
-    ProxySet lbmethod=byrequests
-</Proxy>
-
-ProxyPass "/images/"  "balancer://myset/"
-ProxyPassReverse "/images/"  "balancer://myset/"
- - -

- La "magia" de sta configuracin de tolerancia a fallos es configurar - http://hstandby.example.com:8080 con la marca de estado - +H, que lo pone en modo hot standby (en reserva), - y hacen que los 2 servidores bkup# sean parte del set n 1 del balanceo de carga (el valor por defecto es 0); para tolerancia a fallos, los "hot standby" (si existen) se usan primero cuando todos los workers estndar no estn disponibles; los set de balanceo con el nmero inferior se intentan usar siempre primero. -

- -
top
-
-

Gestor del Balanceador

- - -

- Una de las caractersticas ms tiles y nica del proxy inverso de Apache - httpd es la aplicacin embebida balancer-manager (gestor de balanceo). - wSimilar a mod_status, balancer-manager muestra - la configuracin actual que est funcionando, el estado de los balanceadores - activados y workers que estn en uso en ese momento. Aun as, no slo muestra - estos parmetros, tambin permite reconfiguracin dinmica, en tiempo real, de - prcticamente todos ellos, incluido aadir nuevos BalancerMember (workers) - a un balanceo existente. Para activar esta prestacin, se tiene que aadir lo siguiente a la configuracin: -

- - 
<Location "/balancer-manager">
-    SetHandler balancer-manager
-    Require host localhost
-</Location>
- - -

Atencin

-

No active el balancer-manager hasta que haya securizado su servidor. En particular, - asegrese de que el acceso a sta URL (la de configuracin del balanceador) - est altamente restringido.

-
- -

- Cuando se accede al proxy inverso en la url - (p.e: http://rproxy.example.com/balancer-manager/, ver una - pgina similar a la siguiente: -

-

balancer-manager page

- -

- Este formulario permite al administrador ajustar varios parmetros, desactivar - workers, cambiar los mtodos de balanceo de carga y aadir nuevos workers. - Por ejemplo, haciendo clic en el balanceador, ver la siguiente pgina: -

-

balancer-manager page

- -

- Y haciendo clic en el worker, mostrar esta pgina: -

-

balancer-manager page

- -

- Para hacer que estos cambios sean persistentes en los reinicios del proxy - inverso, asegrese de que BalancerPersist est activado. -

- -
top
-
-

Comprobaciones de estado dinmicas

- - -

- Antes de que httpd haga proxy de una peticin a un worker, puede "comprobar" - si ese worker est disponible mediante el parmetro de configuracin ping - para ese worker usando ProxyPass. - A menudo es ms til comprobar el estado de los workers no disponibles, - con un mtodo dinmico. Esto se consigue con el mdulo mod_proxy_hcheck. -

- -
top
-
-

Marcas de estado de los Miembros del Balanceador

- - -

- En el balancer-manager el estado actual, o status, de un worker - se muestra y puede ser configurado/reseteado. El significado de estos estados es el siguiente: -

- - - - - - - - - - - -
MarcaCadenaDescripcin
 OkEl Worker est disponible
 InitEl Worker ha sido inicializado
DDisEl Worker est - desactivado y no aceptar peticiones; se intentar reutilizar automticamente.
SStopEl Worker ha sido desactivado por el - administrador; no aceptar peticiones y no se reintentar utilizar automticamente
IIgnEl Worker est en modo "ignore-errors" (obviar-errores) y estar siempre en modo disponible.
HStbyEl Worker est en modo "hot-standby" y slo se usar si no hay otros workers disponibles.
EErrEl Worker est en estado de error, - generalmente debido a fallos de comprobacin antes de enviar peticiones; no se har - proxy de peticiones a este worker, pero se reintentar el uso de este worker - dependiendo de la configuracin del parmetro retry.
NDrnEl Worker est en modo vaciado y slo aceptar - sesiones activas previamente destinadas a l mismo y obviar el resto de peticiones.
CHcFlLa comprobacin dinmica del estado del Worker - ha fallado y no se usar hasta que pase las comprobaciones de estado posteriores.
-
-
-

Idiomas disponibles:  en  | - es  | - fr 

-
top

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
-
- \ No newline at end of file diff --git a/docs/manual/howto/reverse_proxy.html.es.utf8 b/docs/manual/howto/reverse_proxy.html.es.utf8 new file mode 100644 index 0000000000..e650988492 --- /dev/null +++ b/docs/manual/howto/reverse_proxy.html.es.utf8 @@ -0,0 +1,339 @@ + + + + + +Gua de Proxy Inverso - Servidor HTTP Apache Versin 2.5 + + + + + + +
+

Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

+

Versin 2.5 del Servidor HTTP Apache

+
+
<-
+

Gua de Proxy Inverso

+
+

Idiomas disponibles:  en  | + es  | + fr 

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

Adems de ser un servidor web "bsico", y proveer contenido esttico y + dinmico a los usuarios finales, Apache HTTPD (al igual que la mayora de + servidores http) puede tambin actuar como proxy inverso, tambin conocido + como "servidor de paso" o gateway. +

+ +

En tales escenarios, el propio httpd no genera contenido o aloja datos, + en su lugar el contenido se obtiene de uno o varios servidores backend, que + normalmente no tienen conexin directa con redes externas. Cuando httpd + recibe una peticin de un cliente, se hace proxy de esta peticin + a uno de estos servidores backend, que gestiona la peticin, genera el + contenido y entonces enva este contenido de vuelta a httpd, que + entonces genera la respuesta HTTP definitiva que se enva de vuelta al cliente. +

+ +

Existen muchas razones para usar esta implementacin, pero generalmente + las razones tpicas se deben a seguridad, alta disponibilidad, balanceo + de carga, y centralizacin de autenticacin/autorizacin. Es crtico en + estas implementaciones que la arquitectura y el diseo de la infraestructura + de los backend (esos servidores que son los que acaban gestionando las peticiones) + estn aislados y protegidos del exterior; en cuanto al cliente se refiere, + el proxy inverso s la nica fuente de todo el contenido.

+ +

Ejemplo de implementacin tpica:

+

reverse-proxy-arch

+ +
+ +
top
+
+

Proxy Inverso

+ +
Mdulos RelacionadosDirectivas Relacionadas
+
top
+
+

Proxy inverso sencillo

+ + +

+ La directiva ProxyPass + especifica el mapeo de peticiones entrantes al servidor backend (o un cluster + de servidores conocido como grupo de Balanceo). El ejemplo + ms sencillo hace proxy de todas las solicitudes ("/") a un solo backend: +

+ + 
ProxyPass "/"  "http://www.example.com/"
+ + +

+ Para asegurarse de ello y que las cabeceras Location: + generadas en el backend se modifican para apuntar al proxy inverso, + en lugar del propio backend, la directiva + ProxyPassReverse suele ser necesaria a menudo: +

+ + 
ProxyPass "/"  "http://www.example.com/"
+ProxyPassReverse "/"  "http://www.example.com/"
+ + +

Slo se har proxy de ciertas URIs, como se muestra en este ejemplo:

+ + 
ProxyPass "/images/"  "http://www.example.com/"
+ProxyPassReverse "/images/"  "http://www.example.com/"
+ + +

En este ejemplo, se har proxy al backend especificado, + de cualquier solicitud que comience con la ruta /images/, si + no se gestionarn localmente. +

+
top
+
+

Clusters y Balanceadores

+ + +

+ Aunque los ejemplos de ms arriba son tiles, tienen la deficiencia en la + que si el backend se cae, o recibe mucha carga, hacer proxy de esas solicitudes + no aporta grandes beneficios. Lo que se necesita es la habilidad de definir un + grupo de servidores backend que puedan gestionar esas peticiones y que el proxy + inverso pueda balancear la carga y aplicar la tolerancia a fallos entre los backend. + A veces a este grupo se le llama cluster, pero el trmino para Apache httpd + es balanceador. Se puede definir un balanceador usando las directivas + <Proxy> and + BalancerMember como se muestra + a continuacin: +

+ + 
<Proxy balancer://myset>
+    BalancerMember http://www2.example.com:8080
+    BalancerMember http://www3.example.com:8080
+    ProxySet lbmethod=bytraffic
+</Proxy>
+
+ProxyPass "/images/"  "balancer://myset/"
+ProxyPassReverse "/images/"  "balancer://myset/"
+ + +

+ El esquema balancer:// es lo que le dice a httpd que estamos + generando un grupo de balanceo, con el nombre myset. Incluye 2 + servidores backend, que httpd llama BalancerMember. En este caso, + se har proxy inverso de cualquier peticin para /images/ + hacia uno de los dos backend. + La directiva ProxySet especifica que + el Balanceador myset usa un algoritmo que balancea basado en los + bytes de entrada/salida (I/O). +

+ +

Informacin adicional

+

+ Tambin se refiere a los Miembros del Balanceador BalancerMember + como workers (trabajadores). +

+
+ +
top
+
+

Configuracin de Balanceador y BalancerMember

+ + +

+ Puede ajustar numerosos parmetros de los balanceadores + y los workers definindolos a travs de la directiva + ProxyPass. Por ejemplo, + asumiendo que quisiramos que http://www3.example.com:8080 gestionara + 3 veces ms trfico con un "timeout" de 1 segundo, ajustaramos la configuracin como sigue: +

+ + 
<Proxy balancer://myset>
+    BalancerMember http://www2.example.com:8080
+    BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
+    ProxySet lbmethod=bytraffic
+</Proxy>
+
+ProxyPass "/images/"  "balancer://myset/"
+ProxyPassReverse "/images/"  "balancer://myset/"
+ + +
top
+
+

Tolerancia a fallos

+ + +

+ Puede tambin ajustar varios escenarios de tolerancia a fallos, detallando + qu workers, e incluso balanceadores, deberan usarse en tales casos. + Por ejemplo, la siguiente configuracin implementa dos casos de tolerancia + a fallos: En el primero, slo se enva trfico a + http://hstandby.example.com:8080 si todos los dems workers en + el balanceador myset no estn disponibles. Si ese worker tampoco est + disponible, slo entonces los workers de http://bkup1.example.com:8080 + y http://bkup2.example.com:8080 sern incluidos en la rotacin: +

+ + 
<Proxy balancer://myset>
+    BalancerMember http://www2.example.com:8080
+    BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
+    BalancerMember http://hstandby.example.com:8080 status=+H
+    BalancerMember http://bkup1.example.com:8080 lbset=1
+    BalancerMember http://bkup2.example.com:8080 lbset=1
+    ProxySet lbmethod=byrequests
+</Proxy>
+
+ProxyPass "/images/"  "balancer://myset/"
+ProxyPassReverse "/images/"  "balancer://myset/"
+ + +

+ La "magia" de sta configuracin de tolerancia a fallos es configurar + http://hstandby.example.com:8080 con la marca de estado + +H, que lo pone en modo hot standby (en reserva), + y hacen que los 2 servidores bkup# sean parte del set n 1 del balanceo de carga (el valor por defecto es 0); para tolerancia a fallos, los "hot standby" (si existen) se usan primero cuando todos los workers estndar no estn disponibles; los set de balanceo con el nmero inferior se intentan usar siempre primero. +

+ +
top
+
+

Gestor del Balanceador

+ + +

+ Una de las caractersticas ms tiles y nica del proxy inverso de Apache + httpd es la aplicacin embebida balancer-manager (gestor de balanceo). + wSimilar a mod_status, balancer-manager muestra + la configuracin actual que est funcionando, el estado de los balanceadores + activados y workers que estn en uso en ese momento. Aun as, no slo muestra + estos parmetros, tambin permite reconfiguracin dinmica, en tiempo real, de + prcticamente todos ellos, incluido aadir nuevos BalancerMember (workers) + a un balanceo existente. Para activar esta prestacin, se tiene que aadir lo siguiente a la configuracin: +

+ + 
<Location "/balancer-manager">
+    SetHandler balancer-manager
+    Require host localhost
+</Location>
+ + +

Atencin

+

No active el balancer-manager hasta que haya securizado su servidor. En particular, + asegrese de que el acceso a sta URL (la de configuracin del balanceador) + est altamente restringido.

+
+ +

+ Cuando se accede al proxy inverso en la url + (p.e: http://rproxy.example.com/balancer-manager/, ver una + pgina similar a la siguiente: +

+

balancer-manager page

+ +

+ Este formulario permite al administrador ajustar varios parmetros, desactivar + workers, cambiar los mtodos de balanceo de carga y aadir nuevos workers. + Por ejemplo, haciendo clic en el balanceador, ver la siguiente pgina: +

+

balancer-manager page

+ +

+ Y haciendo clic en el worker, mostrar esta pgina: +

+

balancer-manager page

+ +

+ Para hacer que estos cambios sean persistentes en los reinicios del proxy + inverso, asegrese de que BalancerPersist est activado. +

+ +
top
+
+

Comprobaciones de estado dinmicas

+ + +

+ Antes de que httpd haga proxy de una peticin a un worker, puede "comprobar" + si ese worker est disponible mediante el parmetro de configuracin ping + para ese worker usando ProxyPass. + A menudo es ms til comprobar el estado de los workers no disponibles, + con un mtodo dinmico. Esto se consigue con el mdulo mod_proxy_hcheck. +

+ +
top
+
+

Marcas de estado de los Miembros del Balanceador

+ + +

+ En el balancer-manager el estado actual, o status, de un worker + se muestra y puede ser configurado/reseteado. El significado de estos estados es el siguiente: +

+ + + + + + + + + + + +
MarcaCadenaDescripcin
 OkEl Worker est disponible
 InitEl Worker ha sido inicializado
DDisEl Worker est + desactivado y no aceptar peticiones; se intentar reutilizar automticamente.
SStopEl Worker ha sido desactivado por el + administrador; no aceptar peticiones y no se reintentar utilizar automticamente
IIgnEl Worker est en modo "ignore-errors" (obviar-errores) y estar siempre en modo disponible.
HStbyEl Worker est en modo "hot-standby" y slo se usar si no hay otros workers disponibles.
EErrEl Worker est en estado de error, + generalmente debido a fallos de comprobacin antes de enviar peticiones; no se har + proxy de peticiones a este worker, pero se reintentar el uso de este worker + dependiendo de la configuracin del parmetro retry.
NDrnEl Worker est en modo vaciado y slo aceptar + sesiones activas previamente destinadas a l mismo y obviar el resto de peticiones.
CHcFlLa comprobacin dinmica del estado del Worker + ha fallado y no se usar hasta que pase las comprobaciones de estado posteriores.
+
+
+

Idiomas disponibles:  en  | + es  | + fr 

+
top

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/reverse_proxy.html.fr b/docs/manual/howto/reverse_proxy.html.fr deleted file mode 100644 index eca27eaba1..0000000000 --- a/docs/manual/howto/reverse_proxy.html.fr +++ /dev/null @@ -1,383 +0,0 @@ - - - - - -Guide de configuration d'un mandataire inverse - Serveur HTTP Apache Version 2.5 - - - - - - -
-

Modules | Directives | FAQ | Glossaire | Plan du site

-

Serveur HTTP Apache Version 2.5

-
-
<-
-

Guide de configuration d'un mandataire inverse

-
-

Langues Disponibles:  en  | - es  | - fr 

-
- -

En plus de ses fonctions de serveur web "basique", à savoir fournir du - contenu statique et dynamique à l'utilisateur, Apache httpd (comme la - plupart des autres serveurs web) peut aussi assurer les fonctions de serveur - mandataire inverse, connu aussi sous le nom de serveur "passerelle".

- -

Dans un tel scénario, httpd ne génère et n'héberge pas lui-même les - données, le contenu étant en général obtenu à partir d'un ou plusieurs serveurs - d'arrière-plan qui n'ont normalement aucune connexion directe avec le réseau - externe. Lorsque httpd reçoit une requête en provenance d'un client, la - requête proprement dite est mandatée vers un de ces serveurs - d'arrière-plan qui traite la requête, génère le contenu et l'envoie à httpd, - ce dernier générant la véritable réponse HTTP à destination du client.

- -

De nombreuses raisons peuvent vous motiver à utiliser cette - fonctionnalité, mais elles sont souvent du domaine de la sécurité, de - la haute disponibilité, de la répartition de charge et de - l'authentification/autorisation centralisée. Il est alors indispensable que - l'organisation, la conception et l'architecture de l'infrastructure - d'arrière-plan (les serveurs qui traitent au sens propre les requêtes) soient - isolées et protégées de l'extérieur ; vu du client, le serveur mandataire - inverse est le seul serveur accessible pouvant lui fournir du - contenu.

- -

Voici un exemple typique d'implémentation de cette fonctionnalité :

-

reverse-proxy-arch

- -
- -
top
-
-

Mandataire inverse

- -
Modules ApparentésDirectives Apparentées
-
top
-
-

Mandatement inverse simple

- - -

- La directive ProxyPass permet de - rediriger les requêtes entrantes vers un serveur d'arrière-plan (ou un - cluster de serveurs plus connu sous le nom de groupe - Balancer). Dans cet exemple le plus simple, toutes les - requêtes ("/") sont redirigées vers un serveur d'arrière-plan - unique : -

- - 
ProxyPass "/"  "http://www.example.com/"
- - -

- Pour être sur que cette redirection soit effectuée et que les en-têtes - Location: générés par le serveur d'arrière-plan soient - modifiés pour pointer vers le mandataire inverse, et non vers le serveur - d'arrière-plan, la directive ProxyPassReverse est souvent requise : -

- - 
ProxyPass "/"  "http://www.example.com/"
-ProxyPassReverse "/"  "http://www.example.com/"
- - -

Seules des URIs spécifiques peuvent être mandatées, comme le montre - l'exemple suivant :

- - 
ProxyPass "/images"  "http://www.example.com/"
-ProxyPassReverse "/images"  "http://www.example.com/"
- - -

Dans l'exemple précédent, si le chemin d'une requête commence par - /images, elle sera redirigée vers le serveur d'arrière-plan - spécifié ; dans le cas contraire, elle sera traitée localement. -

-
top
-
-

Clusters et Balancers

- - -

- Utiliser un serveur d'arrière-plan unique n'est cependant pas une solution - idéale car ce dernier peut devenir indisponible ou surchargé, et le - mandatement inverse vers ce serveur ne présente alors plus aucun avantage. - La solution réside dans la définition d'un groupe de serveurs - d'arrière-plan qui vont se partager le traitement des requêtes via un - mécanisme de répartition de charge et de gestion des indisponibilités pris - en charge par le mandataire. Ce groupe de répartition est plus connu sous le nom de - cluster, mais dans la terminologie d'Apache httpd, on utilise - plutôt le terme de balancer. Un balancer se définit en - utilisant les directives <Proxy> et BalancerMember comme suit : -

- - 
<Proxy balancer://myset>
-    BalancerMember http://www2.example.com:8080
-    BalancerMember http://www3.example.com:8080
-    ProxySet lbmethod=bytraffic
-</Proxy>
-
-ProxyPass "/images/"  "balancer://myset/"
-ProxyPassReverse "/images/"  "balancer://myset/"
- - -

- Le protocole balancer:// indique à httpd que l'on souhaite - créer un balancer nommé myset. Ce balancer comporte deux serveurs - d'arrière-plan référencés dans la terminologie httpd sous le nom de - BalancerMembers. Avec cet exemple, toute requête dont le chemin - commence par /images sera mandatée vers un des deux - serveurs d'arrière-plan. La directive ProxySet définit ici pour le balancer - myset un algorithme de - répartition de charge basé sur le trafic entrées/sorties. -

- -

Remarque

-

- Les BalancerMembers sont aussi souvent référencés sous le terme - workers. -

-
- -
top
-
-

Configuration du Balancer et des BalancerMembers

- - -

- Vous pouvez configurer de manière détaillée les balancers et - workers via les nombreux paramètres de la directive ProxyPass. Par exemple, si vous souhaitez - que http://www3.example.com:8080 traite avec un facteur 3 le - trafic avec un timeout d'une seconde, utilisez la configuration suivante : -

- - 
<Proxy balancer://myset>
-    BalancerMember http://www2.example.com:8080
-    BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
-    ProxySet lbmethod=bytraffic
-</Proxy>
-
-ProxyPass "/images"  "balancer://myset/"
-ProxyPassReverse "/images"  "balancer://myset/"
- - -
top
-
-

Gestion des indisponibilités (Failover)

- - -

- Vous pouvez aussi définir finement des scénarios pour les cas - d'indisponibilité d'un ou plusieurs serveurs d'arrière-plan en spécifiant - quels serveurs doivent alors prendre le relai. Dans l'exemple suivant, - trois scénarios sont envisagés : -

-
    -
  1. - http://spare1.example.com:8080 et - http://spare2.example.com:8080 ne sont sollicités que si - http://www2.example.com:8080 ou - http://www3.example.com:8080 est indisponible (un serveur - de remplacement sera utilisé à la place d'un membre indisponible du même - jeu de serveurs cibles). -
    2. -
  2. - http://hstandby.example.com:8080 n'est sollicité que si - tous les autres serveurs cibles du jeu de serveurs 0 sont - indisponibles. -
    3. -
  3. - Les serveurs http://bkup1.example.com:8080 et - http://bkup2.example.com:8080 du jeu 1 ne seront sollicités que si - tous les serveurs du jeu 0, tous les serveurs de - remplacement et tous les serveurs de standby sont indisponibles. -
    4. -
-

- Il est ainsi possible de définir un ou plusieurs serveurs de remplacement - ou de standby pour chaque jeu de serveurs du répartiteur de charge. -

- - 
<Proxy balancer://myset>
-    BalancerMember http://www2.example.com:8080
-    BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
-    BalancerMember http://spare1.example.com:8080 status=+R
-    BalancerMember http://spare2.example.com:8080 status=+R
-    BalancerMember http://hstandby.example.com:8080 status=+H
-    BalancerMember http://bkup1.example.com:8080 lbset=1
-    BalancerMember http://bkup2.example.com:8080 lbset=1
-    ProxySet lbmethod=byrequests
-</Proxy>
-
-ProxyPass "/images/"  "balancer://myset/"
-ProxyPassReverse "/images/"  "balancer://myset/"
- - -

- Les serveurs de remplacement à chaud remplacent les serveurs indisponibles - du même jeu de serveurs du répartiteur de charge. Un serveur est - considéré comme indisponible s'il est en maintenance, arrêté ou en erreur. - Les serveurs de standby à chaud sont utilisés si tous les serveurs et - serveurs de remplacement du jeu de serveurs du répartiteur de charge sont - indisponibles. Les jeux de serveurs du répartiteur de charge (avec leurs - serveurs de standby et de remplacement à chaud respectifs) sont toujours - sollicités dans l'ordre du plus bas lbset vers le plus haut. -

- -
top
-
-

Gestion du répartiteur de charge

- - -

- L'application balancer-manager fournie avec le mandataire inverse - d'Apache httpd en est un des outils les plus utiles. Comme - mod_status, balancer-manager affiche la - configuration et l'activité actuelles des balancers actifs. L'affichage de - ces informations n'est cependant pas sa seule fonction ; il permet aussi de - modifier la plupart d'entre elles et même d'ajouter des membres au groupe - de répartition de charge en temps réel. Pour activer ces fonctionnalités, - vous devez ajouter les lignes suivantes à votre fichier de configuration : -

- - 
<Location "/balancer-manager">
-    SetHandler balancer-manager
-    Require host localhost
-</Location>
- - -

Avertissement

-

N'activez le balancer-manager que si vous avez déjà sécurisé votre serveur. - Assurez-vous en particulier que l'accès à l'URL soit fortement restreint.

-
- -

- Lorsque vous accédez au serveur mandataire avec une adresse du style - http://rproxy.example.com/balancer-manager/, la page suivante - s'affiche : -

-

balancer-manager page

- -

- Ce formulaire permet à l'administrateur de modifier certains paramètres, - de désactiver ou d'ajouter certains serveurs d'arrière-plan, et de - modifier les règles de répartition de charge. Par exemple, si on clique - sur le répartiteur, la page suivante s'affiche : -

-

balancer-manager page

- -

- Si on clique sur un membre du groupe de répartition de charge, la page - suivante s'affiche : -

-

balancer-manager page

- -

- Si vous souhaitez que ces modifications soient conservées après un - redémarrage du serveur, assurez-vous que la directive BalancerPersist soit définie à On. -

- -
top
-
-

Vérification dynamique du bon fonctionnement d'un serveur - d'arrière-plan

- - -

- Avant que le mandataire httpd ne fasse appel à un serveur d'arrière-plan, il - peut "tester" si ce dernier est disponible en définissant le - paramètre ping de ce serveur via la directive ProxyPass. Cependant, il est souvent plus - judicieux de vérifier le bon fonctionnement d'un serveur hors - bande et de manière dynamique via le module - mod_proxy_hcheck d'Apache httpd. -

- -
top
-
-

Drapeaux d'état d'un membre du groupe de répartition de charge

- - -

- balancer-manager permet d'afficher et de modifier l'état d'un - membre du groupe de répartition de charge. Les différents états et leurs - significations sont les suivants : -

- - - - - - - - - - - - -
DrapeauSigleDescription
 OkLe serveur est disponible
 InitLe serveur a été initialisé
DDisLe serveur est - désactivé et n'accepte aucune requête ; il sera retesté automatiquement.
SStopLe serveur a été - arrêté par l'administrateur ; il n'accepte aucune requête et il ne sera - pas retesté automatiquement.
IIgnLes erreurs - concernant ce serveur sont ignorées et il sera donc toujours considéré - comme disponible.
RSparLe serveur cible sert de remplaçant à - chaud. Lorsqu'un serveur cible avec un lbset donné est inutilisable - (maintenance, arrêt, en erreur, etc...), un serveur de remplacement à - chaud libre de même lbset sera utilisé à sa place. Les remplaçants à - chaud permettent de s'assurer qu'un nombre déterminé de serveurs cibles - sera toujours disponible pour un répartiteur de charge.
HStbyLe serveur est en - mode hot-standby et ne sera donc utilisé que si aucun autre serveur ou - serveur de remplacement n'est disponible dans le jeu de serveurs du - répartiteur de charge.
EErrLe serveur est en - erreur, en général suite à un test préalable à une requête ; aucune - requête ne lui sera soumise, mais il sera retesté en fonction de la - valeur de son paramètre retry.
NDrnLe serveur est en - mode drain ; il n'acceptera de requêtes que dans le cadre des sessions - persistantes qui lui sont réservées et ignorera toutes les autres.
CHcFlLe serveur a échoué - au test dynamique de bon fonctionnement et ne sera utilisé que lorsqu'il - aura réussi un test ultérieur.
-
-
-

Langues Disponibles:  en  | - es  | - fr 

-
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
-
- \ No newline at end of file diff --git a/docs/manual/howto/reverse_proxy.html.fr.utf8 b/docs/manual/howto/reverse_proxy.html.fr.utf8 new file mode 100644 index 0000000000..eca27eaba1 --- /dev/null +++ b/docs/manual/howto/reverse_proxy.html.fr.utf8 @@ -0,0 +1,383 @@ + + + + + +Guide de configuration d'un mandataire inverse - Serveur HTTP Apache Version 2.5 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.5

+
+
<-
+

Guide de configuration d'un mandataire inverse

+
+

Langues Disponibles:  en  | + es  | + fr 

+
+ +

En plus de ses fonctions de serveur web "basique", à savoir fournir du + contenu statique et dynamique à l'utilisateur, Apache httpd (comme la + plupart des autres serveurs web) peut aussi assurer les fonctions de serveur + mandataire inverse, connu aussi sous le nom de serveur "passerelle".

+ +

Dans un tel scénario, httpd ne génère et n'héberge pas lui-même les + données, le contenu étant en général obtenu à partir d'un ou plusieurs serveurs + d'arrière-plan qui n'ont normalement aucune connexion directe avec le réseau + externe. Lorsque httpd reçoit une requête en provenance d'un client, la + requête proprement dite est mandatée vers un de ces serveurs + d'arrière-plan qui traite la requête, génère le contenu et l'envoie à httpd, + ce dernier générant la véritable réponse HTTP à destination du client.

+ +

De nombreuses raisons peuvent vous motiver à utiliser cette + fonctionnalité, mais elles sont souvent du domaine de la sécurité, de + la haute disponibilité, de la répartition de charge et de + l'authentification/autorisation centralisée. Il est alors indispensable que + l'organisation, la conception et l'architecture de l'infrastructure + d'arrière-plan (les serveurs qui traitent au sens propre les requêtes) soient + isolées et protégées de l'extérieur ; vu du client, le serveur mandataire + inverse est le seul serveur accessible pouvant lui fournir du + contenu.

+ +

Voici un exemple typique d'implémentation de cette fonctionnalité :

+

reverse-proxy-arch

+ +
+ +
top
+
+

Mandataire inverse

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

Mandatement inverse simple

+ + +

+ La directive ProxyPass permet de + rediriger les requêtes entrantes vers un serveur d'arrière-plan (ou un + cluster de serveurs plus connu sous le nom de groupe + Balancer). Dans cet exemple le plus simple, toutes les + requêtes ("/") sont redirigées vers un serveur d'arrière-plan + unique : +

+ + 
ProxyPass "/"  "http://www.example.com/"
+ + +

+ Pour être sur que cette redirection soit effectuée et que les en-têtes + Location: générés par le serveur d'arrière-plan soient + modifiés pour pointer vers le mandataire inverse, et non vers le serveur + d'arrière-plan, la directive ProxyPassReverse est souvent requise : +

+ + 
ProxyPass "/"  "http://www.example.com/"
+ProxyPassReverse "/"  "http://www.example.com/"
+ + +

Seules des URIs spécifiques peuvent être mandatées, comme le montre + l'exemple suivant :

+ + 
ProxyPass "/images"  "http://www.example.com/"
+ProxyPassReverse "/images"  "http://www.example.com/"
+ + +

Dans l'exemple précédent, si le chemin d'une requête commence par + /images, elle sera redirigée vers le serveur d'arrière-plan + spécifié ; dans le cas contraire, elle sera traitée localement. +

+
top
+
+

Clusters et Balancers

+ + +

+ Utiliser un serveur d'arrière-plan unique n'est cependant pas une solution + idéale car ce dernier peut devenir indisponible ou surchargé, et le + mandatement inverse vers ce serveur ne présente alors plus aucun avantage. + La solution réside dans la définition d'un groupe de serveurs + d'arrière-plan qui vont se partager le traitement des requêtes via un + mécanisme de répartition de charge et de gestion des indisponibilités pris + en charge par le mandataire. Ce groupe de répartition est plus connu sous le nom de + cluster, mais dans la terminologie d'Apache httpd, on utilise + plutôt le terme de balancer. Un balancer se définit en + utilisant les directives <Proxy> et BalancerMember comme suit : +

+ + 
<Proxy balancer://myset>
+    BalancerMember http://www2.example.com:8080
+    BalancerMember http://www3.example.com:8080
+    ProxySet lbmethod=bytraffic
+</Proxy>
+
+ProxyPass "/images/"  "balancer://myset/"
+ProxyPassReverse "/images/"  "balancer://myset/"
+ + +

+ Le protocole balancer:// indique à httpd que l'on souhaite + créer un balancer nommé myset. Ce balancer comporte deux serveurs + d'arrière-plan référencés dans la terminologie httpd sous le nom de + BalancerMembers. Avec cet exemple, toute requête dont le chemin + commence par /images sera mandatée vers un des deux + serveurs d'arrière-plan. La directive ProxySet définit ici pour le balancer + myset un algorithme de + répartition de charge basé sur le trafic entrées/sorties. +

+ +

Remarque

+

+ Les BalancerMembers sont aussi souvent référencés sous le terme + workers. +

+
+ +
top
+
+

Configuration du Balancer et des BalancerMembers

+ + +

+ Vous pouvez configurer de manière détaillée les balancers et + workers via les nombreux paramètres de la directive ProxyPass. Par exemple, si vous souhaitez + que http://www3.example.com:8080 traite avec un facteur 3 le + trafic avec un timeout d'une seconde, utilisez la configuration suivante : +

+ + 
<Proxy balancer://myset>
+    BalancerMember http://www2.example.com:8080
+    BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
+    ProxySet lbmethod=bytraffic
+</Proxy>
+
+ProxyPass "/images"  "balancer://myset/"
+ProxyPassReverse "/images"  "balancer://myset/"
+ + +
top
+
+

Gestion des indisponibilités (Failover)

+ + +

+ Vous pouvez aussi définir finement des scénarios pour les cas + d'indisponibilité d'un ou plusieurs serveurs d'arrière-plan en spécifiant + quels serveurs doivent alors prendre le relai. Dans l'exemple suivant, + trois scénarios sont envisagés : +

+
    +
  1. + http://spare1.example.com:8080 et + http://spare2.example.com:8080 ne sont sollicités que si + http://www2.example.com:8080 ou + http://www3.example.com:8080 est indisponible (un serveur + de remplacement sera utilisé à la place d'un membre indisponible du même + jeu de serveurs cibles). +
    2. +
  2. + http://hstandby.example.com:8080 n'est sollicité que si + tous les autres serveurs cibles du jeu de serveurs 0 sont + indisponibles. +
    3. +
  3. + Les serveurs http://bkup1.example.com:8080 et + http://bkup2.example.com:8080 du jeu 1 ne seront sollicités que si + tous les serveurs du jeu 0, tous les serveurs de + remplacement et tous les serveurs de standby sont indisponibles. +
    4. +
+

+ Il est ainsi possible de définir un ou plusieurs serveurs de remplacement + ou de standby pour chaque jeu de serveurs du répartiteur de charge. +

+ + 
<Proxy balancer://myset>
+    BalancerMember http://www2.example.com:8080
+    BalancerMember http://www3.example.com:8080 loadfactor=3 timeout=1
+    BalancerMember http://spare1.example.com:8080 status=+R
+    BalancerMember http://spare2.example.com:8080 status=+R
+    BalancerMember http://hstandby.example.com:8080 status=+H
+    BalancerMember http://bkup1.example.com:8080 lbset=1
+    BalancerMember http://bkup2.example.com:8080 lbset=1
+    ProxySet lbmethod=byrequests
+</Proxy>
+
+ProxyPass "/images/"  "balancer://myset/"
+ProxyPassReverse "/images/"  "balancer://myset/"
+ + +

+ Les serveurs de remplacement à chaud remplacent les serveurs indisponibles + du même jeu de serveurs du répartiteur de charge. Un serveur est + considéré comme indisponible s'il est en maintenance, arrêté ou en erreur. + Les serveurs de standby à chaud sont utilisés si tous les serveurs et + serveurs de remplacement du jeu de serveurs du répartiteur de charge sont + indisponibles. Les jeux de serveurs du répartiteur de charge (avec leurs + serveurs de standby et de remplacement à chaud respectifs) sont toujours + sollicités dans l'ordre du plus bas lbset vers le plus haut. +

+ +
top
+
+

Gestion du répartiteur de charge

+ + +

+ L'application balancer-manager fournie avec le mandataire inverse + d'Apache httpd en est un des outils les plus utiles. Comme + mod_status, balancer-manager affiche la + configuration et l'activité actuelles des balancers actifs. L'affichage de + ces informations n'est cependant pas sa seule fonction ; il permet aussi de + modifier la plupart d'entre elles et même d'ajouter des membres au groupe + de répartition de charge en temps réel. Pour activer ces fonctionnalités, + vous devez ajouter les lignes suivantes à votre fichier de configuration : +

+ + 
<Location "/balancer-manager">
+    SetHandler balancer-manager
+    Require host localhost
+</Location>
+ + +

Avertissement

+

N'activez le balancer-manager que si vous avez déjà sécurisé votre serveur. + Assurez-vous en particulier que l'accès à l'URL soit fortement restreint.

+
+ +

+ Lorsque vous accédez au serveur mandataire avec une adresse du style + http://rproxy.example.com/balancer-manager/, la page suivante + s'affiche : +

+

balancer-manager page

+ +

+ Ce formulaire permet à l'administrateur de modifier certains paramètres, + de désactiver ou d'ajouter certains serveurs d'arrière-plan, et de + modifier les règles de répartition de charge. Par exemple, si on clique + sur le répartiteur, la page suivante s'affiche : +

+

balancer-manager page

+ +

+ Si on clique sur un membre du groupe de répartition de charge, la page + suivante s'affiche : +

+

balancer-manager page

+ +

+ Si vous souhaitez que ces modifications soient conservées après un + redémarrage du serveur, assurez-vous que la directive BalancerPersist soit définie à On. +

+ +
top
+
+

Vérification dynamique du bon fonctionnement d'un serveur + d'arrière-plan

+ + +

+ Avant que le mandataire httpd ne fasse appel à un serveur d'arrière-plan, il + peut "tester" si ce dernier est disponible en définissant le + paramètre ping de ce serveur via la directive ProxyPass. Cependant, il est souvent plus + judicieux de vérifier le bon fonctionnement d'un serveur hors + bande et de manière dynamique via le module + mod_proxy_hcheck d'Apache httpd. +

+ +
top
+
+

Drapeaux d'état d'un membre du groupe de répartition de charge

+ + +

+ balancer-manager permet d'afficher et de modifier l'état d'un + membre du groupe de répartition de charge. Les différents états et leurs + significations sont les suivants : +

+ + + + + + + + + + + + +
DrapeauSigleDescription
 OkLe serveur est disponible
 InitLe serveur a été initialisé
DDisLe serveur est + désactivé et n'accepte aucune requête ; il sera retesté automatiquement.
SStopLe serveur a été + arrêté par l'administrateur ; il n'accepte aucune requête et il ne sera + pas retesté automatiquement.
IIgnLes erreurs + concernant ce serveur sont ignorées et il sera donc toujours considéré + comme disponible.
RSparLe serveur cible sert de remplaçant à + chaud. Lorsqu'un serveur cible avec un lbset donné est inutilisable + (maintenance, arrêt, en erreur, etc...), un serveur de remplacement à + chaud libre de même lbset sera utilisé à sa place. Les remplaçants à + chaud permettent de s'assurer qu'un nombre déterminé de serveurs cibles + sera toujours disponible pour un répartiteur de charge.
HStbyLe serveur est en + mode hot-standby et ne sera donc utilisé que si aucun autre serveur ou + serveur de remplacement n'est disponible dans le jeu de serveurs du + répartiteur de charge.
EErrLe serveur est en + erreur, en général suite à un test préalable à une requête ; aucune + requête ne lui sera soumise, mais il sera retesté en fonction de la + valeur de son paramètre retry.
NDrnLe serveur est en + mode drain ; il n'acceptera de requêtes que dans le cadre des sessions + persistantes qui lui sont réservées et ignorera toutes les autres.
CHcFlLe serveur a échoué + au test dynamique de bon fonctionnement et ne sera utilisé que lorsqu'il + aura réussi un test ultérieur.
+
+
+

Langues Disponibles:  en  | + es  | + fr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/ssi.html b/docs/manual/howto/ssi.html index 45d12abd0a..6eea44a76c 100644 --- a/docs/manual/howto/ssi.html +++ b/docs/manual/howto/ssi.html @@ -6,7 +6,7 @@ Content-type: text/html; charset=ISO-8859-1 URI: ssi.html.es Content-Language: es -Content-type: text/html; charset=ISO-8859-1 +Content-type: text/html; charset=UTF-8 URI: ssi.html.fr Content-Language: fr diff --git a/docs/manual/howto/ssi.html.en b/docs/manual/howto/ssi.html.en index 592d175763..89090da361 100644 --- a/docs/manual/howto/ssi.html.en +++ b/docs/manual/howto/ssi.html.en @@ -24,8 +24,8 @@ Apache > HTTP Server > Documentation > Version 2.5 > How-To / Tutorials

Apache httpd Tutorial: Introduction to Server Side Includes

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

@@ -472,8 +472,8 @@ modified?

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

top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
diff --git a/docs/manual/howto/ssi.html.es b/docs/manual/howto/ssi.html.es deleted file mode 100644 index 4f0e6f23a5..0000000000 --- a/docs/manual/howto/ssi.html.es +++ /dev/null @@ -1,356 +0,0 @@ - - - - - -Tutorial de Apache httpd: Introduccin a los Server Side Includes - - Servidor HTTP Apache Versin 2.5 - - - - - - -
-

Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

-

Versin 2.5 del Servidor HTTP Apache

-
-
<-
-

Tutorial de Apache httpd: Introduccin a los Server Side Includes -

-
-

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

-
- -

Los Server Side Includes (Inclusiones en la parte Servidor) facilitan un mtodo para aadir contenido dinmico a documentos HTML existentes.

-
- -
top
-
-

Introduccin

-
Mdulos RelacionadosDirectivas Relacionadas
- -

Este artculo trata sobre los Server Side Includes, generalmente llamados SSI. En este artculo, hablaremos sobre cmo configurar su servidor para permitir SSI e introduciremos algnas tcnicas bsicas de SSI para aadir contenido dinmico a sus pginas HTML existentes.

- -

Ms adelante tambin hablaremos de algunas tcnicas algo ms avanzadas que pueden usarse con SSI, tales como declaraciones condicionales en sus directivas SSI.

- -
top
-
-

Qu son los SSI?

- -

SSI (Server Side Includes) son directivas que se introducen en pginas HTML y son evaluadas por el servidor mientras ste las sirve. Le permiten aadir contenido generado de manera dinmica a sus pginas HTML existentes sin tener que servir una pgina entera a travs de un programa CGI, u otra tecnologa para generar contenido dinmico.

- -

Por ejemplo, podra colocar una directiva en una pgina existente de HTML de esta manera:

- -

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

- -

Y, cuando se sirve la pgina, este fragmento ser evaluado y reemplazado con su resultado:

- -

- Tuesday, 15-Jan-2013 19:28:54 EST -

- -

La decisin sobre cundo usar SSI, o de cundo generar una pgina al completo con algn programa, suele depender generalmente de la cantidad de contenido esttico que contiene, y cunto de esa pgina tiene que ser recalculado cada vez que sta se sirve. SSI es un buen mtodo para aadir pequeas partes de informacin, tales como la hora actual - como se ha mostrado ms arriba. Pero si la mayora de su pgina se tiene que generar en el momento en el que se est sirviendo, necesita buscar otra opcin ms adecuada que no sea SSI.

-
top
-
-

Configurar su servidor para permitir SSI

- - -

Para permitir SSI en su servidor, debe tener la siguiente directiva en su fichero httpd.conf , o en un fichero - .htaccess:

- -
Options +Includes
- - -

Esto le dice a Apache que quiere permitir que se examinen los ficheros buscando directivas SSI. Tenga en cuenta que la mayora de las configuraciones contienen mltiples directivas Options que pueden sobreescribirse las unas a las otras. Probablemente necesitar aplicar Options al directorio especfico donde quiere SSI activado para asegurarse de que se evala en ltimo lugar y por tanto se acabar aplicando.

- -

No se examina cualquier fichero buscando directivas SSI. Usted le tiene que indicar a Apache qu ficheros se tienen que examinar. Hay dos formas de hacer esto. Puede decirle a Apache que examine cualquier fichero con una extensin determinada, como por ejemplo .shtml, con las siguientes directivas:

- -
AddType text/html .shtml
-AddOutputFilter INCLUDES .shtml
- - -

Una desventaja de este mtodo es que si quisiera aadir directivas SSI a una pgina ya existente, tendra que cambiar el nombre de la pgina, y todos los enlaces que apuntasen a esa pgina, todo para poder darle la extensin .shtml y que esas directivas sean interpretadas.

- -

El otro mtodo es usar la directiva XBitHack :

- -
XBitHack on
- - -

XBitHack le dice a Apache que examine ficheros buscando directivas SSI si los ficheros tienen el bit de ejecucin configurado. Asi que, para aadir directivas SSI a una pgina existente, en lugar de tener que cambiarle el nombre, solo tendra que convertirla en ejecutable usando chmod.

- -

- chmod +x pagename.html -

- -

Una breve recomendacin de qu no hay que hacer. Ocasionalmente vemos gente recomendar que le diga a Apache que examine todos los ficheros - .html para activar SSI, para no tener que lidiar renombrando los ficheros a .shtml. Quizs estas personas no hayan oido hablar de XBitHack. Lo que hay que tener en cuenta, es que haciendo eso, est pidiendo al Apache que lea cada uno de los ficheros que manda al cliente, incluso si no contenien directivas SSI. Esto puede ralentizar bastante el servidor, y no es una buena idea.

- -

Por supuesto, en Windows, no hay tal cosa como la configuracin del bit de ejecucin, as que esto limita las opciones un poco.

- -

En su configuracin por defecto, Apache no enva la fecha de ltima modificacin o la longitud de contenido de pginas SSI porque es dificil calcular estos valores para contenido dinmico. Esto puede impedir que se cachee un documento, y dar como resultado en apareciencia un rendimiento ms lento del cliente. Hay dos maneras de solucionar esto:

- -
    -
  1. Usando la configuracin XBitHack Full. Esto le indica a apache que determine la fecha de ltima modificacin mirando slo la fecha del fichero que se ha solicitado originalmente, obviando la modificacin de cualquier otro fichero al que se hace referencia mediante SSI.
    2. - -
  2. Use las directivas facilitadas por mod_expires para configurar una expiracin especfica de tiempo en sus ficheros, y as hacer saber a proxies o navegadores web que es aceptable cachearlos.
    3. -
-
top
-
-

Directivas SSI bsicas

- -

Las directivas SSI tienen la sintaxis siguiente:

-

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

- -

Se formatean como comentarios HTML, as si no tiene SSI habilitado correctamente, el navegador las obviar, pero todava sern visibles en el fichero HTML. Si tiene SSI configurado correctamente, la directiva ser reemplazada con su propio resultado.

- -

Esta funcin es una de tantas, y hablaremos de algunas de ellas ms adelante. Por ahora, aqu mostramos unos ejemplos de lo que puede hacer con SSI.

- -

La fecha de hoy

- -

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

- -

La funcin echo sencillamente muestra el valor de una variable. Hay muchas variables estndar que incluyen un conjunto de variables de entorno disponibles para programas CGI. Tambin puede definir sus propias variables con la funcin set.

- -

Si no le gusta el formato en el que se imprime la fecha, puede usar la funcin config, con un atributo - timefmt para modificar ese formato.

- -

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

- - -

Fecha de modificacin del fichero

- -

- La ltima modificacin de este documento <!--#flastmod file="index.html" --> -

- -

Esta funcin tambin est sujeta a configuraciones de formato de - timefmt.

- - -

Incluyendo los resultados de un programa CGI

- -

Este es uno de los usos ms comunes de SSI - para sacar el resultado de un programa CGI, tal y como ocurre con el que fuera el programa favorito de todos, un ``contador de visitas.''

- -

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

- - -
top
-
-

Ms ejemplos

- - -

A continuacin hay algunos ejemplos especficos de cosas que puede hacer con SSI en sus documentos HTML.

- -

Cundo fue modificado este documento?

- -

Antes mencionamos que puede usar SSI para informar al usuario cuando el documento ha sido modificado por ltima vez. Aun as, el mtodo actual para hacerlo se dej en cuestin. El cdigo que se muestra a continuacin, puesto en un documento HTML, pondr ese sello de tiempo en su pgina. Por descontado, tendr que tener SSI habilitado correctamente, como se indic ms arriba.

-

- <!--#config timefmt="%A %B %d, %Y" -->
- Ultima modificacin de este fichero <!--#flastmod file="ssi.shtml" --> -

- -

Obviamente, necesitar sustituir el nombre de fichero - ssi.shtml con el nombre real del fichero al que usted hace referencia. Esto puede ser inconveniente si solo est buscando un trozo genrico de cdigo que pueda copiar y pegar en cualquier fichero, asi que probablemente necesite usar la variable LAST_MODIFIED en su lugar:

-

- <!--#config timefmt="%D" -->
- ltima modificacin de este fichero <!--#echo var="LAST_MODIFIED" --> -

- -

Para ms detalles sobre el formato timefmt, vaya a su buscador favorito y busque strftime. La sintaxis es la misma.

- - -

Incluyendo un pie de pgina estndar

- - -

Si gestiona un sitio que tiene ms de unas cuantas pginas, probablemente se de cuenta de que modificar todas esa pginas es un autntico engorro, especialmente si trata de mantener una apareciencia homognea en todas ellas.

- -

Si usa un Include de fichero para la cabecera y/o pie de pgina puede reducir la carga de trabajo de estas actualizaciones. Solo tiene que hacer un slo pie de pgina, y despus incluirlo en cada pgina con el comando SSI include. La funcin include - puede determinar qu fichero incluir cuando usa el atributo - file, o el atributo virtual. El atributo file es una ruta de fichero, relativa al directorio actual. Eso significa que no puede ser una ruta de fichero absoluta (que comienza con /), ni tampoco puede contener ../ como parte de la ruta. El atributo virtual es probablemente ms til, y debera especificar una URL relativa al documento que se est sirviendo. Puede empezar con una /, pero debe estar en el mismo servidor que el fichero que se est sirviendo.

-

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

- -

Frecuentemente combinaremos las dos ltimas, poniendo una directiva - LAST_MODIFIED dentro de un fichero de pie de pgina que va a ser incluido. Se pueden encontrar directivas SSI en el fichero que se incluye, las inclusiones pueden anidarse - lo que quiere decir, que el fichero incluido puede incluir otro fichero, y as sucesivamente.

- - -
top
-
-

Qu ms puedo configurar?

- - -

Adems de poder configurar el formato de la hora, tambin puede configurar dos cosas ms.

- -

Generalmente, cuando algo sale mal con sus directivas SSI, obtiene el mensaje (ha ocurrido un error procesando esta directiva)

-

- [an error occurred while processing this directive] -

- -

Si quiere cambiar ese mensaje por otra cosa, puede hacerlo con el atributo errmsg para la funcin - config:

-

- <!--#config errmsg="[Parece que no sabe cmo usar SSI]" --> -

- -

Afortunadamente, los usuarios finales nunca vern este mensaje, porque habr resuelto todos los problemas con sus directivas SSI antes de publicar su pgina web. (Verdad?)

- -

Y puede configurar el formato en el que los tamaos de fichero se muestran con el formato sizefmt. Puede especificar - bytes para un recuento total en bytes, o - abbrev para un nmero abreviado en Kb o Mb, segn sea necesario.

-
top
-
-

Ejecutando comandos

- - -

Aqu tiene algo que puede hacer con la funcin exec. Puede incluso hacer que SSI ejecute un comando usando la shell (/bin/sh, para ser exactos - o la shell DOS, si se encuentra en Win32). Lo siguiente, por ejemplo le dar un listado de directorios.

-

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

- -

o, en Windows

-

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

- -

Notar un formato estrao con esta directiva en Windows, porque el resultado de dir contiene la cadena de caracterers ``<dir>'' ,que confunde a los navegadores.

- -

Tenga en cuenta de que esta caracterstica es muy peligrosa, puesto que ejecutar cualquier cdigo que est especificado con la etiqueta - exec. Si tiene una situacin en la que los usuarios pueden editar contenido en sus pginas web, tales como por ejemplo un ``registro de visitas'', asegrese de tener esta caracterstica deshabilitada. Puede permitir SSI, pero no la caracterstica exec, con el argumento IncludesNOEXEC en la directiva Options.

-
top
-
-

Tcnicas avanzadas de SSI

- - -

Adems de mostrar contenido, SSI en Apache da la opcin de configurar variables y usar esas variables en comparaciones y condicionales.

- -

Configurando Variables

- -

Usando la directiva set, puede configurar variables para su uso posterior. La sintaxis es como sigue:

-

- <!--#set var="name" value="Rich" --> -

- -

Adems de configurar valores literales como esto, puede usar cualquier otra variable, incluyendo variables de entorno o las variables que se han mencionado antes (como por ejemplo LAST_MODIFIED) para dar valores a sus variables. Podr especificar que algo es una vaiable, en lugar de una cadena de caracters literal, usando el smbolo del dolar ($) antes del nombre de la variable.

- -

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

- -

Para poner el smbolo del dolar de manera literal en un valor de su variable tendr que escapar el smbolo del dolar con una barra "\".

-

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

- -

Por ltimo, si quiere poner una variable entre medias de una cadena de caracteres ms larga, y se da la coincidencia de que el nombre de la variable se encontrar con otros caracteres, y de esta manera se confundir con otros caracteres, puedes poner el nombre de la variable entre llaves, y as eliminar la confusin. (Es dificil encontrar un buen ejemplo para esto, pero con ste a lo mejor entiende lo que tratamos de transmitir.)

-

- <!--#set var="date" value="${DATE_LOCAL}_${DATE_GMT}" --> -

- - -

Expresiones condicionales

- - -

Ahora que tenemos variables, y somos capaces de comparar sus valores, podemos usarlas para expresar condicionales. Esto permite a SSI ser un cierto tipo de lenguaje de programacin diminuto. - mod_include provee una estrucura if, - elif, else, endif - para construir declaraciones condicionales. Esto le permite generar de manera efectiva multitud de pginas lgicas desde tan solo una pgina.

- -

La estructura de este sistema condicional es:

-

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

- -

Una test_condition puede ser cualquier tipo de comparacin lgica - o bien comparando valores entre ellos, o probando la ``verdad'' (o falsedad) de un valor en particular. (Una cadena de caracteres cualquiera es verdadera si no est vaca.) Para una lista completa de operadores de comparacin, vea la documentacin de mod_include.

- -

Por ejemplo, si quiere personalizar el texto en su pgina web basado en la hora actual, puede usar la siguiente receta, colocada en su pgina HTML:

- -

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

- -

Cualquier otra variable (o bien las que defina usted, o variables de entorno normales) puede usarse en declaraciones condicionales. - Vea Expresiones en el Servidor Apache HTTP para ms informacin sobre el motor de evaluacin de expresiones.

- -

Con la habilidad de Apache de configurar variables de entorno con directivas SetEnvIf, y otras directivas relacionadas, - esta funcionalidad puede llevarle a hacer una gran variedad de contenido dinmico en la parte de servidor sin tener que depender de una aplicacin web al completo.

- -
top
-
-

Conclusin

- -

Desde luego los SSI no son un reemplazo para CGI u otras tecnologas que se usen para generar pginas web dinmicas. Pero es un gran mtodo para aadir pequeas cantidades de contenido dinmico a pginas web, sin hacer mucho ms trabajo extra.

-
-
-

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

-
top

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
-
- \ No newline at end of file diff --git a/docs/manual/howto/ssi.html.es.utf8 b/docs/manual/howto/ssi.html.es.utf8 new file mode 100644 index 0000000000..4f0e6f23a5 --- /dev/null +++ b/docs/manual/howto/ssi.html.es.utf8 @@ -0,0 +1,356 @@ + + + + + +Tutorial de Apache httpd: Introduccin a los Server Side Includes + - Servidor HTTP Apache Versin 2.5 + + + + + + +
+

Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

+

Versin 2.5 del Servidor HTTP Apache

+
+
<-
+

Tutorial de Apache httpd: Introduccin a los Server Side Includes +

+
+

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

+
+ +

Los Server Side Includes (Inclusiones en la parte Servidor) facilitan un mtodo para aadir contenido dinmico a documentos HTML existentes.

+
+ +
top
+
+

Introduccin

+
Mdulos RelacionadosDirectivas Relacionadas
+ +

Este artculo trata sobre los Server Side Includes, generalmente llamados SSI. En este artculo, hablaremos sobre cmo configurar su servidor para permitir SSI e introduciremos algnas tcnicas bsicas de SSI para aadir contenido dinmico a sus pginas HTML existentes.

+ +

Ms adelante tambin hablaremos de algunas tcnicas algo ms avanzadas que pueden usarse con SSI, tales como declaraciones condicionales en sus directivas SSI.

+ +
top
+
+

Qu son los SSI?

+ +

SSI (Server Side Includes) son directivas que se introducen en pginas HTML y son evaluadas por el servidor mientras ste las sirve. Le permiten aadir contenido generado de manera dinmica a sus pginas HTML existentes sin tener que servir una pgina entera a travs de un programa CGI, u otra tecnologa para generar contenido dinmico.

+ +

Por ejemplo, podra colocar una directiva en una pgina existente de HTML de esta manera:

+ +

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

+ +

Y, cuando se sirve la pgina, este fragmento ser evaluado y reemplazado con su resultado:

+ +

+ Tuesday, 15-Jan-2013 19:28:54 EST +

+ +

La decisin sobre cundo usar SSI, o de cundo generar una pgina al completo con algn programa, suele depender generalmente de la cantidad de contenido esttico que contiene, y cunto de esa pgina tiene que ser recalculado cada vez que sta se sirve. SSI es un buen mtodo para aadir pequeas partes de informacin, tales como la hora actual - como se ha mostrado ms arriba. Pero si la mayora de su pgina se tiene que generar en el momento en el que se est sirviendo, necesita buscar otra opcin ms adecuada que no sea SSI.

+
top
+
+

Configurar su servidor para permitir SSI

+ + +

Para permitir SSI en su servidor, debe tener la siguiente directiva en su fichero httpd.conf , o en un fichero + .htaccess:

+ +
Options +Includes
+ + +

Esto le dice a Apache que quiere permitir que se examinen los ficheros buscando directivas SSI. Tenga en cuenta que la mayora de las configuraciones contienen mltiples directivas Options que pueden sobreescribirse las unas a las otras. Probablemente necesitar aplicar Options al directorio especfico donde quiere SSI activado para asegurarse de que se evala en ltimo lugar y por tanto se acabar aplicando.

+ +

No se examina cualquier fichero buscando directivas SSI. Usted le tiene que indicar a Apache qu ficheros se tienen que examinar. Hay dos formas de hacer esto. Puede decirle a Apache que examine cualquier fichero con una extensin determinada, como por ejemplo .shtml, con las siguientes directivas:

+ +
AddType text/html .shtml
+AddOutputFilter INCLUDES .shtml
+ + +

Una desventaja de este mtodo es que si quisiera aadir directivas SSI a una pgina ya existente, tendra que cambiar el nombre de la pgina, y todos los enlaces que apuntasen a esa pgina, todo para poder darle la extensin .shtml y que esas directivas sean interpretadas.

+ +

El otro mtodo es usar la directiva XBitHack :

+ +
XBitHack on
+ + +

XBitHack le dice a Apache que examine ficheros buscando directivas SSI si los ficheros tienen el bit de ejecucin configurado. Asi que, para aadir directivas SSI a una pgina existente, en lugar de tener que cambiarle el nombre, solo tendra que convertirla en ejecutable usando chmod.

+ +

+ chmod +x pagename.html +

+ +

Una breve recomendacin de qu no hay que hacer. Ocasionalmente vemos gente recomendar que le diga a Apache que examine todos los ficheros + .html para activar SSI, para no tener que lidiar renombrando los ficheros a .shtml. Quizs estas personas no hayan oido hablar de XBitHack. Lo que hay que tener en cuenta, es que haciendo eso, est pidiendo al Apache que lea cada uno de los ficheros que manda al cliente, incluso si no contenien directivas SSI. Esto puede ralentizar bastante el servidor, y no es una buena idea.

+ +

Por supuesto, en Windows, no hay tal cosa como la configuracin del bit de ejecucin, as que esto limita las opciones un poco.

+ +

En su configuracin por defecto, Apache no enva la fecha de ltima modificacin o la longitud de contenido de pginas SSI porque es dificil calcular estos valores para contenido dinmico. Esto puede impedir que se cachee un documento, y dar como resultado en apareciencia un rendimiento ms lento del cliente. Hay dos maneras de solucionar esto:

+ +
    +
  1. Usando la configuracin XBitHack Full. Esto le indica a apache que determine la fecha de ltima modificacin mirando slo la fecha del fichero que se ha solicitado originalmente, obviando la modificacin de cualquier otro fichero al que se hace referencia mediante SSI.
    2. + +
  2. Use las directivas facilitadas por mod_expires para configurar una expiracin especfica de tiempo en sus ficheros, y as hacer saber a proxies o navegadores web que es aceptable cachearlos.
    3. +
+
top
+
+

Directivas SSI bsicas

+ +

Las directivas SSI tienen la sintaxis siguiente:

+

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

+ +

Se formatean como comentarios HTML, as si no tiene SSI habilitado correctamente, el navegador las obviar, pero todava sern visibles en el fichero HTML. Si tiene SSI configurado correctamente, la directiva ser reemplazada con su propio resultado.

+ +

Esta funcin es una de tantas, y hablaremos de algunas de ellas ms adelante. Por ahora, aqu mostramos unos ejemplos de lo que puede hacer con SSI.

+ +

La fecha de hoy

+ +

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

+ +

La funcin echo sencillamente muestra el valor de una variable. Hay muchas variables estndar que incluyen un conjunto de variables de entorno disponibles para programas CGI. Tambin puede definir sus propias variables con la funcin set.

+ +

Si no le gusta el formato en el que se imprime la fecha, puede usar la funcin config, con un atributo + timefmt para modificar ese formato.

+ +

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

+ + +

Fecha de modificacin del fichero

+ +

+ La ltima modificacin de este documento <!--#flastmod file="index.html" --> +

+ +

Esta funcin tambin est sujeta a configuraciones de formato de + timefmt.

+ + +

Incluyendo los resultados de un programa CGI

+ +

Este es uno de los usos ms comunes de SSI - para sacar el resultado de un programa CGI, tal y como ocurre con el que fuera el programa favorito de todos, un ``contador de visitas.''

+ +

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

+ + +
top
+
+

Ms ejemplos

+ + +

A continuacin hay algunos ejemplos especficos de cosas que puede hacer con SSI en sus documentos HTML.

+ +

Cundo fue modificado este documento?

+ +

Antes mencionamos que puede usar SSI para informar al usuario cuando el documento ha sido modificado por ltima vez. Aun as, el mtodo actual para hacerlo se dej en cuestin. El cdigo que se muestra a continuacin, puesto en un documento HTML, pondr ese sello de tiempo en su pgina. Por descontado, tendr que tener SSI habilitado correctamente, como se indic ms arriba.

+

+ <!--#config timefmt="%A %B %d, %Y" -->
+ Ultima modificacin de este fichero <!--#flastmod file="ssi.shtml" --> +

+ +

Obviamente, necesitar sustituir el nombre de fichero + ssi.shtml con el nombre real del fichero al que usted hace referencia. Esto puede ser inconveniente si solo est buscando un trozo genrico de cdigo que pueda copiar y pegar en cualquier fichero, asi que probablemente necesite usar la variable LAST_MODIFIED en su lugar:

+

+ <!--#config timefmt="%D" -->
+ ltima modificacin de este fichero <!--#echo var="LAST_MODIFIED" --> +

+ +

Para ms detalles sobre el formato timefmt, vaya a su buscador favorito y busque strftime. La sintaxis es la misma.

+ + +

Incluyendo un pie de pgina estndar

+ + +

Si gestiona un sitio que tiene ms de unas cuantas pginas, probablemente se de cuenta de que modificar todas esa pginas es un autntico engorro, especialmente si trata de mantener una apareciencia homognea en todas ellas.

+ +

Si usa un Include de fichero para la cabecera y/o pie de pgina puede reducir la carga de trabajo de estas actualizaciones. Solo tiene que hacer un slo pie de pgina, y despus incluirlo en cada pgina con el comando SSI include. La funcin include + puede determinar qu fichero incluir cuando usa el atributo + file, o el atributo virtual. El atributo file es una ruta de fichero, relativa al directorio actual. Eso significa que no puede ser una ruta de fichero absoluta (que comienza con /), ni tampoco puede contener ../ como parte de la ruta. El atributo virtual es probablemente ms til, y debera especificar una URL relativa al documento que se est sirviendo. Puede empezar con una /, pero debe estar en el mismo servidor que el fichero que se est sirviendo.

+

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

+ +

Frecuentemente combinaremos las dos ltimas, poniendo una directiva + LAST_MODIFIED dentro de un fichero de pie de pgina que va a ser incluido. Se pueden encontrar directivas SSI en el fichero que se incluye, las inclusiones pueden anidarse - lo que quiere decir, que el fichero incluido puede incluir otro fichero, y as sucesivamente.

+ + +
top
+
+

Qu ms puedo configurar?

+ + +

Adems de poder configurar el formato de la hora, tambin puede configurar dos cosas ms.

+ +

Generalmente, cuando algo sale mal con sus directivas SSI, obtiene el mensaje (ha ocurrido un error procesando esta directiva)

+

+ [an error occurred while processing this directive] +

+ +

Si quiere cambiar ese mensaje por otra cosa, puede hacerlo con el atributo errmsg para la funcin + config:

+

+ <!--#config errmsg="[Parece que no sabe cmo usar SSI]" --> +

+ +

Afortunadamente, los usuarios finales nunca vern este mensaje, porque habr resuelto todos los problemas con sus directivas SSI antes de publicar su pgina web. (Verdad?)

+ +

Y puede configurar el formato en el que los tamaos de fichero se muestran con el formato sizefmt. Puede especificar + bytes para un recuento total en bytes, o + abbrev para un nmero abreviado en Kb o Mb, segn sea necesario.

+
top
+
+

Ejecutando comandos

+ + +

Aqu tiene algo que puede hacer con la funcin exec. Puede incluso hacer que SSI ejecute un comando usando la shell (/bin/sh, para ser exactos - o la shell DOS, si se encuentra en Win32). Lo siguiente, por ejemplo le dar un listado de directorios.

+

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

+ +

o, en Windows

+

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

+ +

Notar un formato estrao con esta directiva en Windows, porque el resultado de dir contiene la cadena de caracterers ``<dir>'' ,que confunde a los navegadores.

+ +

Tenga en cuenta de que esta caracterstica es muy peligrosa, puesto que ejecutar cualquier cdigo que est especificado con la etiqueta + exec. Si tiene una situacin en la que los usuarios pueden editar contenido en sus pginas web, tales como por ejemplo un ``registro de visitas'', asegrese de tener esta caracterstica deshabilitada. Puede permitir SSI, pero no la caracterstica exec, con el argumento IncludesNOEXEC en la directiva Options.

+
top
+
+

Tcnicas avanzadas de SSI

+ + +

Adems de mostrar contenido, SSI en Apache da la opcin de configurar variables y usar esas variables en comparaciones y condicionales.

+ +

Configurando Variables

+ +

Usando la directiva set, puede configurar variables para su uso posterior. La sintaxis es como sigue:

+

+ <!--#set var="name" value="Rich" --> +

+ +

Adems de configurar valores literales como esto, puede usar cualquier otra variable, incluyendo variables de entorno o las variables que se han mencionado antes (como por ejemplo LAST_MODIFIED) para dar valores a sus variables. Podr especificar que algo es una vaiable, en lugar de una cadena de caracters literal, usando el smbolo del dolar ($) antes del nombre de la variable.

+ +

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

+ +

Para poner el smbolo del dolar de manera literal en un valor de su variable tendr que escapar el smbolo del dolar con una barra "\".

+

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

+ +

Por ltimo, si quiere poner una variable entre medias de una cadena de caracteres ms larga, y se da la coincidencia de que el nombre de la variable se encontrar con otros caracteres, y de esta manera se confundir con otros caracteres, puedes poner el nombre de la variable entre llaves, y as eliminar la confusin. (Es dificil encontrar un buen ejemplo para esto, pero con ste a lo mejor entiende lo que tratamos de transmitir.)

+

+ <!--#set var="date" value="${DATE_LOCAL}_${DATE_GMT}" --> +

+ + +

Expresiones condicionales

+ + +

Ahora que tenemos variables, y somos capaces de comparar sus valores, podemos usarlas para expresar condicionales. Esto permite a SSI ser un cierto tipo de lenguaje de programacin diminuto. + mod_include provee una estrucura if, + elif, else, endif + para construir declaraciones condicionales. Esto le permite generar de manera efectiva multitud de pginas lgicas desde tan solo una pgina.

+ +

La estructura de este sistema condicional es:

+

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

+ +

Una test_condition puede ser cualquier tipo de comparacin lgica - o bien comparando valores entre ellos, o probando la ``verdad'' (o falsedad) de un valor en particular. (Una cadena de caracteres cualquiera es verdadera si no est vaca.) Para una lista completa de operadores de comparacin, vea la documentacin de mod_include.

+ +

Por ejemplo, si quiere personalizar el texto en su pgina web basado en la hora actual, puede usar la siguiente receta, colocada en su pgina HTML:

+ +

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

+ +

Cualquier otra variable (o bien las que defina usted, o variables de entorno normales) puede usarse en declaraciones condicionales. + Vea Expresiones en el Servidor Apache HTTP para ms informacin sobre el motor de evaluacin de expresiones.

+ +

Con la habilidad de Apache de configurar variables de entorno con directivas SetEnvIf, y otras directivas relacionadas, + esta funcionalidad puede llevarle a hacer una gran variedad de contenido dinmico en la parte de servidor sin tener que depender de una aplicacin web al completo.

+ +
top
+
+

Conclusin

+ +

Desde luego los SSI no son un reemplazo para CGI u otras tecnologas que se usen para generar pginas web dinmicas. Pero es un gran mtodo para aadir pequeas cantidades de contenido dinmico a pginas web, sin hacer mucho ms trabajo extra.

+
+
+

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

+
top

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/howto/ssi.html.fr b/docs/manual/howto/ssi.html.fr deleted file mode 100644 index 9e5fe04990..0000000000 --- a/docs/manual/howto/ssi.html.fr +++ /dev/null @@ -1,518 +0,0 @@ - - - - - -Tutoriel Apache httpd : Introduction aux "Inclusions Côté Serveur" -(Server Side Includes - SSI) - Serveur HTTP Apache Version 2.5 - - - - - - -
-

Modules | Directives | FAQ | Glossaire | Plan du site

-

Serveur HTTP Apache Version 2.5

-
-
<-
-

Tutoriel Apache httpd : Introduction aux "Inclusions Côté Serveur" -(Server Side Includes - SSI)

-
-

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

-
- -

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

-
- -
top
-
-

Introduction

-
Modules ApparentésDirectives Apparentées
- -

Cet article traite des Inclusions Côté Serveur (Server Side - Includes), plus communément appelés SSI. Vous trouverez ici la - manière de configurer votre serveur pour permettre les SSI, ainsi - qu'une introduction à quelques techniques SSI de base permettant - d'ajouter du contenu dynamique à vos pages HTML préexistantes.

- -

La dernière partie de cet article sera consacrée aux - configurations SSI plus avancées, telles que les expressions - conditionnelles dans les directives SSI.

- -
top
-
-

Qu'est-ce que SSI ?

- -

SSI (Server Side Includes) est constitué de directives placées dans - des pages HTML, et évaluées par le serveur au moment où les pages - sont servies. Elles vous permettent d'ajouter du contenu généré - dynamiquement à une page HTML préexistante, sans avoir à servir la - page entière via un programme CGI, ou toute autre technologie de - contenu dynamique.

- -

Par exemple, vous pouvez insérer la directive suivante dans une - page HTML existante :

- -

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

- -

Ainsi, lorsque la page sera servie, la directive sera évaluée et - remplacée par sa valeur :

- -

- Tuesday, 15-Jan-2013 19:28:54 EST -

- -

Le choix entre l'utilisation des SSI et la génération entière de - la page par un programme quelconque, est en général dicté par la - proportion de contenu statique et de contenu devant être généré - chaque fois que la page est servie. SSI est idéal pour ajouter de - petites quantités d'information, comme l'heure courante dans - l'exemple précédent. Mais si la - plus grande partie de votre page est générée au moment où elle est - servie, vous devez vous tourner vers une autre solution.

-
top
-
-

Configurer votre serveur pour permettre les SSI

- - -

Pour permettre l'utilisation des SSI sur votre serveur, vous - devez ajouter la directive suivante dans votre fichier - httpd.conf, ou dans un fichier .htaccess - :

-
Options +Includes
- - -

Cette directive indique à Apache que vous désirez permettre la - recherche de directives SSI lors de l'interprétation des fichiers. - Notez cependant que la plupart des configurations contiennent de - nombreuses directives Options - qui peuvent s'écraser les unes les autres. Vous devrez probablement - appliquer ces directives Options au répertoire - spécifique pour lequel vous voulez activer les SSI, afin d'être sûr - qu'elles y seront bien activées.

- -

Tout fichier ne fera cependant pas l'objet de recherche de - directives SSI. Vous devez indiquer à Apache quels fichiers seront - concernés. Vous pouvez y parvenir en indiquant une extension, comme - .shtml, à l'aide des directives suivantes :

-
AddType text/html .shtml
-AddOutputFilter INCLUDES .shtml
- - -

Un des désavantages de cette approche réside dans le fait que si - vous voulez ajouter des directives SSI à une page préexistante, vous - devrez changer le nom de cette page, et donc tout lien qui la - contient, de façon à ce qu'elle possède l'extension - .shtml, condition nécessaire pour que les directives - SSI qu'elle contient soient traitées.

- -

Une autre méthode consiste à utiliser la directive XBitHack :

-
XBitHack on
- - -

La directive XBitHack - indique à Apache qu'il doit rechercher des directivves SSI dans les - fichiers si leur bit d'exécution est positionné. Il n'est ainsi plus - nécessaire de changer le nom du fichier pour ajouter des directives - SSI à une page préexistante ; vous devez simplement attribuer les - droits d'exécution au fichier à l'aide de chmod.

-

- chmod +x pagename.html -

- -

Un bref commentaire sur ce qu'il ne faut pas faire. Certaines - personnes peuvent vous conseiller de tout simplement indiquer à - Apache de rechercher des directives SSI dans tous les fichiers - .html, ce qui vous évite d'avoir à gérer les noms de - fichiers avec extension .shtml. Ils n'ont probablement - pas entendu parler de la directive XBitHack. En effet, vous devez - garder à l'esprit qu'en faisant ceci, Apache va devoir rechercher - des directives SSI dans chaque fichier qu'il sert, même s'il n'en - contient aucune. Ce n'est donc pas une bonne idée car les - performances peuvent en être sensiblement affectées.

- -

Bien entendu, sous Windows, il n'y a pas de bit d'exécution à - positionner, ce qui limite un peu vos choix.

- -

Dans sa configuration par défaut, Apache n'envoie pas la date de - dernière modification ou les en-têtes HTTP relatifs à la taille des - contenus dans les pages SSI, car ses valeurs sont difficiles à - calculer pour les contenus dynamiques. Ceci peut induire une - impression de diminution des performances côté client, en empêchant - la mise en cache de votre document. Il existe deux méthodes pour - résoudre ce problème :

- -
    -
  1. Utilisez la configuration XBitHack Full. Elle - indique à Apache de déterminer la date de dernière modification en - ne regardant que la date du fichier à l'origine de la requête, - tout en ignorant la date de modification de tout fichier inclus.
    2. - -
  2. Utilisez les directives fournies par le module - mod_expires pour définir de manière explicite la - date d'expiration de vos fichiers, laissant par la-même - aux navigateurs et aux mandataires le soin de déterminer s'il est - opportun ou non de les mettre en cache.
    3. -
-
top
-
-

Directives SSI de base

- -

Les directives SSI adoptent la syntaxe suivante :

-

- <!--#fonction attribut=valeur attribut=valeur ... --> -

- -

Le format d'une directive SSI étant similaire à celui d'un - commentaire HTML, si vous n'avez pas activé correctement SSI, le - navigateur l'ignorera, mais elle sera encore visible dans le source - HTML. Si SSI est correctement configuré, la directive sera remplacée - par ses résultats.

- -

"fonction" peut prendre de nombreuses formes, et nous décrirons - plus précisément la plupart d'entre eux dans la prochaine version de - ce document. Pour le moment, voici quelques exemples de ce que vous - pouvez faire avec SSI.

- -

La date courante

- -

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

- -

La fonction echo permet d'afficher la valeur d'une - variable. Il existe un grand nombre de variables standards, y - compris l'ensemble des variables d'environnement disponibles pour - les programmes CGI. De plus, vous pouvez définir vos propres - variables à l'aide de la fonction set.

- -

Si vous n'aimez pas le format sous lequel la date s'affiche, vous - pouvez utiliser la fonction config avec un attribut - timefmt, pour le modifier.

- -

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

- - -

Date de modification du fichier

- -

- Dernière modification du document <!--#flastmod file="index.html" --> -

- -

Le format peut là aussi être modifié à l'aide de l'attribut - timefmt.

- - -

Inclusion des résultats d'un programme CGI

- -

C'est le cas le plus courant d'utilisation des SSI - afficher les - résultats d'un programme CGI, comme l'universellement adoré - "compteur d'accès".

- -

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

- - -
top
-
-

Exemples additionnels

- - -

Vous trouverez dans ce qui suit quelques exemples spécifiques de - ce que vous pouvez faire de vos documents HTML avec SSI.

- -

Quand ce document a-t-il été modifié ?

- -

Nous avons mentionné plus haut que vous pouviez utiliser SSI pour - informer l'utilisateur de la date de dernière modification du - document. Cependant, la méthode pour y parvenir n'a pas été vraiment - abordée. Placé dans votre document HTML, le code suivant va insérer - un repère de temps dans votre page. Bien entendu, SSI devra avoir - été correctement activé, comme décrit plus haut.

-

- <!--#config timefmt="%A %B %d, %Y" -->
- Dernière modification du fichier <!--#flastmod file="ssi.shtml" --> -

- -

Bien entendu, vous devez remplacer ssi.shtml par le - nom du fichier auquel vous faites référence. Ceci ne conviendra pas - si vous recherchez un morceau de code générique que vous pourrez - insérer dans tout fichier ; dans ce cas, il est préférable - d'utiliser la variable LAST_MODIFIED :

-

- <!--#config timefmt="%D" -->
- This file last modified <!--#echo var="LAST_MODIFIED" --> -

- -

Pour plus de détails sur le format timefmt, tapez - strftime dans votre moteur de recherche préferé. La - syntaxe est identique.

- - -

Inclusion d'un pied de page standard

- - -

Si le site que vous gérez comporte plus que quelques pages, vous - allez vite vous apercevoir qu'effectuer des modifications sur toutes - ces pages peut devenir très contraignant, en particulier si vous - voulez qu'elles conservent un aspect homogène.

- -

Inclure un fichier pour un en-tête et/ou un pied de page peut - simplifier cette corvée de mises à jour. Il vous suffit de - confectionner un fichier de pied de page, et de l'inclure dans - chaque page à l'aide de l'élément SSI include. Pour - définir le fichier à inclure, la fonction include peut - utiliser soit l'attribut file, soit l'attribut - virtual. L'attribut file est un chemin de - fichier relatif au répertoire courant. C'est à dire qu'il - ne peut ni avoir pour valeur un chemin absolu (commençant par /), ni - comporter "../" dans son chemin. L'attribut virtual est - probablement plus commode, et peut spécifier une URL relative au - document servi. Elle peut commencer par un /, mais le fichier inclus - et le fichier servi doivent résider sur le même serveur.

-

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

- -

Je combinerai souvent ces deux derniers points, en ajoutant une - directive LAST_MODIFIED dans un fichier de pied de page - destiné à être inclus. Le fichier inclus peut contenir des - directives SSI, et les inclusions peuvent être imbriquées - à - savoir, le fichier inclus peut inclure un autre fichier, etc...

- - -
top
-
-

Que puis-je configurer d'autre ?

- - -

En plus du format de date, vous pouvez utiliser l'élément - config pour configurer deux autres choses.

- -

En général, lorsque quelque chose se passe mal avec votre - directive SSI, vous recevez le message :

-

- [an error occurred while processing this directive] -

- -

Pour modifier ce message, vous pouvez utiliser l'attribut - errmsg avec la fonction config :

-

- <!--#config errmsg="[Il semblerait que vous ne sachiez pas - utiliser les SSI]" --> -

- -

Il est cependant probable que les utilisateurs finaux ne voient - jamais ce message, car vous aurez résolu tous les problèmes issus de - vos directives SSI avant que votre site ne soit mis en production. - (N'est-ce pas ?)

- -

Vous pouvez aussi modifier le format sous lequel les tailles de - fichiers sont affichées à l'aide de l'attribut sizefmt. - Vous pouvez spécifier bytes pour un affichage en - octets, ou abbrev pour un affichage plus concis en Ko - ou Mo, selon le cas.

-
top
-
-

Exécution de commandes

- - -

Voici autre chose que vous pouvez faire avec la fonction - exec. Vous pouvez vraiment faire exécuter une commande - par SSI en utilisant le shell (/bin/sh, pour être plus - précis - ou le shell DOS, si vous êtes sous Win32). Par exemple, ce - qui suit vous permet d'afficher le contenu d'un répertoire.

-

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

- -

ou, sous Windows

-

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

- -

Vous noterez probablement l'étrange formatage provoqué par cette - directive sous Windows, car la sortie de dir contient - la chaîne de caractères "<dir>", ce qui trompe le - navigateur.

- -

Notez que cette fonctionnalité est très dangereuse, car elle va - permettre d'exécuter tout code associé à l'élément - exec. Si vous êtes dans la situation où les - utilisateurs peuvent éditer le contenu de vos pages web, dans le cas - d'un "livre d'or" par exemple, assurez-vous de désactiver cette - fonctionnalité. Vous pouvez, tout en permettant les SSI, désactiver - la fonctionnalité exec à l'aide de l'argument - IncludesNOEXEC de la directive - Options.

-
top
-
-

Techniques SSI avancées

- - -

Outre l'affichage de contenu, les SSI d'Apache vous permettent de - définir des variables, et de les utiliser dans des comparaisons et - des conditions.

- -

Définition de variables

- -

Avec l'élément set, vous pouvez définir des - variables pour un usage ultérieur. Comme nous en aurons besoin plus - loin, nous allons en parler tout de suite. La syntaxe se présente - comme suit :

-

- <!--#set var="name" value="Rich" --> -

- -

Pour affecter une valeur à vos variables, en plus de la - définition littérale de l'exemple ci-dessus, vous pouvez utiliser - une autre variable, y compris les variables d'environnement, ou les variables - décrites plus haut (comme LAST_MODIFIED par exemple). - Pour indiquer qu'il s'agit d'une variable et non d'une chaîne, vous - devez utiliser le symbole dollar ($) devant le nom de la - variable.

- -

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

- -

Pour insérer un caractère $ dans la valeur de votre variable, - vous devez l'échapper à l'aide d'un backslash.

-

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

- -

Enfin, si vous voulez insérer une variable dans une chaîne, et - s'il y a une chance pour que le nom de la variable se confonde avec - le reste de la chaîne, vous pouvez l'entourer d'accolades pour - eviter toute confusion (Il est difficile de trouver un bon exemple - pour illustrer ceci, mais j'espère que vous comprendrez).

-

- <!--#set var="date" value="${DATE_LOCAL}_${DATE_GMT}" --> -

- - -

Expressions conditionnelles

- - -

Maintenent que nous avons des variables, et que nous pouvons - définir et comparer leurs valeurs, nous sommes à même de les - utiliser dans des expressions conditionnelles. Ceci confère à SSI le - statut de petit langage de programmation. - mod_include fournit une structure if, - elif, else, endif pour la - construction d'expressions conditionnelles, ce qui vous permet de - générer plusieurs pages logiques à partir d'une seule vraie - page.

- -

La structure de l'expression conditionnelle est :

-

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

- -

Une condition peut revêtir la forme de toute comparaison - logique - soit une comparaison de valeurs avec une autre, soit une - vérification de la "vérité" d'une valeur particulière (Une chaîne - donnée est vraie si elle n'est pas vide). Pour une liste exhaustive - des opérateurs de comparaison disponibles, voir la documentation du - module mod_include.

- -

Par exemple, spour insérer l'heure du jour dans votre page web, - vous pouvez ajouter ces lignes dans la page HTML :

- -

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

- -

Toute autre variable (que vous avez définie, ou une variable - d'environnement normale) peut être utilisée dans les expressions - conditionnelles. Voir le document Expressions - rationnelles dans le serveur HTTP Apache pour plus de détails à - propos du fonctionnement du moteur d'évaluation des expressions - rationnelles.

- -

Associée à la possibilité avec Apache de définir - des variables d'environnement à l'aide de directives - SetEnvIf, ainsi que d'autres directives en rapport, - cette fonctionnalité vous permet d'ajouter une grande variété - de contenus dynamiques côté serveur sans avoir à concevoir une - application web de A à Z.

- -
top
-
-

Conclusion

- -

SSI ne remplace certainement pas CGI, ou d'autres technologies - utilisées pour la génération de pages web dynamiques. Mais c'est une - bonne méthode pour ajouter des petits contenus dynamiques à vos - pages, sans devoir fournir un gros effort supplémentaire.

-
-
-

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

-
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
-
- \ No newline at end of file diff --git a/docs/manual/howto/ssi.html.fr.utf8 b/docs/manual/howto/ssi.html.fr.utf8 new file mode 100644 index 0000000000..9e5fe04990 --- /dev/null +++ b/docs/manual/howto/ssi.html.fr.utf8 @@ -0,0 +1,518 @@ + + + + + +Tutoriel Apache httpd : Introduction aux "Inclusions Côté Serveur" +(Server Side Includes - SSI) - Serveur HTTP Apache Version 2.5 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.5

+
+
<-
+

Tutoriel Apache httpd : Introduction aux "Inclusions Côté Serveur" +(Server Side Includes - SSI)

+
+

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

+
+ +

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

+
+ +
top
+
+

Introduction

+
Modules ApparentésDirectives Apparentées
+ +

Cet article traite des Inclusions Côté Serveur (Server Side + Includes), plus communément appelés SSI. Vous trouverez ici la + manière de configurer votre serveur pour permettre les SSI, ainsi + qu'une introduction à quelques techniques SSI de base permettant + d'ajouter du contenu dynamique à vos pages HTML préexistantes.

+ +

La dernière partie de cet article sera consacrée aux + configurations SSI plus avancées, telles que les expressions + conditionnelles dans les directives SSI.

+ +
top
+
+

Qu'est-ce que SSI ?

+ +

SSI (Server Side Includes) est constitué de directives placées dans + des pages HTML, et évaluées par le serveur au moment où les pages + sont servies. Elles vous permettent d'ajouter du contenu généré + dynamiquement à une page HTML préexistante, sans avoir à servir la + page entière via un programme CGI, ou toute autre technologie de + contenu dynamique.

+ +

Par exemple, vous pouvez insérer la directive suivante dans une + page HTML existante :

+ +

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

+ +

Ainsi, lorsque la page sera servie, la directive sera évaluée et + remplacée par sa valeur :

+ +

+ Tuesday, 15-Jan-2013 19:28:54 EST +

+ +

Le choix entre l'utilisation des SSI et la génération entière de + la page par un programme quelconque, est en général dicté par la + proportion de contenu statique et de contenu devant être généré + chaque fois que la page est servie. SSI est idéal pour ajouter de + petites quantités d'information, comme l'heure courante dans + l'exemple précédent. Mais si la + plus grande partie de votre page est générée au moment où elle est + servie, vous devez vous tourner vers une autre solution.

+
top
+
+

Configurer votre serveur pour permettre les SSI

+ + +

Pour permettre l'utilisation des SSI sur votre serveur, vous + devez ajouter la directive suivante dans votre fichier + httpd.conf, ou dans un fichier .htaccess + :

+
Options +Includes
+ + +

Cette directive indique à Apache que vous désirez permettre la + recherche de directives SSI lors de l'interprétation des fichiers. + Notez cependant que la plupart des configurations contiennent de + nombreuses directives Options + qui peuvent s'écraser les unes les autres. Vous devrez probablement + appliquer ces directives Options au répertoire + spécifique pour lequel vous voulez activer les SSI, afin d'être sûr + qu'elles y seront bien activées.

+ +

Tout fichier ne fera cependant pas l'objet de recherche de + directives SSI. Vous devez indiquer à Apache quels fichiers seront + concernés. Vous pouvez y parvenir en indiquant une extension, comme + .shtml, à l'aide des directives suivantes :

+
AddType text/html .shtml
+AddOutputFilter INCLUDES .shtml
+ + +

Un des désavantages de cette approche réside dans le fait que si + vous voulez ajouter des directives SSI à une page préexistante, vous + devrez changer le nom de cette page, et donc tout lien qui la + contient, de façon à ce qu'elle possède l'extension + .shtml, condition nécessaire pour que les directives + SSI qu'elle contient soient traitées.

+ +

Une autre méthode consiste à utiliser la directive XBitHack :

+
XBitHack on
+ + +

La directive XBitHack + indique à Apache qu'il doit rechercher des directivves SSI dans les + fichiers si leur bit d'exécution est positionné. Il n'est ainsi plus + nécessaire de changer le nom du fichier pour ajouter des directives + SSI à une page préexistante ; vous devez simplement attribuer les + droits d'exécution au fichier à l'aide de chmod.

+

+ chmod +x pagename.html +

+ +

Un bref commentaire sur ce qu'il ne faut pas faire. Certaines + personnes peuvent vous conseiller de tout simplement indiquer à + Apache de rechercher des directives SSI dans tous les fichiers + .html, ce qui vous évite d'avoir à gérer les noms de + fichiers avec extension .shtml. Ils n'ont probablement + pas entendu parler de la directive XBitHack. En effet, vous devez + garder à l'esprit qu'en faisant ceci, Apache va devoir rechercher + des directives SSI dans chaque fichier qu'il sert, même s'il n'en + contient aucune. Ce n'est donc pas une bonne idée car les + performances peuvent en être sensiblement affectées.

+ +

Bien entendu, sous Windows, il n'y a pas de bit d'exécution à + positionner, ce qui limite un peu vos choix.

+ +

Dans sa configuration par défaut, Apache n'envoie pas la date de + dernière modification ou les en-têtes HTTP relatifs à la taille des + contenus dans les pages SSI, car ses valeurs sont difficiles à + calculer pour les contenus dynamiques. Ceci peut induire une + impression de diminution des performances côté client, en empêchant + la mise en cache de votre document. Il existe deux méthodes pour + résoudre ce problème :

+ +
    +
  1. Utilisez la configuration XBitHack Full. Elle + indique à Apache de déterminer la date de dernière modification en + ne regardant que la date du fichier à l'origine de la requête, + tout en ignorant la date de modification de tout fichier inclus.
    2. + +
  2. Utilisez les directives fournies par le module + mod_expires pour définir de manière explicite la + date d'expiration de vos fichiers, laissant par la-même + aux navigateurs et aux mandataires le soin de déterminer s'il est + opportun ou non de les mettre en cache.
    3. +
+
top
+
+

Directives SSI de base

+ +

Les directives SSI adoptent la syntaxe suivante :

+

+ <!--#fonction attribut=valeur attribut=valeur ... --> +

+ +

Le format d'une directive SSI étant similaire à celui d'un + commentaire HTML, si vous n'avez pas activé correctement SSI, le + navigateur l'ignorera, mais elle sera encore visible dans le source + HTML. Si SSI est correctement configuré, la directive sera remplacée + par ses résultats.

+ +

"fonction" peut prendre de nombreuses formes, et nous décrirons + plus précisément la plupart d'entre eux dans la prochaine version de + ce document. Pour le moment, voici quelques exemples de ce que vous + pouvez faire avec SSI.

+ +

La date courante

+ +

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

+ +

La fonction echo permet d'afficher la valeur d'une + variable. Il existe un grand nombre de variables standards, y + compris l'ensemble des variables d'environnement disponibles pour + les programmes CGI. De plus, vous pouvez définir vos propres + variables à l'aide de la fonction set.

+ +

Si vous n'aimez pas le format sous lequel la date s'affiche, vous + pouvez utiliser la fonction config avec un attribut + timefmt, pour le modifier.

+ +

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

+ + +

Date de modification du fichier

+ +

+ Dernière modification du document <!--#flastmod file="index.html" --> +

+ +

Le format peut là aussi être modifié à l'aide de l'attribut + timefmt.

+ + +

Inclusion des résultats d'un programme CGI

+ +

C'est le cas le plus courant d'utilisation des SSI - afficher les + résultats d'un programme CGI, comme l'universellement adoré + "compteur d'accès".

+ +

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

+ + +
top
+
+

Exemples additionnels

+ + +

Vous trouverez dans ce qui suit quelques exemples spécifiques de + ce que vous pouvez faire de vos documents HTML avec SSI.

+ +

Quand ce document a-t-il été modifié ?

+ +

Nous avons mentionné plus haut que vous pouviez utiliser SSI pour + informer l'utilisateur de la date de dernière modification du + document. Cependant, la méthode pour y parvenir n'a pas été vraiment + abordée. Placé dans votre document HTML, le code suivant va insérer + un repère de temps dans votre page. Bien entendu, SSI devra avoir + été correctement activé, comme décrit plus haut.

+

+ <!--#config timefmt="%A %B %d, %Y" -->
+ Dernière modification du fichier <!--#flastmod file="ssi.shtml" --> +

+ +

Bien entendu, vous devez remplacer ssi.shtml par le + nom du fichier auquel vous faites référence. Ceci ne conviendra pas + si vous recherchez un morceau de code générique que vous pourrez + insérer dans tout fichier ; dans ce cas, il est préférable + d'utiliser la variable LAST_MODIFIED :

+

+ <!--#config timefmt="%D" -->
+ This file last modified <!--#echo var="LAST_MODIFIED" --> +

+ +

Pour plus de détails sur le format timefmt, tapez + strftime dans votre moteur de recherche préferé. La + syntaxe est identique.

+ + +

Inclusion d'un pied de page standard

+ + +

Si le site que vous gérez comporte plus que quelques pages, vous + allez vite vous apercevoir qu'effectuer des modifications sur toutes + ces pages peut devenir très contraignant, en particulier si vous + voulez qu'elles conservent un aspect homogène.

+ +

Inclure un fichier pour un en-tête et/ou un pied de page peut + simplifier cette corvée de mises à jour. Il vous suffit de + confectionner un fichier de pied de page, et de l'inclure dans + chaque page à l'aide de l'élément SSI include. Pour + définir le fichier à inclure, la fonction include peut + utiliser soit l'attribut file, soit l'attribut + virtual. L'attribut file est un chemin de + fichier relatif au répertoire courant. C'est à dire qu'il + ne peut ni avoir pour valeur un chemin absolu (commençant par /), ni + comporter "../" dans son chemin. L'attribut virtual est + probablement plus commode, et peut spécifier une URL relative au + document servi. Elle peut commencer par un /, mais le fichier inclus + et le fichier servi doivent résider sur le même serveur.

+

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

+ +

Je combinerai souvent ces deux derniers points, en ajoutant une + directive LAST_MODIFIED dans un fichier de pied de page + destiné à être inclus. Le fichier inclus peut contenir des + directives SSI, et les inclusions peuvent être imbriquées - à + savoir, le fichier inclus peut inclure un autre fichier, etc...

+ + +
top
+
+

Que puis-je configurer d'autre ?

+ + +

En plus du format de date, vous pouvez utiliser l'élément + config pour configurer deux autres choses.

+ +

En général, lorsque quelque chose se passe mal avec votre + directive SSI, vous recevez le message :

+

+ [an error occurred while processing this directive] +

+ +

Pour modifier ce message, vous pouvez utiliser l'attribut + errmsg avec la fonction config :

+

+ <!--#config errmsg="[Il semblerait que vous ne sachiez pas + utiliser les SSI]" --> +

+ +

Il est cependant probable que les utilisateurs finaux ne voient + jamais ce message, car vous aurez résolu tous les problèmes issus de + vos directives SSI avant que votre site ne soit mis en production. + (N'est-ce pas ?)

+ +

Vous pouvez aussi modifier le format sous lequel les tailles de + fichiers sont affichées à l'aide de l'attribut sizefmt. + Vous pouvez spécifier bytes pour un affichage en + octets, ou abbrev pour un affichage plus concis en Ko + ou Mo, selon le cas.

+
top
+
+

Exécution de commandes

+ + +

Voici autre chose que vous pouvez faire avec la fonction + exec. Vous pouvez vraiment faire exécuter une commande + par SSI en utilisant le shell (/bin/sh, pour être plus + précis - ou le shell DOS, si vous êtes sous Win32). Par exemple, ce + qui suit vous permet d'afficher le contenu d'un répertoire.

+

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

+ +

ou, sous Windows

+

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

+ +

Vous noterez probablement l'étrange formatage provoqué par cette + directive sous Windows, car la sortie de dir contient + la chaîne de caractères "<dir>", ce qui trompe le + navigateur.

+ +

Notez que cette fonctionnalité est très dangereuse, car elle va + permettre d'exécuter tout code associé à l'élément + exec. Si vous êtes dans la situation où les + utilisateurs peuvent éditer le contenu de vos pages web, dans le cas + d'un "livre d'or" par exemple, assurez-vous de désactiver cette + fonctionnalité. Vous pouvez, tout en permettant les SSI, désactiver + la fonctionnalité exec à l'aide de l'argument + IncludesNOEXEC de la directive + Options.

+
top
+
+

Techniques SSI avancées

+ + +

Outre l'affichage de contenu, les SSI d'Apache vous permettent de + définir des variables, et de les utiliser dans des comparaisons et + des conditions.

+ +

Définition de variables

+ +

Avec l'élément set, vous pouvez définir des + variables pour un usage ultérieur. Comme nous en aurons besoin plus + loin, nous allons en parler tout de suite. La syntaxe se présente + comme suit :

+

+ <!--#set var="name" value="Rich" --> +

+ +

Pour affecter une valeur à vos variables, en plus de la + définition littérale de l'exemple ci-dessus, vous pouvez utiliser + une autre variable, y compris les variables d'environnement, ou les variables + décrites plus haut (comme LAST_MODIFIED par exemple). + Pour indiquer qu'il s'agit d'une variable et non d'une chaîne, vous + devez utiliser le symbole dollar ($) devant le nom de la + variable.

+ +

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

+ +

Pour insérer un caractère $ dans la valeur de votre variable, + vous devez l'échapper à l'aide d'un backslash.

+

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

+ +

Enfin, si vous voulez insérer une variable dans une chaîne, et + s'il y a une chance pour que le nom de la variable se confonde avec + le reste de la chaîne, vous pouvez l'entourer d'accolades pour + eviter toute confusion (Il est difficile de trouver un bon exemple + pour illustrer ceci, mais j'espère que vous comprendrez).

+

+ <!--#set var="date" value="${DATE_LOCAL}_${DATE_GMT}" --> +

+ + +

Expressions conditionnelles

+ + +

Maintenent que nous avons des variables, et que nous pouvons + définir et comparer leurs valeurs, nous sommes à même de les + utiliser dans des expressions conditionnelles. Ceci confère à SSI le + statut de petit langage de programmation. + mod_include fournit une structure if, + elif, else, endif pour la + construction d'expressions conditionnelles, ce qui vous permet de + générer plusieurs pages logiques à partir d'une seule vraie + page.

+ +

La structure de l'expression conditionnelle est :

+

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

+ +

Une condition peut revêtir la forme de toute comparaison + logique - soit une comparaison de valeurs avec une autre, soit une + vérification de la "vérité" d'une valeur particulière (Une chaîne + donnée est vraie si elle n'est pas vide). Pour une liste exhaustive + des opérateurs de comparaison disponibles, voir la documentation du + module mod_include.

+ +

Par exemple, spour insérer l'heure du jour dans votre page web, + vous pouvez ajouter ces lignes dans la page HTML :

+ +

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

+ +

Toute autre variable (que vous avez définie, ou une variable + d'environnement normale) peut être utilisée dans les expressions + conditionnelles. Voir le document Expressions + rationnelles dans le serveur HTTP Apache pour plus de détails à + propos du fonctionnement du moteur d'évaluation des expressions + rationnelles.

+ +

Associée à la possibilité avec Apache de définir + des variables d'environnement à l'aide de directives + SetEnvIf, ainsi que d'autres directives en rapport, + cette fonctionnalité vous permet d'ajouter une grande variété + de contenus dynamiques côté serveur sans avoir à concevoir une + application web de A à Z.

+ +
top
+
+

Conclusion

+ +

SSI ne remplace certainement pas CGI, ou d'autres technologies + utilisées pour la génération de pages web dynamiques. Mais c'est une + bonne méthode pour ajouter des petits contenus dynamiques à vos + pages, sans devoir fournir un gros effort supplémentaire.

+
+
+

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

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/index.html b/docs/manual/index.html index a72aafa6f2..dcfdc973dc 100644 --- a/docs/manual/index.html +++ b/docs/manual/index.html @@ -14,7 +14,7 @@ Content-type: text/html; charset=ISO-8859-1 URI: index.html.es Content-Language: es -Content-type: text/html; charset=ISO-8859-1 +Content-type: text/html; charset=UTF-8 URI: index.html.fr Content-Language: fr diff --git a/docs/manual/index.html.en b/docs/manual/index.html.en index ff924aa09c..993ff58e22 100644 --- a/docs/manual/index.html.en +++ b/docs/manual/index.html.en @@ -30,12 +30,12 @@ Documentation

Available Languages:  da  |  de  |  en  | - es  | - fr  | + es  | + fr  |  ja  |  ko  | - pt-br  | - tr  | + pt-br  | + tr  |  zh-cn 

@@ -109,12 +109,12 @@ Documentation

Available Languages:  da  |  de  |  en  | - es  | - fr  | + es  | + fr  |  ja  |  ko  | - pt-br  | - tr  | + pt-br  | + tr  |  zh-cn 

Available Languages:  en  | - fr  | + fr  |  ko  | - tr 

+ tr 

top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
- - -
-

Modules | Directives | FAQ | Glossaire | Plan du site

-

Serveur HTTP Apache Version 2.5

-
-
<-
-

logresolve - Résoud les adresses IP en noms d'hôtes dans les - fichiers journaux d'Apache

-
-

Langues Disponibles:  en  | - fr  | - ko  | - tr 

-
- -

logresolve est un programme agissant après - traitement pour résoudre les adresses IP dans les journaux d'accès - d'Apache. Pour minimiser la charge de votre serveur de noms, - logresolve possède son propre cache interne sous forme d'une table - de hashage. Cela implique que chaque numéro IP ne fera l'objet - d'une requête DNS que la première fois où il est rencontré dans le - fichier journal.

- -

Le programme reçoit le fichier journal sur son entrée standard. - Les adresses IP doivent se trouver en tête de chaque ligne et - doivent être séparées du reste de la ligne par un espace.

-
- -
top
-
-

Syntaxe

- -

logresolve [ -s - nom-fichier ] [ -c ] < - access_log > access_log.new

-
top
-
-

Options

- -
- -
-s nom-fichier
- -
Spécifie le nom du fichier où seront enregistrées des -statistiques.
- -
-c
- -
Avec cette option, logresolve effectue certaines -vérifications DNS : après avoir trouvé le nom d'hôte correspondant à une -adresse IP, logresolve effectue une recherche DNS sur ce -nom d'hôte et vérifie si une des adresses IP trouvées correspond à -l'adresse originale.
- -
-
-
-

Langues Disponibles:  en  | - fr  | - ko  | - tr 

-
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
-
- \ No newline at end of file diff --git a/docs/manual/programs/logresolve.html.fr.utf8 b/docs/manual/programs/logresolve.html.fr.utf8 new file mode 100644 index 0000000000..2d94f42261 --- /dev/null +++ b/docs/manual/programs/logresolve.html.fr.utf8 @@ -0,0 +1,106 @@ + + + + + +logresolve - Résoud les adresses IP en noms d'hôtes dans les + fichiers journaux d'Apache - Serveur HTTP Apache Version 2.5 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.5

+
+
<-
+

logresolve - Résoud les adresses IP en noms d'hôtes dans les + fichiers journaux d'Apache

+
+

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

+
+ +

logresolve est un programme agissant après + traitement pour résoudre les adresses IP dans les journaux d'accès + d'Apache. Pour minimiser la charge de votre serveur de noms, + logresolve possède son propre cache interne sous forme d'une table + de hashage. Cela implique que chaque numéro IP ne fera l'objet + d'une requête DNS que la première fois où il est rencontré dans le + fichier journal.

+ +

Le programme reçoit le fichier journal sur son entrée standard. + Les adresses IP doivent se trouver en tête de chaque ligne et + doivent être séparées du reste de la ligne par un espace.

+
+ +
top
+
+

Syntaxe

+ +

logresolve [ -s + nom-fichier ] [ -c ] < + access_log > access_log.new

+
top
+
+

Options

+ +
+ +
-s nom-fichier
+ +
Spécifie le nom du fichier où seront enregistrées des +statistiques.
+ +
-c
+ +
Avec cette option, logresolve effectue certaines +vérifications DNS : après avoir trouvé le nom d'hôte correspondant à une +adresse IP, logresolve effectue une recherche DNS sur ce +nom d'hôte et vérifie si une des adresses IP trouvées correspond à +l'adresse originale.
+ +
+
+
+

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

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/programs/other.html.en b/docs/manual/programs/other.html.en index a88fa4ad94..c0b2817afc 100644 --- a/docs/manual/programs/other.html.en +++ b/docs/manual/programs/other.html.en @@ -24,9 +24,9 @@ Apache > HTTP Server > Documentation > Version 2.5 > Programs

Other Programs

Available Languages:  en  | - fr  | + fr  |  ko  | - tr 

+ tr 

This page used to contain documentation for programs which now @@ -38,9 +38,9 @@

Available Languages:  en  | - fr  | + fr  |  ko  | - tr 

+ tr 

top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
- - -
-

Modules | Directives | FAQ | Glossaire | Plan du site

-

Serveur HTTP Apache Version 2.5

-
-
<-
-

Autres programmes

-
-

Langues Disponibles:  en  | - fr  | - ko  | - tr 

-
- - -

Cette page contenait la documentation de programmes qui possèdent - maintenant leurs propres pages de documentation. Merci de bien - vouloir mettre à jour vos liens.

- -

log_server_status

-

split-logfile

-
-
-
-

Langues Disponibles:  en  | - fr  | - ko  | - tr 

-
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
-
- \ No newline at end of file diff --git a/docs/manual/programs/other.html.fr.utf8 b/docs/manual/programs/other.html.fr.utf8 new file mode 100644 index 0000000000..a72c8fe1b7 --- /dev/null +++ b/docs/manual/programs/other.html.fr.utf8 @@ -0,0 +1,70 @@ + + + + + +Autres programmes - Serveur HTTP Apache Version 2.5 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.5

+
+
<-
+

Autres programmes

+
+

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

+
+ + +

Cette page contenait la documentation de programmes qui possèdent + maintenant leurs propres pages de documentation. Merci de bien + vouloir mettre à jour vos liens.

+ +

log_server_status

+

split-logfile

+
+
+
+

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

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/programs/rotatelogs.html.en b/docs/manual/programs/rotatelogs.html.en index 5b3e1d03de..d4a3105108 100644 --- a/docs/manual/programs/rotatelogs.html.en +++ b/docs/manual/programs/rotatelogs.html.en @@ -24,9 +24,9 @@ Apache > HTTP Server > Documentation > Version 2.5 > Programs

rotatelogs - Piped logging program to rotate Apache logs

Available Languages:  en  | - fr  | + fr  |  ko  | - tr 

+ tr 

rotatelogs is a simple program for use in @@ -262,9 +262,9 @@ extensions.

Available Languages:  en  | - fr  | + fr  |  ko  | - tr 

+ tr 

top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
- - -
-

Modules | Directives | FAQ | Glossaire | Plan du site

-

Serveur HTTP Apache Version 2.5

-
-
<-
-

rotatelogs - Rotation des journaux d'Apache par redirection de - ces derniers dans un "pipe"

-
-

Langues Disponibles:  en  | - fr  | - ko  | - tr 

-
- -

rotatelogs est un programme simple à utiliser en - conjonction avec la fonctionnalité d'Apache de redirection dans un - "pipe" des fichiers journaux. Il supporte une rotation basée sur un - intervalle de temps ou une taille maximale du journal.

-
- -
top
-
-

Syntaxe

- -

rotatelogs - [ -l ] - [ -L nom-lien ] - [ -p programme ] - [ -f ] - [ -D ] - [ -t ] - [ -v ] - [ -e ] - [ -c ] - [ -n nombre-de-fichiers ] - fichier-journal - heure-de-rotation|taille-fichier(B|K|M|G) - [ décalage ]

-
top
-
-

Options

- -
- -
-l
-
Utilise le temps local plutôt que GMT comme base pour l'intervalle -de temps ou pour le formatage de strftime(3) avec une -rotation basée sur la taille.
- -
-L nom-lien
-
Etablit un lien physique entre le fichier journal courant et le lien -spécifié. Cette option permet de consulter le journal de manière -continue malgré les rotations via une commande du style tail -F -nom-lien.
- -
-p programme
-
Avec cette option, rotatelogs exécutera le programme -programme chaque fois qu'un nouveau fichier journal sera -ouvert. Le nom du fichier nouvellement ouvert est passé comme premier -argument au programme. Si l'exécution se produit après une rotation, -l'ancien nom du fichier journal est passé au programme comme second -argument. rotatelogs -n'attend pas la fin du programme pour continuer son -exécution, et cessera tout enregistrement de codes d'erreur lorsqu'il -aura terminé son processus. Le programme utilise les mêmes -canaux stdin, stdout, et stderr que rotatelogs, et hérite de son -environnement.
- -
-f
-
Ouvre le fichier journal immédiatement, dès que -rotatelogs démarre, au lieu d'attendre la lecture de la -première entrée de journal (pour les sites peu chargés, il peut -s'écouler un temps substantiel entre le démarrage du serveur et le -traitement de la première requête, temps pendant lequel le fichier -journal associé n'"existe" pas, ce qui peut causer des problèmes à -certains utilitaires de journalisation automatiques).
- -
-D
-
Crée les répertoires parents du chemin du fichier journal s'ils -n'existent pas déjà, ce qui permet d'utiliser le format -strftime(3) dans les chemins au lieu du nom de fichier seul.
- -
-t
-
Provoque une troncature du fichier journal au lieu d'une rotation. -Cela peut s'avérer utile lorsqu'un journal est élaboré en temps réel par -une commande telle que tail, l'archivage des données n'étant ici pas -nécessaire. Si aucun suffixe n'est ajouté au nom de fichier, les -chaînes de format contenant des caractères '%' sont cependant -respectées. -
- -
-v
-
Affiche une sortie verbeuse sur STDERR. La sortie contient le -résultat de l'interprétation de la configuration, ainsi que toutes les -opérations d'ouverture et de fermeture de fichiers.
- -
-c
-
Crée un fichier journal pour chaque intervalle, même s'il est vide.
- -
-e
-
Envoie les messages de journalisation vers stdout. Ceci s'avère -utile lorsque les journaux doivent être traités par un autre programme.
- -
-n nombre-de-fichiers
-
Utilise une liste circulaire de fichiers sans repères de temps. Avec --n 3, la série de fichiers conservés sera "logfile", -"logfile.1", "logfile.2" avec écrasement de "logfile".
-Disponible à partir de la version 2.4.5 du serveur HTTP Apache.
- -
fichier-journal
-

Le chemin et le nom de base du fichier journal. Si -fichier-journal contient des caractères '%', il est considéré -comme une chaîne de formatage pour strftime(3). Dans le cas -contraire, le suffixe .nnnnnnnnnn est automatiquement ajouté -et correspond au temps en secondes (sauf si l'option -t est spécifiée). -Les deux formats calculent le temps -de démarrage depuis le début de la période courante. Par exemple, si un -temps de rotation de 86400 est spécifié, les champs heure, minute et -seconde créés à partir du format strftime(3) auront tous -pour valeur 0, en référence au début de la période de 24 heures courante -(minuit).

-

Si vous utilisez le formatage de noms de fichiers -strftime(3), assurez-vous que le format du fichier journal -possède une granularité suffisamment importante pour générer un nom de -fichier différent à chaque rotation des journaux. Si ce n'est pas le -cas, la rotation va écraser le fichier existant au lieu d'en générer un -nouveau. Par exemple, si fichier-journal était -/var/log/errorlog.%Y-%m-%d avec une rotation à 5 -mégaoctets, et si la limite de 5 mégaoctets a été atteinte deux fois -dans la même journée, le même nom de fichier va être généré, et la -rotation va écraser le fichier existant.

-
- -
temps-rotation
- -
Le temps entre deux rotations des fichiers journaux en secondes. La -rotation intervient au début de cet intervalle. Par exemple, si le temps -de rotation est de 3600, la rotation des fichiers journaux s'effectuera -au début de chaque heure ; si le temps de rotation est de 86400, la -rotation des fichiers journaux s'effectuera chaque nuit à minuit. (Si -aucune donnée n'est enregistrée au cours d'un intervalle, aucun fichier -ne sera créé).
- -
taille-fichier(B|K|M|G)
- -
La taille maximale du fichier suivie par une des lettres -B (Octets), K (KOctets), M (MOctets) -ou G (GOctets). -

-Lorsque temps et taille sont spécifiés, la taille doit l'être après le -temps. La rotation interviendra alors aussitôt que l'une des deux limites -(temps ou taille) sera atteinte. -

-
- -
décalage
- -
Le décalage en minutes par rapport au temps UTC. Par défaut, le -décalage est considéré comme nul et c'est le temps UTC qui est utilisé. -Par exemple, pour utiliser le temps local de la zone UTC -5 heures, -spécifiez une valeur de -300 pour cette option. Dans la -plupart des cas, il vaut mieux utiliser l'option -l que -spécifier un décalage.
- -
-
top
-
-

Exemples

- -

- CustomLog "|bin/rotatelogs /var/log/fichier-journal 86400" common -

- -

Cette directive crée les fichiers /var/log/fichier-journal.nnnn - où nnnn correspond au temps système auquel la journalisation - démarre effectivement (ce temps sera toujours un multiple du temps - de rotation, si bien que vous pouvez synchroniser les scripts cron - avec lui). A la fin de chaque temps de rotation (ici après 24 - heures), une nouvelle journalisation démarre.

- -

- CustomLog "|bin/rotatelogs -l /var/log/fichier-journal.%Y.%m.%d 86400" common -

- -

Cette directive crée les fichiers - /var/log/fichier-journal.yyyy.mm.dd où yyyy correspond à l'année, - mm au mois et dd au jour du mois. La journalisation basculera vers - un nouveau fichier chaque jour à minuit, temps local.

- -

- CustomLog "|bin/rotatelogs /var/log/fichier-journal 5M" common -

- -

Cette directive va effectuer une rotation du fichier journal - chaque fois que la taille de ce dernier atteindra 5 MOctets.

- -

- ErrorLog "|bin/rotatelogs /var/log/journal-erreurs.%Y-%m-%d-%H_%M_%S 5M" -

-

Cette directive va effectuer une rotation du fichier journal des - erreurs chaque fois que la taille de ce dernier atteindra 5 - MOctets, et le nom du fichier journal se présentera sous - la forme journal-erreurs.YYYY-mm-dd-HH_MM_SS.

- -

- CustomLog "|bin/rotatelogs -t /var/log/journal 86400" common -

- -

Cet exemple crée le fichier /var/log/journal en le tronquant - au démarrage, puis une fois par jour. Ce scénario implique qu'un - processus séparé (tel que tail) traite le fichier en temps - réel.

- -
top
-
-

Portabilité

- -

Les substitutions des chaînes de format du fichier journal suivantes -doivent être supportées par toutes les implémentations de -strftime(3) ; voir la page de manuel de -strftime(3) pour les extensions spécifiques à une -bibliothèque.

- - - - - - - - - - - - - - - - - - - - - - - -
%Anom du jour de la semaine en entier -(localisé)
%anom du jour de la semaine sur 3 -caractères (localisé)
%Bnom du mois en entier (localisé)
%bnom du mois sur 3 caractères (localisé)
%cdate et heure (localisé)
%djour du mois sur 2 chiffres
%Hheure sur 2 chiffres (de 0 à 24h)
%Iheure sur 2 chiffres (de 0 à 12h)
%jjour de l'année sur 3 chiffres
%Mminutes sur 2 chiffres
%mmois sur 2 chiffres
%psuffixe am/pm pour l'heure de 0 à 12h -(localisé)
%Ssecondes sur 2 chiffres
%Usemaine de l'année sur 2 chiffres -(Dimanche est le premier jour de la semaine)
%W semaine de l'année sur 2 chiffres -(Lundi est le premier jour de la semaine)
%wjour de la semaine sur 1 chiffre -(Dimanche est le premier jour de la semaine)
%Xheure (localisée)
%xdate (localisée)
%Yannée sur 4 chiffres
%yannée sur 2 chiffres
%Znom de la zone de temps
%%caractère littéral `%'
- -
-
-

Langues Disponibles:  en  | - fr  | - ko  | - tr 

-
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
-
- \ No newline at end of file diff --git a/docs/manual/programs/rotatelogs.html.fr.utf8 b/docs/manual/programs/rotatelogs.html.fr.utf8 new file mode 100644 index 0000000000..786c9a13d2 --- /dev/null +++ b/docs/manual/programs/rotatelogs.html.fr.utf8 @@ -0,0 +1,307 @@ + + + + + +rotatelogs - Rotation des journaux d'Apache par redirection de + ces derniers dans un "pipe" - Serveur HTTP Apache Version 2.5 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.5

+
+
<-
+

rotatelogs - Rotation des journaux d'Apache par redirection de + ces derniers dans un "pipe"

+
+

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

+
+ +

rotatelogs est un programme simple à utiliser en + conjonction avec la fonctionnalité d'Apache de redirection dans un + "pipe" des fichiers journaux. Il supporte une rotation basée sur un + intervalle de temps ou une taille maximale du journal.

+
+ +
top
+
+

Syntaxe

+ +

rotatelogs + [ -l ] + [ -L nom-lien ] + [ -p programme ] + [ -f ] + [ -D ] + [ -t ] + [ -v ] + [ -e ] + [ -c ] + [ -n nombre-de-fichiers ] + fichier-journal + heure-de-rotation|taille-fichier(B|K|M|G) + [ décalage ]

+
top
+
+

Options

+ +
+ +
-l
+
Utilise le temps local plutôt que GMT comme base pour l'intervalle +de temps ou pour le formatage de strftime(3) avec une +rotation basée sur la taille.
+ +
-L nom-lien
+
Etablit un lien physique entre le fichier journal courant et le lien +spécifié. Cette option permet de consulter le journal de manière +continue malgré les rotations via une commande du style tail -F +nom-lien.
+ +
-p programme
+
Avec cette option, rotatelogs exécutera le programme +programme chaque fois qu'un nouveau fichier journal sera +ouvert. Le nom du fichier nouvellement ouvert est passé comme premier +argument au programme. Si l'exécution se produit après une rotation, +l'ancien nom du fichier journal est passé au programme comme second +argument. rotatelogs +n'attend pas la fin du programme pour continuer son +exécution, et cessera tout enregistrement de codes d'erreur lorsqu'il +aura terminé son processus. Le programme utilise les mêmes +canaux stdin, stdout, et stderr que rotatelogs, et hérite de son +environnement.
+ +
-f
+
Ouvre le fichier journal immédiatement, dès que +rotatelogs démarre, au lieu d'attendre la lecture de la +première entrée de journal (pour les sites peu chargés, il peut +s'écouler un temps substantiel entre le démarrage du serveur et le +traitement de la première requête, temps pendant lequel le fichier +journal associé n'"existe" pas, ce qui peut causer des problèmes à +certains utilitaires de journalisation automatiques).
+ +
-D
+
Crée les répertoires parents du chemin du fichier journal s'ils +n'existent pas déjà, ce qui permet d'utiliser le format +strftime(3) dans les chemins au lieu du nom de fichier seul.
+ +
-t
+
Provoque une troncature du fichier journal au lieu d'une rotation. +Cela peut s'avérer utile lorsqu'un journal est élaboré en temps réel par +une commande telle que tail, l'archivage des données n'étant ici pas +nécessaire. Si aucun suffixe n'est ajouté au nom de fichier, les +chaînes de format contenant des caractères '%' sont cependant +respectées. +
+ +
-v
+
Affiche une sortie verbeuse sur STDERR. La sortie contient le +résultat de l'interprétation de la configuration, ainsi que toutes les +opérations d'ouverture et de fermeture de fichiers.
+ +
-c
+
Crée un fichier journal pour chaque intervalle, même s'il est vide.
+ +
-e
+
Envoie les messages de journalisation vers stdout. Ceci s'avère +utile lorsque les journaux doivent être traités par un autre programme.
+ +
-n nombre-de-fichiers
+
Utilise une liste circulaire de fichiers sans repères de temps. Avec +-n 3, la série de fichiers conservés sera "logfile", +"logfile.1", "logfile.2" avec écrasement de "logfile".
+Disponible à partir de la version 2.4.5 du serveur HTTP Apache.
+ +
fichier-journal
+

Le chemin et le nom de base du fichier journal. Si +fichier-journal contient des caractères '%', il est considéré +comme une chaîne de formatage pour strftime(3). Dans le cas +contraire, le suffixe .nnnnnnnnnn est automatiquement ajouté +et correspond au temps en secondes (sauf si l'option -t est spécifiée). +Les deux formats calculent le temps +de démarrage depuis le début de la période courante. Par exemple, si un +temps de rotation de 86400 est spécifié, les champs heure, minute et +seconde créés à partir du format strftime(3) auront tous +pour valeur 0, en référence au début de la période de 24 heures courante +(minuit).

+

Si vous utilisez le formatage de noms de fichiers +strftime(3), assurez-vous que le format du fichier journal +possède une granularité suffisamment importante pour générer un nom de +fichier différent à chaque rotation des journaux. Si ce n'est pas le +cas, la rotation va écraser le fichier existant au lieu d'en générer un +nouveau. Par exemple, si fichier-journal était +/var/log/errorlog.%Y-%m-%d avec une rotation à 5 +mégaoctets, et si la limite de 5 mégaoctets a été atteinte deux fois +dans la même journée, le même nom de fichier va être généré, et la +rotation va écraser le fichier existant.

+
+ +
temps-rotation
+ +
Le temps entre deux rotations des fichiers journaux en secondes. La +rotation intervient au début de cet intervalle. Par exemple, si le temps +de rotation est de 3600, la rotation des fichiers journaux s'effectuera +au début de chaque heure ; si le temps de rotation est de 86400, la +rotation des fichiers journaux s'effectuera chaque nuit à minuit. (Si +aucune donnée n'est enregistrée au cours d'un intervalle, aucun fichier +ne sera créé).
+ +
taille-fichier(B|K|M|G)
+ +
La taille maximale du fichier suivie par une des lettres +B (Octets), K (KOctets), M (MOctets) +ou G (GOctets). +

+Lorsque temps et taille sont spécifiés, la taille doit l'être après le +temps. La rotation interviendra alors aussitôt que l'une des deux limites +(temps ou taille) sera atteinte. +

+
+ +
décalage
+ +
Le décalage en minutes par rapport au temps UTC. Par défaut, le +décalage est considéré comme nul et c'est le temps UTC qui est utilisé. +Par exemple, pour utiliser le temps local de la zone UTC -5 heures, +spécifiez une valeur de -300 pour cette option. Dans la +plupart des cas, il vaut mieux utiliser l'option -l que +spécifier un décalage.
+ +
+
top
+
+

Exemples

+ +

+ CustomLog "|bin/rotatelogs /var/log/fichier-journal 86400" common +

+ +

Cette directive crée les fichiers /var/log/fichier-journal.nnnn + où nnnn correspond au temps système auquel la journalisation + démarre effectivement (ce temps sera toujours un multiple du temps + de rotation, si bien que vous pouvez synchroniser les scripts cron + avec lui). A la fin de chaque temps de rotation (ici après 24 + heures), une nouvelle journalisation démarre.

+ +

+ CustomLog "|bin/rotatelogs -l /var/log/fichier-journal.%Y.%m.%d 86400" common +

+ +

Cette directive crée les fichiers + /var/log/fichier-journal.yyyy.mm.dd où yyyy correspond à l'année, + mm au mois et dd au jour du mois. La journalisation basculera vers + un nouveau fichier chaque jour à minuit, temps local.

+ +

+ CustomLog "|bin/rotatelogs /var/log/fichier-journal 5M" common +

+ +

Cette directive va effectuer une rotation du fichier journal + chaque fois que la taille de ce dernier atteindra 5 MOctets.

+ +

+ ErrorLog "|bin/rotatelogs /var/log/journal-erreurs.%Y-%m-%d-%H_%M_%S 5M" +

+

Cette directive va effectuer une rotation du fichier journal des + erreurs chaque fois que la taille de ce dernier atteindra 5 + MOctets, et le nom du fichier journal se présentera sous + la forme journal-erreurs.YYYY-mm-dd-HH_MM_SS.

+ +

+ CustomLog "|bin/rotatelogs -t /var/log/journal 86400" common +

+ +

Cet exemple crée le fichier /var/log/journal en le tronquant + au démarrage, puis une fois par jour. Ce scénario implique qu'un + processus séparé (tel que tail) traite le fichier en temps + réel.

+ +
top
+
+

Portabilité

+ +

Les substitutions des chaînes de format du fichier journal suivantes +doivent être supportées par toutes les implémentations de +strftime(3) ; voir la page de manuel de +strftime(3) pour les extensions spécifiques à une +bibliothèque.

+ + + + + + + + + + + + + + + + + + + + + + + +
%Anom du jour de la semaine en entier +(localisé)
%anom du jour de la semaine sur 3 +caractères (localisé)
%Bnom du mois en entier (localisé)
%bnom du mois sur 3 caractères (localisé)
%cdate et heure (localisé)
%djour du mois sur 2 chiffres
%Hheure sur 2 chiffres (de 0 à 24h)
%Iheure sur 2 chiffres (de 0 à 12h)
%jjour de l'année sur 3 chiffres
%Mminutes sur 2 chiffres
%mmois sur 2 chiffres
%psuffixe am/pm pour l'heure de 0 à 12h +(localisé)
%Ssecondes sur 2 chiffres
%Usemaine de l'année sur 2 chiffres +(Dimanche est le premier jour de la semaine)
%W semaine de l'année sur 2 chiffres +(Lundi est le premier jour de la semaine)
%wjour de la semaine sur 1 chiffre +(Dimanche est le premier jour de la semaine)
%Xheure (localisée)
%xdate (localisée)
%Yannée sur 4 chiffres
%yannée sur 2 chiffres
%Znom de la zone de temps
%%caractère littéral `%'
+ +
+
+

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

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/programs/split-logfile.html.en b/docs/manual/programs/split-logfile.html.en index 43b83673a2..7a6e44b1fc 100644 --- a/docs/manual/programs/split-logfile.html.en +++ b/docs/manual/programs/split-logfile.html.en @@ -24,7 +24,7 @@ Apache > HTTP Server > Documentation > Version 2.5 > Programs

split-logfile - Split up multi-vhost logfiles

Available Languages:  en  | - fr 

+ fr 

This perl script will take a combined Web server access log file and @@ -57,7 +57,7 @@ CustomLog "logs/access_log" combined_plus_vhost

Available Languages:  en  | - fr 

+ fr 

top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
- - -
-

Modules | Directives | FAQ | Glossaire | Plan du site

-

Serveur HTTP Apache Version 2.5

-
-
<-
-

split-logfile - Eclatement des journaux en fonction des serveurs -virtuels

-
-

Langues Disponibles:  en  | - fr 

-
- -

Ce script perl permet d'extraire un journal pour chaque serveur - virtuel à partir d'un journal d'accès global du serveur web. Pour - que ce script fonctionne, le premier champ de chaque ligne du - journal global doit contenir l'identité du serveur virtuel ; ce - champ aura été ajouté à la directive LogFormat via la variable - "%v". -

-
-
top
-
-

Mode d'emploi

- -

Création d'un fichier journal comportant l'identité du serveur - virtuel considéré :

- - 
LogFormat "%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined_plus_vhost
-CustomLog "logs/access_log" combined_plus_vhost
- - -

Un fichier journal sera créé dans le répertoire à partir duquel - vous exécutez le script pour chaque serveur virtuel qui apparaît - dans le journal global. Ces fichiers journaux seront nommés à partir - du nom du serveur virtuel considéré, avec l'extension - .log.

- -

Le fichier journal global est lu depuis l'entrée standard stdin. - Les entrées de ce journal sont alors ajoutées au journal du serveur - virtuel correspondant.

- -

split-logfile < access_log

- - -
-
-

Langues Disponibles:  en  | - fr 

-
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
-
- \ No newline at end of file diff --git a/docs/manual/programs/split-logfile.html.fr.utf8 b/docs/manual/programs/split-logfile.html.fr.utf8 new file mode 100644 index 0000000000..0fa016f682 --- /dev/null +++ b/docs/manual/programs/split-logfile.html.fr.utf8 @@ -0,0 +1,92 @@ + + + + + +split-logfile - Eclatement des journaux en fonction des serveurs +virtuels - Serveur HTTP Apache Version 2.5 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.5

+
+
<-
+

split-logfile - Eclatement des journaux en fonction des serveurs +virtuels

+
+

Langues Disponibles:  en  | + fr 

+
+ +

Ce script perl permet d'extraire un journal pour chaque serveur + virtuel à partir d'un journal d'accès global du serveur web. Pour + que ce script fonctionne, le premier champ de chaque ligne du + journal global doit contenir l'identité du serveur virtuel ; ce + champ aura été ajouté à la directive LogFormat via la variable + "%v". +

+
+
top
+
+

Mode d'emploi

+ +

Création d'un fichier journal comportant l'identité du serveur + virtuel considéré :

+ + 
LogFormat "%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined_plus_vhost
+CustomLog "logs/access_log" combined_plus_vhost
+ + +

Un fichier journal sera créé dans le répertoire à partir duquel + vous exécutez le script pour chaque serveur virtuel qui apparaît + dans le journal global. Ces fichiers journaux seront nommés à partir + du nom du serveur virtuel considéré, avec l'extension + .log.

+ +

Le fichier journal global est lu depuis l'entrée standard stdin. + Les entrées de ce journal sont alors ajoutées au journal du serveur + virtuel correspondant.

+ +

split-logfile < access_log

+ + +
+
+

Langues Disponibles:  en  | + fr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/programs/suexec.html.en b/docs/manual/programs/suexec.html.en index 23eb0dbd59..2baf0bfe8c 100644 --- a/docs/manual/programs/suexec.html.en +++ b/docs/manual/programs/suexec.html.en @@ -24,9 +24,9 @@ Apache > HTTP Server > Documentation > Version 2.5 > Programs

suexec - Switch user before executing external programs

Available Languages:  en  | - fr  | + fr  |  ko  | - tr 

+ tr 

suexec is used by the Apache HTTP Server to switch @@ -61,9 +61,9 @@ changeable only at compile time.

Available Languages:  en  | - fr  | + fr  |  ko  | - tr 

+ tr 

top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
- - -
-

Modules | Directives | FAQ | Glossaire | Plan du site

-

Serveur HTTP Apache Version 2.5

-
-
<-
-

suexec - Change d'utilisateur avant l'exécution d'un programme -externe

-
-

Langues Disponibles:  en  | - fr  | - ko  | - tr 

-
- -

suexec permet au serveur HTTP Apache de changer - d'utilisateur avant d'exécuter un programme CGI. Pour ce faire, il - doit être exécuté par root. A cet effet, comme le - démon HTTP ne s'exécute en général pas en tant que - root, l'exécutable suexec doit posséder - le bit setuid et avoir comme propriétaire root. Seul - root doit en posséder les droits en écriture.

- -

Pour plus d'informations à propos des concepts et du modèle de - sécurité du programme suexec, veuillez vous reporter à sa - documentation : http://httpd.apache.org/docs/trunk/suexec.html.

-
- -
top
-
-

Synopsis

-

suexec -V

-
top
-
-

Options

- -
-
-V
- -
Si vous êtes root, cette option permet d'afficher les -options de compilation du programme suexec. Pour des -raisons de sécurité, toutes les options de configuration ne sont -modifiables qu'à la compilation.
- -
-
-
-

Langues Disponibles:  en  | - fr  | - ko  | - tr 

-
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
-
- \ No newline at end of file diff --git a/docs/manual/programs/suexec.html.fr.utf8 b/docs/manual/programs/suexec.html.fr.utf8 new file mode 100644 index 0000000000..0f4bfa9880 --- /dev/null +++ b/docs/manual/programs/suexec.html.fr.utf8 @@ -0,0 +1,96 @@ + + + + + +suexec - Change d'utilisateur avant l'exécution d'un programme +externe - Serveur HTTP Apache Version 2.5 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.5

+
+
<-
+

suexec - Change d'utilisateur avant l'exécution d'un programme +externe

+
+

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

+
+ +

suexec permet au serveur HTTP Apache de changer + d'utilisateur avant d'exécuter un programme CGI. Pour ce faire, il + doit être exécuté par root. A cet effet, comme le + démon HTTP ne s'exécute en général pas en tant que + root, l'exécutable suexec doit posséder + le bit setuid et avoir comme propriétaire root. Seul + root doit en posséder les droits en écriture.

+ +

Pour plus d'informations à propos des concepts et du modèle de + sécurité du programme suexec, veuillez vous reporter à sa + documentation : http://httpd.apache.org/docs/trunk/suexec.html.

+
+ +
top
+
+

Synopsis

+

suexec -V

+
top
+
+

Options

+ +
+
-V
+ +
Si vous êtes root, cette option permet d'afficher les +options de compilation du programme suexec. Pour des +raisons de sécurité, toutes les options de configuration ne sont +modifiables qu'à la compilation.
+ +
+
+
+

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

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/rewrite/access.html.en b/docs/manual/rewrite/access.html.en index e6b217dbed..83120ceb1c 100644 --- a/docs/manual/rewrite/access.html.en +++ b/docs/manual/rewrite/access.html.en @@ -24,7 +24,7 @@ Apache > HTTP Server > Documentation > Version 2.5 > Rewrite

Using mod_rewrite to control access

Available Languages:  en  | - fr 

+ fr 

@@ -295,7 +295,7 @@ http://badguys.example.com/bad/index3.html http://somewhere.example.com/

Available Languages:  en  | - fr 

+ fr 

top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
- - -
-

Modules | Directives | FAQ | Glossaire | Plan du site

-

Serveur HTTP Apache Version 2.5

-
-
<-
-

Utiliser mod_rewrite pour le contrôle d'accès

-
-

Langues Disponibles:  en  | - fr 

-
- - -

Ce document est un complément à la documentation de référence de -mod_rewrite. Il explique comment utiliser -mod_rewrite pour contrôler l'accès à diverses -ressources, ainsi que d'autres techniques en rapport. Il contient de -nombreux exemples d'utilisation courante de mod_rewrite avec une -description détaillée de leur fonctionnement.

- -
Vous devez vous attacher à comprendre le -fonctionnement des exemples, car la plupart d'entre eux ne -fonctionneront pas sur votre système si vous vous contentez de les -copier/coller dans vos fichiers de configuration.
- -
- -
top
-
-

Blocage du référencement à chaud (Hotlinking) d'images

- - - -
-
Description :
- -
-

Cette technique vous permet d'interdire à d'autres sites - d'inclure directement vos images dans leurs pages. On fait - souvent référence à cette pratique sous le nom de - référencement à chaud (Hotlinking) qui entraîne l'utilisation - de votre bande passante pour servir des contenus faisant - partie du site de quelqu'un d'autre.

-
- -
Solution :
- -
-

Cette technique repose sur la valeur de la variable - optionnelle HTTP_REFERER. Certaines personnes - pourront donc contourner cette limitation. Pour la plupart des - utilisateurs cependant, la requête échouera, en ce sens que - l'image ne sera pas affichée depuis le site tiers.

-

Il y a plusieurs manières de gérer cette situation.

- -

Dans le premier exemple, nous rejetons tout simplement la - requête si elle ne provenait pas d'une page appartenant à notre - site. Pour les besoins de cet exemple, nous supposons que le nom - de votre site est www.example.com.

- - - -
RewriteCond "%{HTTP_REFERER}" "!^$"
-RewriteCond "%{HTTP_REFERER}" "!www.example.com" [NC]
-RewriteRule "\.(gif|jpg|png)$"    "-"   [F,NC]
- - -

Dans le second exemple, plutôt que de rejeter la requête, - nous affichons une autre image à la place.

- -
RewriteCond "%{HTTP_REFERER}" "!^$"
-RewriteCond "%{HTTP_REFERER}" "!www.example.com" [NC]
-RewriteRule "\.(gif|jpg|png)$"    "/images/go-away.png"   [R,NC]
- - -

Dans le troisième exemple, nous redirigeons la requête vers - une image appartenant à un autre site.

- -
RewriteCond "%{HTTP_REFERER}" "!^$"
-RewriteCond "%{HTTP_REFERER}" "!www.example.com" [NC]
-RewriteRule "\.(gif|jpg|png)$" "http://other.example.com/image.gif"   [R,NC]
- - -

De tous ces exemples, les deux derniers semblent les plus - efficaces pour faire en sorte que les gens arrêtent de - référencer vos images à chaud, car il ne verront pas les images - qu'ils s'attendent à voir.

- -
- -
Discussion :
- -
-

Si vous ne voulez pas rediriger la requête, mais - simplement interdire l'accès à la ressource, vous pouvez y - parvenir sans utiliser mod_rewrite :

- - 
SetEnvIf Referer example\.com localreferer
-<FilesMatch "\.(jpg|png|gif)$">
-    Require env localreferer
-</FilesMatch>
- -
-
- -
top
-
-

Blocage des robots

- - - -
-
Description :
- -
-

- Dans cet exemple, nous allons discuter d'une méthode permettant - de bloquer les requêtes persistentes en provenance d'un robot - particulier, ou d'un navigateur.

- -

La méthode classique pour exclure un robot consiste à définir - un fichier, /robots.txt qui spécifie les parties de - votre site web pour lesquelles vous voulez exclure les robots. - Malheureusement, certains robots ne tiennent pas compte de ces - fichiers. -

- -

Notez qu'il existe des méthodes d'exclusion qui n'utilisent - pas mod_rewrite. Notez aussi que toute technique qui repose sur - le contenu de la chaîne client USER_AGENT peut être - contournée très facilement car cette chaîne peut être modifiée.

-
- -
Solution :
- -
-

On utilise un jeu de règles qui spécifie le répertoire à - protéger, ainsi que la chaîne client USER_AGENT qui - identifie le robot malin ou envahissant.

- -

Dans cet exemple, nous bloquons un robot nommé - Vilain_Robot pour le répertoire - /secret/fichiers. Si vous voulez bloquer ce client - seulement depuis une source particulière, vous pouvez aussi - spécifier un intervalle d'adresses IP.

- -
RewriteCond "%{HTTP_USER_AGENT}"   "^NameOfBadRobot"
-RewriteCond "%{REMOTE_ADDR}"       "=123\.45\.67\.[8-9]"
-RewriteRule "^/secret/files/"   "-"   [F]
- -
- -
Discussion :
- -
-

- Vous pouvez cependant parvenir au même résultat sans utiliser - mod_rewrite via la méthode alternative suivante : -

- 
SetEnvIfNoCase User-Agent ^NameOfBadRobot goaway
-<Location "/secret/files">
-    <RequireAll>
-        Require all granted
-        Require not env goaway
-    </RequireAll>
-</Location>
- -

- Comme indiqué plus haut, il est aisé de contourner cette - technique, simplement en modifiant le contenu de l'en-tête - USER_AGENT. Si vous subissez une attaque en règle, - vous allez devoir réfléchir à un blocage à un niveau supérieur, - par exemple une règle de filtrage de votre pare-feu. -

- -
- -
- -
top
-
-

Rejet des clients contenus dans une liste noire

- - - -
-
Description :
- -
-

Nous voulons interdire l'accès à notre serveur aux clients - contenus dans une liste noire similaire à - hosts.deny.

-
- -
Solution :
- -
-
RewriteEngine on
-RewriteMap    hosts-deny  "txt:/path/to/hosts.deny"
-RewriteCond   "${hosts-deny:%{REMOTE_ADDR}|NOT-FOUND}" "!=NOT-FOUND" [OR]
-RewriteCond   "${hosts-deny:%{REMOTE_HOST}|NOT-FOUND}" "!=NOT-FOUND"
-RewriteRule   "^"  "-"  [F]
- - -

-##
-## hosts.deny
-##
-## ATTENTION! Ceci est une table de correspondances, non une liste,
-## même si elle est traitée comme telle. mod_rewrite
-## l'interprète comme une liste de paires clé/valeur, et
-## chaque entrée doit au moins posséder une valeur par
-## défaut "-".
-
-193.102.180.41 -
-bsdti1.sdm.de -
-192.76.162.40 -
-

-
- -
Discussion :
-
-

- La seconde condition RewriteCond présuppose que HostNameLookups est - défini à On, de façon à ce que les adresses IP des clients puissent - être résolues. Dans le cas contraire, vous devez supprimer la - seconde condition, ainsi que le drapeau [OR] de la - première. -

-
-
- -
top
-
-

Aiguillage basé sur l'en-tête Referer

- - - -
-
Description :
- -
-

Redirige les requêtes en fonction du Referer de provenance de - la requête, avec des cibles différentes pour chaque Referer.

-
- -
Solution :
- -
-

Le jeu de règles suivant utilise un fichier de correspondances pour - associer chaque Referer à une cible de redirection.

- -
RewriteMap  deflector "txt:/path/to/deflector.map"
-
-RewriteCond "%{HTTP_REFERER}" !=""
-RewriteCond "${deflector:%{HTTP_REFERER}}" =-
-RewriteRule "^" "%{HTTP_REFERER}" [R,L]
-
-RewriteCond "%{HTTP_REFERER}" !=""
-RewriteCond "${deflector:%{HTTP_REFERER}|NOT-FOUND}" "!=NOT-FOUND"
-RewriteRule "^" "${deflector:%{HTTP_REFERER}}" [R,L]
- - -

Le fichier de correspondances contient les cibles de - redirection associées à chaque Referer, ou, si nous voulons - simplement rediriger les requêtes vers leur Referer, un "-" est - inscrit dans le fichier de correspondances :

- -
##
-##  deflector.map
-##
-
-http://badguys.example.com/bad/index.html    -
-http://badguys.example.com/bad/index2.html   -
-http://badguys.example.com/bad/index3.html   http://somewhere.example.com/
- - -
-
- -
-
-

Langues Disponibles:  en  | - fr 

-
top

Commentaires

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

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.5

+
+
<-
+

Utiliser mod_rewrite pour le contrôle d'accès

+
+

Langues Disponibles:  en  | + fr 

+
+ + +

Ce document est un complément à la documentation de référence de +mod_rewrite. Il explique comment utiliser +mod_rewrite pour contrôler l'accès à diverses +ressources, ainsi que d'autres techniques en rapport. Il contient de +nombreux exemples d'utilisation courante de mod_rewrite avec une +description détaillée de leur fonctionnement.

+ +
Vous devez vous attacher à comprendre le +fonctionnement des exemples, car la plupart d'entre eux ne +fonctionneront pas sur votre système si vous vous contentez de les +copier/coller dans vos fichiers de configuration.
+ +
+ +
top
+
+

Blocage du référencement à chaud (Hotlinking) d'images

+ + + +
+
Description :
+ +
+

Cette technique vous permet d'interdire à d'autres sites + d'inclure directement vos images dans leurs pages. On fait + souvent référence à cette pratique sous le nom de + référencement à chaud (Hotlinking) qui entraîne l'utilisation + de votre bande passante pour servir des contenus faisant + partie du site de quelqu'un d'autre.

+
+ +
Solution :
+ +
+

Cette technique repose sur la valeur de la variable + optionnelle HTTP_REFERER. Certaines personnes + pourront donc contourner cette limitation. Pour la plupart des + utilisateurs cependant, la requête échouera, en ce sens que + l'image ne sera pas affichée depuis le site tiers.

+

Il y a plusieurs manières de gérer cette situation.

+ +

Dans le premier exemple, nous rejetons tout simplement la + requête si elle ne provenait pas d'une page appartenant à notre + site. Pour les besoins de cet exemple, nous supposons que le nom + de votre site est www.example.com.

+ + + +
RewriteCond "%{HTTP_REFERER}" "!^$"
+RewriteCond "%{HTTP_REFERER}" "!www.example.com" [NC]
+RewriteRule "\.(gif|jpg|png)$"    "-"   [F,NC]
+ + +

Dans le second exemple, plutôt que de rejeter la requête, + nous affichons une autre image à la place.

+ +
RewriteCond "%{HTTP_REFERER}" "!^$"
+RewriteCond "%{HTTP_REFERER}" "!www.example.com" [NC]
+RewriteRule "\.(gif|jpg|png)$"    "/images/go-away.png"   [R,NC]
+ + +

Dans le troisième exemple, nous redirigeons la requête vers + une image appartenant à un autre site.

+ +
RewriteCond "%{HTTP_REFERER}" "!^$"
+RewriteCond "%{HTTP_REFERER}" "!www.example.com" [NC]
+RewriteRule "\.(gif|jpg|png)$" "http://other.example.com/image.gif"   [R,NC]
+ + +

De tous ces exemples, les deux derniers semblent les plus + efficaces pour faire en sorte que les gens arrêtent de + référencer vos images à chaud, car il ne verront pas les images + qu'ils s'attendent à voir.

+ +
+ +
Discussion :
+ +
+

Si vous ne voulez pas rediriger la requête, mais + simplement interdire l'accès à la ressource, vous pouvez y + parvenir sans utiliser mod_rewrite :

+ + 
SetEnvIf Referer example\.com localreferer
+<FilesMatch "\.(jpg|png|gif)$">
+    Require env localreferer
+</FilesMatch>
+ +
+
+ +
top
+
+

Blocage des robots

+ + + +
+
Description :
+ +
+

+ Dans cet exemple, nous allons discuter d'une méthode permettant + de bloquer les requêtes persistentes en provenance d'un robot + particulier, ou d'un navigateur.

+ +

La méthode classique pour exclure un robot consiste à définir + un fichier, /robots.txt qui spécifie les parties de + votre site web pour lesquelles vous voulez exclure les robots. + Malheureusement, certains robots ne tiennent pas compte de ces + fichiers. +

+ +

Notez qu'il existe des méthodes d'exclusion qui n'utilisent + pas mod_rewrite. Notez aussi que toute technique qui repose sur + le contenu de la chaîne client USER_AGENT peut être + contournée très facilement car cette chaîne peut être modifiée.

+
+ +
Solution :
+ +
+

On utilise un jeu de règles qui spécifie le répertoire à + protéger, ainsi que la chaîne client USER_AGENT qui + identifie le robot malin ou envahissant.

+ +

Dans cet exemple, nous bloquons un robot nommé + Vilain_Robot pour le répertoire + /secret/fichiers. Si vous voulez bloquer ce client + seulement depuis une source particulière, vous pouvez aussi + spécifier un intervalle d'adresses IP.

+ +
RewriteCond "%{HTTP_USER_AGENT}"   "^NameOfBadRobot"
+RewriteCond "%{REMOTE_ADDR}"       "=123\.45\.67\.[8-9]"
+RewriteRule "^/secret/files/"   "-"   [F]
+ +
+ +
Discussion :
+ +
+

+ Vous pouvez cependant parvenir au même résultat sans utiliser + mod_rewrite via la méthode alternative suivante : +

+ 
SetEnvIfNoCase User-Agent ^NameOfBadRobot goaway
+<Location "/secret/files">
+    <RequireAll>
+        Require all granted
+        Require not env goaway
+    </RequireAll>
+</Location>
+ +

+ Comme indiqué plus haut, il est aisé de contourner cette + technique, simplement en modifiant le contenu de l'en-tête + USER_AGENT. Si vous subissez une attaque en règle, + vous allez devoir réfléchir à un blocage à un niveau supérieur, + par exemple une règle de filtrage de votre pare-feu. +

+ +
+ +
+ +
top
+
+

Rejet des clients contenus dans une liste noire

+ + + +
+
Description :
+ +
+

Nous voulons interdire l'accès à notre serveur aux clients + contenus dans une liste noire similaire à + hosts.deny.

+
+ +
Solution :
+ +
+
RewriteEngine on
+RewriteMap    hosts-deny  "txt:/path/to/hosts.deny"
+RewriteCond   "${hosts-deny:%{REMOTE_ADDR}|NOT-FOUND}" "!=NOT-FOUND" [OR]
+RewriteCond   "${hosts-deny:%{REMOTE_HOST}|NOT-FOUND}" "!=NOT-FOUND"
+RewriteRule   "^"  "-"  [F]
+ + +

+##
+## hosts.deny
+##
+## ATTENTION! Ceci est une table de correspondances, non une liste,
+## même si elle est traitée comme telle. mod_rewrite
+## l'interprète comme une liste de paires clé/valeur, et
+## chaque entrée doit au moins posséder une valeur par
+## défaut "-".
+
+193.102.180.41 -
+bsdti1.sdm.de -
+192.76.162.40 -
+

+
+ +
Discussion :
+
+

+ La seconde condition RewriteCond présuppose que HostNameLookups est + défini à On, de façon à ce que les adresses IP des clients puissent + être résolues. Dans le cas contraire, vous devez supprimer la + seconde condition, ainsi que le drapeau [OR] de la + première. +

+
+
+ +
top
+
+

Aiguillage basé sur l'en-tête Referer

+ + + +
+
Description :
+ +
+

Redirige les requêtes en fonction du Referer de provenance de + la requête, avec des cibles différentes pour chaque Referer.

+
+ +
Solution :
+ +
+

Le jeu de règles suivant utilise un fichier de correspondances pour + associer chaque Referer à une cible de redirection.

+ +
RewriteMap  deflector "txt:/path/to/deflector.map"
+
+RewriteCond "%{HTTP_REFERER}" !=""
+RewriteCond "${deflector:%{HTTP_REFERER}}" =-
+RewriteRule "^" "%{HTTP_REFERER}" [R,L]
+
+RewriteCond "%{HTTP_REFERER}" !=""
+RewriteCond "${deflector:%{HTTP_REFERER}|NOT-FOUND}" "!=NOT-FOUND"
+RewriteRule "^" "${deflector:%{HTTP_REFERER}}" [R,L]
+ + +

Le fichier de correspondances contient les cibles de + redirection associées à chaque Referer, ou, si nous voulons + simplement rediriger les requêtes vers leur Referer, un "-" est + inscrit dans le fichier de correspondances :

+ +
##
+##  deflector.map
+##
+
+http://badguys.example.com/bad/index.html    -
+http://badguys.example.com/bad/index2.html   -
+http://badguys.example.com/bad/index3.html   http://somewhere.example.com/
+ + +
+
+ +
+
+

Langues Disponibles:  en  | + fr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/rewrite/advanced.html.en b/docs/manual/rewrite/advanced.html.en index f4c3f552e0..aa4ed61206 100644 --- a/docs/manual/rewrite/advanced.html.en +++ b/docs/manual/rewrite/advanced.html.en @@ -24,7 +24,7 @@ Apache > HTTP Server > Documentation > Version 2.5 > Rewrite

Advanced Techniques with mod_rewrite

Available Languages:  en  | - fr 

+ fr 

@@ -340,7 +340,7 @@ RewriteRule "^/horse/(.*)" "/pony/$1" [E=rewritten:1]

Available Languages:  en  | - fr 

+ fr 

top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
- - -
-

Modules | Directives | FAQ | Glossaire | Plan du site

-

Serveur HTTP Apache Version 2.5

-
-
<-
-

Advanced Techniques with mod_rewrite

-
-

Langues Disponibles:  en  | - fr 

-
- - -

Ce document complète la documentation de référence du - module mod_rewrite. Il présente un certain nombre - de techniques avancées quant à - l'utilisation de mod_rewrite.

- - - -
Notez que la plupart des exemples ne fonctionneront -pas en l'état dans la configuration particulière de votre serveur ; il -est donc important de bien comprendre leur fonctionnement, plutôt que de -simplement les copier/coller dans votre configuration.
- -
- -
top
-
-

Distribution de la charge entre plusieurs serveurs - d'arrière-plan en fonction de l'adresse IP

- - - -
-
Description :
- -
-

La fragmentation ou "sharding" est une technique courante de - distribution de la charge du serveur ou de l'espace de stockage. - Quand on utilise cette méthode, un serveur frontal utilise l'URL - pour répartir de manière appropriée les utilisateurs et objets - entre différents serveurs d'arrière-plan.

-
- -
Solution :
- -
-

On maintient une table de correspondance entre utilisateurs et - serveurs cibles dans des fichiers externes. Ces derniers se - présentent comme suit :

- -

-utilisateur1 serveur_physique_utilisateur1
-utilisateur2 serveur_physique_utilisateur2
-: : -

- -

Tout ceci est enregistré dans un fichier - correspondances-utilisateurs-serveurs. Le but est de - faire correspondre

- -

-/u/utilisateur1/chemin -

- -

avec

- -

-http://serveur_physique_utilisateur1/u/utilisateur/chemin -

- -

il n'est ainsi pas nécessaire que tous les chemins URL soient - valides sur tous les serveurs physiques d'arrière-plan. Le jeu de - règles suivant fait tout ceci pour nous, en s'appuyant sur les - fichiers de correspondances, en supposant que serveur0 est un - serveur par défaut qui sera utilisé lorsqu'un utilisateur ne - possèdera pas d'entrée dans la table de correspondances :

- -
RewriteEngine on
-RewriteMap      users-to-hosts   "txt:/path/to/map.users-to-hosts"
-RewriteRule   "^/u/([^/]+)/?(.*)"   "http://${users-to-hosts:$1|server0}/u/$1/$2"
- -
-
- -

Voir la documentation de RewriteMap pour une description plus - approfondie de la syntaxe de cette directive.

- -
top
-
-

Régéneration de contenu à la volée

- - - -
-
Description :
- -
-

Nous voulons générer du contenu de manière dynamique, mais le - conserver de manière statique lorsqu'il a été généré. La règle - suivante vérifie l'existence du fichier statique, et le génère - s'il est absent. Les fichiers statiques peuvent être supprimés - périodiquement si on le désire (par exemple via cron), et seront - régénérés à la demande.

-
- -
Solution :
- -
- A cet effet, on utilise le jeu de règles suivant : - -
# Cet exemple n'est valable que dans un contexte de répertoire
-RewriteCond "%{REQUEST_URI}"   !-U
-RewriteRule "^(.+)\.html$"          "/regenerate_page.cgi"   [PT,L]
- - -

L'opérateur -U permet de déterminer si la chaîne - de test (dans ce cas REQUEST_URI) est une URL valide. - Pour ce faire, il utilise une sous-requête. Si cette sous-requête - échoue, ou en d'autres termes, si la ressource demandée n'existe pas, - cette règle invoque le programme CGI - /regenerate_page.cgi qui génère la ressource - demandée et la sauvegarde dans le répertoire des documents, de - façon à ce qu'une copie statique puisse être servie lors d'une - demande ultérieure.

- -

De cette façon, les documents qui ne sont pas mis à jour - régulièrement peuvent être servis sous une forme statique. Si ces - documents doivent être réactualisés, on peut les supprimer du - répertoire des documents, et ils seront ainsi régénérés à la - prochaine demande.

-
-
- -
top
-
-

Répartition de charge

- - - -
-
Description :
- -
-

Nous voulons répartir la charge de manière aléatoire entre - plusieurs serveurs en utilisant mod_rewrite.

-
- -
Solution :
- -
-

Pour y parvenir, nous allons utiliser la directive RewriteMap et une liste de - serveurs.

- -
RewriteEngine on
-RewriteMap lb "rnd:/path/to/serverlist.txt"
-RewriteRule "^/(.*)" "http://${lb:serveurs}/$1" [P,L]
- - -

liste-serveurs.txt contiendra la liste des serveurs :

- -

-## liste-serveurs.txt
-
-serveurs un.example.com|deux.example.com|trois.example.com
-

- -

Si vous voulez qu'un serveur se voit confier d'avantage de charge que -les autres, faites le figurer plusieurs fois dans la liste.

- -
- -
Discussion
-
-

Apache possède un module de répartition de charge - -mod_proxy_balancer - beaucoup plus souple et présentant -plus de fonctionnalités dans ce domaine que mod_rewrite.

-
-
- -
top
-
-

Répertoires Home structurés

- - - -
-
Description :
- -
-

Certains sites avec des milliers d'utilisateurs organisent - les répertoires utilisateurs de manière structurée, c'est à - dire que chaque répertoire utilisateur se trouve dans un - sous-répertoire dont le nom commence (par exemple) par le - premier caractère du nom de l'utilisateur. Ainsi, - /~larry/chemin correspond à - /home/l/larry/public_html/chemin, alors - que /~waldo/chemin correspond à - /home/w/waldo/public_html/chemin.

-
- -
Solution :
- -
-

On utilise le jeu de règles suivant pour développer les - URLs avec tilde selon l'organisation structurée précédente.

- -
RewriteEngine on
-RewriteRule   "^/~(([a-z])[a-z0-9]+)(.*)"  "/home/$2/$1/public_html$3"
- -
-
- -
top
-
-

Redirection des ancrages

- - - -
-
Description :
- -
-

Par défaut, la redirection vers un ancrage HTML ne fonctionne - pas, car mod_rewrite échappe le caractère # en le - transformant en %23, ce qui rend la redirection - inopérante.

-
- -
Solution :
- -
-

On utilise le drapeau [NE] dans la règle - RewriteRule. NE signifie "No Escape". -

-
- -
Discussion :
-
Cette technique fonctionne bien entendu pour tout autre - caractère spécial que mod_rewrite, par défaut, code pour insertion - dans une URL.
-
- -
top
-
-

Réécriture dépendant de l'heure

- - - -
-
Description :
- -
-

Nous voulons servir des contenus différents selon l'heure du - jour en utilisant mod_rewrite.

-
- -
Solution :
- -
-

Il existe de nombreuses variables nommées - TIME_xxx utilisables dans les conditions de - réécriture. Utilisées en conjonction avec les modèles de - comparaison lexicographique spéciaux <STRING, - >STRING et =STRING, elles - permettent d'effectuer des redirections dépendant de - l'heure :

- -
RewriteEngine on
-RewriteCond   "%{TIME_HOUR}%{TIME_MIN}" >0700
-RewriteCond   "%{TIME_HOUR}%{TIME_MIN}" <1900
-RewriteRule   "^foo\.html$"             "foo.day.html" [L]
-RewriteRule   "^foo\.html$"             "foo.night.html"
- - -

Avec cet exemple, l'URL foo.html renvoie - le contenu de foo.jour.html durant le - créneau horaire 07:01-18:59, et le contenu de - foo.nuit.html le reste du temps.

- -
mod_cache, les mandataires - intermédiaires et les navigateurs peuvent chacun mettre en cache - les réponses et ainsi afficher une des deux pages en dehors de - la fenêtre de temps configurée. On peut utiliser - mod_expires pour contourner ce problème. Il est - cependant bien plus commode de servir un contenu dynamique, et - de le personnaliser en fonction de l'heure du jour.
-
- -
top
-
-

Définir des variables d'environnement en fonction de - certaines parties de l'URL

- - - -
-
Description :
- -
-

Ici, nous voulons conserver une certaine forme de statut - lorsqu'une réécriture a eu lieu. Par exemple, vous souhaitez - consigner le fait que cette réécriture a eu lieu, et vous servir - plus tard de cette information pour déterminer si une requête sera - concernée par cette réécriture. Pour y parvenir, on peut utiliser - une variable d'environnement.

-
- -
Solution :
- -
-

Utiliser le drapeau [E] pour définir une variable - d'environnement.

- -
RewriteEngine on
-RewriteRule   "^/cheval/(.*)"   "/poney/$1" [E=rewritten:1]
- - -

Plus loin dans votre jeu de règles, vous pouvez vérifier le - contenu de cette variable d'environnement via une directive - RewriteCond :

- -
RewriteCond "%{ENV:rewritten}" =1
- - -
-
- -
-
-

Langues Disponibles:  en  | - fr 

-
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
-
- \ No newline at end of file diff --git a/docs/manual/rewrite/advanced.html.fr.utf8 b/docs/manual/rewrite/advanced.html.fr.utf8 new file mode 100644 index 0000000000..486bfb5386 --- /dev/null +++ b/docs/manual/rewrite/advanced.html.fr.utf8 @@ -0,0 +1,385 @@ + + + + + +Advanced Techniques with mod_rewrite - Serveur HTTP Apache Version 2.5 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.5

+
+
<-
+

Advanced Techniques with mod_rewrite

+
+

Langues Disponibles:  en  | + fr 

+
+ + +

Ce document complète la documentation de référence du + module mod_rewrite. Il présente un certain nombre + de techniques avancées quant à + l'utilisation de mod_rewrite.

+ + + +
Notez que la plupart des exemples ne fonctionneront +pas en l'état dans la configuration particulière de votre serveur ; il +est donc important de bien comprendre leur fonctionnement, plutôt que de +simplement les copier/coller dans votre configuration.
+ +
+ +
top
+
+

Distribution de la charge entre plusieurs serveurs + d'arrière-plan en fonction de l'adresse IP

+ + + +
+
Description :
+ +
+

La fragmentation ou "sharding" est une technique courante de + distribution de la charge du serveur ou de l'espace de stockage. + Quand on utilise cette méthode, un serveur frontal utilise l'URL + pour répartir de manière appropriée les utilisateurs et objets + entre différents serveurs d'arrière-plan.

+
+ +
Solution :
+ +
+

On maintient une table de correspondance entre utilisateurs et + serveurs cibles dans des fichiers externes. Ces derniers se + présentent comme suit :

+ +

+utilisateur1 serveur_physique_utilisateur1
+utilisateur2 serveur_physique_utilisateur2
+: : +

+ +

Tout ceci est enregistré dans un fichier + correspondances-utilisateurs-serveurs. Le but est de + faire correspondre

+ +

+/u/utilisateur1/chemin +

+ +

avec

+ +

+http://serveur_physique_utilisateur1/u/utilisateur/chemin +

+ +

il n'est ainsi pas nécessaire que tous les chemins URL soient + valides sur tous les serveurs physiques d'arrière-plan. Le jeu de + règles suivant fait tout ceci pour nous, en s'appuyant sur les + fichiers de correspondances, en supposant que serveur0 est un + serveur par défaut qui sera utilisé lorsqu'un utilisateur ne + possèdera pas d'entrée dans la table de correspondances :

+ +
RewriteEngine on
+RewriteMap      users-to-hosts   "txt:/path/to/map.users-to-hosts"
+RewriteRule   "^/u/([^/]+)/?(.*)"   "http://${users-to-hosts:$1|server0}/u/$1/$2"
+ +
+
+ +

Voir la documentation de RewriteMap pour une description plus + approfondie de la syntaxe de cette directive.

+ +
top
+
+

Régéneration de contenu à la volée

+ + + +
+
Description :
+ +
+

Nous voulons générer du contenu de manière dynamique, mais le + conserver de manière statique lorsqu'il a été généré. La règle + suivante vérifie l'existence du fichier statique, et le génère + s'il est absent. Les fichiers statiques peuvent être supprimés + périodiquement si on le désire (par exemple via cron), et seront + régénérés à la demande.

+
+ +
Solution :
+ +
+ A cet effet, on utilise le jeu de règles suivant : + +
# Cet exemple n'est valable que dans un contexte de répertoire
+RewriteCond "%{REQUEST_URI}"   !-U
+RewriteRule "^(.+)\.html$"          "/regenerate_page.cgi"   [PT,L]
+ + +

L'opérateur -U permet de déterminer si la chaîne + de test (dans ce cas REQUEST_URI) est une URL valide. + Pour ce faire, il utilise une sous-requête. Si cette sous-requête + échoue, ou en d'autres termes, si la ressource demandée n'existe pas, + cette règle invoque le programme CGI + /regenerate_page.cgi qui génère la ressource + demandée et la sauvegarde dans le répertoire des documents, de + façon à ce qu'une copie statique puisse être servie lors d'une + demande ultérieure.

+ +

De cette façon, les documents qui ne sont pas mis à jour + régulièrement peuvent être servis sous une forme statique. Si ces + documents doivent être réactualisés, on peut les supprimer du + répertoire des documents, et ils seront ainsi régénérés à la + prochaine demande.

+
+
+ +
top
+
+

Répartition de charge

+ + + +
+
Description :
+ +
+

Nous voulons répartir la charge de manière aléatoire entre + plusieurs serveurs en utilisant mod_rewrite.

+
+ +
Solution :
+ +
+

Pour y parvenir, nous allons utiliser la directive RewriteMap et une liste de + serveurs.

+ +
RewriteEngine on
+RewriteMap lb "rnd:/path/to/serverlist.txt"
+RewriteRule "^/(.*)" "http://${lb:serveurs}/$1" [P,L]
+ + +

liste-serveurs.txt contiendra la liste des serveurs :

+ +

+## liste-serveurs.txt
+
+serveurs un.example.com|deux.example.com|trois.example.com
+

+ +

Si vous voulez qu'un serveur se voit confier d'avantage de charge que +les autres, faites le figurer plusieurs fois dans la liste.

+ +
+ +
Discussion
+
+

Apache possède un module de répartition de charge - +mod_proxy_balancer - beaucoup plus souple et présentant +plus de fonctionnalités dans ce domaine que mod_rewrite.

+
+
+ +
top
+
+

Répertoires Home structurés

+ + + +
+
Description :
+ +
+

Certains sites avec des milliers d'utilisateurs organisent + les répertoires utilisateurs de manière structurée, c'est à + dire que chaque répertoire utilisateur se trouve dans un + sous-répertoire dont le nom commence (par exemple) par le + premier caractère du nom de l'utilisateur. Ainsi, + /~larry/chemin correspond à + /home/l/larry/public_html/chemin, alors + que /~waldo/chemin correspond à + /home/w/waldo/public_html/chemin.

+
+ +
Solution :
+ +
+

On utilise le jeu de règles suivant pour développer les + URLs avec tilde selon l'organisation structurée précédente.

+ +
RewriteEngine on
+RewriteRule   "^/~(([a-z])[a-z0-9]+)(.*)"  "/home/$2/$1/public_html$3"
+ +
+
+ +
top
+
+

Redirection des ancrages

+ + + +
+
Description :
+ +
+

Par défaut, la redirection vers un ancrage HTML ne fonctionne + pas, car mod_rewrite échappe le caractère # en le + transformant en %23, ce qui rend la redirection + inopérante.

+
+ +
Solution :
+ +
+

On utilise le drapeau [NE] dans la règle + RewriteRule. NE signifie "No Escape". +

+
+ +
Discussion :
+
Cette technique fonctionne bien entendu pour tout autre + caractère spécial que mod_rewrite, par défaut, code pour insertion + dans une URL.
+
+ +
top
+
+

Réécriture dépendant de l'heure

+ + + +
+
Description :
+ +
+

Nous voulons servir des contenus différents selon l'heure du + jour en utilisant mod_rewrite.

+
+ +
Solution :
+ +
+

Il existe de nombreuses variables nommées + TIME_xxx utilisables dans les conditions de + réécriture. Utilisées en conjonction avec les modèles de + comparaison lexicographique spéciaux <STRING, + >STRING et =STRING, elles + permettent d'effectuer des redirections dépendant de + l'heure :

+ +
RewriteEngine on
+RewriteCond   "%{TIME_HOUR}%{TIME_MIN}" >0700
+RewriteCond   "%{TIME_HOUR}%{TIME_MIN}" <1900
+RewriteRule   "^foo\.html$"             "foo.day.html" [L]
+RewriteRule   "^foo\.html$"             "foo.night.html"
+ + +

Avec cet exemple, l'URL foo.html renvoie + le contenu de foo.jour.html durant le + créneau horaire 07:01-18:59, et le contenu de + foo.nuit.html le reste du temps.

+ +
mod_cache, les mandataires + intermédiaires et les navigateurs peuvent chacun mettre en cache + les réponses et ainsi afficher une des deux pages en dehors de + la fenêtre de temps configurée. On peut utiliser + mod_expires pour contourner ce problème. Il est + cependant bien plus commode de servir un contenu dynamique, et + de le personnaliser en fonction de l'heure du jour.
+
+ +
top
+
+

Définir des variables d'environnement en fonction de + certaines parties de l'URL

+ + + +
+
Description :
+ +
+

Ici, nous voulons conserver une certaine forme de statut + lorsqu'une réécriture a eu lieu. Par exemple, vous souhaitez + consigner le fait que cette réécriture a eu lieu, et vous servir + plus tard de cette information pour déterminer si une requête sera + concernée par cette réécriture. Pour y parvenir, on peut utiliser + une variable d'environnement.

+
+ +
Solution :
+ +
+

Utiliser le drapeau [E] pour définir une variable + d'environnement.

+ +
RewriteEngine on
+RewriteRule   "^/cheval/(.*)"   "/poney/$1" [E=rewritten:1]
+ + +

Plus loin dans votre jeu de règles, vous pouvez vérifier le + contenu de cette variable d'environnement via une directive + RewriteCond :

+ +
RewriteCond "%{ENV:rewritten}" =1
+ + +
+
+ +
+
+

Langues Disponibles:  en  | + fr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/rewrite/avoid.html.en b/docs/manual/rewrite/avoid.html.en index 116226a0a9..7f5286f731 100644 --- a/docs/manual/rewrite/avoid.html.en +++ b/docs/manual/rewrite/avoid.html.en @@ -24,7 +24,7 @@ Apache > HTTP Server > Documentation > Version 2.5 > Rewrite

When not to use mod_rewrite

Available Languages:  en  | - fr 

+ fr 

@@ -226,7 +226,7 @@ and in certain other directives.

Available Languages:  en  | - fr 

+ fr 

top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
- - -
-

Modules | Directives | FAQ | Glossaire | Plan du site

-

Serveur HTTP Apache Version 2.5

-
-
<-
-

Quand ne pas utiliser mod_rewrite

-
-

Langues Disponibles:  en  | - fr 

-
- - -

Ce document est un complément à la Documentation de référence de -mod_rewrite. Il décrit peut-être un des concepts les -plus importants à propos de mod_rewrite - à savoir, quand doit-on éviter -de l'utiliser.

- -

mod_rewrite doit être considéré comme un dernier recours, -lorsqu'aucune alternative n'est possible. Utiliser mod_rewrite lorsqu'il -existe des alternatives plus simples conduit à des configurations -confuses, fragiles, et difficiles à maintenir. La compréhension des -autres alternatives disponibles est une étape très importante sur le -chemin de la maîtrise de mod_rewrite.

- -

Vous devez vous attacher à comprendre le -fonctionnement des exemples, car la plupart d'entre eux ne -fonctionneront pas sur votre système si vous vous contentez de les -copier/coller dans vos fichiers de configuration.

- -

Le cas le plus courant dans lequel mod_rewrite est -l'outil approprié est la situation où la seule solution envisageable -nécessite l'accès aux fichiers de configuration du serveur, alors que -cet accès ne vous est pas accordé. Certaines directives de configuration -ne sont disponibles que dans le fichier de configuration du serveur. Si -vous ne pouvez agir que sur les fichiers .htaccess, vous devrez donc -vous tourner vers mod_rewrite.

- -
- -
top
-
-

Redirection simple

- - -

mod_alias fournit les directives Redirect et RedirectMatch qui permettent de -rediriger une URL vers une autre. Plutôt que d'utiliser la directive -RewriteRule pour ce genre de -redirection simple d'une URL ou d'une classe d'URLs vers une autre, on -préfèrera l'utilisation de ces directives. En outre, avec -RedirectMatch, vous pouvez inclure une expression -rationnelle dans votre critère de redirection, ce qui vous permet de -bénéficier de nombreux avantages de la directive -RewriteRule.

- -

Une utilisation courante de la directive RewriteRule est -la redirection de toute une classe d'URLs. Par exemple, toutes les URLs -faisant référence au répertoire /un doivent être -redirigées vers http://un.example.com/, ou toutes les -requêtes http doivent être redirigées vers -https.

- -

Pour ce faire, il est préférable d'utiliser la directive -Redirect. Souvenez-vous que la directive -Redirect conserve les informations relatives au chemin. En -d'autres termes, la redirection d'une URL /un va aussi -rediriger toutes les URLs de niveaux inférieurs comme -/un/deux.html et /un/trois/quatre.html.

- -

Pour rediriger les URLs sous /un vers -http://un.example.com/, utilisez cette définition :

- -
Redirect /one/ http://one.example.com/
- - -

Pour rediriger un nom d'hôte vers un autre nom d'hôte, par exemple -example.com vers www.example.com, voir la -méthode Noms d'hôtes canoniques.

- -

Pour rediriger les URLs http vers https, -utilisez cette définition :

- -
<VirtualHost *:80>
-ServerName www.example.com
-Redirect "/" "https://www.example.com/"
-</VirtualHost>
-
-<VirtualHost *:443>
-ServerName www.example.com
-#  ... insérer ici la configuration SSL
-</VirtualHost>
- - -

L'utilisation de la directive RewriteRule pour accomplir -cette tâche peut se justifier s'il existe d'autres directives -RewriteRule dans la même portée. En effet, lorsque des -directives Redirect et RewriteRule se trouvent -dans la même portée, les directives RewriteRule sont -exécutées en premier, sans tenir compte de leur ordre d'apparition dans -le fichier de configuration.

- -

Dans le cas de la redirection http-vers-https, l'utilisation -de règles RewriteRule se justifie si vous n'avez pas accès -au fichier de configuration principal, et devez donc accomplir cette -tâche au sein d'un fichier .htaccess.

- -
top
-
-

Alias d'URL

-

La directive Alias permet -de mettre en correspondance un URI avec un répertoire, ce dernier étant -en général situé en dehors de l'arborescence définie par la directive -DocumentRoot. Bien qu'il soit -possible d'effectuer cette mise en correspondance avec -mod_rewrite, il est préférable d'utiliser la directive -Alias pour des raisons de simplicité -et de performances.

- -

Utilisation de la directive Alias

Alias "/cats" "/var/www/virtualhosts/felines/htdocs"
-
- -

-Pour effectuer cette mise en correspondance, mod_rewrite -s'impose si vous n'avez pas accès aux fichiers de configuration du -serveur. En effet, la directive Alias ne peut pas être utilisée dans un -fichier .htaccess, mais seulement dans un contexte de -serveur principal ou de serveur virtuel. -

- -

En outre, vous pouvez arriver au même résultat avec les liens -symboliques, pourvu que Options FollowSymLinks soit activé -sur votre serveur.

-
top
-
-

Hébergement virtuel

-

Bien qu'il soit possible de gérer les serveurs -virtuels avec mod_rewrite, il s'agit rarement de la bonne méthode. -Il est pratiquement toujours préférable de créer des blocs -<VirtualHost> individuels. -Dans l'éventualité où vous devez gérer -un grand nombre de serveurs virtuels, vous devez vous tourner vers -mod_vhost_alias pour créer ces serveurs -automatiquement.

- -

Il est aussi possible d'utiliser des modules comme mod_macro pour -créer un grand nombre de serveurs virtuels dynamiquement.

- -

L'utilisation de mod_rewrite pour la création de -serveurs virtuels peut se révéler appropriée si votre service -d'hébergement ne vous permet pas d'accéder aux fichiers de configuration -du serveur, et que vous soyez par conséquent obligé de passer par les -fichiers .htaccess.

- -

Voir le document création de serveurs virtuels -avec mod_rewrite pour plus de détails sur la manière d'y parvenir si -cela semble être tout de même la meilleure approche.

- -
top
-
-

Mandat simple

- -

La directive RewriteRule fournit -le drapeau [P] qui permet de faire passer les URIs -réécrits par mod_proxy.

- -
RewriteRule "^/?images(.*)" "http://serveur-images.local/images$1" [P]
- - -

Cependant, dans les nombreux cas où aucune correspondance au modèle -n'est vraiment nécessaire, comme dans l'exemple ci-dessus, il est -préférable d'utiliser la directive ProxyPass. L'exemple précédent pourrait -être remplacé par :

- -
ProxyPass "/images/" "http://serveur-images.local/images/"
- - -

Que vous utilisiez RewriteRule ou ProxyPass, vous devrez dans tous les cas -utiliser aussi la directive ProxyPassReverse pour intercepter les -redirections en provenance du serveur d'arrière-plan :

- -
ProxyPassReverse "/images/" "http://serveur-images.local/images/"
- - -

Vous devrez cependant tout de même utiliser RewriteRule -lorsque d'autres RewriteRules se trouvent dans la même portée, -car elles agissent en général avant les directives -ProxyPass, et peuvent ainsi les court-circuiter.

- -
top
-
-

Test de variables d'environnement

- -

mod_rewrite est souvent utilisé pour effectuer une -action en fonction de la présence ou de l'absence d'une variable -d'environnement particulière ou d'un en-tête de requête, ce qui peut -être accompli de manière plus efficace via la directive <If>.

- -

Considérons par exemple le scénario courant où la directive -RewriteRule est utilisée pour forcer un nom -d'hôte canonique, tel que www.example.com au lieu de -example.com. Il est possible d'utiliser à la place la -directive <If> comme -suit :

- -
<If "req('Host') != 'www.example.com'">
-    Redirect "/" "http://www.example.com"
-</If>
- - -

On peut utiliser cette technique dans de nombreux scénarios courant -pour remplacer mod_rewrite pour effectuer des actions -en fonction d'en-têtes de requêtes ou de réponses, ou de variables -d'environnement.

- -

Voir en particulier la documentation sur -l'évaluation des expressions pour une vue d'ensemble des types -d'expressions que vous pouvez utiliser dans les sections <If>, -ainsi que dans certaines directives.

- -
-
-

Langues Disponibles:  en  | - fr 

-
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
-
- \ No newline at end of file diff --git a/docs/manual/rewrite/avoid.html.fr.utf8 b/docs/manual/rewrite/avoid.html.fr.utf8 new file mode 100644 index 0000000000..bd873ae5d9 --- /dev/null +++ b/docs/manual/rewrite/avoid.html.fr.utf8 @@ -0,0 +1,271 @@ + + + + + +Quand ne pas utiliser mod_rewrite - Serveur HTTP Apache Version 2.5 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.5

+
+
<-
+

Quand ne pas utiliser mod_rewrite

+
+

Langues Disponibles:  en  | + fr 

+
+ + +

Ce document est un complément à la Documentation de référence de +mod_rewrite. Il décrit peut-être un des concepts les +plus importants à propos de mod_rewrite - à savoir, quand doit-on éviter +de l'utiliser.

+ +

mod_rewrite doit être considéré comme un dernier recours, +lorsqu'aucune alternative n'est possible. Utiliser mod_rewrite lorsqu'il +existe des alternatives plus simples conduit à des configurations +confuses, fragiles, et difficiles à maintenir. La compréhension des +autres alternatives disponibles est une étape très importante sur le +chemin de la maîtrise de mod_rewrite.

+ +

Vous devez vous attacher à comprendre le +fonctionnement des exemples, car la plupart d'entre eux ne +fonctionneront pas sur votre système si vous vous contentez de les +copier/coller dans vos fichiers de configuration.

+ +

Le cas le plus courant dans lequel mod_rewrite est +l'outil approprié est la situation où la seule solution envisageable +nécessite l'accès aux fichiers de configuration du serveur, alors que +cet accès ne vous est pas accordé. Certaines directives de configuration +ne sont disponibles que dans le fichier de configuration du serveur. Si +vous ne pouvez agir que sur les fichiers .htaccess, vous devrez donc +vous tourner vers mod_rewrite.

+ +
+ +
top
+
+

Redirection simple

+ + +

mod_alias fournit les directives Redirect et RedirectMatch qui permettent de +rediriger une URL vers une autre. Plutôt que d'utiliser la directive +RewriteRule pour ce genre de +redirection simple d'une URL ou d'une classe d'URLs vers une autre, on +préfèrera l'utilisation de ces directives. En outre, avec +RedirectMatch, vous pouvez inclure une expression +rationnelle dans votre critère de redirection, ce qui vous permet de +bénéficier de nombreux avantages de la directive +RewriteRule.

+ +

Une utilisation courante de la directive RewriteRule est +la redirection de toute une classe d'URLs. Par exemple, toutes les URLs +faisant référence au répertoire /un doivent être +redirigées vers http://un.example.com/, ou toutes les +requêtes http doivent être redirigées vers +https.

+ +

Pour ce faire, il est préférable d'utiliser la directive +Redirect. Souvenez-vous que la directive +Redirect conserve les informations relatives au chemin. En +d'autres termes, la redirection d'une URL /un va aussi +rediriger toutes les URLs de niveaux inférieurs comme +/un/deux.html et /un/trois/quatre.html.

+ +

Pour rediriger les URLs sous /un vers +http://un.example.com/, utilisez cette définition :

+ +
Redirect /one/ http://one.example.com/
+ + +

Pour rediriger un nom d'hôte vers un autre nom d'hôte, par exemple +example.com vers www.example.com, voir la +méthode Noms d'hôtes canoniques.

+ +

Pour rediriger les URLs http vers https, +utilisez cette définition :

+ +
<VirtualHost *:80>
+ServerName www.example.com
+Redirect "/" "https://www.example.com/"
+</VirtualHost>
+
+<VirtualHost *:443>
+ServerName www.example.com
+#  ... insérer ici la configuration SSL
+</VirtualHost>
+ + +

L'utilisation de la directive RewriteRule pour accomplir +cette tâche peut se justifier s'il existe d'autres directives +RewriteRule dans la même portée. En effet, lorsque des +directives Redirect et RewriteRule se trouvent +dans la même portée, les directives RewriteRule sont +exécutées en premier, sans tenir compte de leur ordre d'apparition dans +le fichier de configuration.

+ +

Dans le cas de la redirection http-vers-https, l'utilisation +de règles RewriteRule se justifie si vous n'avez pas accès +au fichier de configuration principal, et devez donc accomplir cette +tâche au sein d'un fichier .htaccess.

+ +
top
+
+

Alias d'URL

+

La directive Alias permet +de mettre en correspondance un URI avec un répertoire, ce dernier étant +en général situé en dehors de l'arborescence définie par la directive +DocumentRoot. Bien qu'il soit +possible d'effectuer cette mise en correspondance avec +mod_rewrite, il est préférable d'utiliser la directive +Alias pour des raisons de simplicité +et de performances.

+ +

Utilisation de la directive Alias

Alias "/cats" "/var/www/virtualhosts/felines/htdocs"
+
+ +

+Pour effectuer cette mise en correspondance, mod_rewrite +s'impose si vous n'avez pas accès aux fichiers de configuration du +serveur. En effet, la directive Alias ne peut pas être utilisée dans un +fichier .htaccess, mais seulement dans un contexte de +serveur principal ou de serveur virtuel. +

+ +

En outre, vous pouvez arriver au même résultat avec les liens +symboliques, pourvu que Options FollowSymLinks soit activé +sur votre serveur.

+
top
+
+

Hébergement virtuel

+

Bien qu'il soit possible de gérer les serveurs +virtuels avec mod_rewrite, il s'agit rarement de la bonne méthode. +Il est pratiquement toujours préférable de créer des blocs +<VirtualHost> individuels. +Dans l'éventualité où vous devez gérer +un grand nombre de serveurs virtuels, vous devez vous tourner vers +mod_vhost_alias pour créer ces serveurs +automatiquement.

+ +

Il est aussi possible d'utiliser des modules comme mod_macro pour +créer un grand nombre de serveurs virtuels dynamiquement.

+ +

L'utilisation de mod_rewrite pour la création de +serveurs virtuels peut se révéler appropriée si votre service +d'hébergement ne vous permet pas d'accéder aux fichiers de configuration +du serveur, et que vous soyez par conséquent obligé de passer par les +fichiers .htaccess.

+ +

Voir le document création de serveurs virtuels +avec mod_rewrite pour plus de détails sur la manière d'y parvenir si +cela semble être tout de même la meilleure approche.

+ +
top
+
+

Mandat simple

+ +

La directive RewriteRule fournit +le drapeau [P] qui permet de faire passer les URIs +réécrits par mod_proxy.

+ +
RewriteRule "^/?images(.*)" "http://serveur-images.local/images$1" [P]
+ + +

Cependant, dans les nombreux cas où aucune correspondance au modèle +n'est vraiment nécessaire, comme dans l'exemple ci-dessus, il est +préférable d'utiliser la directive ProxyPass. L'exemple précédent pourrait +être remplacé par :

+ +
ProxyPass "/images/" "http://serveur-images.local/images/"
+ + +

Que vous utilisiez RewriteRule ou ProxyPass, vous devrez dans tous les cas +utiliser aussi la directive ProxyPassReverse pour intercepter les +redirections en provenance du serveur d'arrière-plan :

+ +
ProxyPassReverse "/images/" "http://serveur-images.local/images/"
+ + +

Vous devrez cependant tout de même utiliser RewriteRule +lorsque d'autres RewriteRules se trouvent dans la même portée, +car elles agissent en général avant les directives +ProxyPass, et peuvent ainsi les court-circuiter.

+ +
top
+
+

Test de variables d'environnement

+ +

mod_rewrite est souvent utilisé pour effectuer une +action en fonction de la présence ou de l'absence d'une variable +d'environnement particulière ou d'un en-tête de requête, ce qui peut +être accompli de manière plus efficace via la directive <If>.

+ +

Considérons par exemple le scénario courant où la directive +RewriteRule est utilisée pour forcer un nom +d'hôte canonique, tel que www.example.com au lieu de +example.com. Il est possible d'utiliser à la place la +directive <If> comme +suit :

+ +
<If "req('Host') != 'www.example.com'">
+    Redirect "/" "http://www.example.com"
+</If>
+ + +

On peut utiliser cette technique dans de nombreux scénarios courant +pour remplacer mod_rewrite pour effectuer des actions +en fonction d'en-têtes de requêtes ou de réponses, ou de variables +d'environnement.

+ +

Voir en particulier la documentation sur +l'évaluation des expressions pour une vue d'ensemble des types +d'expressions que vous pouvez utiliser dans les sections <If>, +ainsi que dans certaines directives.

+ +
+
+

Langues Disponibles:  en  | + fr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/rewrite/flags.html.en b/docs/manual/rewrite/flags.html.en index 02f0b9a31c..4d98a39194 100644 --- a/docs/manual/rewrite/flags.html.en +++ b/docs/manual/rewrite/flags.html.en @@ -24,7 +24,7 @@ Apache > HTTP Server > Documentation > Version 2.5 > Rewrite

RewriteRule Flags

Available Languages:  en  | - fr 

+ fr 

This document discusses the flags which are available to the @@ -763,7 +763,7 @@ The L flag can be useful in this context to end the

Available Languages:  en  | - fr 

+ fr 

top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
- - -
-

Modules | Directives | FAQ | Glossaire | Plan du site

-

Serveur HTTP Apache Version 2.5

-
-
<-
-

Les drapeaux de réécriture

-
-

Langues Disponibles:  en  | - fr 

-
- -

Ce document décrit les drapeaux disponibles dans la directive -RewriteRule, en fournissant -des explications détaillées et des exemples.

-
- -
top
-
-

Introduction

-

Le comportement d'une directive RewriteRule peut être modifié par un ou -plusieurs drapeaux. Les drapeaux sont situés en fin de règle, entourés -de crochets, et séparés le cas échéant par des virgules.

-
RewriteRule pattern target [Flag1,Flag2,Flag3]
- - -

Chaque drapeau (à quelques exceptions près) -possède une forme courte, comme CO, ainsi qu'une forme longue, -comme cookie. Bien que -la forme courte soit la plus couramment utilisée, nous vous recommandons -de vous familiariser avec les drapeaux sous leur forme longue, afin de -bien mémoriser ce que chaque drapeau est supposé faire. -Certains drapeaux acceptent un ou plusieurs arguments. Les drapeaux ne -sont pas sensibles à la casse.

- -

Les drapeaux qui modifient les métadonnées associées à la requête -(T=, H=, E=) n'ont aucun effet dans un contexte de répertoire ou de -fichier htaccess, lorsqu'une substitution (autre que '-') est effectuée -au cours de la même passe du processus de réécriture. -

- -

Chaque drapeau disponible est présenté ici, avec un exemple -d'utilisation.

-
top
-
-

B (échappement dans les références arrières)

-

Avec le drapeau [B], la directive RewriteRule échappe les caractères -non-alphanumériques avant d'appliquer la transformation. A partir -de la version 2.4.26, vous pouvez limiter l'échappement dans les -références arrières à une liste de caractères que vous pouvez spécifiez comme -dans cet exemple : [B=#?;]. Notez que l'espace peut faire -partie de la liste des caractères à échapper, mais qu'il ne doit pas -être le dernier caractère de cette liste. -

- -

mod_rewrite doit supprimer les séquences d'échappement -des URLs avant leur -mise en correspondance avec le système de fichiers ; les séquences -d'échappement sont donc supprimées des références arrières au moment où -ces dernières sont appliquées. Avec le drapeau B, les caractères -non-alphanumériques des références arrières seront échappés. Considérons -par exemple cette règle :

- -
RewriteRule "^search/(.*)$" "/search.php?term=$1"
- - -

Soit le terme de recherche 'x & y/z' ; un navigateur va le coder -en 'x%20%26%20y%2Fz', transformant la requête en -'search/x%20%26%20y%2Fz'. Sans le drapeau B, cette règle de réécriture -va réécrire la requête en 'search.php?term=x & y/z', ce qui ne -correspond pas à une URL valide et cette dernière sera encodée en -search.php?term=x%20&y%2Fz=, ce qui ne correspond pas à -ce que l'on souhaitait.

- -

Avec le drapeau B, les paramètres sont réencodés avant d'être passés -à l'URL résultante, ce qui fournit une réécriture correcte en -/search.php?term=x%20%26%20y%2Fz.

- -
RewriteRule "^search/(.*)$" "/search.php?term=$1" [B,PT]
- - -

Notez que vous devrez peut-être aussi définir la -directive AllowEncodedSlashes -à On pour -que cet exemple particulier fonctionne, car httpd ne permet pas les -slashes encodés dans les URLs, et renvoie une erreur 404 s'il en -rencontre un.

- -

Ce processus d'échappement est en particulier nécessaire dans le -contexte d'un mandataire, où l'accès au serveur d'arrière-plan échouera -si on présente à ce dernier une URL non échappée.

- -

Une alternative à ce drapeau consiste à utiliser une directive -RewriteCond pour capturer -%{THE_REQUEST}, les chaînes capturées se présentant -alors sous la forme codée.

- -
top
-
-

BNP|backrefnoplus (ne pas échapper -l'espace en +)

-

Si le drapeau [BNP] est spécifié, la directive RewriteRule échappera le caractère -espace en %20 au lieu de '+' dans les références arrières. Ceci s'avère -utile lorsque la référence arrière est utilisée dans la partie chemin, -et non dans les paramètres de la requête.

- -

Ce drapeau est disponible à partir de la version 2.4.26 du serveur HTTP -Apache.

- -
top
-
-

C|chain

-

Le drapeau [C] ou [chain] indique que la règle RewriteRule est chaînée avec la -suivante. Autrement dit, si la règle s'applique, elle est traitée -normalement et passe le contrôle à la règle suivante. Par contre, si -elle ne s'applique pas, la règle suivante, ainsi que toutes les règles -chaînées qui suivent, seront sautées.

- -
top
-
-

CO|cookie

-

Le drapeau [CO], ou [cookie], vous permet de définir un cookie -lorsqu'une règle RewriteRule -s'applique. Il possède trois arguments obligatoires et -quatre arguments optionnels.

- -

La syntaxe complète de ce drapeau, avec tous ses attributs, est la -suivante :

- -

-[CO=NAME:VALUE:DOMAIN:lifetime:path:secure:httponly] -

- -

Si un caractère littéral ':' doit être insérer dans un des champs du -cookie, une autre syntaxe est disponible. Pour utiliser cette syntaxe -alternative, le contenu du champ "Name" doit être précédé du caractère -';', et les sépateurs de champs deviendront des ';'.

- -

-[CO=;NAME;VALUE:MOREVALUE;DOMAIN;lifetime;path;secure;httponly] -

- -

Vous devez déclarer un nom, une valeur et un domaine pour que -le cookie puisse être défini.

- - -
-
Domain
-
Le domaine pour lequel vous souhaitez que le cookie soit valide. Ce -peut être un nom de serveur, comme www.example.com, ou un -domaine, comme .example.com. Il doit comporter au moins -deux parties séparées par un point. C'est à dire que vous ne pouvez pas -utiliser les valeurs .com ou .net. En effet, -ce style de cookie est interdit par le modèle de sécurité des cookies.
-
- -

Vous pouvez aussi définir les valeurs suivantes :

- -
-
Lifetime
-
La durée de vie du cookie, en minutes.
-
Une valeur de 0 indique une durée de vie correspondant à la session -courante du navigateur. Il s'agit de la valeur par défaut.
- -
Path
-
Le chemin, sur le site web concerné, pour lequel le cookie est -valide, du style /clients/ or -/fichiers/telechargement/.
-
La valeur par défaut est / - c'est à dire l'ensemble du -site web.
- -
Secure
-
Si cet argument a pour valeur secure, -true, ou 1, le cookie ne pourra être transmis -que dans le cadre d'une connexion sécurisée (https).
- -
httponly
-
Si cet argument a pour valeur HttpOnly, -true, ou 1, le cookie aura son drapeau -HttpOnly activé, ce qui signifie qu'il sera inaccessible au -code JavaScript pour les navigateurs qui supportent cette -fonctionnalité.
-
- -

Voici un exemple :

- -
RewriteEngine On
-RewriteRule "^/index\.html" "-" [CO=frontdoor:yes:.example.org:1440:/]
- - -

Dans l'exemple ci-dessus, la règle ne réécrit -pas la requête. La cible de réécriture "-" -indique à mod_rewrite de transmettre la requête sans -modification. Par contre, il -définit un cookie nommé 'frontdoor' avec une valeur 'yes'. Le cookie est -valide pour tout hôte situé dans le domaine .example.org. Sa -durée de vie est limitée à 1440 minutes (24 heures), et il sera renvoyé -pour tous les URIs.

- -
top
-
-

DPI|discardpath

-

Avec le drapeau DPI, la partie PATH_INFO de l'URI -réécrit est supprimée.

-

Ce drapeau est disponible dans les versions 2.2.12 et supérieures.

-

Dans un contexte de répertoire, l'URI mis en comparaison par chaque -règle RewriteRule est la concaténation des -valeurs courantes de l'URI et de PATH_INFO.

- -

L'URI courant peut être l'URI initial tel qu'il a été fourni par le -client, le résultat d'une passe précédente du processus de réécriture, -ou le résultat de la règle précédente dans le processus courant de -réécriture.

- -

Par contre, la partie PATH_INFO ajoutée à l'URI avant chaque règle ne -reflète que la valeur de PATH_INFO avant la passe courante du processus -de réécriture. En conséquence, si de larges portions de l'URI -correspondent et sont traduites via plusieurs directives -RewriteRule, sans prendre en compte -quelles parties de l'URI provenaient du PATH_INFO courant, l'URI final -pourra se voir ajouter plusieurs copies de PATH_INFO.

- -

Utilisez ce drapeau pour toute substitution où la présence du PATH_INFO qui -résultait de la mise en correspondance précédente de cette requête avec -le système de fichier n'est pas nécessaire. Avec ce drapeau, le -PATH_INFO établi avant que cette passe du processus de réécriture ne -débute est oublié. PATH_INFO ne sera pas recalculé tant que la passe -courante du processus de réécriture ne sera pas achevée. Les règles -suivantes de cette passe ne verront que le résultat direct des -substitutions, sans aucun PATH_INFO ajouté.

-
top
-
-

E|env

-

Avec le drapeau [E], ou [env], vous pouvez définir la valeur d'une -variable d'environnement. Notez que certaines variables d'environnement -peuvent être définies après le traitement de la règle, annulant par -la-même ce que vous avez défini. Voir le document -sur les variables d'environnement pour plus de détails sur le -fonctionnement des variables d'environnement.

- -

La syntaxe complète pour ce drapeau est :

- -
[E=!VAR]
- - -

VAL peut comporter des références arrières -($N ou %N) qui seront développées.

- -

En utilisant la version courte

- -

-[E=VAR] -

- -

vous pouvez définir la variable d'environnement nommée -VAR avec une valeur vide.

- -

La forme

- -

-[E=!VAR] -

- -

permet d'annuler la définition de la variable VAR.

- -

Les variables d'environnement s'emploient dans différents contextes, -comme les programmes CGI, d'autres directives RewriteRule, ou des -directives CustomLog.

- -

L'exemple suivant définit une variable d'environnement nommée 'image' -avec une valeur de '1' si l'URI de la requête correspond à un fichier -image. Cette variable d'environnement est ensuite utilisée pour exclure -une telle requête du journal des accès.

- -
RewriteRule "\.(png|gif|jpg)" "-" [E=image:1]

-CustomLog "logs/access_log" combined env=!image
- - -

Notez que le même effet peut être obtenu à l'aide de la directive -SetEnvIf. Cette technique -est présentée à titre d'exemple et non de recommandation.

-
top
-
-

END

-

L'utilisation du drapeau [END] permet non seulement de terminer le -processus de réécriture en cours (comme [L]), mais aussi d'empêcher tout -processus de réécriture ultérieur dans un contexte de répertoire -(htaccess).

- -

Ceci ne s'applique pas aux nouvelles requêtes résultant d'une -redirection externe.

-
top
-
-

F|forbidden

-

L'utilisation du drapeau [F] permet de faire envoyer par le serveur au -client un code de statut "403 Forbidden". Le même effet peut être obtenu à -l'aide de la directive Deny, -mais ce drapeau offre plus de souplesse dans l'attribution d'un statut -Forbidden.

- -

La règle suivante va interdire la téléchargement de fichiers -.exe depuis votre serveur.

- -
RewriteRule "\.exe" "-" [F]
- - -

Cet exemple utilise la syntaxe "-" pour la cible de réécriture, ce -qui signifie que l'URI de la requête n'est pas modifié. Il n'y a aucune -raison de réécrire un URI, si vous avez l'intention d'interdire la -requête.

- -

Lorsqu'on utilise [F], [L] est implicite - c'est à dire que la -réponse est renvoyée immédiatement, et aucune autre règle n'est évaluée.

- -
top
-
-

G|gone

-

Le drapeau [G] permet de faire envoyer par le serveur un code de statut -"410 Gone" avec la réponse. Ce code indique qu'une ressource qui était -disponible auparavant ne l'est plus actuellement.

- -

Comme dans le cas du drapeau [F], on utilise en général la syntaxe -"-" pour la cible de réécriture lorsqu'on utilise le drapeau [G] :

- -
RewriteRule "oldproduct" "-" [G,NC]
- - -

Lorsqu'on utilise [G], [L] est implicite - c'est à dire que la -réponse est renvoyée immédiatement, et aucune autre règle n'est évaluée.

- -
top
-
-

H|handler

-

Force le traitement de la requête résultante par le gestionnaire -spécifié. Par exemple, on peut utiliser ce drapeau pour forcer -l'interprétation de tous les fichiers sans extension par le gestionnaire -php :

- -
RewriteRule "!\." "-" [H=application/x-httpd-php]
- - -

-L'expression rationnelle ci-dessus - !\. - correspond à -toute requête qui ne contient pas le caractère .. -

-

On peut aussi utiliser ce drapeau pour forcer l'utilisation d'un -certain gestionnaire en fonction de certaines conditions. Par exemple, -l'extrait suivant utilisé dans un contexte de niveau serveur permet de -faire en sorte que les fichiers .php soient -affichés par mod_php dans le cas où ils font -l'objet d'une requête avec l'extension .phps :

- -
RewriteRule "^(/source/.+\.php)s$" "$1" [H=application/x-httpd-php-source]
- - - -

L'expression rationnelle ci-dessus - -^(/source/.+\.php)s$ - va correspondre à toute requête qui -débutera par /source/, continuera par 1 ou n caractères -puis par .phps. La référence arrière $1 fait référence à la -correspondance capturée entre parenthèses de l'expression -rationnelle.

- - -
top
-
-

L|last

-

Lorsque le drapeau [L] est présent, mod_rewrite -arrête le traitement du jeu de règles. Cela signifie dans la plupart des -situations que si la règle s'applique, aucune autre règle ne sera -traitée. Ce drapeau correspond à la commande Perl last, ou -à la commande break en C. Utilisez ce drapeau pour indiquer -que la règle courante doit être appliquée immédiatement, sans tenir -compte des règles ultérieures.

- -

Si vous utilisez des règles RewriteRule dans des fichiers -.htaccess ou des sections <Directory>, il est important d'avoir quelques -notions sur la manière dont les règles sont traitées. Pour simplifier, -une fois les règles traitées, la requête réécrite est passée à nouveau -au moteur d'interprétation des URLs afin que ce dernier puisse la -traiter. Il est possible qu'au cours du traitement de la requête -réécrite, le fichier .htaccess ou la section <Directory> soient à nouveau -rencontrés, entraînant un nouveau traitement du jeu de règles depuis le -début. Cette situation se présente le plus souvent lorsqu'une des règles -provoque une redirection - interne ou externe - ce qui réinitialise le -traitement de la requête.

- -

Si vous utilisez des directives RewriteRule dans un de ces contextes, -il importe par conséquent de prévoir explicitement des étapes permettant -d'éviter un bouclage infini sur les règles, -et de ne pas compter seulement sur -le drapeau [L] pour terminer l'exécution d'une série de règles, comme -décrit ci-dessous.

- -

Un autre drapeau, [END], permet non seulement d'interrompre le cycle -courant du processus de réécriture, mais aussi d'empêcher toute -réécriture ultérieure dans le contexte de répertoire (htaccess). Ceci ne -s'applique pas aux nouvelles requêtes résultant de redirections -externes.

- -

Dans l'exemple donné ici, toute requête est réécrite en -index.php, la requête originale étant ajoutée comme chaîne -de requête en argument à index.php ; cependant, la -directive RewriteCond permet de s'assurer que si -la requête concerne déjà index.php, la directive RewriteRule sera sautée.

- -
RewriteBase "/"
-RewriteCond "%{REQUEST_URI}" !=/index.php
-RewriteRule "^(.*)" "/index.php?req=$1" [L,PT]
- -
top
-
-

N|next

-

Le drapeau [N] provoque un redémarrage du traitement des règles -depuis le début, en utilisant le résultat du jeu de règles, sous -réserve qu'il existe un point de démarrage ; à utiliser avec précautions -car il peut provoquer un bouclage infini. -

-

-Le drapeau [Next] peut servir, par exemple, -à remplacer de manière répétitive -une chaîne de caractère ou une lettre dans une requête. Dans l'exemple -suivant, chaque occurence de A sera remplacée par B dans la requête, et -ceci jusqu'il n'y ait plus de A à remplacer. -

- -
RewriteRule "(.*)A(.*)" "$1B$2" [N]
- - -

Vous pouvez vous représenter ce traitement comme une boucle -while : tant que le modèle de la règle correspond (c'est à -dire, tant que l'URI contient un A), -effectuer la substitution (c'est à dire, remplacer le A par -un B).

- -

A partir de la version 2.5.0, ce module renvoie une erreur après -10000 itérations afin d'éviter les boucles infinies. Ce nombre maximum -d'itération peut être modifié via le drapeau N.

-
# On veut remplacer 1 caractère à chaque itération de la boucle
-RewriteRule "(.+)[><;]$" "$1" [N=32000]
-# ... ou s'arrêter après 10 itérations
-RewriteRule "(.+)[><;]$" "$1" [N=10]
- - -
top
-
-

NC|nocase

-

Avec le drapeau [NC], le modèle de la règle RewriteRule est comparé à la requête de -manière insensible à la casse. C'est à dire que cette comparaison -s'effectue sans tenir compte des majuscules/minuscules dans l'URI -comparé.

- -

Dans l'exemple suivant, toute requête pour un fichier image sera -transmise par Apache à votre serveur d'images dédié. La correspondance est -insensible à la casse, si bien que par exemple, .jpg aussi -bien que .JPG seront acceptés.

- -
RewriteRule "(.*\.(jpg|gif|png))$" "http://images.example.com$1" [P,NC]
- -
top
-
-

NE|noescape

-

Par défaut, les caractères spéciaux, comme & et -?, sont convertis en leur équivalent -hexadécimal. Le drapeau [NE] permet d'éviter cette conversion. -

- -
RewriteRule "^/anchor/(.+)" "/bigpage.html#$1" [NE,R]
- - -

-Dans l'exemple ci-dessus, /anchor/xyz est réécrit en -/bigpage.html#xyz. En l'absence du drapeau [NE], le # -aurait été converti en son équivalent hexadécimal, %23, ce -qui aurait provoqué un code d'erreur "404 Not Found". -

- -
top
-
-

NS|nosubreq

-

Le drapeau [NS] empêche la règle de s'appliquer aux sous-requêtes. -Par exemple, une page incluse au moyen d'une SSI (Server -Side Include) est une sous-requête, et vous ne voudrez probablement pas que -la réécriture s'applique à ces sous-requêtes. Ainsi, lorsque -mod_dir recherche des informations à propos des -fichiers par défaut du répertoire (comme les fichiers -index.html), il s'agit d'une sous-requête interne, et vous -ne désirez en général pas que ces sous-requêtes soient réécrites. Cette -réécriture -n'est pas toujours utile pour les sous-requêtes, et peut même causer des -erreurs si l'ensemble du jeu de règles est appliqué. L'utilisation de -ce drapeau permet d'exclure les règles qui peuvent poser problème.

- -

Comment déterminer si vous devez utiliser cette règle ou non : si -vous préfixez les URLs avec des scripts CGI, afin de forcer leur -traitement par le script CGI, vous vous exposez à des problèmes (ou du -moins à une surcharge significative) avec les sous-requêtes. Dans ces -cas, vous devez utiliser ce drapeau.

- -

-Les images, scripts java, ou fichiers css, chargés en tant que partie -d'une page html, ne sont pas des sous-requêtes - le navigateur les -appelle sous forme de requêtes HTTP à part entière. -

-
top
-
-

P|proxy

-

L'utilisation du drapeau [P] entraîne le traitement de la requête par -le module mod_proxy, et ceci via une requête de -mandataire. Par exemple, si vous voulez que toutes les requêtes d'images -soient traitées par un serveur d'images annexe, vous pouvez utiliser -une règle de ce style :

- -
RewriteRule "/(.*)\.(jpg|gif|png)$" "http://images.example.com/$1.$2" [P]
- - -

L'utilisation du drapeau [P] provoque aussi l'effet du drapeau [L] - -autrement dit, la requête est immédiatement envoyée au mandataire, et -toute règle ultérieure sera ignorée.

- -

-Vous devez vous assurer que la chaîne de substitution soit un URI valide -(commençant typiquement par http://nom-serveur) -qui puisse être traitée par le module mod_proxy. Dans -le cas contraire, le module mandataire vous renverra une erreur. -L'utilisation de ce drapeau implémente de manière plus puissante la -directive ProxyPass, pour -faire correspondre le contenu distant à l'espace de nommage du serveur -local.

- -
-

Avertissement à propos de la sécurité

-

Lors de la construction de l'URL cible de la règle, il convient - de prendre en compte l'impact en matière de sécurité qu'aura le - fait de permettre au client d'influencer le jeu d'URLs pour - lesquelles votre serveur agira en tant que mandataire. - Assurez-vous que la partie protocole://nom-serveur de l'URL soit - fixe, ou ne permette pas au client de l'influencer induement.

-
- -
-

Avertissement au sujet des performances

-

Utiliser ce drapeau fait intervenir mod_proxy sans la gestion des connexions - persistantes, ce qui signifie que vous obtiendrez des performances meilleurs si vous utilisez - ProxyPass ou ProxyPassMatch.

-

Ceci est du au fait que ce drapeau induit l'utilisation du worker par défaut, qui - ne gère pas la mise en commun et la réutilisation des connexions.

-

Partout où cela est possible, préférez l'utilisation de ces directives.

-
- -

Note: mod_proxy doit être activé pour pouvoir -utiliser ce drapeau.

- -
top
-
-

PT|passthrough

- -

-Par défaut, la cible (ou chaîne de substitution) d'une règle -RewriteRule est sensée être un chemin de fichier. Avec le drapeau [PT], -par contre, elle est traitée comme un URI. Autrement dit, avec le -drapeau [PT], le résultat de la règle RewriteRule est passé à nouveau au -système de mise en correspondance des URLs avec le système de fichiers, -de façon à ce que les systèmes de mise en correspondance basés sur les -chemins de fichiers, comme la directive Alias, Redirect, ou ScriptAlias, par exemple, puissent avoir une -chance d'accomplir leur tâche. -

- -

-Si par exemple, vous avez un Alias pour /icons, et une règle RewriteRule qui renvoie vers /icons, -vous devez utiliser le drapeau [PT] pour être sûr que l'Alias sera bien évalué. -

- -
Alias "/icons" "/usr/local/apache/icons"
-RewriteRule "/pics/(.+)\.jpg$" "/icons/$1.gif" [PT]
- - -

-Dans l'exemple précédent, en l'absence du drapeau [PT], l'Alias aurait -été ignoré, ce qui aurait provoqué une erreur 'File not found'. -

- -

Avec le drapeau PT, le drapeau L est -implicite : la réécriture s'arrêtera afin de transmettre la requête à la -phase suivante du traitement.

- -

Notez que le drapeau PT est implicite dans des contextes -de répertoire comme les sections <Directory> ou les fichiers -.htaccess. Le seul moyen de contourner ceci consiste à -réécrire vers -.

- -
top
-
-

QSA|qsappend

-

-Quand l'URI de remplacement contient une chaîne de requête, le -comportement par défaut de la règle RewriteRule est de supprimer la -query string (il s'agit des paramètres éventuellement passés dans l'URL après le -caractère ?, usuellement pour les formulaires traités par la -méthode HTTP GET) existante, et de la remplacer par celle nouvellement créée. -Avec le drapeau [QSA], les chaînes de requête peuvent être combinées. -

- -

Considérons la règle suivante :

- -
RewriteRule "/pages/(.+)" "/page.php?page=$1" [QSA]
- - -

Avec le drapeau [QSA], une requête pour -/pages/123?one=two sera réécrite en -/page.php?page=123&one=two. Sans le drapeau [QSA], la -même requête sera réécrite en /page.php?page=123 - -autrement dit, la chaîne de requête (query string) existante sera supprimée. -

-
top
-
-

QSD|qsdiscard

-

-Lorsque l'URI de la requête contient une chaîne de paramètres, et si -l'URI cible n'en contient pas, le comportement par défaut de la -directive RewriteRule consiste à copier cette -chaîne de paramètres dans l'URI cible. Avec le drapeau [QSD], la chaîne -de paramètres est supprimée. -

- -

Ce drapeau est disponible dans les versions 2.4.0 et supérieures.

- -

-Lorsque les drapeaux [QSD] et [QSA] sont utilisés ensemble, c'est le -drapeau [QSD] qui l'emporte. -

- -

-Si l'URI cible possède une chaîne de paramètres, le comportement par -défaut sera respecté - c'est à dire que la chaîne de paramètres -originale sera supprimée et remplacée par la chaîne de paramètres de -l'URI cible. -

- -
top
-
-

QSL|qslast

-

-Par défaut, le premier (le plus à gauche) point d'interrogation de la -substitution sépare le chemin de la requête de sa chaîne de paramètres. Avec le -drapeau [QSL] au contraire, les deux composants seront séparés en utilisant le -dernier (le plus à droite) point d'interrogation.

- -

-Cela peut s'avérer utile lorsqu'on recherche un fichier dont le nom contient des -points d'interrogation. Si aucune chaîne de paramètre n'est présente dans la -substitution, il est alors possible d'ajouter un point d'interrogation à la fin -et d'utiliser ce drapeau.

- -

Ce drapeau est disponible à partir de la version 2.4.19 du serveur HTTP -Apache.

- -
top
-
-

R|redirect

-

-L'utilisation du drapeau [R] provoque l'envoi d'une redirection au -navigateur. Si une URL pleinement qualifiée (FQDN - fully qualified domain name) - est spécifiée (c'est à dire incluant http://nom-du-serveur/), - une redirection sera effectuée vers cette adresse. Dans le cas contraire, - le protocole courant, le nom du serveur et le numéro de port seront - utilisés pour générer l'URL envoyée avec la redirection. -

- -

Tout code de statut de réponse HTTP valide peut être -spécifié, en utilisant la syntaxe [R=305], le code de statut 302 étant -utilisé par défaut si aucun code n'est spécifié. Le code de statut -spécifié n'est pas nécessairement un code de statut -de redirection (3xx). Cependant, si le code de statut est en dehors de la plage des codes de -redirection (300-399), la chaîne de substitution est entièrement -supprimée, et la réécriture s'arrête comme si le drapeau L -était utilisé.

- -

En plus des codes de statut de réponse, vous pouvez spécifier les -codes de redirection en utilisant leurs noms symboliques : -temp (défaut), permanent, ou -seeother.

- -

-Vous utiliserez presque toujours [R] en conjonction avec [L] (c'est à -dire [R,L]), car employé seul, le drapeau [R] préfixe l'URI avec -http://cet-hôte[:ce-port], mais passe ensuite cette adresse -à la règle suivante, ce qui provoquera le plus souvent des -avertissements 'Invalid URI in request'. -

- -
top
-
-

S|skip

-

Le drapeau [S] sert à sauter des règles que vous ne voulez pas voir -exécuter. La syntaxe du drapeau [S] est [S=N], où -N correspond au nombre de règles à sauter (sous -réserve que la règle RewriteRule corresponde et qu'au moins -une condition RewriteCond -préalable soit vérifiée). -Ceci peut s'interpréter comme une instruction -goto dans votre jeu de règles de réécriture. Dans -l'exemple suivant, nous ne voulons exécuter la règle RewriteRule que si l'URI demandé ne -correspond pas à un fichier existant.

-
# La requête concerne-t-elle un fichier qui n'existe pas ?
-RewriteCond "%{REQUEST_FILENAME}" !-f
-RewriteCond "%{REQUEST_FILENAME}" !-d
-# Si c'est la cas, on saute les deux règles de réécriture suivantes
-RewriteRule ".?" "-" [S=2]
-
-RewriteRule "(.*\.gif)" "images.php?$1"
-RewriteRule "(.*\.html)" "docs.php?$1"
- - - - -

Cette technique trouve son utilité dans le fait qu'une directive -RewriteCond ne s'applique -qu'à la règle qui la suit immédiatement. Ainsi, si vous voulez -qu'une directive RewriteCond s'applique à plusieurs règles -RewriteRule, une technique possible consiste à inverser ces -conditions et ajouter une RewriteRule avec le drapeau [Skip]. Cette technique permet -d'élaborer des pseudo-constructions if-then-else : la dernière règle du -bloc then contiendra skip=N, où N est le nombre de règles -contenues dans le bloc else :

-
# Est-ce que le fichier existe ?
-RewriteCond "%{REQUEST_FILENAME}" !-f
-RewriteCond "%{REQUEST_FILENAME}" !-d
-# Create an if-then-else construct by skipping 3 lines if we meant to go to the "else" stanza.
-RewriteRule ".?" "-" [S=3]
-
-# Si le fichier existe, alors :
-RewriteRule "(.*\.gif)" "images.php?$1"
-    RewriteRule "(.*\.html)" "docs.php?$1"
-    # Skip past the "else" stanza.
-    RewriteRule ".?" "-" [S=1]
-# ELSE...
-RewriteRule "(.*)" "404.php?file=$1"
-# END
- - -

Il est probablement plus aisé de définir ce genre de configuration -via les directives <If>, <ElseIf>, et <Else>.

- -
top
-
-

T|type

-

Définit le type MIME de la réponse résultante renvoyée. L'effet est -identique à celui de la directive AddType.

- -

Par exemple, vous pouvez utiliser la technique suivante pour servir -du code source Perl en tant que plein texte, s'il est requis d'une -certaine manière :

- -
# Sert les fichier .pl en tant que plein texte
-RewriteRule "\.pl$" "-" [T=text/plain]
- - -

Ou encore, si vous possédez une caméra qui produit des fichiers -images jpeg sans extension, vous pouvez forcer le renvoi de ces images -avec le type MIME correct en se basant sur le nom du fichier :

- -
# Les fichiers dont le nom contient 'IMG' sont des images jpg.
-RewriteRule "IMG" "-" [T=image/jpg]
- - -

Notez cependant qu'il s'agit d'un exemple trivial, et que le problème -aurait pu être résolu en utilisant à la place la directive <FilesMatch>. Il faut toujours -envisager la possibilité d'une solution alternative à un problème avant -d'avoir recours à la réécriture, qui sera toujours moins efficace qu'une -solution alternative.

- -

-Dans un contexte de niveau répertoire, n'utilisez que - -(tiret) comme substitution, dans toute la séquence de réécriture de -mod_rewrite, sinon le type MIME défini avec ce drapeau -sera perdu suite à un retraitement interne (y compris les séquences de -réécriture suivantes de mod_rewrite). Dans ce contexte, vous pouvez -utiliser le drapeau L pour terminer la séquence -courante de réécriture de mod_rewrite.

- -
-
-

Langues Disponibles:  en  | - fr 

-
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
-
- \ No newline at end of file diff --git a/docs/manual/rewrite/flags.html.fr.utf8 b/docs/manual/rewrite/flags.html.fr.utf8 new file mode 100644 index 0000000000..edc8138107 --- /dev/null +++ b/docs/manual/rewrite/flags.html.fr.utf8 @@ -0,0 +1,853 @@ + + + + + +Les drapeaux de réécriture - Serveur HTTP Apache Version 2.5 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.5

+
+
<-
+

Les drapeaux de réécriture

+
+

Langues Disponibles:  en  | + fr 

+
+ +

Ce document décrit les drapeaux disponibles dans la directive +RewriteRule, en fournissant +des explications détaillées et des exemples.

+
+ +
top
+
+

Introduction

+

Le comportement d'une directive RewriteRule peut être modifié par un ou +plusieurs drapeaux. Les drapeaux sont situés en fin de règle, entourés +de crochets, et séparés le cas échéant par des virgules.

+
RewriteRule pattern target [Flag1,Flag2,Flag3]
+ + +

Chaque drapeau (à quelques exceptions près) +possède une forme courte, comme CO, ainsi qu'une forme longue, +comme cookie. Bien que +la forme courte soit la plus couramment utilisée, nous vous recommandons +de vous familiariser avec les drapeaux sous leur forme longue, afin de +bien mémoriser ce que chaque drapeau est supposé faire. +Certains drapeaux acceptent un ou plusieurs arguments. Les drapeaux ne +sont pas sensibles à la casse.

+ +

Les drapeaux qui modifient les métadonnées associées à la requête +(T=, H=, E=) n'ont aucun effet dans un contexte de répertoire ou de +fichier htaccess, lorsqu'une substitution (autre que '-') est effectuée +au cours de la même passe du processus de réécriture. +

+ +

Chaque drapeau disponible est présenté ici, avec un exemple +d'utilisation.

+
top
+
+

B (échappement dans les références arrières)

+

Avec le drapeau [B], la directive RewriteRule échappe les caractères +non-alphanumériques avant d'appliquer la transformation. A partir +de la version 2.4.26, vous pouvez limiter l'échappement dans les +références arrières à une liste de caractères que vous pouvez spécifiez comme +dans cet exemple : [B=#?;]. Notez que l'espace peut faire +partie de la liste des caractères à échapper, mais qu'il ne doit pas +être le dernier caractère de cette liste. +

+ +

mod_rewrite doit supprimer les séquences d'échappement +des URLs avant leur +mise en correspondance avec le système de fichiers ; les séquences +d'échappement sont donc supprimées des références arrières au moment où +ces dernières sont appliquées. Avec le drapeau B, les caractères +non-alphanumériques des références arrières seront échappés. Considérons +par exemple cette règle :

+ +
RewriteRule "^search/(.*)$" "/search.php?term=$1"
+ + +

Soit le terme de recherche 'x & y/z' ; un navigateur va le coder +en 'x%20%26%20y%2Fz', transformant la requête en +'search/x%20%26%20y%2Fz'. Sans le drapeau B, cette règle de réécriture +va réécrire la requête en 'search.php?term=x & y/z', ce qui ne +correspond pas à une URL valide et cette dernière sera encodée en +search.php?term=x%20&y%2Fz=, ce qui ne correspond pas à +ce que l'on souhaitait.

+ +

Avec le drapeau B, les paramètres sont réencodés avant d'être passés +à l'URL résultante, ce qui fournit une réécriture correcte en +/search.php?term=x%20%26%20y%2Fz.

+ +
RewriteRule "^search/(.*)$" "/search.php?term=$1" [B,PT]
+ + +

Notez que vous devrez peut-être aussi définir la +directive AllowEncodedSlashes +à On pour +que cet exemple particulier fonctionne, car httpd ne permet pas les +slashes encodés dans les URLs, et renvoie une erreur 404 s'il en +rencontre un.

+ +

Ce processus d'échappement est en particulier nécessaire dans le +contexte d'un mandataire, où l'accès au serveur d'arrière-plan échouera +si on présente à ce dernier une URL non échappée.

+ +

Une alternative à ce drapeau consiste à utiliser une directive +RewriteCond pour capturer +%{THE_REQUEST}, les chaînes capturées se présentant +alors sous la forme codée.

+ +
top
+
+

BNP|backrefnoplus (ne pas échapper +l'espace en +)

+

Si le drapeau [BNP] est spécifié, la directive RewriteRule échappera le caractère +espace en %20 au lieu de '+' dans les références arrières. Ceci s'avère +utile lorsque la référence arrière est utilisée dans la partie chemin, +et non dans les paramètres de la requête.

+ +

Ce drapeau est disponible à partir de la version 2.4.26 du serveur HTTP +Apache.

+ +
top
+
+

C|chain

+

Le drapeau [C] ou [chain] indique que la règle RewriteRule est chaînée avec la +suivante. Autrement dit, si la règle s'applique, elle est traitée +normalement et passe le contrôle à la règle suivante. Par contre, si +elle ne s'applique pas, la règle suivante, ainsi que toutes les règles +chaînées qui suivent, seront sautées.

+ +
top
+
+

CO|cookie

+

Le drapeau [CO], ou [cookie], vous permet de définir un cookie +lorsqu'une règle RewriteRule +s'applique. Il possède trois arguments obligatoires et +quatre arguments optionnels.

+ +

La syntaxe complète de ce drapeau, avec tous ses attributs, est la +suivante :

+ +

+[CO=NAME:VALUE:DOMAIN:lifetime:path:secure:httponly] +

+ +

Si un caractère littéral ':' doit être insérer dans un des champs du +cookie, une autre syntaxe est disponible. Pour utiliser cette syntaxe +alternative, le contenu du champ "Name" doit être précédé du caractère +';', et les sépateurs de champs deviendront des ';'.

+ +

+[CO=;NAME;VALUE:MOREVALUE;DOMAIN;lifetime;path;secure;httponly] +

+ +

Vous devez déclarer un nom, une valeur et un domaine pour que +le cookie puisse être défini.

+ + +
+
Domain
+
Le domaine pour lequel vous souhaitez que le cookie soit valide. Ce +peut être un nom de serveur, comme www.example.com, ou un +domaine, comme .example.com. Il doit comporter au moins +deux parties séparées par un point. C'est à dire que vous ne pouvez pas +utiliser les valeurs .com ou .net. En effet, +ce style de cookie est interdit par le modèle de sécurité des cookies.
+
+ +

Vous pouvez aussi définir les valeurs suivantes :

+ +
+
Lifetime
+
La durée de vie du cookie, en minutes.
+
Une valeur de 0 indique une durée de vie correspondant à la session +courante du navigateur. Il s'agit de la valeur par défaut.
+ +
Path
+
Le chemin, sur le site web concerné, pour lequel le cookie est +valide, du style /clients/ or +/fichiers/telechargement/.
+
La valeur par défaut est / - c'est à dire l'ensemble du +site web.
+ +
Secure
+
Si cet argument a pour valeur secure, +true, ou 1, le cookie ne pourra être transmis +que dans le cadre d'une connexion sécurisée (https).
+ +
httponly
+
Si cet argument a pour valeur HttpOnly, +true, ou 1, le cookie aura son drapeau +HttpOnly activé, ce qui signifie qu'il sera inaccessible au +code JavaScript pour les navigateurs qui supportent cette +fonctionnalité.
+
+ +

Voici un exemple :

+ +
RewriteEngine On
+RewriteRule "^/index\.html" "-" [CO=frontdoor:yes:.example.org:1440:/]
+ + +

Dans l'exemple ci-dessus, la règle ne réécrit +pas la requête. La cible de réécriture "-" +indique à mod_rewrite de transmettre la requête sans +modification. Par contre, il +définit un cookie nommé 'frontdoor' avec une valeur 'yes'. Le cookie est +valide pour tout hôte situé dans le domaine .example.org. Sa +durée de vie est limitée à 1440 minutes (24 heures), et il sera renvoyé +pour tous les URIs.

+ +
top
+
+

DPI|discardpath

+

Avec le drapeau DPI, la partie PATH_INFO de l'URI +réécrit est supprimée.

+

Ce drapeau est disponible dans les versions 2.2.12 et supérieures.

+

Dans un contexte de répertoire, l'URI mis en comparaison par chaque +règle RewriteRule est la concaténation des +valeurs courantes de l'URI et de PATH_INFO.

+ +

L'URI courant peut être l'URI initial tel qu'il a été fourni par le +client, le résultat d'une passe précédente du processus de réécriture, +ou le résultat de la règle précédente dans le processus courant de +réécriture.

+ +

Par contre, la partie PATH_INFO ajoutée à l'URI avant chaque règle ne +reflète que la valeur de PATH_INFO avant la passe courante du processus +de réécriture. En conséquence, si de larges portions de l'URI +correspondent et sont traduites via plusieurs directives +RewriteRule, sans prendre en compte +quelles parties de l'URI provenaient du PATH_INFO courant, l'URI final +pourra se voir ajouter plusieurs copies de PATH_INFO.

+ +

Utilisez ce drapeau pour toute substitution où la présence du PATH_INFO qui +résultait de la mise en correspondance précédente de cette requête avec +le système de fichier n'est pas nécessaire. Avec ce drapeau, le +PATH_INFO établi avant que cette passe du processus de réécriture ne +débute est oublié. PATH_INFO ne sera pas recalculé tant que la passe +courante du processus de réécriture ne sera pas achevée. Les règles +suivantes de cette passe ne verront que le résultat direct des +substitutions, sans aucun PATH_INFO ajouté.

+
top
+
+

E|env

+

Avec le drapeau [E], ou [env], vous pouvez définir la valeur d'une +variable d'environnement. Notez que certaines variables d'environnement +peuvent être définies après le traitement de la règle, annulant par +la-même ce que vous avez défini. Voir le document +sur les variables d'environnement pour plus de détails sur le +fonctionnement des variables d'environnement.

+ +

La syntaxe complète pour ce drapeau est :

+ +
[E=!VAR]
+ + +

VAL peut comporter des références arrières +($N ou %N) qui seront développées.

+ +

En utilisant la version courte

+ +

+[E=VAR] +

+ +

vous pouvez définir la variable d'environnement nommée +VAR avec une valeur vide.

+ +

La forme

+ +

+[E=!VAR] +

+ +

permet d'annuler la définition de la variable VAR.

+ +

Les variables d'environnement s'emploient dans différents contextes, +comme les programmes CGI, d'autres directives RewriteRule, ou des +directives CustomLog.

+ +

L'exemple suivant définit une variable d'environnement nommée 'image' +avec une valeur de '1' si l'URI de la requête correspond à un fichier +image. Cette variable d'environnement est ensuite utilisée pour exclure +une telle requête du journal des accès.

+ +
RewriteRule "\.(png|gif|jpg)" "-" [E=image:1]

+CustomLog "logs/access_log" combined env=!image
+ + +

Notez que le même effet peut être obtenu à l'aide de la directive +SetEnvIf. Cette technique +est présentée à titre d'exemple et non de recommandation.

+
top
+
+

END

+

L'utilisation du drapeau [END] permet non seulement de terminer le +processus de réécriture en cours (comme [L]), mais aussi d'empêcher tout +processus de réécriture ultérieur dans un contexte de répertoire +(htaccess).

+ +

Ceci ne s'applique pas aux nouvelles requêtes résultant d'une +redirection externe.

+
top
+
+

F|forbidden

+

L'utilisation du drapeau [F] permet de faire envoyer par le serveur au +client un code de statut "403 Forbidden". Le même effet peut être obtenu à +l'aide de la directive Deny, +mais ce drapeau offre plus de souplesse dans l'attribution d'un statut +Forbidden.

+ +

La règle suivante va interdire la téléchargement de fichiers +.exe depuis votre serveur.

+ +
RewriteRule "\.exe" "-" [F]
+ + +

Cet exemple utilise la syntaxe "-" pour la cible de réécriture, ce +qui signifie que l'URI de la requête n'est pas modifié. Il n'y a aucune +raison de réécrire un URI, si vous avez l'intention d'interdire la +requête.

+ +

Lorsqu'on utilise [F], [L] est implicite - c'est à dire que la +réponse est renvoyée immédiatement, et aucune autre règle n'est évaluée.

+ +
top
+
+

G|gone

+

Le drapeau [G] permet de faire envoyer par le serveur un code de statut +"410 Gone" avec la réponse. Ce code indique qu'une ressource qui était +disponible auparavant ne l'est plus actuellement.

+ +

Comme dans le cas du drapeau [F], on utilise en général la syntaxe +"-" pour la cible de réécriture lorsqu'on utilise le drapeau [G] :

+ +
RewriteRule "oldproduct" "-" [G,NC]
+ + +

Lorsqu'on utilise [G], [L] est implicite - c'est à dire que la +réponse est renvoyée immédiatement, et aucune autre règle n'est évaluée.

+ +
top
+
+

H|handler

+

Force le traitement de la requête résultante par le gestionnaire +spécifié. Par exemple, on peut utiliser ce drapeau pour forcer +l'interprétation de tous les fichiers sans extension par le gestionnaire +php :

+ +
RewriteRule "!\." "-" [H=application/x-httpd-php]
+ + +

+L'expression rationnelle ci-dessus - !\. - correspond à +toute requête qui ne contient pas le caractère .. +

+

On peut aussi utiliser ce drapeau pour forcer l'utilisation d'un +certain gestionnaire en fonction de certaines conditions. Par exemple, +l'extrait suivant utilisé dans un contexte de niveau serveur permet de +faire en sorte que les fichiers .php soient +affichés par mod_php dans le cas où ils font +l'objet d'une requête avec l'extension .phps :

+ +
RewriteRule "^(/source/.+\.php)s$" "$1" [H=application/x-httpd-php-source]
+ + + +

L'expression rationnelle ci-dessus - +^(/source/.+\.php)s$ - va correspondre à toute requête qui +débutera par /source/, continuera par 1 ou n caractères +puis par .phps. La référence arrière $1 fait référence à la +correspondance capturée entre parenthèses de l'expression +rationnelle.

+ + +
top
+
+

L|last

+

Lorsque le drapeau [L] est présent, mod_rewrite +arrête le traitement du jeu de règles. Cela signifie dans la plupart des +situations que si la règle s'applique, aucune autre règle ne sera +traitée. Ce drapeau correspond à la commande Perl last, ou +à la commande break en C. Utilisez ce drapeau pour indiquer +que la règle courante doit être appliquée immédiatement, sans tenir +compte des règles ultérieures.

+ +

Si vous utilisez des règles RewriteRule dans des fichiers +.htaccess ou des sections <Directory>, il est important d'avoir quelques +notions sur la manière dont les règles sont traitées. Pour simplifier, +une fois les règles traitées, la requête réécrite est passée à nouveau +au moteur d'interprétation des URLs afin que ce dernier puisse la +traiter. Il est possible qu'au cours du traitement de la requête +réécrite, le fichier .htaccess ou la section <Directory> soient à nouveau +rencontrés, entraînant un nouveau traitement du jeu de règles depuis le +début. Cette situation se présente le plus souvent lorsqu'une des règles +provoque une redirection - interne ou externe - ce qui réinitialise le +traitement de la requête.

+ +

Si vous utilisez des directives RewriteRule dans un de ces contextes, +il importe par conséquent de prévoir explicitement des étapes permettant +d'éviter un bouclage infini sur les règles, +et de ne pas compter seulement sur +le drapeau [L] pour terminer l'exécution d'une série de règles, comme +décrit ci-dessous.

+ +

Un autre drapeau, [END], permet non seulement d'interrompre le cycle +courant du processus de réécriture, mais aussi d'empêcher toute +réécriture ultérieure dans le contexte de répertoire (htaccess). Ceci ne +s'applique pas aux nouvelles requêtes résultant de redirections +externes.

+ +

Dans l'exemple donné ici, toute requête est réécrite en +index.php, la requête originale étant ajoutée comme chaîne +de requête en argument à index.php ; cependant, la +directive RewriteCond permet de s'assurer que si +la requête concerne déjà index.php, la directive RewriteRule sera sautée.

+ +
RewriteBase "/"
+RewriteCond "%{REQUEST_URI}" !=/index.php
+RewriteRule "^(.*)" "/index.php?req=$1" [L,PT]
+ +
top
+
+

N|next

+

Le drapeau [N] provoque un redémarrage du traitement des règles +depuis le début, en utilisant le résultat du jeu de règles, sous +réserve qu'il existe un point de démarrage ; à utiliser avec précautions +car il peut provoquer un bouclage infini. +

+

+Le drapeau [Next] peut servir, par exemple, +à remplacer de manière répétitive +une chaîne de caractère ou une lettre dans une requête. Dans l'exemple +suivant, chaque occurence de A sera remplacée par B dans la requête, et +ceci jusqu'il n'y ait plus de A à remplacer. +

+ +
RewriteRule "(.*)A(.*)" "$1B$2" [N]
+ + +

Vous pouvez vous représenter ce traitement comme une boucle +while : tant que le modèle de la règle correspond (c'est à +dire, tant que l'URI contient un A), +effectuer la substitution (c'est à dire, remplacer le A par +un B).

+ +

A partir de la version 2.5.0, ce module renvoie une erreur après +10000 itérations afin d'éviter les boucles infinies. Ce nombre maximum +d'itération peut être modifié via le drapeau N.

+
# On veut remplacer 1 caractère à chaque itération de la boucle
+RewriteRule "(.+)[><;]$" "$1" [N=32000]
+# ... ou s'arrêter après 10 itérations
+RewriteRule "(.+)[><;]$" "$1" [N=10]
+ + +
top
+
+

NC|nocase

+

Avec le drapeau [NC], le modèle de la règle RewriteRule est comparé à la requête de +manière insensible à la casse. C'est à dire que cette comparaison +s'effectue sans tenir compte des majuscules/minuscules dans l'URI +comparé.

+ +

Dans l'exemple suivant, toute requête pour un fichier image sera +transmise par Apache à votre serveur d'images dédié. La correspondance est +insensible à la casse, si bien que par exemple, .jpg aussi +bien que .JPG seront acceptés.

+ +
RewriteRule "(.*\.(jpg|gif|png))$" "http://images.example.com$1" [P,NC]
+ +
top
+
+

NE|noescape

+

Par défaut, les caractères spéciaux, comme & et +?, sont convertis en leur équivalent +hexadécimal. Le drapeau [NE] permet d'éviter cette conversion. +

+ +
RewriteRule "^/anchor/(.+)" "/bigpage.html#$1" [NE,R]
+ + +

+Dans l'exemple ci-dessus, /anchor/xyz est réécrit en +/bigpage.html#xyz. En l'absence du drapeau [NE], le # +aurait été converti en son équivalent hexadécimal, %23, ce +qui aurait provoqué un code d'erreur "404 Not Found". +

+ +
top
+
+

NS|nosubreq

+

Le drapeau [NS] empêche la règle de s'appliquer aux sous-requêtes. +Par exemple, une page incluse au moyen d'une SSI (Server +Side Include) est une sous-requête, et vous ne voudrez probablement pas que +la réécriture s'applique à ces sous-requêtes. Ainsi, lorsque +mod_dir recherche des informations à propos des +fichiers par défaut du répertoire (comme les fichiers +index.html), il s'agit d'une sous-requête interne, et vous +ne désirez en général pas que ces sous-requêtes soient réécrites. Cette +réécriture +n'est pas toujours utile pour les sous-requêtes, et peut même causer des +erreurs si l'ensemble du jeu de règles est appliqué. L'utilisation de +ce drapeau permet d'exclure les règles qui peuvent poser problème.

+ +

Comment déterminer si vous devez utiliser cette règle ou non : si +vous préfixez les URLs avec des scripts CGI, afin de forcer leur +traitement par le script CGI, vous vous exposez à des problèmes (ou du +moins à une surcharge significative) avec les sous-requêtes. Dans ces +cas, vous devez utiliser ce drapeau.

+ +

+Les images, scripts java, ou fichiers css, chargés en tant que partie +d'une page html, ne sont pas des sous-requêtes - le navigateur les +appelle sous forme de requêtes HTTP à part entière. +

+
top
+
+

P|proxy

+

L'utilisation du drapeau [P] entraîne le traitement de la requête par +le module mod_proxy, et ceci via une requête de +mandataire. Par exemple, si vous voulez que toutes les requêtes d'images +soient traitées par un serveur d'images annexe, vous pouvez utiliser +une règle de ce style :

+ +
RewriteRule "/(.*)\.(jpg|gif|png)$" "http://images.example.com/$1.$2" [P]
+ + +

L'utilisation du drapeau [P] provoque aussi l'effet du drapeau [L] - +autrement dit, la requête est immédiatement envoyée au mandataire, et +toute règle ultérieure sera ignorée.

+ +

+Vous devez vous assurer que la chaîne de substitution soit un URI valide +(commençant typiquement par http://nom-serveur) +qui puisse être traitée par le module mod_proxy. Dans +le cas contraire, le module mandataire vous renverra une erreur. +L'utilisation de ce drapeau implémente de manière plus puissante la +directive ProxyPass, pour +faire correspondre le contenu distant à l'espace de nommage du serveur +local.

+ +
+

Avertissement à propos de la sécurité

+

Lors de la construction de l'URL cible de la règle, il convient + de prendre en compte l'impact en matière de sécurité qu'aura le + fait de permettre au client d'influencer le jeu d'URLs pour + lesquelles votre serveur agira en tant que mandataire. + Assurez-vous que la partie protocole://nom-serveur de l'URL soit + fixe, ou ne permette pas au client de l'influencer induement.

+
+ +
+

Avertissement au sujet des performances

+

Utiliser ce drapeau fait intervenir mod_proxy sans la gestion des connexions + persistantes, ce qui signifie que vous obtiendrez des performances meilleurs si vous utilisez + ProxyPass ou ProxyPassMatch.

+

Ceci est du au fait que ce drapeau induit l'utilisation du worker par défaut, qui + ne gère pas la mise en commun et la réutilisation des connexions.

+

Partout où cela est possible, préférez l'utilisation de ces directives.

+
+ +

Note: mod_proxy doit être activé pour pouvoir +utiliser ce drapeau.

+ +
top
+
+

PT|passthrough

+ +

+Par défaut, la cible (ou chaîne de substitution) d'une règle +RewriteRule est sensée être un chemin de fichier. Avec le drapeau [PT], +par contre, elle est traitée comme un URI. Autrement dit, avec le +drapeau [PT], le résultat de la règle RewriteRule est passé à nouveau au +système de mise en correspondance des URLs avec le système de fichiers, +de façon à ce que les systèmes de mise en correspondance basés sur les +chemins de fichiers, comme la directive Alias, Redirect, ou ScriptAlias, par exemple, puissent avoir une +chance d'accomplir leur tâche. +

+ +

+Si par exemple, vous avez un Alias pour /icons, et une règle RewriteRule qui renvoie vers /icons, +vous devez utiliser le drapeau [PT] pour être sûr que l'Alias sera bien évalué. +

+ +
Alias "/icons" "/usr/local/apache/icons"
+RewriteRule "/pics/(.+)\.jpg$" "/icons/$1.gif" [PT]
+ + +

+Dans l'exemple précédent, en l'absence du drapeau [PT], l'Alias aurait +été ignoré, ce qui aurait provoqué une erreur 'File not found'. +

+ +

Avec le drapeau PT, le drapeau L est +implicite : la réécriture s'arrêtera afin de transmettre la requête à la +phase suivante du traitement.

+ +

Notez que le drapeau PT est implicite dans des contextes +de répertoire comme les sections <Directory> ou les fichiers +.htaccess. Le seul moyen de contourner ceci consiste à +réécrire vers -.

+ +
top
+
+

QSA|qsappend

+

+Quand l'URI de remplacement contient une chaîne de requête, le +comportement par défaut de la règle RewriteRule est de supprimer la +query string (il s'agit des paramètres éventuellement passés dans l'URL après le +caractère ?, usuellement pour les formulaires traités par la +méthode HTTP GET) existante, et de la remplacer par celle nouvellement créée. +Avec le drapeau [QSA], les chaînes de requête peuvent être combinées. +

+ +

Considérons la règle suivante :

+ +
RewriteRule "/pages/(.+)" "/page.php?page=$1" [QSA]
+ + +

Avec le drapeau [QSA], une requête pour +/pages/123?one=two sera réécrite en +/page.php?page=123&one=two. Sans le drapeau [QSA], la +même requête sera réécrite en /page.php?page=123 - +autrement dit, la chaîne de requête (query string) existante sera supprimée. +

+
top
+
+

QSD|qsdiscard

+

+Lorsque l'URI de la requête contient une chaîne de paramètres, et si +l'URI cible n'en contient pas, le comportement par défaut de la +directive RewriteRule consiste à copier cette +chaîne de paramètres dans l'URI cible. Avec le drapeau [QSD], la chaîne +de paramètres est supprimée. +

+ +

Ce drapeau est disponible dans les versions 2.4.0 et supérieures.

+ +

+Lorsque les drapeaux [QSD] et [QSA] sont utilisés ensemble, c'est le +drapeau [QSD] qui l'emporte. +

+ +

+Si l'URI cible possède une chaîne de paramètres, le comportement par +défaut sera respecté - c'est à dire que la chaîne de paramètres +originale sera supprimée et remplacée par la chaîne de paramètres de +l'URI cible. +

+ +
top
+
+

QSL|qslast

+

+Par défaut, le premier (le plus à gauche) point d'interrogation de la +substitution sépare le chemin de la requête de sa chaîne de paramètres. Avec le +drapeau [QSL] au contraire, les deux composants seront séparés en utilisant le +dernier (le plus à droite) point d'interrogation.

+ +

+Cela peut s'avérer utile lorsqu'on recherche un fichier dont le nom contient des +points d'interrogation. Si aucune chaîne de paramètre n'est présente dans la +substitution, il est alors possible d'ajouter un point d'interrogation à la fin +et d'utiliser ce drapeau.

+ +

Ce drapeau est disponible à partir de la version 2.4.19 du serveur HTTP +Apache.

+ +
top
+
+

R|redirect

+

+L'utilisation du drapeau [R] provoque l'envoi d'une redirection au +navigateur. Si une URL pleinement qualifiée (FQDN - fully qualified domain name) + est spécifiée (c'est à dire incluant http://nom-du-serveur/), + une redirection sera effectuée vers cette adresse. Dans le cas contraire, + le protocole courant, le nom du serveur et le numéro de port seront + utilisés pour générer l'URL envoyée avec la redirection. +

+ +

Tout code de statut de réponse HTTP valide peut être +spécifié, en utilisant la syntaxe [R=305], le code de statut 302 étant +utilisé par défaut si aucun code n'est spécifié. Le code de statut +spécifié n'est pas nécessairement un code de statut +de redirection (3xx). Cependant, si le code de statut est en dehors de la plage des codes de +redirection (300-399), la chaîne de substitution est entièrement +supprimée, et la réécriture s'arrête comme si le drapeau L +était utilisé.

+ +

En plus des codes de statut de réponse, vous pouvez spécifier les +codes de redirection en utilisant leurs noms symboliques : +temp (défaut), permanent, ou +seeother.

+ +

+Vous utiliserez presque toujours [R] en conjonction avec [L] (c'est à +dire [R,L]), car employé seul, le drapeau [R] préfixe l'URI avec +http://cet-hôte[:ce-port], mais passe ensuite cette adresse +à la règle suivante, ce qui provoquera le plus souvent des +avertissements 'Invalid URI in request'. +

+ +
top
+
+

S|skip

+

Le drapeau [S] sert à sauter des règles que vous ne voulez pas voir +exécuter. La syntaxe du drapeau [S] est [S=N], où +N correspond au nombre de règles à sauter (sous +réserve que la règle RewriteRule corresponde et qu'au moins +une condition RewriteCond +préalable soit vérifiée). +Ceci peut s'interpréter comme une instruction +goto dans votre jeu de règles de réécriture. Dans +l'exemple suivant, nous ne voulons exécuter la règle RewriteRule que si l'URI demandé ne +correspond pas à un fichier existant.

+
# La requête concerne-t-elle un fichier qui n'existe pas ?
+RewriteCond "%{REQUEST_FILENAME}" !-f
+RewriteCond "%{REQUEST_FILENAME}" !-d
+# Si c'est la cas, on saute les deux règles de réécriture suivantes
+RewriteRule ".?" "-" [S=2]
+
+RewriteRule "(.*\.gif)" "images.php?$1"
+RewriteRule "(.*\.html)" "docs.php?$1"
+ + + + +

Cette technique trouve son utilité dans le fait qu'une directive +RewriteCond ne s'applique +qu'à la règle qui la suit immédiatement. Ainsi, si vous voulez +qu'une directive RewriteCond s'applique à plusieurs règles +RewriteRule, une technique possible consiste à inverser ces +conditions et ajouter une RewriteRule avec le drapeau [Skip]. Cette technique permet +d'élaborer des pseudo-constructions if-then-else : la dernière règle du +bloc then contiendra skip=N, où N est le nombre de règles +contenues dans le bloc else :

+
# Est-ce que le fichier existe ?
+RewriteCond "%{REQUEST_FILENAME}" !-f
+RewriteCond "%{REQUEST_FILENAME}" !-d
+# Create an if-then-else construct by skipping 3 lines if we meant to go to the "else" stanza.
+RewriteRule ".?" "-" [S=3]
+
+# Si le fichier existe, alors :
+RewriteRule "(.*\.gif)" "images.php?$1"
+    RewriteRule "(.*\.html)" "docs.php?$1"
+    # Skip past the "else" stanza.
+    RewriteRule ".?" "-" [S=1]
+# ELSE...
+RewriteRule "(.*)" "404.php?file=$1"
+# END
+ + +

Il est probablement plus aisé de définir ce genre de configuration +via les directives <If>, <ElseIf>, et <Else>.

+ +
top
+
+

T|type

+

Définit le type MIME de la réponse résultante renvoyée. L'effet est +identique à celui de la directive AddType.

+ +

Par exemple, vous pouvez utiliser la technique suivante pour servir +du code source Perl en tant que plein texte, s'il est requis d'une +certaine manière :

+ +
# Sert les fichier .pl en tant que plein texte
+RewriteRule "\.pl$" "-" [T=text/plain]
+ + +

Ou encore, si vous possédez une caméra qui produit des fichiers +images jpeg sans extension, vous pouvez forcer le renvoi de ces images +avec le type MIME correct en se basant sur le nom du fichier :

+ +
# Les fichiers dont le nom contient 'IMG' sont des images jpg.
+RewriteRule "IMG" "-" [T=image/jpg]
+ + +

Notez cependant qu'il s'agit d'un exemple trivial, et que le problème +aurait pu être résolu en utilisant à la place la directive <FilesMatch>. Il faut toujours +envisager la possibilité d'une solution alternative à un problème avant +d'avoir recours à la réécriture, qui sera toujours moins efficace qu'une +solution alternative.

+ +

+Dans un contexte de niveau répertoire, n'utilisez que - +(tiret) comme substitution, dans toute la séquence de réécriture de +mod_rewrite, sinon le type MIME défini avec ce drapeau +sera perdu suite à un retraitement interne (y compris les séquences de +réécriture suivantes de mod_rewrite). Dans ce contexte, vous pouvez +utiliser le drapeau L pour terminer la séquence +courante de réécriture de mod_rewrite.

+ +
+
+

Langues Disponibles:  en  | + fr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/rewrite/htaccess.html.en b/docs/manual/rewrite/htaccess.html.en index 2e46b0809c..2f0ffb7605 100644 --- a/docs/manual/rewrite/htaccess.html.en +++ b/docs/manual/rewrite/htaccess.html.en @@ -24,7 +24,7 @@ Apache > HTTP Server > Documentation > Version 2.5 > Rewrite

mod_rewrite and .htaccess files

Available Languages:  en  | - fr 

+ fr 

@@ -38,7 +38,7 @@ and how to deal with these changes.

Available Languages:  en  | - fr 

+ fr 

top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
- - -
-

Modules | Directives | FAQ | Glossaire | Plan du site

-

Serveur HTTP Apache Version 2.5

-
-
<-
-

mod_rewrite et les fichiers .htaccess

-
-

Langues Disponibles:  en  | - fr 

-
- - -

Ce document est un complément de la documentation de référence du module -mod_rewrite. Il décrit les changements apportés aux règles -lorsqu'on utilise mod_rewrite dans les fichiers .htaccess, et comment -travailler avec ces changements.

- -
- -
-
-

Langues Disponibles:  en  | - fr 

-
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
-
- \ No newline at end of file diff --git a/docs/manual/rewrite/htaccess.html.fr.utf8 b/docs/manual/rewrite/htaccess.html.fr.utf8 new file mode 100644 index 0000000000..152a02040b --- /dev/null +++ b/docs/manual/rewrite/htaccess.html.fr.utf8 @@ -0,0 +1,67 @@ + + + + + +mod_rewrite et les fichiers .htaccess - Serveur HTTP Apache Version 2.5 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.5

+
+
<-
+

mod_rewrite et les fichiers .htaccess

+
+

Langues Disponibles:  en  | + fr 

+
+ + +

Ce document est un complément de la documentation de référence du module +mod_rewrite. Il décrit les changements apportés aux règles +lorsqu'on utilise mod_rewrite dans les fichiers .htaccess, et comment +travailler avec ces changements.

+ +
+ +
+
+

Langues Disponibles:  en  | + fr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/rewrite/index.html.en b/docs/manual/rewrite/index.html.en index d0a450f9da..2952d709ae 100644 --- a/docs/manual/rewrite/index.html.en +++ b/docs/manual/rewrite/index.html.en @@ -24,8 +24,8 @@ Apache > HTTP Server > Documentation > Version 2.5

Apache mod_rewrite

Available Languages:  en  | - fr  | - tr  | + fr  | + tr  |  zh-cn 

@@ -83,8 +83,8 @@ wiki
  • Glossary

    • Available Languages:  en  | - fr  | - tr  | + fr  | + tr  |  zh-cn 

    Apache mod_rewrite Introduction

    Available Languages:  en  | - fr 

    + fr 

    This document supplements the mod_rewrite @@ -336,7 +336,7 @@ the Rewrit

    Available Languages:  en  | - fr 

    + fr 

    top

    Comments

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    - - -
    -

    Modules | Directives | FAQ | Glossaire | Plan du site

    -

    Serveur HTTP Apache Version 2.5

    -
    -
    <-
    -

    Introduction au module Apache mod_rewrite

    -
    -

    Langues Disponibles:  en  | - fr 

    -
    - -

    Ce document est un complément à la documentation de référence du module -mod_rewrite. Il décrit les concepts de base dont la -connaissance est nécessaire pour l'utilisation de -mod_rewrite. D'autres documents entrent d'avantage dans -les détails, mais celui-ci devrait aider le débutant à se mouiller les -pieds. -

    -
    - -
    top
    -
    -

    Introduction

    -

    Le module Apache mod_rewrite est un module puissant -et sophistiqué qui permet la réécriture des URLs. Grâce à lui, vous -pouvez effectuer quasiment tous les types de réécriture d'URLs dont vous -avez besoin. Il est cependant assez complexe, et peut paraître -intimidant au débutant. Certains ont aussi tendance à traiter les -règles de réécriture comme des incantations magiques, et à les utiliser -sans vraiment comprendre leur manière d'agir.

    - -

    Ce document a pour ambition d'être suffisamment explicite pour -permettre la compréhension, et non la copie en aveugle, de ce qui suit. -

    - -

    Gardez à l'esprit que de nombreuses tâches de manipulation d'URLs -courantes n'ont pas besoin de la puissance et de la complexité de -mod_rewrite. Pour les tâches simples, voir -mod_alias et la documentation sur la Mise en correspondance des URLs avec le -système de fichiers.

    - -

    Enfin, avant de procéder, assurez-vous d'avoir configuré le niveau de -journalisation de mod_rewrite à un des niveaux de trace -via la directive LogLevel. Bien que -ceci risque de vous submerger sous une énorme quantité d'informations, -le débogage des problèmes avec la configuration de -mod_rewrite est à ce prix car vous verrez alors -exactement comment chaque règle est traitée.

    - -
    top
    -
    -

    Expressions rationnelles

    - -

    mod_rewrite utilise le vocabulaire des Expressions rationnelles compatibles Perl. -Ce document n'a pas pour prétention d'être une référence détaillée des -expressions rationnelles. A cet effet, nous recommandons les pages de manuel de PCRE, la page de manuel des -expressions rationnelles Perl, et l'ouvrage Mastering -Regular Expressions, by Jeffrey Friedl.

    - -

    Dans ce document, nous avons pour but de vous fournir suffisamment de -vocabulaire des expressions rationnelles pour vous mettre le pied à -l'étrier, sans être dépassé, en espérant que les directives RewriteRule vous apparaîtront comme des -formules scientifiques, plutôt que comme des incantations magiques.

    - -

    Vocabulaire des expressions rationnelles

    - -

    Vous trouverez dans ce qui suit le minimum à connaître pour être en -mesure d'écrire des expressions rationnelles et des règles RewriteRule. Ceci ne représente -certainement pas un vocabulaire des expressions rationnelles complet, -mais constitue un bon point de départ, et devrait vous aider à -déchiffrer les expressions rationnelles simples, et à écrire vos propres -expressions.

    - - - - - - - - - - - - - - - - - - - - - - - - - -
    MotifSignificationExemple
    .Correspond à tout caractère unique -c.t correspondra à cat, -cot, cut, etc.
    +Répète le caractère de correspondance -précédent une ou plusieurs foisa+ correspond à a, aa, -aaa, etc.
    *Répète le caractère de correspondance -précédent zéro ou plusieurs foisa* correspond à tout ce à quoi correspond -a+, mais correspond aussi à la chaîne vide.
    ?Rend la correspondance optionnelle. -colou?r correspondra à color et colour.
    ^Appelé ancrage, correspond au début de la -chaîne^a correspond à une chaîne qui commence par -a
    $L'autre ancrage, correspond à la fin de -la chaîne.a$ correspond à une chaîne qui se termine par -a.
    ( )Regroupe plusieurs caractères en une -seule entité, et conserve une correspondance à des fins d'utilisation -dans une référence arrière.(ab)+ -correspond à ababab - à savoir, le + -s'applique au groupe. -Pour plus de détails sur les références arrières, voir ci-dessous.
    [ ]Une classe de caractères - correspond à -un des caractères de la classec[uoa]t correspond à cut, -cot ou cat.
    [^ ]Négation de la classe de caractères - -correspond à tout caractère ne faisant pas partie de la classec[^/]t correspond à cat ou -c=t mais pas à c/t
    - -

    Avec mod_rewrite, le caractère ! peut -préfixer une expression rationnelle afin d'en exprimer la négation. -Autrement dit, une chaîne ne correspondra que si elle ne correspond pas -à l'expression située après le !.

    - - - -

    Disponibilité des références -arrières dans les expressions rationnelles

    - -

    Vous devez vous souvenir d'une chose importante : chaque fois - que vous utilisez des parenthèses dans un Modèle ou dans - un des modèles de conditions, des références arrières - sont créées en interne et peuvent être rappelées via les chaînes - $N et %N (voir ci-dessous). Ces - références sont disponibles lors de la - création de la chaîne de substitution d'une directive - RewriteRule ou de la - chaîne de test d'une directive RewriteCond.

    -

    Les captures dans les modèles de directives RewriteRule sont paradoxalement - disponibles dans toutes les directives RewriteCond qui précèdent, car - les expressions des directives RewriteRule sont évaluées avant - les conditions individuelles.

    - -

    La figure 1 montre à quels endroits les - références arrières sont suceptibles - d'être développées, et illustre le flux des comparaisons - effectuées par les règles RewriteRule et - RewriteCond. Dans les chapitres suivants, nous examinerons comment - utiliser ces références arrières, donc ne vous affolez pas si - elles vous paraissent un peu exotiques au premier abord.

    - -

    - Flux des comparaisons effectuées par les règles RewriteRule et RewriteCond
    - Figure 1 : Le cheminement d'une référence arrière à - travers une règle.
    - Dans cet exemple, une requête pour /test/1234 serait - transformée en - /admin.foo?page=test&id=1234&host=admin.example.com. -

    - - -
    top
    -
    -

    Les bases des règles de réécriture

    -

    Une règle de réécriture RewriteRule est constituée de trois -arguments séparés par des espaces. Les arguments sont :

    -
      -
    1. Modèle: le modèle des URLs auxquelles la règle doit -s'appliquer;
      2. -
    2. Substitution: vers quoi la requête correspondante doit être -transformée;
      3. -
    3. [drapeaux]: options affectant la requête réécrite.
      4. -
    - -

    Le Modèle est une expression -rationnelle. Au sein de la première règle de réécriture, ou jusqu'à -ce qu'une substitution survienne, elle est comparée au chemin de -l'URL de la requête entrante (la -partie située après le nom d'hôte mais avant tout point d'interrogation -qui indique le début d'une chaîne de paramètres de -requête) ou, dans un contexte de répertoire, au chemin de la -requête relativement au répertoire pour lequel la -règle est définie. Lorsqu'une substitution a eu lieu, les -règles suivantes effectuent leurs comparaisons par rapport à la valeur -substituée.

    - -

    - Syntaxe de la directive RewriteRule
    - Figure 2 : Syntaxe de la directive RewriteRule. -

    - -

    La chaîne de Substitution peut, quant à elle, être de -trois types :

    - -
    -
    Un chemin complet du système de fichiers vers une ressource
    -
    -
    RewriteRule "^/jeux" "/usr/local/jeux/web"
    - -

    Ceci peut faire correspondre une requête à toute localisation voulue de -votre système de fichiers, un peu comme la directive Alias.

    -
    - -
    Un chemin web vers une ressource
    -
    -
    RewriteRule "^/foo$" "/bar"
    - -

    Si la directive DocumentRoot a -pour valeur /usr/local/apache2/htdocs, cette règle va faire -correspondre les requêtes pour http://example.com/foo au -chemin /usr/local/apache2/htdocs/bar.

    -
    - -
    Une URL absolue
    -
    -
    RewriteRule "^/produits/vues$" "http://site2.example.com/voirproduits.html" [R]
    - -

    Ceci informe le client qu'il doit effectuer une nouvelle requête vers -l'URL spécifiée.

    -
    -
    - -

    La chaîne de Substitution peut aussi contenir des -références arrières vers des parties du chemin d'URL entrant -correspondant au Modèle. Considérons ce qui suit :

    -
    RewriteRule "^/produits/(.*)/view$" "/var/web/produitsdb/$1"
    - -

    La variable $1 sera remplacée par tout texte -correspondant à l'expression située entre les parenthèses dans le -Modèle. Par exemple, une requête pour -http://example.com/produits/r14df/vue correspondra au -chemin /var/web/produitsdb/r14df.

    - -

    S'il y a plus d'une expression entre parenthèses, elle seront -accessibles selon leur ordre d'apparition via les variables -$1, $2, $3, etc...

    - - -
    top
    -
    -

    Drapeaux de réécriture

    -

    Le comportement d'une règle RewriteRule peut être modifié par la -présence d'un ou plusieurs drapeaux en fin de règle. Par exemple, les -conditions de correspondance d'une règle peuvent être rendues -insensibles à la casse par la présence du drapeau [NC] : -

    -
    RewriteRule "^puppy.html" "petitchien.html" [NC]
    - - -

    Pour une liste des drapeaux disponibles, leurs significations, et des -exemples, voir le document Drapeaux de -réécriture.

    - -
    top
    -
    -

    Conditions de réécriture

    -

    Il est possible d'utiliser une ou plusieurs directives RewriteCond pour restreindre les types -de requêtes auxquelles devra s'appliquer la règle RewriteRule suivante. Le premier -argument est une variable décrivant une caractéristique de la requête, -le second argument est une expression rationnelle -qui doit correspondre à la variable, et un troisième argument optionnel -est une liste de drapeaux qui modifient la manière dont la -correspondance est évaluée.

    - -

    - Syntaxe de la directive RewriteCond
    - Figure 3 : Syntaxe de la directive RewriteCond -

    - - -

    Par exemple, pour renvoyer toutes les requêtes en provenance d'une -certaine tranche d'adresses IP vers un autre serveur, vous pouvez -utiliser :

    -
    RewriteCond "%{REMOTE_ADDR}" "^10\.2\."
-RewriteRule "(.*)" "http://intranet.example.com$1"
    - - -

    Si vous spécifiez plus d'une directive RewriteCond, ces directives -doivent toutes être satisfaites pour que la règle RewriteRule suivante s'applique. Par exemple, -pour interdire les requêtes qui contiennent le mot "hack" dans la chaîne -de requête, sauf si elles contiennent aussi un cookie contenant le mot -"go", vous pouvez utiliser :

    -
    RewriteCond "%{QUERY_STRING}" "hack"
-RewriteCond "%{HTTP_COOKIE}" "!go"
-RewriteRule "." "-" [F]
    - -

    Notez que le point d'exclamation indique une correspondance négative -; ainsi, la règle n'est appliquée que si le cookie ne contient pas "go"

    - -

    Les correspondances dans les expressions rationnelles contenues dans -les directives RewriteCond -peuvent constituer des parties de la chaîne de Substitution -de la règle RewriteRule via -les variables %1, %2, etc... Par -exemple, ce qui suit va diriger la requête vers un répertoire différent -en fonction du nom d'hôte utilisé pour accéder au site :

    -
    RewriteCond "%{HTTP_HOST}" "(.*)"
-RewriteRule "^/(.*)" "/sites/%1/$1"
    - -

    Si la requête concernait http://example.com/foo/bar, -alors %1 contiendrait example.com et -$1 contiendrait foo/bar.

    - - - -
    top
    -
    -

    Tables de réécriture

    - -

    La directive RewriteMap -permet en quelque sorte de faire appel à une fonction externe pour -effectuer la réécriture à votre place. Tout ceci est décrit plus en -détails dans la Documentation -supplémentaire sur RewriteMap.

    -
    top
    -
    -

    Fichiers .htaccess

    - -

    La réécriture est en général définie au niveau de la configuration du -serveur principal (en dehors de toute section <Directory>) ou dans une section <VirtualHost>. Il s'agit là de la -manière la plus simple de mettre en oeuvre la réécriture et nous la -recommandons. Il est possible, cependant, de mettre en oeuvre la -réécriture au sein d'une section <Directory> ou d'un fichier .htaccess ; ce type de -configuration est cependant plus complexe. Cette technique est appelée -réécriture par répertoire.

    - -

    La principale différence avec les réécritures au niveau du serveur réside -dans le fait que le préfixe du chemin du répertoire contenant le fichier -.htaccess est supprimé avant la mise en correspondance dans -la règle RewriteRule. De -plus, on doit utiliser la directive RewriteBase pour s'assurer que la -requête est correctement mise en correspondance.

    - -
    -
    -

    Langues Disponibles:  en  | - fr 

    -
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    -
    - \ No newline at end of file diff --git a/docs/manual/rewrite/intro.html.fr.utf8 b/docs/manual/rewrite/intro.html.fr.utf8 new file mode 100644 index 0000000000..e3216eb902 --- /dev/null +++ b/docs/manual/rewrite/intro.html.fr.utf8 @@ -0,0 +1,389 @@ + + + + + +Introduction au module Apache mod_rewrite - Serveur HTTP Apache Version 2.5 + + + + + + +
    +

    Modules | Directives | FAQ | Glossaire | Plan du site

    +

    Serveur HTTP Apache Version 2.5

    +
    +
    <-
    +

    Introduction au module Apache mod_rewrite

    +
    +

    Langues Disponibles:  en  | + fr 

    +
    + +

    Ce document est un complément à la documentation de référence du module +mod_rewrite. Il décrit les concepts de base dont la +connaissance est nécessaire pour l'utilisation de +mod_rewrite. D'autres documents entrent d'avantage dans +les détails, mais celui-ci devrait aider le débutant à se mouiller les +pieds. +

    +
    + +
    top
    +
    +

    Introduction

    +

    Le module Apache mod_rewrite est un module puissant +et sophistiqué qui permet la réécriture des URLs. Grâce à lui, vous +pouvez effectuer quasiment tous les types de réécriture d'URLs dont vous +avez besoin. Il est cependant assez complexe, et peut paraître +intimidant au débutant. Certains ont aussi tendance à traiter les +règles de réécriture comme des incantations magiques, et à les utiliser +sans vraiment comprendre leur manière d'agir.

    + +

    Ce document a pour ambition d'être suffisamment explicite pour +permettre la compréhension, et non la copie en aveugle, de ce qui suit. +

    + +

    Gardez à l'esprit que de nombreuses tâches de manipulation d'URLs +courantes n'ont pas besoin de la puissance et de la complexité de +mod_rewrite. Pour les tâches simples, voir +mod_alias et la documentation sur la Mise en correspondance des URLs avec le +système de fichiers.

    + +

    Enfin, avant de procéder, assurez-vous d'avoir configuré le niveau de +journalisation de mod_rewrite à un des niveaux de trace +via la directive LogLevel. Bien que +ceci risque de vous submerger sous une énorme quantité d'informations, +le débogage des problèmes avec la configuration de +mod_rewrite est à ce prix car vous verrez alors +exactement comment chaque règle est traitée.

    + +
    top
    +
    +

    Expressions rationnelles

    + +

    mod_rewrite utilise le vocabulaire des Expressions rationnelles compatibles Perl. +Ce document n'a pas pour prétention d'être une référence détaillée des +expressions rationnelles. A cet effet, nous recommandons les pages de manuel de PCRE, la page de manuel des +expressions rationnelles Perl, et l'ouvrage Mastering +Regular Expressions, by Jeffrey Friedl.

    + +

    Dans ce document, nous avons pour but de vous fournir suffisamment de +vocabulaire des expressions rationnelles pour vous mettre le pied à +l'étrier, sans être dépassé, en espérant que les directives RewriteRule vous apparaîtront comme des +formules scientifiques, plutôt que comme des incantations magiques.

    + +

    Vocabulaire des expressions rationnelles

    + +

    Vous trouverez dans ce qui suit le minimum à connaître pour être en +mesure d'écrire des expressions rationnelles et des règles RewriteRule. Ceci ne représente +certainement pas un vocabulaire des expressions rationnelles complet, +mais constitue un bon point de départ, et devrait vous aider à +déchiffrer les expressions rationnelles simples, et à écrire vos propres +expressions.

    + + + + + + + + + + + + + + + + + + + + + + + + + +
    MotifSignificationExemple
    .Correspond à tout caractère unique +c.t correspondra à cat, +cot, cut, etc.
    +Répète le caractère de correspondance +précédent une ou plusieurs foisa+ correspond à a, aa, +aaa, etc.
    *Répète le caractère de correspondance +précédent zéro ou plusieurs foisa* correspond à tout ce à quoi correspond +a+, mais correspond aussi à la chaîne vide.
    ?Rend la correspondance optionnelle. +colou?r correspondra à color et colour.
    ^Appelé ancrage, correspond au début de la +chaîne^a correspond à une chaîne qui commence par +a
    $L'autre ancrage, correspond à la fin de +la chaîne.a$ correspond à une chaîne qui se termine par +a.
    ( )Regroupe plusieurs caractères en une +seule entité, et conserve une correspondance à des fins d'utilisation +dans une référence arrière.(ab)+ +correspond à ababab - à savoir, le + +s'applique au groupe. +Pour plus de détails sur les références arrières, voir ci-dessous.
    [ ]Une classe de caractères - correspond à +un des caractères de la classec[uoa]t correspond à cut, +cot ou cat.
    [^ ]Négation de la classe de caractères - +correspond à tout caractère ne faisant pas partie de la classec[^/]t correspond à cat ou +c=t mais pas à c/t
    + +

    Avec mod_rewrite, le caractère ! peut +préfixer une expression rationnelle afin d'en exprimer la négation. +Autrement dit, une chaîne ne correspondra que si elle ne correspond pas +à l'expression située après le !.

    + + + +

    Disponibilité des références +arrières dans les expressions rationnelles

    + +

    Vous devez vous souvenir d'une chose importante : chaque fois + que vous utilisez des parenthèses dans un Modèle ou dans + un des modèles de conditions, des références arrières + sont créées en interne et peuvent être rappelées via les chaînes + $N et %N (voir ci-dessous). Ces + références sont disponibles lors de la + création de la chaîne de substitution d'une directive + RewriteRule ou de la + chaîne de test d'une directive RewriteCond.

    +

    Les captures dans les modèles de directives RewriteRule sont paradoxalement + disponibles dans toutes les directives RewriteCond qui précèdent, car + les expressions des directives RewriteRule sont évaluées avant + les conditions individuelles.

    + +

    La figure 1 montre à quels endroits les + références arrières sont suceptibles + d'être développées, et illustre le flux des comparaisons + effectuées par les règles RewriteRule et + RewriteCond. Dans les chapitres suivants, nous examinerons comment + utiliser ces références arrières, donc ne vous affolez pas si + elles vous paraissent un peu exotiques au premier abord.

    + +

    + Flux des comparaisons effectuées par les règles RewriteRule et RewriteCond
    + Figure 1 : Le cheminement d'une référence arrière à + travers une règle.
    + Dans cet exemple, une requête pour /test/1234 serait + transformée en + /admin.foo?page=test&id=1234&host=admin.example.com. +

    + + +
    top
    +
    +

    Les bases des règles de réécriture

    +

    Une règle de réécriture RewriteRule est constituée de trois +arguments séparés par des espaces. Les arguments sont :

    +
      +
    1. Modèle: le modèle des URLs auxquelles la règle doit +s'appliquer;
      2. +
    2. Substitution: vers quoi la requête correspondante doit être +transformée;
      3. +
    3. [drapeaux]: options affectant la requête réécrite.
      4. +
    + +

    Le Modèle est une expression +rationnelle. Au sein de la première règle de réécriture, ou jusqu'à +ce qu'une substitution survienne, elle est comparée au chemin de +l'URL de la requête entrante (la +partie située après le nom d'hôte mais avant tout point d'interrogation +qui indique le début d'une chaîne de paramètres de +requête) ou, dans un contexte de répertoire, au chemin de la +requête relativement au répertoire pour lequel la +règle est définie. Lorsqu'une substitution a eu lieu, les +règles suivantes effectuent leurs comparaisons par rapport à la valeur +substituée.

    + +

    + Syntaxe de la directive RewriteRule
    + Figure 2 : Syntaxe de la directive RewriteRule. +

    + +

    La chaîne de Substitution peut, quant à elle, être de +trois types :

    + +
    +
    Un chemin complet du système de fichiers vers une ressource
    +
    +
    RewriteRule "^/jeux" "/usr/local/jeux/web"
    + +

    Ceci peut faire correspondre une requête à toute localisation voulue de +votre système de fichiers, un peu comme la directive Alias.

    +
    + +
    Un chemin web vers une ressource
    +
    +
    RewriteRule "^/foo$" "/bar"
    + +

    Si la directive DocumentRoot a +pour valeur /usr/local/apache2/htdocs, cette règle va faire +correspondre les requêtes pour http://example.com/foo au +chemin /usr/local/apache2/htdocs/bar.

    +
    + +
    Une URL absolue
    +
    +
    RewriteRule "^/produits/vues$" "http://site2.example.com/voirproduits.html" [R]
    + +

    Ceci informe le client qu'il doit effectuer une nouvelle requête vers +l'URL spécifiée.

    +
    +
    + +

    La chaîne de Substitution peut aussi contenir des +références arrières vers des parties du chemin d'URL entrant +correspondant au Modèle. Considérons ce qui suit :

    +
    RewriteRule "^/produits/(.*)/view$" "/var/web/produitsdb/$1"
    + +

    La variable $1 sera remplacée par tout texte +correspondant à l'expression située entre les parenthèses dans le +Modèle. Par exemple, une requête pour +http://example.com/produits/r14df/vue correspondra au +chemin /var/web/produitsdb/r14df.

    + +

    S'il y a plus d'une expression entre parenthèses, elle seront +accessibles selon leur ordre d'apparition via les variables +$1, $2, $3, etc...

    + + +
    top
    +
    +

    Drapeaux de réécriture

    +

    Le comportement d'une règle RewriteRule peut être modifié par la +présence d'un ou plusieurs drapeaux en fin de règle. Par exemple, les +conditions de correspondance d'une règle peuvent être rendues +insensibles à la casse par la présence du drapeau [NC] : +

    +
    RewriteRule "^puppy.html" "petitchien.html" [NC]
    + + +

    Pour une liste des drapeaux disponibles, leurs significations, et des +exemples, voir le document Drapeaux de +réécriture.

    + +
    top
    +
    +

    Conditions de réécriture

    +

    Il est possible d'utiliser une ou plusieurs directives RewriteCond pour restreindre les types +de requêtes auxquelles devra s'appliquer la règle RewriteRule suivante. Le premier +argument est une variable décrivant une caractéristique de la requête, +le second argument est une expression rationnelle +qui doit correspondre à la variable, et un troisième argument optionnel +est une liste de drapeaux qui modifient la manière dont la +correspondance est évaluée.

    + +

    + Syntaxe de la directive RewriteCond
    + Figure 3 : Syntaxe de la directive RewriteCond +

    + + +

    Par exemple, pour renvoyer toutes les requêtes en provenance d'une +certaine tranche d'adresses IP vers un autre serveur, vous pouvez +utiliser :

    +
    RewriteCond "%{REMOTE_ADDR}" "^10\.2\."
+RewriteRule "(.*)" "http://intranet.example.com$1"
    + + +

    Si vous spécifiez plus d'une directive RewriteCond, ces directives +doivent toutes être satisfaites pour que la règle RewriteRule suivante s'applique. Par exemple, +pour interdire les requêtes qui contiennent le mot "hack" dans la chaîne +de requête, sauf si elles contiennent aussi un cookie contenant le mot +"go", vous pouvez utiliser :

    +
    RewriteCond "%{QUERY_STRING}" "hack"
+RewriteCond "%{HTTP_COOKIE}" "!go"
+RewriteRule "." "-" [F]
    + +

    Notez que le point d'exclamation indique une correspondance négative +; ainsi, la règle n'est appliquée que si le cookie ne contient pas "go"

    + +

    Les correspondances dans les expressions rationnelles contenues dans +les directives RewriteCond +peuvent constituer des parties de la chaîne de Substitution +de la règle RewriteRule via +les variables %1, %2, etc... Par +exemple, ce qui suit va diriger la requête vers un répertoire différent +en fonction du nom d'hôte utilisé pour accéder au site :

    +
    RewriteCond "%{HTTP_HOST}" "(.*)"
+RewriteRule "^/(.*)" "/sites/%1/$1"
    + +

    Si la requête concernait http://example.com/foo/bar, +alors %1 contiendrait example.com et +$1 contiendrait foo/bar.

    + + + +
    top
    +
    +

    Tables de réécriture

    + +

    La directive RewriteMap +permet en quelque sorte de faire appel à une fonction externe pour +effectuer la réécriture à votre place. Tout ceci est décrit plus en +détails dans la Documentation +supplémentaire sur RewriteMap.

    +
    top
    +
    +

    Fichiers .htaccess

    + +

    La réécriture est en général définie au niveau de la configuration du +serveur principal (en dehors de toute section <Directory>) ou dans une section <VirtualHost>. Il s'agit là de la +manière la plus simple de mettre en oeuvre la réécriture et nous la +recommandons. Il est possible, cependant, de mettre en oeuvre la +réécriture au sein d'une section <Directory> ou d'un fichier .htaccess ; ce type de +configuration est cependant plus complexe. Cette technique est appelée +réécriture par répertoire.

    + +

    La principale différence avec les réécritures au niveau du serveur réside +dans le fait que le préfixe du chemin du répertoire contenant le fichier +.htaccess est supprimé avant la mise en correspondance dans +la règle RewriteRule. De +plus, on doit utiliser la directive RewriteBase pour s'assurer que la +requête est correctement mise en correspondance.

    + +
    +
    +

    Langues Disponibles:  en  | + fr 

    +
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    +
    + \ No newline at end of file diff --git a/docs/manual/rewrite/proxy.html.en b/docs/manual/rewrite/proxy.html.en index d51876bd6a..886cf73925 100644 --- a/docs/manual/rewrite/proxy.html.en +++ b/docs/manual/rewrite/proxy.html.en @@ -24,7 +24,7 @@ Apache > HTTP Server > Documentation > Version 2.5 > Rewrite

    Using mod_rewrite for Proxying

    Available Languages:  en  | - fr 

    + fr 

    @@ -91,7 +91,7 @@ ProxyPassReverse "/" "http://old.example.com/"

    Available Languages:  en  | - fr 

    + fr 

    top

    Comments

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    - - -
    -

    Modules | Directives | FAQ | Glossaire | Plan du site

    -

    Serveur HTTP Apache Version 2.5

    -
    -
    <-
    -

    Utilisation de mod_rewrite comme mandataire

    -
    -

    Langues Disponibles:  en  | - fr 

    -
    - - -

    Ce document est un complément de la documentation de référence du module -mod_rewrite. Il décrit comment utiliser le drapeau [P] -de la directive RewriteRule pour mandater un contenu vers un autre -serveur. Plusieurs recettes décrivant des scénarios courants sont -fournies.

    - -
    - -
    top
    -
    -

    Mandater du contenu avec mod_rewrite

    - - - -
    -
    Description :
    - -
    -

    - mod_rewrite implémente le drapeau [P] qui permet de passer des URLs, - via mod_proxy, à un autre serveur. Deux exemples sont fournis ici. - Dans le premier, une URL est passée directement à un autre serveur, - et servie comme si c'était une URL locale. Dans le deuxième, nous - mandatons un contenu manquant vers un serveur d'arrière-plan.

    -
    - -
    Solution :
    - -
    -

    Pour passer une URL à un autre serveur, on utilise le drapeau - [P] comme suit :

    - -
    RewriteEngine  on
-RewriteBase    "/produits/"
-RewriteRule    "^widget/(.*)$"  "http://produits.example.com/widget/$1"  [P]
-ProxyPassReverse "/produits/objet/" "http://produits.example.com/objet/"
    - - -

    Dans le deuxième exemple, nous ne mandatons la requête que si nous - ne trouvons pas la ressource localement. Ceci peut s'avérer très - utile lorsque vous effectuez une migration d'un serveur vers un - autre, et que vous n'êtes pas certain que tout le contenu a déjà été - migré.

    - -
    RewriteCond "%{REQUEST_FILENAME}"       !-f
-RewriteCond "%{REQUEST_FILENAME}"       !-d
-RewriteRule "^/(.*)" "http://ancien.exemple.com/$1" [P]
-ProxyPassReverse "/" "http://ancien.exemple.com/"
    - -
    - -
    Discussion :
    - -

    Dans les deux cas, on ajoute une directive ProxyPassReverse afin de s'assurer - que toute redirection en provenance du serveur d'arrière-plan est - renvoyée correctement au client.

    - -

    Chaque fois que cela est possible, préférez l'utilisation de la - directive ProxyPass ou - ProxyPassMatch à - mod_rewrite.

    -
    -
    - -
    -
    -

    Langues Disponibles:  en  | - fr 

    -
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    -
    - \ No newline at end of file diff --git a/docs/manual/rewrite/proxy.html.fr.utf8 b/docs/manual/rewrite/proxy.html.fr.utf8 new file mode 100644 index 0000000000..4cf3462a27 --- /dev/null +++ b/docs/manual/rewrite/proxy.html.fr.utf8 @@ -0,0 +1,124 @@ + + + + + +Utilisation de mod_rewrite comme mandataire - Serveur HTTP Apache Version 2.5 + + + + + + +
    +

    Modules | Directives | FAQ | Glossaire | Plan du site

    +

    Serveur HTTP Apache Version 2.5

    +
    +
    <-
    +

    Utilisation de mod_rewrite comme mandataire

    +
    +

    Langues Disponibles:  en  | + fr 

    +
    + + +

    Ce document est un complément de la documentation de référence du module +mod_rewrite. Il décrit comment utiliser le drapeau [P] +de la directive RewriteRule pour mandater un contenu vers un autre +serveur. Plusieurs recettes décrivant des scénarios courants sont +fournies.

    + +
    + +
    top
    +
    +

    Mandater du contenu avec mod_rewrite

    + + + +
    +
    Description :
    + +
    +

    + mod_rewrite implémente le drapeau [P] qui permet de passer des URLs, + via mod_proxy, à un autre serveur. Deux exemples sont fournis ici. + Dans le premier, une URL est passée directement à un autre serveur, + et servie comme si c'était une URL locale. Dans le deuxième, nous + mandatons un contenu manquant vers un serveur d'arrière-plan.

    +
    + +
    Solution :
    + +
    +

    Pour passer une URL à un autre serveur, on utilise le drapeau + [P] comme suit :

    + +
    RewriteEngine  on
+RewriteBase    "/produits/"
+RewriteRule    "^widget/(.*)$"  "http://produits.example.com/widget/$1"  [P]
+ProxyPassReverse "/produits/objet/" "http://produits.example.com/objet/"
    + + +

    Dans le deuxième exemple, nous ne mandatons la requête que si nous + ne trouvons pas la ressource localement. Ceci peut s'avérer très + utile lorsque vous effectuez une migration d'un serveur vers un + autre, et que vous n'êtes pas certain que tout le contenu a déjà été + migré.

    + +
    RewriteCond "%{REQUEST_FILENAME}"       !-f
+RewriteCond "%{REQUEST_FILENAME}"       !-d
+RewriteRule "^/(.*)" "http://ancien.exemple.com/$1" [P]
+ProxyPassReverse "/" "http://ancien.exemple.com/"
    + +
    + +
    Discussion :
    + +

    Dans les deux cas, on ajoute une directive ProxyPassReverse afin de s'assurer + que toute redirection en provenance du serveur d'arrière-plan est + renvoyée correctement au client.

    + +

    Chaque fois que cela est possible, préférez l'utilisation de la + directive ProxyPass ou + ProxyPassMatch à + mod_rewrite.

    +
    +
    + +
    +
    +

    Langues Disponibles:  en  | + fr 

    +
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    +
    + \ No newline at end of file diff --git a/docs/manual/rewrite/remapping.html.en b/docs/manual/rewrite/remapping.html.en index 522c821a0b..78b20fe9fb 100644 --- a/docs/manual/rewrite/remapping.html.en +++ b/docs/manual/rewrite/remapping.html.en @@ -24,7 +24,7 @@ Apache > HTTP Server > Documentation > Version 2.5 > Rewrite

    Redirecting and Remapping with mod_rewrite

    Available Languages:  en  | - fr 

    + fr 

    @@ -629,7 +629,7 @@ RewriteRule "^/?path/([^/]+)/([^/]+)" "/path?$1=$2" [PT]

    Available Languages:  en  | - fr 

    + fr 

    top

    Comments

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    - - -
    -

    Modules | Directives | FAQ | Glossaire | Plan du site

    -

    Serveur HTTP Apache Version 2.5

    -
    -
    <-
    -

    Redirection et remise en correspondance avec mod_rewrite

    -
    -

    Langues Disponibles:  en  | - fr 

    -
    - - -

    Ce document est un complément à la Documentation de référence de -mod_rewrite. Il montre comment utiliser -mod_rewrite pour rediriger et remettre en -correspondance une requête. Il contient de -nombreux exemples d'utilisation courante de mod_rewrite avec une -description détaillée de leur fonctionnement.

    - -
    Vous devez vous attacher à comprendre le -fonctionnement des exemples, car la plupart d'entre eux ne -fonctionneront pas sur votre système si vous vous contentez de les -copier/coller dans vos fichiers de configuration.
    - -
    - -
    top
    -
    -

    De l'ancienne à la nouvelle URL (en interne)

    - - - -
    -
    Description :
    - -
    -

    Supposons que nous ayons récemment renommé la page - foo.html en bar.html, et voulions - maintenant que l'ancienne URL soit toujours valide à des fins - de compatibilité ascendante. En fait, on voudrait que le - changement de nom soit transparent aux utilisateurs de - l'ancienne URL.

    -
    - -
    Solution :
    - -
    -

    On réécrit l'ancienne URL en interne vers la nouvelle via - la règle suivante :

    - -
    RewriteEngine  on
-RewriteRule    "^/foo\.html$" "/bar.html" [PT]
    - -
    -
    - -
    top
    -
    -

    De l'ancien au nouveau (en externe)

    - - - -
    -
    Description :
    - -
    -

    Supposons toujours que nous ayons récemment renommé la page - foo.html en bar.html, et voulions - maintenant que l'ancienne URL soit toujours valide à des fins - de compatibilité ascendante. En revanche, nous voulons cette - fois que la nouvelle URL soit suggérée aux utilisateurs de - l'ancienne URL, c'est à dire que l'adresse vue depuis leur - navigateur doit également être modifiée.

    -
    - -
    Solution :
    - -
    -

    On force une redirection HTTP vers la nouvelle URL, ce qui - entraîne une modification de celle du navigateur et aussi de ce - que voit l'utilisateur :

    - -
    RewriteEngine  on
-RewriteRule    "^foo\.html$"  "bar.html"  [R]
    - -
    - -
    Discussion
    - -
    -

    Dans l'exemple interne, on a utilisé mod_rewrite afin - de dissimuler la redirection au client. Dans cet exemple, en - revanche, on aurait pu se contenter d'une directive Redirect :

    - - 
    Redirect "/foo.html" "/bar.html"
    - - -
    -
    - -
    top
    -
    -

    Ressource déplacée vers un autre serveur

    - - - -
    -
    Description :
    - -
    -

    Si une ressource a été déplacée vers un autre serveur, vous - pouvez faire en sorte que les URLs de l'ancien serveur continuent - de fonctionner pendant un certain temps, afin de laisser au - utilisateurs le temps de modifier leurs favoris.

    -
    - -
    Solution :
    - -
    -

    Vous pouvez utiliser mod_rewrite pour - rediriger ces URLs vers le nouveau serveur, mais vous pouvez aussi - utiliser les directives Redirect ou RedirectMatch.

    - -
    #Avec mod_rewrite
-RewriteEngine on
-RewriteRule   "^/docs/(.+)"  "http://nouveau.example.com/docs/$1"  [R,L]
    - - -
    #Avec RedirectMatch
-RedirectMatch "^/docs/(.*)" "http://nouveau.example.com/docs/$1"
    - - -
    #Avec Redirect
-Redirect "/docs/" "http://nouveau.example.com/docs/"
    - -
    -
    - -
    top
    -
    -

    De statique à dynamique

    - - - -
    -
    Description :
    - -
    -

    Comment transformer une page statique foo.html - en sa variante dynamique foo.cgi de manière - transparente, c'est à dire sans en avertir le - navigateur/utilisateur.

    -
    - -
    Solution :
    - -
    -

    On réécrit simplement l'URL en script CGI et force le - gestionnaire de contenu à cgi-script de façon - à ce que le script s'exécute en tant que programme CGI. - Ainsi, une requête vers /~quux/foo.html conduit - en interne à l'invocation de - /~quux/foo.cgi.

    - -
    RewriteEngine  on
-RewriteBase    "/~quux/"
-RewriteRule    "^foo\.html$"  "foo.cgi"  [H=cgi-script]
    - -
    -
    - -
    top
    -
    -

    Compatibilité ascendante dans le cadre d'une modification - d'extension de nom de fichier

    - - - -
    -
    Description :
    - -
    -

    Comment conférer une compatibilité ascendante aux URLs - (existant encore virtuellement) après avoir migré - document.YYYY vers document.XXXX, - c'est à dire après avoir par exemple traduit un lot de - fichiers .html en fichiers .php - ?

    -
    - -
    Solution :
    - -
    -

    On réécrit simplement le nom du fichier en son nom - de base et vérifie s'il existe aussi avec la nouvelle - extension. Si c'est le cas, on utilise ce nom, sinon on - réécrit l'URL sous sa forme originale.

    - - -
    #   jeu de règles assurant une compatibilité ascendante en réécrivant
    
-#   document.html en document.php si et seulement si document.php
    
-#   existe
-<Directory "/var/www/htdocs">
-    RewriteEngine on
-    RewriteBase "/var/www/htdocs"
-
-    RewriteCond "$1.php" -f
-    RewriteCond "$1.html" !-f
-    RewriteRule "^(.*).html$" "$1.php"
-</Directory>
    - -
    - -
    Discussion
    -
    -

    Cet exemple utilise une fonctionnalité souvent méconnue de - mod_rewrite, en tirant avantage de l'ordre d'exécution du jeu de - règles. En particulier, mod_rewrite évalue la partie gauche des - règles de réécriture avant d'évaluer les directives RewriteCond. En - conséquence, $1 est déjà défini au moment où les directives - RewriteCond sont évaluées. Ceci nous permet de tester l'existence du - fichier original (document.html) et du fichier cible - (document.php) en utilisant le même nom de base.

    - -

    Ce jeu de règles est conçu pour une utilisation dans un contexte - de répertoire (au sein d'une section <Directory> ou d'un - fichier .htaccess), de façon à ce que les vérifications - -f effectuent leurs recherches dans le bon répertoire. - Vous serez peut-être amené à définir une directive RewriteBase pour spécifier le - répertoire de base à partir duquel vous travaillez.

    -
    -
    - -
    top
    -
    -

    Noms d'hôtes canoniques

    - - - -
    -
    Description :
    - -
    Le but de cette règle est de préférer l'utilisation d'un nom - d'hôte particulier à d'autres noms d'hôte utilisables - pour atteindre le même site. Par exemple, si vous voulez - utiliser www.example.com à la place de - example.com, vous pouvez utiliser une solution - du style :
    - -
    Solution :
    - -
    - -

    Pour y parvenir, il vaut mieux se passer de mod_rewrite, et utiliser -plutôt la directive Redirect dans -une section de serveur virtuel pour le/les noms d'hôte non canoniques.

    - -
    <VirtualHost *:80>
-  ServerName undesired.example.com
-  ServerAlias example.com notthis.example.com
-
-  Redirect "/" "http://www.example.com/"
-</VirtualHost>
-
-<VirtualHost *:80>
-  ServerName www.example.com
-</VirtualHost>
    - - -

    Vous pouvez aussi utiliser la directive <If> (versions 2.4 et ultérieures) :

    - -
    <If "%{HTTP_HOST} != 'www.example.com'">
-	Redirect "/" "http://www.example.com/"
-</If>
    - - -

    Ou, par exemple, pour rediriger une portion de votre site vers HTTPS -:

    - -
    <If "%{SERVER_PROTOCOL} != 'HTTPS'">
-	Redirect "/admin/" "https://www.example.com/admin/"
-</If>
    - - -

    Si, pour une raison particulière, vous voulez tout de même utiliser -mod_rewrite - dans le cas, par exemple, où vous avez besoin -d'un jeu plus important de règles de réécritures - vous pouvez utiliser -la recette suivante :

    - -

    Pour les sites écoutant sur un port autre que 80:

    -
    RewriteCond "%{HTTP_HOST}"   "!^www\.example\.com" [NC]
-RewriteCond "%{HTTP_HOST}"   "!^$"
-RewriteCond "%{SERVER_PORT}" "!^80$"
-RewriteRule "^/?(.*)"         "http://www.example.com:%{SERVER_PORT}/$1" [L,R,NE]
    - - -

    Et pour un site écoutant sur le port 80

    -
    RewriteCond "%{HTTP_HOST}"   "!^www\.example\.com" [NC]
-RewriteCond "%{HTTP_HOST}"   "!^$"
-RewriteRule "^/?(.*)"         "http://www.example.com/$1" [L,R,NE]
    - -

    - Si vous souhaitez que cette règle s'applique à tous les noms de - domaine - en d'autres termes, si vous voulez rediriger - example.com vers - www.example.com pour toutes les valeurs - possibles de example.com, vous pouvez utiliser - le jeu de règles suivants :

    - -
    RewriteCond "%{HTTP_HOST}" "!^www\." [NC]
-RewriteCond "%{HTTP_HOST}" "!^$"
-RewriteRule "^/?(.*)" "http://www.%{HTTP_HOST}/$1" [L,R,NE]
    - -

    - Vous pouvez utiliser ce jeu de règles aussi bien dans le fichier - de configuration de votre serveur principal que dans un fichier - .htaccess placé dans le répertoire défini par la - directive DocumentRoot du serveur.

    -
    -
    - -
    top
    -
    -

    Recherche de pages dans plus d'un répertoire

    - - - -
    -
    Description:
    - -
    -

    Une ressource peut exister dans plusieurs répertoires, et nous - voulons rechercher cette ressource dans ces répertoires - lorsqu'elle fait l'objet d'une requête. Il est possible que nous - ayons récemment réorganisé la structure de notre site en - répartissant son contenu dans plusieurs répertoires.

    -
    - -
    Solution :
    - -
    -

    Le jeu de règles suivant recherche la ressource dans deux - répertoires, et s'il ne la trouve dans aucun des deux, il tentera - simplement de la servir à partir de l'adresse fournie dans la - requête.

    - -
    RewriteEngine on
-
-#   on cherche tout d'abord dans dir1/...
-#   ... et si on trouve, on est content et on arrête :
-RewriteCond         "%{DOCUMENT_ROOT}/dir1/%{REQUEST_URI}"  -f
-RewriteRule  "^(.+)"  "%{DOCUMENT_ROOT}/dir1/$1"  [L]
-
-#   on cherche ensuite dans dir2/...
-#   ... et si on trouve, on est content et on arrête :
-RewriteCond         "%{DOCUMENT_ROOT}/dir2/%{REQUEST_URI}"  -f
-RewriteRule  "^(.+)"  "%{DOCUMENT_ROOT}/dir2/$1"  [L]
-
-#   sinon, on continue la recherche avec d'autres directives Alias
-#   ou ScriptAlias, etc...
-RewriteRule   "^"  "-"  [PT]
    - -
    -
    - -
    top
    -
    -

    Redirection vers des serveurs géographiquement distribués

    - - - -
    -
    Description :
    - -
    -

    Notre site web possède de nombreux miroirs, et nous voulons - rediriger les utilisateurs vers celui qui se situe dans le pays où - ils se trouvent.

    -
    - -
    Solution :
    - -
    -

    En consultant le nom d'hôte du client demandeur, on détermine le - pays dans lequel il se trouve. S'il est impossible d'effectuer une - recherche sur leur adresse IP, on se rabat sur un serveur par - défaut.

    -

    Nous allons utiliser une directive RewriteMap afin de construire une - liste des serveurs que nous voulons utiliser.

    - -
    HostnameLookups on
-RewriteEngine on
-RewriteMap    multiplex         "txt:/path/to/map.mirrors"
-RewriteCond  "%{REMOTE_HOST}"     "([a-z]+)$ [NC]"
-RewriteRule   "^/(.*)$"  "${multiplex:%1|http://www.example.com/}$1"  [R,L]
    - - -

    -## liste_miroirs -- Table de correspondance pays - serveurs
    -
    -de http://www.exemple.de/
    -uk http://www.exemple.uk/
    -com http://www.example.com/
    -##EOF## -

    -
    - -
    Discussion
    -
    -
    Ce jeu de règles nécessite la définition à - on de la directive HostNameLookups, ce qui peut induire une - baisse de performance significative.
    - -

    La directive RewriteCond extrait la dernière - partie du nom d'hôte du client demandeur - le code du pays - et la - règle de réécriture qui suit utilise cette valeur pour rechercher le - serveur miroir approprié dans le fichier de correspondances.

    -
    -
    - -
    top
    -
    -

    URLs canoniques

    - - - -
    -
    Description :
    - -
    -

    Sur certains serveurs, une ressource peut posséder plusieurs - URLs. Il y a en général les URLs canoniques (celles qui sont - réellement distribuées et utilisées), et celles qui correspondent à - des raccourcis, les URLs internes, etc... Quelle que soit l'adresse - que l'utilisateur fournit dans la requête, il devrait finalement - voir l'URL canonique dans la barre d'adresse de son navigateur.

    -
    - -
    Solution :
    - -
    -

    Nous effectuons une redirection HTTP externe pour toutes les - URLs non canoniques afin de les corriger dans la barre d'adresse - du navigateur, et ceci pour toutes les requêtes futures. Dans le - jeu de règles suivant, nous remplaçons /matous et - /minettes par le canonique /chats.

    - - 
    RewriteRule   "^/(matous|minettes)/(.*)"    "/chats/$2"  [R]
    - -
    - -
    Discussion :
    -
    On serait mieux inspiré d'utiliser ici les directives Redirect ou - RedirectMatch : - - 
    RedirectMatch "^/(matous|minettes)/(.*)" "/chats/$2"
    - -
    -
    - -
    top
    -
    -

    Déplacement du répertoire DocumentRoot

    - - - -
    -
    Description :
    - -
    -

    En général, le répertoire DocumentRoot du serveur web correspond à l'URL -"/". Ce répertoire ne contient cependant pas forcément des -ressources de première importance pour l'utilisateur. Par exemple, vous -préférerez peut-être que le répertoire d'accueil d'un visiteur accédant -pour la première fois à votre site soit un répertoire particulier -/a-propos-de/. Pour y parvenir, utilisez le jeu de règles -suivant :

    -
    - -
    Solution :
    - -
    -

    On redirige l'URL / vers - /a-propos-de/ : -

    - -
    RewriteEngine on
-RewriteRule   "^/$"  "/a-propos-de/"  [R]
    - - -

    Notez que l'on peut aussi y parvenir en utilisant la directive -RedirectMatch :

    - -
    RedirectMatch "^/$" "http://example.com/a-propos-de/"
    - - -

    Notez aussi que cet exemple ne réécrit que l'URL racine. En d'autres -termes, il réécrit une requête pour http://example.com/, -mais pas pour une requête http://example.com/page.html. Si -vous avez effectivement modifié la racine de vos documents - c'est à dire -si tous vos contenus se trouvent dans un -sous-répertoire, il est largement préférable de modifier simplement -votre directive DocumentRoot, ou de -déplacer l'ensemble du contenu vers le répertoire supérieur, plutôt que -de réécrire les URLs.

    -
    -
    - -
    top
    -
    -

    Ressource par défaut

    - - -
    -
    Description :
    -
    Vous voulez qu'une seule ressource (disons un certain fichier tel -que index.php) soit servie pour toutes les requêtes à destination d'un -certain répertoire, sauf pour celles qui concernent une ressource -existant effectivement comme une image, ou un fichier css.
    - -
    Solution :
    -
    -

    Depuis la version 2.2.16, vous pouvez y parvenir via la directive -FallbackResource :

    - -
    <Directory "/var/www/my_blog">
-  FallbackResource index.php
-</Directory>
    - - -

    Cependant, si vos besoins étaient plus complexes, vous pouviez, dans -les versions plus anciennes d'Apache, utiliser un jeu de règles du style -:

    - -
    <Directory "/var/www/my_blog">
-  RewriteBase "/my_blog"
-
-  RewriteCond "/var/www/my_blog/%{REQUEST_FILENAME}" !-f
-  RewriteCond "/var/www/my_blog/%{REQUEST_FILENAME}" !-d
-  RewriteRule "^" "index.php" [PT]
-</Directory>
    - - -

    D'autre part, si vous voulez transmettre l'URI de la requête en tant -que chaîne de paramètres à index.php, vous pouvez remplacer cette règle -de réécriture par :

    - -
    RewriteRule "(.*)" "index.php?$1" [PT,QSA]
    - - -

    Notez que l'on peut utiliser ces jeux de règles aussi bien dans un -fichier .htaccess que dans une section -<Directory>.

    - -
    - -
    - -
    top
    -
    -

    Rewrite query string

    - - -
    -
    Description :
    -
    Vous voulez extraire une valeur particulière d'une chaîne de -paramètres d'une URL, et soit la remplacer, soit l'incorporer dans un -autre composant de l'URL.
    - -
    Solutions :
    -
    -

    Dans la plupart des solutions de cette section, on utilise la même -condition qui stocke la valeur recherchée dans la référence arrière %2. -%1 est le début de la requête, et %3 ce qui reste. Cette condition est -un peu complexe car elle introduit de la flexibilité et évite les -doubles perluettes '&&' dans les substitutions.

    -
      -
    • Cette solution supprime le couple clé/valeur recherché : - -
      # Remove mykey=???
-RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))mykey=([^&]*)&?(.*)&?$"
-RewriteRule "(.*)" "$1?%1%3"
      - -
      • - -
    • Cette solution remplace la partie de l'URL qui suit la valeur - recherchée par un '?' : - -
      # Copy from query string to PATH_INFO
-RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))mykey=([^&]*)&?(.*)&?$"
-RewriteRule "(.*)" "$1/products/%2/?" [PT]
      - -
      • - -
    • Cette solution utilise la valeur recherchée dans une deuxième - condition :: - -
      # Capture the value of mykey in the query string
-RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))mykey=([^&]*)&?(.*)&?$""
-RewriteCond "%2" !=not-so-secret-value 
-RewriteRule "(.*)" - [F]
      - -
      • - -
    • Cette solution produit l'effet inverse des précédentes ; elle - copie des composantes du chemin (peut-être PATH_INFO) depuis l'URL - vers sa chaîne de paramètres : -
      # The desired URL might be /products/kitchen-sink, and the script expects 
-# /path?products=kitchen-sink.
-RewriteRule "^/?path/([^/]+)/([^/]+)" "/path?$1=$2" [PT]
      - -
      • -
    - -
    - -
    -
    -
    -

    Langues Disponibles:  en  | - fr 

    -
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    -
    - \ No newline at end of file diff --git a/docs/manual/rewrite/remapping.html.fr.utf8 b/docs/manual/rewrite/remapping.html.fr.utf8 new file mode 100644 index 0000000000..49d9ba10e5 --- /dev/null +++ b/docs/manual/rewrite/remapping.html.fr.utf8 @@ -0,0 +1,677 @@ + + + + + +Redirection et remise en correspondance avec mod_rewrite - Serveur HTTP Apache Version 2.5 + + + + + + +
    +

    Modules | Directives | FAQ | Glossaire | Plan du site

    +

    Serveur HTTP Apache Version 2.5

    +
    +
    <-
    +

    Redirection et remise en correspondance avec mod_rewrite

    +
    +

    Langues Disponibles:  en  | + fr 

    +
    + + +

    Ce document est un complément à la Documentation de référence de +mod_rewrite. Il montre comment utiliser +mod_rewrite pour rediriger et remettre en +correspondance une requête. Il contient de +nombreux exemples d'utilisation courante de mod_rewrite avec une +description détaillée de leur fonctionnement.

    + +
    Vous devez vous attacher à comprendre le +fonctionnement des exemples, car la plupart d'entre eux ne +fonctionneront pas sur votre système si vous vous contentez de les +copier/coller dans vos fichiers de configuration.
    + +
    + +
    top
    +
    +

    De l'ancienne à la nouvelle URL (en interne)

    + + + +
    +
    Description :
    + +
    +

    Supposons que nous ayons récemment renommé la page + foo.html en bar.html, et voulions + maintenant que l'ancienne URL soit toujours valide à des fins + de compatibilité ascendante. En fait, on voudrait que le + changement de nom soit transparent aux utilisateurs de + l'ancienne URL.

    +
    + +
    Solution :
    + +
    +

    On réécrit l'ancienne URL en interne vers la nouvelle via + la règle suivante :

    + +
    RewriteEngine  on
+RewriteRule    "^/foo\.html$" "/bar.html" [PT]
    + +
    +
    + +
    top
    +
    +

    De l'ancien au nouveau (en externe)

    + + + +
    +
    Description :
    + +
    +

    Supposons toujours que nous ayons récemment renommé la page + foo.html en bar.html, et voulions + maintenant que l'ancienne URL soit toujours valide à des fins + de compatibilité ascendante. En revanche, nous voulons cette + fois que la nouvelle URL soit suggérée aux utilisateurs de + l'ancienne URL, c'est à dire que l'adresse vue depuis leur + navigateur doit également être modifiée.

    +
    + +
    Solution :
    + +
    +

    On force une redirection HTTP vers la nouvelle URL, ce qui + entraîne une modification de celle du navigateur et aussi de ce + que voit l'utilisateur :

    + +
    RewriteEngine  on
+RewriteRule    "^foo\.html$"  "bar.html"  [R]
    + +
    + +
    Discussion
    + +
    +

    Dans l'exemple interne, on a utilisé mod_rewrite afin + de dissimuler la redirection au client. Dans cet exemple, en + revanche, on aurait pu se contenter d'une directive Redirect :

    + + 
    Redirect "/foo.html" "/bar.html"
    + + +
    +
    + +
    top
    +
    +

    Ressource déplacée vers un autre serveur

    + + + +
    +
    Description :
    + +
    +

    Si une ressource a été déplacée vers un autre serveur, vous + pouvez faire en sorte que les URLs de l'ancien serveur continuent + de fonctionner pendant un certain temps, afin de laisser au + utilisateurs le temps de modifier leurs favoris.

    +
    + +
    Solution :
    + +
    +

    Vous pouvez utiliser mod_rewrite pour + rediriger ces URLs vers le nouveau serveur, mais vous pouvez aussi + utiliser les directives Redirect ou RedirectMatch.

    + +
    #Avec mod_rewrite
+RewriteEngine on
+RewriteRule   "^/docs/(.+)"  "http://nouveau.example.com/docs/$1"  [R,L]
    + + +
    #Avec RedirectMatch
+RedirectMatch "^/docs/(.*)" "http://nouveau.example.com/docs/$1"
    + + +
    #Avec Redirect
+Redirect "/docs/" "http://nouveau.example.com/docs/"
    + +
    +
    + +
    top
    +
    +

    De statique à dynamique

    + + + +
    +
    Description :
    + +
    +

    Comment transformer une page statique foo.html + en sa variante dynamique foo.cgi de manière + transparente, c'est à dire sans en avertir le + navigateur/utilisateur.

    +
    + +
    Solution :
    + +
    +

    On réécrit simplement l'URL en script CGI et force le + gestionnaire de contenu à cgi-script de façon + à ce que le script s'exécute en tant que programme CGI. + Ainsi, une requête vers /~quux/foo.html conduit + en interne à l'invocation de + /~quux/foo.cgi.

    + +
    RewriteEngine  on
+RewriteBase    "/~quux/"
+RewriteRule    "^foo\.html$"  "foo.cgi"  [H=cgi-script]
    + +
    +
    + +
    top
    +
    +

    Compatibilité ascendante dans le cadre d'une modification + d'extension de nom de fichier

    + + + +
    +
    Description :
    + +
    +

    Comment conférer une compatibilité ascendante aux URLs + (existant encore virtuellement) après avoir migré + document.YYYY vers document.XXXX, + c'est à dire après avoir par exemple traduit un lot de + fichiers .html en fichiers .php + ?

    +
    + +
    Solution :
    + +
    +

    On réécrit simplement le nom du fichier en son nom + de base et vérifie s'il existe aussi avec la nouvelle + extension. Si c'est le cas, on utilise ce nom, sinon on + réécrit l'URL sous sa forme originale.

    + + +
    #   jeu de règles assurant une compatibilité ascendante en réécrivant
    
+#   document.html en document.php si et seulement si document.php
    
+#   existe
+<Directory "/var/www/htdocs">
+    RewriteEngine on
+    RewriteBase "/var/www/htdocs"
+
+    RewriteCond "$1.php" -f
+    RewriteCond "$1.html" !-f
+    RewriteRule "^(.*).html$" "$1.php"
+</Directory>
    + +
    + +
    Discussion
    +
    +

    Cet exemple utilise une fonctionnalité souvent méconnue de + mod_rewrite, en tirant avantage de l'ordre d'exécution du jeu de + règles. En particulier, mod_rewrite évalue la partie gauche des + règles de réécriture avant d'évaluer les directives RewriteCond. En + conséquence, $1 est déjà défini au moment où les directives + RewriteCond sont évaluées. Ceci nous permet de tester l'existence du + fichier original (document.html) et du fichier cible + (document.php) en utilisant le même nom de base.

    + +

    Ce jeu de règles est conçu pour une utilisation dans un contexte + de répertoire (au sein d'une section <Directory> ou d'un + fichier .htaccess), de façon à ce que les vérifications + -f effectuent leurs recherches dans le bon répertoire. + Vous serez peut-être amené à définir une directive RewriteBase pour spécifier le + répertoire de base à partir duquel vous travaillez.

    +
    +
    + +
    top
    +
    +

    Noms d'hôtes canoniques

    + + + +
    +
    Description :
    + +
    Le but de cette règle est de préférer l'utilisation d'un nom + d'hôte particulier à d'autres noms d'hôte utilisables + pour atteindre le même site. Par exemple, si vous voulez + utiliser www.example.com à la place de + example.com, vous pouvez utiliser une solution + du style :
    + +
    Solution :
    + +
    + +

    Pour y parvenir, il vaut mieux se passer de mod_rewrite, et utiliser +plutôt la directive Redirect dans +une section de serveur virtuel pour le/les noms d'hôte non canoniques.

    + +
    <VirtualHost *:80>
+  ServerName undesired.example.com
+  ServerAlias example.com notthis.example.com
+
+  Redirect "/" "http://www.example.com/"
+</VirtualHost>
+
+<VirtualHost *:80>
+  ServerName www.example.com
+</VirtualHost>
    + + +

    Vous pouvez aussi utiliser la directive <If> (versions 2.4 et ultérieures) :

    + +
    <If "%{HTTP_HOST} != 'www.example.com'">
+	Redirect "/" "http://www.example.com/"
+</If>
    + + +

    Ou, par exemple, pour rediriger une portion de votre site vers HTTPS +:

    + +
    <If "%{SERVER_PROTOCOL} != 'HTTPS'">
+	Redirect "/admin/" "https://www.example.com/admin/"
+</If>
    + + +

    Si, pour une raison particulière, vous voulez tout de même utiliser +mod_rewrite - dans le cas, par exemple, où vous avez besoin +d'un jeu plus important de règles de réécritures - vous pouvez utiliser +la recette suivante :

    + +

    Pour les sites écoutant sur un port autre que 80:

    +
    RewriteCond "%{HTTP_HOST}"   "!^www\.example\.com" [NC]
+RewriteCond "%{HTTP_HOST}"   "!^$"
+RewriteCond "%{SERVER_PORT}" "!^80$"
+RewriteRule "^/?(.*)"         "http://www.example.com:%{SERVER_PORT}/$1" [L,R,NE]
    + + +

    Et pour un site écoutant sur le port 80

    +
    RewriteCond "%{HTTP_HOST}"   "!^www\.example\.com" [NC]
+RewriteCond "%{HTTP_HOST}"   "!^$"
+RewriteRule "^/?(.*)"         "http://www.example.com/$1" [L,R,NE]
    + +

    + Si vous souhaitez que cette règle s'applique à tous les noms de + domaine - en d'autres termes, si vous voulez rediriger + example.com vers + www.example.com pour toutes les valeurs + possibles de example.com, vous pouvez utiliser + le jeu de règles suivants :

    + +
    RewriteCond "%{HTTP_HOST}" "!^www\." [NC]
+RewriteCond "%{HTTP_HOST}" "!^$"
+RewriteRule "^/?(.*)" "http://www.%{HTTP_HOST}/$1" [L,R,NE]
    + +

    + Vous pouvez utiliser ce jeu de règles aussi bien dans le fichier + de configuration de votre serveur principal que dans un fichier + .htaccess placé dans le répertoire défini par la + directive DocumentRoot du serveur.

    +
    +
    + +
    top
    +
    +

    Recherche de pages dans plus d'un répertoire

    + + + +
    +
    Description:
    + +
    +

    Une ressource peut exister dans plusieurs répertoires, et nous + voulons rechercher cette ressource dans ces répertoires + lorsqu'elle fait l'objet d'une requête. Il est possible que nous + ayons récemment réorganisé la structure de notre site en + répartissant son contenu dans plusieurs répertoires.

    +
    + +
    Solution :
    + +
    +

    Le jeu de règles suivant recherche la ressource dans deux + répertoires, et s'il ne la trouve dans aucun des deux, il tentera + simplement de la servir à partir de l'adresse fournie dans la + requête.

    + +
    RewriteEngine on
+
+#   on cherche tout d'abord dans dir1/...
+#   ... et si on trouve, on est content et on arrête :
+RewriteCond         "%{DOCUMENT_ROOT}/dir1/%{REQUEST_URI}"  -f
+RewriteRule  "^(.+)"  "%{DOCUMENT_ROOT}/dir1/$1"  [L]
+
+#   on cherche ensuite dans dir2/...
+#   ... et si on trouve, on est content et on arrête :
+RewriteCond         "%{DOCUMENT_ROOT}/dir2/%{REQUEST_URI}"  -f
+RewriteRule  "^(.+)"  "%{DOCUMENT_ROOT}/dir2/$1"  [L]
+
+#   sinon, on continue la recherche avec d'autres directives Alias
+#   ou ScriptAlias, etc...
+RewriteRule   "^"  "-"  [PT]
    + +
    +
    + +
    top
    +
    +

    Redirection vers des serveurs géographiquement distribués

    + + + +
    +
    Description :
    + +
    +

    Notre site web possède de nombreux miroirs, et nous voulons + rediriger les utilisateurs vers celui qui se situe dans le pays où + ils se trouvent.

    +
    + +
    Solution :
    + +
    +

    En consultant le nom d'hôte du client demandeur, on détermine le + pays dans lequel il se trouve. S'il est impossible d'effectuer une + recherche sur leur adresse IP, on se rabat sur un serveur par + défaut.

    +

    Nous allons utiliser une directive RewriteMap afin de construire une + liste des serveurs que nous voulons utiliser.

    + +
    HostnameLookups on
+RewriteEngine on
+RewriteMap    multiplex         "txt:/path/to/map.mirrors"
+RewriteCond  "%{REMOTE_HOST}"     "([a-z]+)$ [NC]"
+RewriteRule   "^/(.*)$"  "${multiplex:%1|http://www.example.com/}$1"  [R,L]
    + + +

    +## liste_miroirs -- Table de correspondance pays - serveurs
    +
    +de http://www.exemple.de/
    +uk http://www.exemple.uk/
    +com http://www.example.com/
    +##EOF## +

    +
    + +
    Discussion
    +
    +
    Ce jeu de règles nécessite la définition à + on de la directive HostNameLookups, ce qui peut induire une + baisse de performance significative.
    + +

    La directive RewriteCond extrait la dernière + partie du nom d'hôte du client demandeur - le code du pays - et la + règle de réécriture qui suit utilise cette valeur pour rechercher le + serveur miroir approprié dans le fichier de correspondances.

    +
    +
    + +
    top
    +
    +

    URLs canoniques

    + + + +
    +
    Description :
    + +
    +

    Sur certains serveurs, une ressource peut posséder plusieurs + URLs. Il y a en général les URLs canoniques (celles qui sont + réellement distribuées et utilisées), et celles qui correspondent à + des raccourcis, les URLs internes, etc... Quelle que soit l'adresse + que l'utilisateur fournit dans la requête, il devrait finalement + voir l'URL canonique dans la barre d'adresse de son navigateur.

    +
    + +
    Solution :
    + +
    +

    Nous effectuons une redirection HTTP externe pour toutes les + URLs non canoniques afin de les corriger dans la barre d'adresse + du navigateur, et ceci pour toutes les requêtes futures. Dans le + jeu de règles suivant, nous remplaçons /matous et + /minettes par le canonique /chats.

    + + 
    RewriteRule   "^/(matous|minettes)/(.*)"    "/chats/$2"  [R]
    + +
    + +
    Discussion :
    +
    On serait mieux inspiré d'utiliser ici les directives Redirect ou + RedirectMatch : + + 
    RedirectMatch "^/(matous|minettes)/(.*)" "/chats/$2"
    + +
    +
    + +
    top
    +
    +

    Déplacement du répertoire DocumentRoot

    + + + +
    +
    Description :
    + +
    +

    En général, le répertoire DocumentRoot du serveur web correspond à l'URL +"/". Ce répertoire ne contient cependant pas forcément des +ressources de première importance pour l'utilisateur. Par exemple, vous +préférerez peut-être que le répertoire d'accueil d'un visiteur accédant +pour la première fois à votre site soit un répertoire particulier +/a-propos-de/. Pour y parvenir, utilisez le jeu de règles +suivant :

    +
    + +
    Solution :
    + +
    +

    On redirige l'URL / vers + /a-propos-de/ : +

    + +
    RewriteEngine on
+RewriteRule   "^/$"  "/a-propos-de/"  [R]
    + + +

    Notez que l'on peut aussi y parvenir en utilisant la directive +RedirectMatch :

    + +
    RedirectMatch "^/$" "http://example.com/a-propos-de/"
    + + +

    Notez aussi que cet exemple ne réécrit que l'URL racine. En d'autres +termes, il réécrit une requête pour http://example.com/, +mais pas pour une requête http://example.com/page.html. Si +vous avez effectivement modifié la racine de vos documents - c'est à dire +si tous vos contenus se trouvent dans un +sous-répertoire, il est largement préférable de modifier simplement +votre directive DocumentRoot, ou de +déplacer l'ensemble du contenu vers le répertoire supérieur, plutôt que +de réécrire les URLs.

    +
    +
    + +
    top
    +
    +

    Ressource par défaut

    + + +
    +
    Description :
    +
    Vous voulez qu'une seule ressource (disons un certain fichier tel +que index.php) soit servie pour toutes les requêtes à destination d'un +certain répertoire, sauf pour celles qui concernent une ressource +existant effectivement comme une image, ou un fichier css.
    + +
    Solution :
    +
    +

    Depuis la version 2.2.16, vous pouvez y parvenir via la directive +FallbackResource :

    + +
    <Directory "/var/www/my_blog">
+  FallbackResource index.php
+</Directory>
    + + +

    Cependant, si vos besoins étaient plus complexes, vous pouviez, dans +les versions plus anciennes d'Apache, utiliser un jeu de règles du style +:

    + +
    <Directory "/var/www/my_blog">
+  RewriteBase "/my_blog"
+
+  RewriteCond "/var/www/my_blog/%{REQUEST_FILENAME}" !-f
+  RewriteCond "/var/www/my_blog/%{REQUEST_FILENAME}" !-d
+  RewriteRule "^" "index.php" [PT]
+</Directory>
    + + +

    D'autre part, si vous voulez transmettre l'URI de la requête en tant +que chaîne de paramètres à index.php, vous pouvez remplacer cette règle +de réécriture par :

    + +
    RewriteRule "(.*)" "index.php?$1" [PT,QSA]
    + + +

    Notez que l'on peut utiliser ces jeux de règles aussi bien dans un +fichier .htaccess que dans une section +<Directory>.

    + +
    + +
    + +
    top
    +
    +

    Rewrite query string

    + + +
    +
    Description :
    +
    Vous voulez extraire une valeur particulière d'une chaîne de +paramètres d'une URL, et soit la remplacer, soit l'incorporer dans un +autre composant de l'URL.
    + +
    Solutions :
    +
    +

    Dans la plupart des solutions de cette section, on utilise la même +condition qui stocke la valeur recherchée dans la référence arrière %2. +%1 est le début de la requête, et %3 ce qui reste. Cette condition est +un peu complexe car elle introduit de la flexibilité et évite les +doubles perluettes '&&' dans les substitutions.

    +
      +
    • Cette solution supprime le couple clé/valeur recherché : + +
      # Remove mykey=???
+RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))mykey=([^&]*)&?(.*)&?$"
+RewriteRule "(.*)" "$1?%1%3"
      + +
      • + +
    • Cette solution remplace la partie de l'URL qui suit la valeur + recherchée par un '?' : + +
      # Copy from query string to PATH_INFO
+RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))mykey=([^&]*)&?(.*)&?$"
+RewriteRule "(.*)" "$1/products/%2/?" [PT]
      + +
      • + +
    • Cette solution utilise la valeur recherchée dans une deuxième + condition :: + +
      # Capture the value of mykey in the query string
+RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))mykey=([^&]*)&?(.*)&?$""
+RewriteCond "%2" !=not-so-secret-value 
+RewriteRule "(.*)" - [F]
      + +
      • + +
    • Cette solution produit l'effet inverse des précédentes ; elle + copie des composantes du chemin (peut-être PATH_INFO) depuis l'URL + vers sa chaîne de paramètres : +
      # The desired URL might be /products/kitchen-sink, and the script expects 
+# /path?products=kitchen-sink.
+RewriteRule "^/?path/([^/]+)/([^/]+)" "/path?$1=$2" [PT]
      + +
      • +
    + +
    + +
    +
    +
    +

    Langues Disponibles:  en  | + fr 

    +
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    +
    + \ No newline at end of file diff --git a/docs/manual/rewrite/rewritemap.html.en b/docs/manual/rewrite/rewritemap.html.en index 0b40c33cba..cac2d87be5 100644 --- a/docs/manual/rewrite/rewritemap.html.en +++ b/docs/manual/rewrite/rewritemap.html.en @@ -24,7 +24,7 @@ Apache > HTTP Server > Documentation > Version 2.5 > Rewrite

    Using RewriteMap

    Available Languages:  en  | - fr 

    + fr 

    @@ -453,7 +453,7 @@ this process, or if the script itself is very slow.

    Available Languages:  en  | - fr 

    + fr 

    top

    Comments

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    - - -
    -

    Modules | Directives | FAQ | Glossaire | Plan du site

    -

    Serveur HTTP Apache Version 2.5

    -
    -
    <-
    -

    Utilisation de RewriteMap

    -
    -

    Langues Disponibles:  en  | - fr 

    -
    - - -

    Ce document est un complément à la documentation de référence du - module mod_rewrite. Il décrit l'utilisation de la - directive RewriteMap, et - fournit des exemples pour chacun des différents types de - RewriteMap.

    - -
    Notez que la plupart de ces exemples ne - fonctionneront pas en l'état dans le contexte de votre configuration - particulière ; vous devez donc vous attacher à les - comprendre, plutôt que de simplement les insérer dans votre - configuration par copier/coller.
    - -
    - -
    top
    -
    -

    Introduction

    - - -

    - La directive RewriteMap - définit une fonction externe qui peut être appelée depuis une - directive RewriteRule ou - RewriteCond pour - accomplir une réécriture trop compliquée, ou trop spécialisée pour - être effectuée à partir d'expressions rationnelles. Vous trouverez - ci-dessous les différents types disponibles pour la source de - données, ceux-ci étant par ailleurs énumérés dans la documentation de - référence de RewriteMap.

    - -

    La syntaxe de la directive RewriteMap est la suivante :

    - -
    RewriteMap MapName MapType:MapSource
    - - -

    L'argument MapName - est un nom arbitraire que vous associez à la table de - correspondances, et que vous - pourrez utilisez par la suite dans les directives de réécriture. Les - recherches dans la table de correspondance s'effectuent en - respectant cette syntaxe :

    - -

    - - ${ nom-map : - clé-recherche - }
    ${ nom-map : - clé-recherche | DefaultValue } -     -

    - -

    Lorsque cette syntaxe est employée, la table de correspondances - nom-map est consultée et la clé clé-recherche - recherchée. Si la clé est trouvée, la fonction de recherche dans la - table de correspondance est remplacée par SubstValue, ou - par DefaultValue dans le cas contraire, ou par la chaîne - vide si aucune DefaultValue n'a été spécifiée.

    - -

    Par exemple, vous pouvez définir une directive - RewriteMap comme suit :

    - 
    RewriteMap examplemap "txt:/path/to/file/map.txt"
    - -

    Vous pourrez par la suite utiliser cette table de correspondances - dans une directive RewriteRule comme suit :

    -
    RewriteRule "^/ex/(.*)" "${examplemap:$1}"
    - - -

    Il est possible de spécifier une valeur par défaut qui sera utilisée -si la recherche dans la table de correspondances est infructueuse :

    - -
    RewriteRule "^/ex/(.*)" "${examplemap:$1|/not_found.html}"
    - - -

    Contexte de répertoire et fichiers.htaccess

    -

    -Vous ne pouvez utilisez la directive RewriteMap ni dans -les sections <Directory>, ni dans les fichiers -.htaccess. Vous devez déclarer la table de correspondances -au niveau du serveur principal ou dans un contexte de serveur virtuel. -Par contre, si vous ne pouvez pas déclarer la table dans une section -<Directory> ou dans un fichier .htaccess, vous -pourrez y faire référence dans ces contextes, une fois cette table -créée. -

    -
    - -

    Les sections suivantes décrivent les différents types de tables de -correspondances type-map disponibles, et fournissent des -exemples pour chacun d'entre eux.

    -
    top
    -
    -

    int: fonction interne

    - - -

    Quand le type de table int est spécifié, la - correspondance s'effectue via une des fonctions internes RewriteMap disponibles. Les - développeurs de modules peuvent fournir des fonctions internes - supplémentaires en les enregistrant via l'API - ap_register_rewrite_mapfunc. Les fonctions fournies par - défaut sont : -

    - -
      -
    • toupper:
      - Met la clé en majuscules.
      • -
    • tolower:
      - Met la clé en minuscules.
      • -
    • escape:
      - Remplace les caractères spéciaux de la clé en codes - hexadécimaux.
      • -
    • unescape:
      - Reconvertit les codes hexadécimaux de la clé en caractères - spéciaux.
      • -
    - -

    - Pour utiliser une de ces fonctions, créez une - RewriteMap qui référence la - fonction interne, et insérez-la dans votre RewriteRule : -

    - -

    Redirection d'un URI vers une version en minuscules - d'elle-même

    - 
    RewriteMap lc int:tolower
-RewriteRule "(.*)" "${lc:$1}" [R]
    - - -
    -

    Notez que cet exemple n'est présenté ici qu'à titre - d'illustration et ne constitue pas une recommandation. Si vous - voulez rendre les URLs insensibles à la casse, utiliser plutôt le - module mod_speling. -

    -
    - -
    top
    -
    -

    txt: tables de correspondances au format texte

    - - -

    Lorsqu'un type-map txt est utilisé, la source-map - est un chemin du système de fichiers vers un fichier de - correspondances au format texte, contenant sur chaque ligne une - paire clé/valeur séparées par un espace. Il est possible d'insérer - des commentaires sous la forme de chaînes commençant par le caractère - '#'.

    - -

    Un fichier de correspondances au format texte valide possèdera la - syntaxe suivante :

    - -

    - # Ligne de commentaires
    - clé valeur-substitution
    - clé valeur-substitution # commentaire
    -

    - -

    Lorsque la table de correspondance fait l'objet d'une recherche, - la valeur spécifiée est recherchée dans le premier champ, et si elle - est trouvée, la valeur de substitution est renvoyée.

    - -

    Par exemple, nous pourrions utiliser un fichier de - correspondances pour traduire des noms de produits en identifiants - produits pour obtenir des URLs plus simples à mémoriser, en - utilisant la recette suivante :

    - -

    Product to ID configuration

    - 
    RewriteMap product2id "txt:/etc/apache2/productmap.txt"
-RewriteRule "^/product/(.*)" "/prods.php?id=${product2id:$1|NOTFOUND}" [PT]
    - - -

    Nous supposons ici que le script prods.php sait quoi - faire lorsqu'il reçoit un argument id=NON-TROUVE, dans - le cas où le produit ne se trouve pas dans la table de - correspondances.

    - -

    Le fichier /etc/apache2/map-produit.txt contient ce - qui suit :

    - -

    Fichier de correspondances Produit - Identifiant

    -##
    -## map-produit.txt - Fichier de correspondances Produit - Identifiant
    -##
    -
    -TELEVISION 993
    -STEREO 198
    -CANNE-A-PECHE 043
    -BALLON-BASKET 418
    -TELEPHONE 328 -

    - -

    Ainsi, lorsqu'une requête pour - http://example.com/produit/TELEVISION arrive, la directive - RewriteRule s'applique, et la - requête est transformée en interne en /prods.php?id=993.

    - -

    Note: fichiers .htaccess

    - L'exemple donné est conçu pour être utilisé dans un contexte de - serveur principal ou de serveur virtuel. Si vous voulez l'utiliser - dans un fichier .htaccess, vous devrez supprimer le - slash de début dans le modèle de réécriture afin que ce dernier - puisse correspondre à toute URL : - 
    RewriteRule "^product/(.*)" "/prods.php?id=${product2id:$1|NOTFOUND}" [PT]
    - -
    - -

    Recherches mises en cache

    -

    - Les clés de recherche sont mises en cache par httpd jusqu'à ce que - le mtime (date de modification) du fichier de - correspondances soit modifié, ou que le serveur httpd soit - redémarré, ce qui améliore les performances pour les tables de - correspondances consultées par de nombreuses requêtes. -

    -
    - -
    top
    -
    -

    rnd: Fichier texte à valeurs de substitution multiples - choisies de manière aléatoire

    - - -

    Lorsque le type-map spécifié est rnd, la source est - un chemin du système de fichiers vers un fichier de correspondances - au format texte dont chaque ligne contient une clé, et une ou - plusieurs valeurs séparées par le caractère |. Si une - clé convient, une des valeurs correspondantes sera choisie de - manière aléatoire.

    - -

    Par exemple, vous pouvez utiliser le fichier de correspondances - et les directives suivants pour implémenter une répartition de - charge aléatoire entre plusieurs serveurs d'arrière-plan, par - l'intermédiaire d'un mandataire inverse. Les images sont envoyées - vers un des serveurs de l'ensemble 'statique', tandis que tout le - reste est envoyé vers un des serveurs de l'ensemble 'dynamique'.

    - -

    Fichier de correspondances

    -##
    -## map.txt -- table de réécriture
    -##
    -
    -statique www1|www2|www3|www4
    -dynamique www5|www6 -

    -

    Configuration directives

    - 
    RewriteMap servers "rnd:/path/to/file/map.txt"
-
-RewriteRule "^/(.*\.(png|gif|jpg))" "http://${servers:static}/$1" [NC,P,L]
-RewriteRule "^/(.*)" "http://${servers:dynamic}/$1" [P,L]
    - - - -

    Ainsi, lorsqu'une image est demandée et que la première règle - convient, RewriteMap recherche la chaîne - statique dans le fichier de correspondances qui - renvoie un des noms de serveurs spécifiés de manière aléatoire, - ce dernier étant utilisé dans la cible de la règle - RewriteRule.

    - -

    Si vous voulez qu'un des serveurs soit plus souvent sollicité que - les autres (par exemple s'il possède plus de mémoire, et peut donc - traiter d'avantage de requêtes), spécifiez-le plusieurs fois dans la - liste des serveurs.

    - -

    -statique www1|www1|www2|www3|www4 -

    - -
    top
    -
    -

    dbm: Fichier condensé DBM

    - - -

    Lorsque le type-map dbm est utilisé, la source est - un chemin du système de fichiers vers un fichier de données DBM - contenant des paires clé/valeur permettant d'effectuer la - correspondance. Le fonctionnement est identique à celui du type-map - txt, mais beaucoup plus rapide car un fichier DBM est - indexé, alors qu'un fichier texte ne l'est pas. L'accès à la clé - recherchée est donc plus rapide.

    - -

    Vous pouvez éventuellement spécifier un type dbm particulier :

    - - 
    RewriteMap examplemap "dbm=sdbm:/etc/apache/mapfile.dbm"
    - - -

    Ce type peut être choisi parmi sdbm, gdbm, - ndbm ou db. Il est - cependant recommandé d'utiliser l'utilitaire httxt2dbm fourni avec le - serveur HTTP Apache, car il utilise la bibliothèque DBM appropriée, - à savoir celle qui a été utilisée lors de la compilation de httpd.

    - -

    Pour créer un fichier dbm, créez tout d'abord un fichier de - correspondances au format texte comme décrit dans la section txt. Traitez ensuite ce fichier avec - httxt2dbm :

    - -

    -$ httxt2dbm -i fichier-map.txt -o fichier-map.map -

    - -

    Vous pouvez alors faire référence au fichier obtenu dans votre -directive RewriteMap :

    -
    RewriteMap mapname "dbm:/etc/apache/mapfile.map"
    - - -
    -

    Notez qu'avec certains types dbm, plusieurs fichiers possédant le -même nom de base sont créés. Par exemple, vous pouvez obtenir deux -fichiers nommés fichier-map.map.dir et -fichier-map.map.pag. Ceci est tout à fait normal, et vous -ne devez utiliser que le nom de base fichier-map.map dans votre -directive RewriteMap.

    -
    - -

    Mise en cache des recherches

    -

    - Les clés de recherche sont mises en cache par httpd jusqu'à ce que - le mtime (date de modification) du fichier de - correspondances soit modifié, ou que le serveur httpd soit - redémarré, ce qui améliore les performances pour les tables de - correspondances consultées par de nombreuses requêtes. -

    -
    - -
    top
    -
    -

    prg: Programme de réécriture externe

    - -

    Lorque le type-map prg est spécifié, la source est - un chemin du système de fichiers vers un programme exécutable - destiné à effectuer la mise en correspondance. Il peut s'agir d'un - fichier binaire compilé, ou d'un programme en langage interprété - comme Perl ou Python.

    - -

    Ce programme est lancé une fois au démarrage du serveur HTTP - Apache, puis communique avec le moteur de réécriture via - STDIN et STDOUT. En d'autres termes, pour - chaque recherche de correspondance, il reçoit un argument via - STDIN, et doit renvoyer en guise de réponse une chaîne - terminée par un caractère nouvelle-ligne sur STDOUT. Si - la recherche de correspondance est infructueuse, le programme doit - l'indiquer en retournant la chaîne de quatre caractères - "NULL".

    - -

    Les programmes de réécriture externes ne sont pas lancés s'il - n'ont pas été définis dans un contexte où la directive RewriteEngine est définie à - on.

    - -

    Par défaut, les programmes de réécriture externes s'exécutent sous - l'utilisateur/groupe qui a démarré httpd. Pour en changer, il est possible - sur les systèmes de style Unix de spécifier un autre couple - utilisateur/groupe via le troisième argument de la directive RewriteMap, et ceci au format - utilisateur:groupe.

    - -

    Cette fonctionnalité utilise le mutex rewrite-map - nécessaire à la fiabilité des communications avec le programme. Le - mécanisme de mutex et le fichier verrou peuvent être définis via la - directive Mutex.

    - -

    Voici un exemple simple qui remplace tous les tirets par des - caractères de soulignement dans l'URI de la requête.

    - -

    Configuration de la réécriture

    - 
    RewriteMap d2u "prg:/www/bin/dash2under.pl" apache:apache
-RewriteRule "-" "${d2u:%{REQUEST_URI}}"
    - - -

    dash2under.pl

    - 
        #!/usr/bin/perl
-    $| = 1; # Turn off I/O buffering
-    while (<STDIN>) {
-        s/-/_/g; # Remplace tous les tirets par des caractères de soulignement
-        print $_;
-    }
    - - -

    Mises en garde !

    -
      -
    • Votre programme doit être le plus -simple possible. Si le programme se bloque, httpd va attendre -indéfiniment une réponse de sa part, et par conséquent ne répondra plus -aux requêtes.
      • -
    • Assurez-vous de bien désactiver la mise en tampon dans votre -programme. En Perl, ceci est effectué à la seconde ligne du script de -l'exemple - $| = 1; - La syntaxe sera bien entendu -différente dans -d'autres langages. Si les entrées/sorties sont mises en tampon, httpd va -attendre une sortie, et va par conséquent se bloquer.
      • -
    • Rappelez-vous qu'il n'existe qu'une copie du programme lancé au -démarrage du serveur, et que toutes les requêtes vont devoir passer par -ce goulot d'étranglement. Ceci peut provoquer des ralentissements -significatifs si de nombreuses requêtes doivent être traitées, ou si le -script lui-même est très lent.
      • -
    -
    - -
    top
    -
    -

    dbd ou fastdbd: requête SQL

    - - -

    Lorsque le type-map dbd ou fastdbd est - spécifié, la source est une requête SQL SELECT qui reçoit un - argument et renvoie une seule valeur.

    - -

    Pour que cette requête puisse être exécutée, - mod_dbd doit être configuré pour attaquer la base - de données concernée.

    - -

    Ce type-map existe sous deux formes. Avec le type-map - dbd, la requête est exécutée à chaque demande, tandis - qu'avec le type-map fastdbd, les recherches dans la - base de données sont mises en cache en interne. fastdbd - est donc plus efficace et donc plus rapide ; par contre, il ne - tiendra pas compte des modifications apportées à la base de données - jusqu'à ce que le serveur soit redémarré.

    - -

    Si une requête renvoie plusieurs enregistrements, un de ceux-ci - sera sélectionné aléatoirement.

    - -

    Exemple

    RewriteMap ma-requete "fastdbd:SELECT destination FROM rewrite WHERE source = %s"
    -
    - -

    Note

    -

    Le nom de la requête est transmis au pilote de base de données en tant - que label pour une requête SQL préparée, et doit donc respecter toutes les - règles imposées par votre base de données (comme la sensibilité à la casse).

    - -
    top
    -
    -

    Résumé

    - - -

    La directive RewriteMap peut apparaître - plusieurs fois. Utilisez une directive - RewriteMap pour chaque fonction de mise en - correspondance pour déclarer son fichier de correspondances.

    - -

    Bien que l'on ne puisse pas déclarer de fonction - de mise en correspondance dans un contexte de répertoire (fichier - .htaccess ou section <Directory>), il est - possible d'utiliser cette fonction dans un tel contexte.

    - -
    -
    -

    Langues Disponibles:  en  | - fr 

    -
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    -
    - \ No newline at end of file diff --git a/docs/manual/rewrite/rewritemap.html.fr.utf8 b/docs/manual/rewrite/rewritemap.html.fr.utf8 new file mode 100644 index 0000000000..5d360b794a --- /dev/null +++ b/docs/manual/rewrite/rewritemap.html.fr.utf8 @@ -0,0 +1,512 @@ + + + + + +Utilisation de RewriteMap - Serveur HTTP Apache Version 2.5 + + + + + + +
    +

    Modules | Directives | FAQ | Glossaire | Plan du site

    +

    Serveur HTTP Apache Version 2.5

    +
    +
    <-
    +

    Utilisation de RewriteMap

    +
    +

    Langues Disponibles:  en  | + fr 

    +
    + + +

    Ce document est un complément à la documentation de référence du + module mod_rewrite. Il décrit l'utilisation de la + directive RewriteMap, et + fournit des exemples pour chacun des différents types de + RewriteMap.

    + +
    Notez que la plupart de ces exemples ne + fonctionneront pas en l'état dans le contexte de votre configuration + particulière ; vous devez donc vous attacher à les + comprendre, plutôt que de simplement les insérer dans votre + configuration par copier/coller.
    + +
    + +
    top
    +
    +

    Introduction

    + + +

    + La directive RewriteMap + définit une fonction externe qui peut être appelée depuis une + directive RewriteRule ou + RewriteCond pour + accomplir une réécriture trop compliquée, ou trop spécialisée pour + être effectuée à partir d'expressions rationnelles. Vous trouverez + ci-dessous les différents types disponibles pour la source de + données, ceux-ci étant par ailleurs énumérés dans la documentation de + référence de RewriteMap.

    + +

    La syntaxe de la directive RewriteMap est la suivante :

    + +
    RewriteMap MapName MapType:MapSource
    + + +

    L'argument MapName + est un nom arbitraire que vous associez à la table de + correspondances, et que vous + pourrez utilisez par la suite dans les directives de réécriture. Les + recherches dans la table de correspondance s'effectuent en + respectant cette syntaxe :

    + +

    + + ${ nom-map : + clé-recherche + }
    ${ nom-map : + clé-recherche | DefaultValue } +     +

    + +

    Lorsque cette syntaxe est employée, la table de correspondances + nom-map est consultée et la clé clé-recherche + recherchée. Si la clé est trouvée, la fonction de recherche dans la + table de correspondance est remplacée par SubstValue, ou + par DefaultValue dans le cas contraire, ou par la chaîne + vide si aucune DefaultValue n'a été spécifiée.

    + +

    Par exemple, vous pouvez définir une directive + RewriteMap comme suit :

    + 
    RewriteMap examplemap "txt:/path/to/file/map.txt"
    + +

    Vous pourrez par la suite utiliser cette table de correspondances + dans une directive RewriteRule comme suit :

    +
    RewriteRule "^/ex/(.*)" "${examplemap:$1}"
    + + +

    Il est possible de spécifier une valeur par défaut qui sera utilisée +si la recherche dans la table de correspondances est infructueuse :

    + +
    RewriteRule "^/ex/(.*)" "${examplemap:$1|/not_found.html}"
    + + +

    Contexte de répertoire et fichiers.htaccess

    +

    +Vous ne pouvez utilisez la directive RewriteMap ni dans +les sections <Directory>, ni dans les fichiers +.htaccess. Vous devez déclarer la table de correspondances +au niveau du serveur principal ou dans un contexte de serveur virtuel. +Par contre, si vous ne pouvez pas déclarer la table dans une section +<Directory> ou dans un fichier .htaccess, vous +pourrez y faire référence dans ces contextes, une fois cette table +créée. +

    +
    + +

    Les sections suivantes décrivent les différents types de tables de +correspondances type-map disponibles, et fournissent des +exemples pour chacun d'entre eux.

    +
    top
    +
    +

    int: fonction interne

    + + +

    Quand le type de table int est spécifié, la + correspondance s'effectue via une des fonctions internes RewriteMap disponibles. Les + développeurs de modules peuvent fournir des fonctions internes + supplémentaires en les enregistrant via l'API + ap_register_rewrite_mapfunc. Les fonctions fournies par + défaut sont : +

    + +
      +
    • toupper:
      + Met la clé en majuscules.
      • +
    • tolower:
      + Met la clé en minuscules.
      • +
    • escape:
      + Remplace les caractères spéciaux de la clé en codes + hexadécimaux.
      • +
    • unescape:
      + Reconvertit les codes hexadécimaux de la clé en caractères + spéciaux.
      • +
    + +

    + Pour utiliser une de ces fonctions, créez une + RewriteMap qui référence la + fonction interne, et insérez-la dans votre RewriteRule : +

    + +

    Redirection d'un URI vers une version en minuscules + d'elle-même

    + 
    RewriteMap lc int:tolower
+RewriteRule "(.*)" "${lc:$1}" [R]
    + + +
    +

    Notez que cet exemple n'est présenté ici qu'à titre + d'illustration et ne constitue pas une recommandation. Si vous + voulez rendre les URLs insensibles à la casse, utiliser plutôt le + module mod_speling. +

    +
    + +
    top
    +
    +

    txt: tables de correspondances au format texte

    + + +

    Lorsqu'un type-map txt est utilisé, la source-map + est un chemin du système de fichiers vers un fichier de + correspondances au format texte, contenant sur chaque ligne une + paire clé/valeur séparées par un espace. Il est possible d'insérer + des commentaires sous la forme de chaînes commençant par le caractère + '#'.

    + +

    Un fichier de correspondances au format texte valide possèdera la + syntaxe suivante :

    + +

    + # Ligne de commentaires
    + clé valeur-substitution
    + clé valeur-substitution # commentaire
    +

    + +

    Lorsque la table de correspondance fait l'objet d'une recherche, + la valeur spécifiée est recherchée dans le premier champ, et si elle + est trouvée, la valeur de substitution est renvoyée.

    + +

    Par exemple, nous pourrions utiliser un fichier de + correspondances pour traduire des noms de produits en identifiants + produits pour obtenir des URLs plus simples à mémoriser, en + utilisant la recette suivante :

    + +

    Product to ID configuration

    + 
    RewriteMap product2id "txt:/etc/apache2/productmap.txt"
+RewriteRule "^/product/(.*)" "/prods.php?id=${product2id:$1|NOTFOUND}" [PT]
    + + +

    Nous supposons ici que le script prods.php sait quoi + faire lorsqu'il reçoit un argument id=NON-TROUVE, dans + le cas où le produit ne se trouve pas dans la table de + correspondances.

    + +

    Le fichier /etc/apache2/map-produit.txt contient ce + qui suit :

    + +

    Fichier de correspondances Produit - Identifiant

    +##
    +## map-produit.txt - Fichier de correspondances Produit - Identifiant
    +##
    +
    +TELEVISION 993
    +STEREO 198
    +CANNE-A-PECHE 043
    +BALLON-BASKET 418
    +TELEPHONE 328 +

    + +

    Ainsi, lorsqu'une requête pour + http://example.com/produit/TELEVISION arrive, la directive + RewriteRule s'applique, et la + requête est transformée en interne en /prods.php?id=993.

    + +

    Note: fichiers .htaccess

    + L'exemple donné est conçu pour être utilisé dans un contexte de + serveur principal ou de serveur virtuel. Si vous voulez l'utiliser + dans un fichier .htaccess, vous devrez supprimer le + slash de début dans le modèle de réécriture afin que ce dernier + puisse correspondre à toute URL : + 
    RewriteRule "^product/(.*)" "/prods.php?id=${product2id:$1|NOTFOUND}" [PT]
    + +
    + +

    Recherches mises en cache

    +

    + Les clés de recherche sont mises en cache par httpd jusqu'à ce que + le mtime (date de modification) du fichier de + correspondances soit modifié, ou que le serveur httpd soit + redémarré, ce qui améliore les performances pour les tables de + correspondances consultées par de nombreuses requêtes. +

    +
    + +
    top
    +
    +

    rnd: Fichier texte à valeurs de substitution multiples + choisies de manière aléatoire

    + + +

    Lorsque le type-map spécifié est rnd, la source est + un chemin du système de fichiers vers un fichier de correspondances + au format texte dont chaque ligne contient une clé, et une ou + plusieurs valeurs séparées par le caractère |. Si une + clé convient, une des valeurs correspondantes sera choisie de + manière aléatoire.

    + +

    Par exemple, vous pouvez utiliser le fichier de correspondances + et les directives suivants pour implémenter une répartition de + charge aléatoire entre plusieurs serveurs d'arrière-plan, par + l'intermédiaire d'un mandataire inverse. Les images sont envoyées + vers un des serveurs de l'ensemble 'statique', tandis que tout le + reste est envoyé vers un des serveurs de l'ensemble 'dynamique'.

    + +

    Fichier de correspondances

    +##
    +## map.txt -- table de réécriture
    +##
    +
    +statique www1|www2|www3|www4
    +dynamique www5|www6 +

    +

    Configuration directives

    + 
    RewriteMap servers "rnd:/path/to/file/map.txt"
+
+RewriteRule "^/(.*\.(png|gif|jpg))" "http://${servers:static}/$1" [NC,P,L]
+RewriteRule "^/(.*)" "http://${servers:dynamic}/$1" [P,L]
    + + + +

    Ainsi, lorsqu'une image est demandée et que la première règle + convient, RewriteMap recherche la chaîne + statique dans le fichier de correspondances qui + renvoie un des noms de serveurs spécifiés de manière aléatoire, + ce dernier étant utilisé dans la cible de la règle + RewriteRule.

    + +

    Si vous voulez qu'un des serveurs soit plus souvent sollicité que + les autres (par exemple s'il possède plus de mémoire, et peut donc + traiter d'avantage de requêtes), spécifiez-le plusieurs fois dans la + liste des serveurs.

    + +

    +statique www1|www1|www2|www3|www4 +

    + +
    top
    +
    +

    dbm: Fichier condensé DBM

    + + +

    Lorsque le type-map dbm est utilisé, la source est + un chemin du système de fichiers vers un fichier de données DBM + contenant des paires clé/valeur permettant d'effectuer la + correspondance. Le fonctionnement est identique à celui du type-map + txt, mais beaucoup plus rapide car un fichier DBM est + indexé, alors qu'un fichier texte ne l'est pas. L'accès à la clé + recherchée est donc plus rapide.

    + +

    Vous pouvez éventuellement spécifier un type dbm particulier :

    + + 
    RewriteMap examplemap "dbm=sdbm:/etc/apache/mapfile.dbm"
    + + +

    Ce type peut être choisi parmi sdbm, gdbm, + ndbm ou db. Il est + cependant recommandé d'utiliser l'utilitaire httxt2dbm fourni avec le + serveur HTTP Apache, car il utilise la bibliothèque DBM appropriée, + à savoir celle qui a été utilisée lors de la compilation de httpd.

    + +

    Pour créer un fichier dbm, créez tout d'abord un fichier de + correspondances au format texte comme décrit dans la section txt. Traitez ensuite ce fichier avec + httxt2dbm :

    + +

    +$ httxt2dbm -i fichier-map.txt -o fichier-map.map +

    + +

    Vous pouvez alors faire référence au fichier obtenu dans votre +directive RewriteMap :

    +
    RewriteMap mapname "dbm:/etc/apache/mapfile.map"
    + + +
    +

    Notez qu'avec certains types dbm, plusieurs fichiers possédant le +même nom de base sont créés. Par exemple, vous pouvez obtenir deux +fichiers nommés fichier-map.map.dir et +fichier-map.map.pag. Ceci est tout à fait normal, et vous +ne devez utiliser que le nom de base fichier-map.map dans votre +directive RewriteMap.

    +
    + +

    Mise en cache des recherches

    +

    + Les clés de recherche sont mises en cache par httpd jusqu'à ce que + le mtime (date de modification) du fichier de + correspondances soit modifié, ou que le serveur httpd soit + redémarré, ce qui améliore les performances pour les tables de + correspondances consultées par de nombreuses requêtes. +

    +
    + +
    top
    +
    +

    prg: Programme de réécriture externe

    + +

    Lorque le type-map prg est spécifié, la source est + un chemin du système de fichiers vers un programme exécutable + destiné à effectuer la mise en correspondance. Il peut s'agir d'un + fichier binaire compilé, ou d'un programme en langage interprété + comme Perl ou Python.

    + +

    Ce programme est lancé une fois au démarrage du serveur HTTP + Apache, puis communique avec le moteur de réécriture via + STDIN et STDOUT. En d'autres termes, pour + chaque recherche de correspondance, il reçoit un argument via + STDIN, et doit renvoyer en guise de réponse une chaîne + terminée par un caractère nouvelle-ligne sur STDOUT. Si + la recherche de correspondance est infructueuse, le programme doit + l'indiquer en retournant la chaîne de quatre caractères + "NULL".

    + +

    Les programmes de réécriture externes ne sont pas lancés s'il + n'ont pas été définis dans un contexte où la directive RewriteEngine est définie à + on.

    + +

    Par défaut, les programmes de réécriture externes s'exécutent sous + l'utilisateur/groupe qui a démarré httpd. Pour en changer, il est possible + sur les systèmes de style Unix de spécifier un autre couple + utilisateur/groupe via le troisième argument de la directive RewriteMap, et ceci au format + utilisateur:groupe.

    + +

    Cette fonctionnalité utilise le mutex rewrite-map + nécessaire à la fiabilité des communications avec le programme. Le + mécanisme de mutex et le fichier verrou peuvent être définis via la + directive Mutex.

    + +

    Voici un exemple simple qui remplace tous les tirets par des + caractères de soulignement dans l'URI de la requête.

    + +

    Configuration de la réécriture

    + 
    RewriteMap d2u "prg:/www/bin/dash2under.pl" apache:apache
+RewriteRule "-" "${d2u:%{REQUEST_URI}}"
    + + +

    dash2under.pl

    + 
        #!/usr/bin/perl
+    $| = 1; # Turn off I/O buffering
+    while (<STDIN>) {
+        s/-/_/g; # Remplace tous les tirets par des caractères de soulignement
+        print $_;
+    }
    + + +

    Mises en garde !

    +
      +
    • Votre programme doit être le plus +simple possible. Si le programme se bloque, httpd va attendre +indéfiniment une réponse de sa part, et par conséquent ne répondra plus +aux requêtes.
      • +
    • Assurez-vous de bien désactiver la mise en tampon dans votre +programme. En Perl, ceci est effectué à la seconde ligne du script de +l'exemple - $| = 1; - La syntaxe sera bien entendu +différente dans +d'autres langages. Si les entrées/sorties sont mises en tampon, httpd va +attendre une sortie, et va par conséquent se bloquer.
      • +
    • Rappelez-vous qu'il n'existe qu'une copie du programme lancé au +démarrage du serveur, et que toutes les requêtes vont devoir passer par +ce goulot d'étranglement. Ceci peut provoquer des ralentissements +significatifs si de nombreuses requêtes doivent être traitées, ou si le +script lui-même est très lent.
      • +
    +
    + +
    top
    +
    +

    dbd ou fastdbd: requête SQL

    + + +

    Lorsque le type-map dbd ou fastdbd est + spécifié, la source est une requête SQL SELECT qui reçoit un + argument et renvoie une seule valeur.

    + +

    Pour que cette requête puisse être exécutée, + mod_dbd doit être configuré pour attaquer la base + de données concernée.

    + +

    Ce type-map existe sous deux formes. Avec le type-map + dbd, la requête est exécutée à chaque demande, tandis + qu'avec le type-map fastdbd, les recherches dans la + base de données sont mises en cache en interne. fastdbd + est donc plus efficace et donc plus rapide ; par contre, il ne + tiendra pas compte des modifications apportées à la base de données + jusqu'à ce que le serveur soit redémarré.

    + +

    Si une requête renvoie plusieurs enregistrements, un de ceux-ci + sera sélectionné aléatoirement.

    + +

    Exemple

    RewriteMap ma-requete "fastdbd:SELECT destination FROM rewrite WHERE source = %s"
    +
    + +

    Note

    +

    Le nom de la requête est transmis au pilote de base de données en tant + que label pour une requête SQL préparée, et doit donc respecter toutes les + règles imposées par votre base de données (comme la sensibilité à la casse).

    + +
    top
    +
    +

    Résumé

    + + +

    La directive RewriteMap peut apparaître + plusieurs fois. Utilisez une directive + RewriteMap pour chaque fonction de mise en + correspondance pour déclarer son fichier de correspondances.

    + +

    Bien que l'on ne puisse pas déclarer de fonction + de mise en correspondance dans un contexte de répertoire (fichier + .htaccess ou section <Directory>), il est + possible d'utiliser cette fonction dans un tel contexte.

    + +
    +
    +

    Langues Disponibles:  en  | + fr 

    +
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    +
    + \ No newline at end of file diff --git a/docs/manual/rewrite/tech.html.en b/docs/manual/rewrite/tech.html.en index cc6959acb6..5572e6627f 100644 --- a/docs/manual/rewrite/tech.html.en +++ b/docs/manual/rewrite/tech.html.en @@ -24,7 +24,7 @@ Apache > HTTP Server > Documentation > Version 2.5 > Rewrite

    Apache mod_rewrite Technical Details

    Available Languages:  en  | - fr 

    + fr 

    This document discusses some of the technical details of mod_rewrite @@ -177,7 +177,7 @@ and URL matching.

    Available Languages:  en  | - fr 

    + fr 

    top

    Comments

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    - - -
    -

    Modules | Directives | FAQ | Glossaire | Plan du site

    -

    Serveur HTTP Apache Version 2.5

    -
    -
    <-
    -

    Détails techniques sur le module Apache mod_rewrite

    -
    -

    Langues Disponibles:  en  | - fr 

    -
    - -

    Ce document passe en revue certains détails techniques à propos du -module mod_rewrite et de la mise en correspondance des URLs

    -
    - -
    top
    -
    -

    Phases de l'API

    - -

    Le traitement des requêtes par le serveur HTTP Apache se - déroule en plusieurs phases. Au cours de chaque phase, un ou - plusieurs modules peuvent être appelés pour traiter la partie - concernée du cycle de vie de la requête. Les différentes phases - peuvent consister en traduction d'URL en nom de fichier, - authentification, autorisation, gestion de contenu ou journalisation (la - liste n'est pas exhaustive).

    - -

    mod_rewrite agit dans deux de ces phases (ou accroches - hooks - - comme on les nomme souvent) pour la réécriture des URLs.

    - -

    Tout d'abord, il utilise le hook traduction URL vers nom de - fichier qui intervient après la lecture de la requête HTTP, mais - avant le processus d'autorisation. Ensuite, il utilise le hook - Fixup, qui intervient après les phases d'autorisation, après la - lecture des fichiers de configuration de niveau répertoire (fichiers - .htaccess), mais avant l'appel du gestionnaire de - contenu.

    - -

    Lorsqu'une requête arrive et une fois le serveur - correspondant ou le serveur virtuel déterminé, le moteur de - réécriture commence à traiter toute directive apparaissant dans la - configuration de niveau serveur (autrement dit dans le - fichier de configuration principal du serveur et les sections - <Virtualhost>). - Tout ce processus s'exécute au cours de la phase de traduction URL - vers nom de fichier.

    - -

    Quelques étapes plus loin, une fois les répertoires de données - finaux trouvés, les directives de configuration de niveau répertoire - (fichiers .htaccess et sections <Directory>) sont appliquées. Ce processus - s'exécute au cours de la phase Fixup.

    - -

    Dans tous ces cas, mod_rewrite réécrit le - REQUEST_URI soit vers une nouvelle URL, soit vers un - nom de fichier.

    - -

    Dans un contexte de niveau répertoire (autrement dit dans les - fichiers .htaccess et les sections - Directory), les règles de réécriture s'appliquent après - la traduction de l'URL en nom de fichier. C'est pourquoi le chemin - URL auquel mod_rewrite compare initialement les directives - RewriteRule est le - chemin complet vers le nom de fichier traduit amputé de la partie - répertoires (y compris le dernier slash).

    - -

    Un exemple : si les règles se trouvent dans - /var/www/foo/.htaccess et si une requête pour /foo/bar/baz est - traité, une expression comme ^bar/baz$ correspondra.

    - -

    Si une substitution intervient dans un contexte de répertoire, - une nouvelle sous-requête interne est générée avec la nouvelle URL, - ce qui relance le traitement des phases de la requête. Si la - substitution est un chemin relatif, la directive RewriteBase détermine le chemin URL - devant préfixer cette substitution. Dans un contexte de répertoire, - il faut s'assurer de créer des règles qui - n'effectueront pas de substitution au - cours d'une passe ultérieure du processus de réécriture au niveau - répertoire afin d'éviter les bouclages . Voir Bouclage dans le - processus de réécriture pour une discussion plus détaillée à - propos de ce problème.

    - -

    En conséquence de cette manipulation de l'URL , vous devrez - pensez à confectionner différemment vos règles de réécriture dans un - contexte de niveau répertoire. En particulier, rappelez-vous que le - chemin de répertoire sera absent de l'URL que vos règles de - réécriture verront. Voici quelques exemples qui permettront de - clarifier les choses :

    - - - - - - - - - - - - - - - - - - - - - - - -
    Position de la règleRègle
    Section VirtualHostRewriteRule "^/images/(.+)\.jpg" "/images/$1.gif"
    Fichier .htaccess à la racine des documentsRewriteRule "^images/(.+)\.jpg" "images/$1.gif"
    Fichier .htaccess dans le répertoire imagesRewriteRule "^(.+)\.jpg" "$1.gif"
    - -

    Pour une étude plus approfondie de la manière dont mod_rewrite - manipule les URLs dans les différents contextes, vous pouvez - consulter les entrées du - journal générées au cours du processus de réécriture.

    - -
    top
    -
    -

    Traitement du jeu de règles

    - -

    Maintenant, quand mod_rewrite se lance dans ces deux phases de - l'API, il lit le jeu de règles configurées depuis la structure - contenant sa configuration (qui a été elle-même créée soit au - démarrage d'Apache pour le contexte du serveur, soit lors du - parcours des répertoires par le noyau d'Apache pour le contexte de - répertoire). Puis le moteur de réécriture est démarré avec le jeu - de règles contenu (une ou plusieurs règles associées à leurs - conditions). En lui-même, le mode opératoire du moteur de - réécriture d'URLs est exactement le même dans les deux contextes - de configuration. Seul le traitement du résultat final diffère.

    - -

    L'ordre dans lequel les règles sont définies est important car - le moteur de réécriture les traite selon une chronologie - particulière (et pas très évidente). Le principe est le suivant : - le moteur de réécriture traite les règles (les directives RewriteRule) les unes - à la suite des autres, et lorsqu'une règle s'applique, il parcourt - les éventuelles conditions (directives - RewriteConddirectives) associées. - Pour des raisons historiques, les - conditions précèdent les règles, si bien que le déroulement du - contrôle est un peu compliqué. Voir la figure 1 pour plus de - détails.

    -

    - Flux des comparaisons des directives RewriteRule et RewriteCond
    - Figure 1:Déroulement du contrôle à travers le jeu de - règles de réécriture -

    -

    L'URL est tout d'abord comparée au - Modèle de chaque règle. Lorsqu'une règle ne s'applique - pas, mod_rewrite stoppe immédiatement le traitement de cette règle - et passe à la règle suivante. Si l'URL correspond au - Modèle, mod_rewrite recherche la présence de conditions - correspondantes (les directives Rewritecond apparaissant dans la - configuration juste - avant les règles de réécriture). S'il n'y en a pas, mod_rewrite remplace - l'URL par une chaîne élaborée à partir de la chaîne de - Substitution, puis passe à la règle suivante. Si des - conditions sont présentes, mod_rewrite lance un bouclage - secondaire afin de les traiter selon l'ordre dans lequel elles - sont définies. La logique de traitement des conditions est - différente : on ne compare pas l'URL à un modèle. Une chaîne de - test TestString est tout d'abord élaborée en développant - des variables, des références arrières, des recherches dans des - tables de correspondances, etc..., puis cette chaîne de test est - comparée au modèle de condition CondPattern. Si le modèle - ne correspond pas, les autres conditions du jeu ne sont pas - examinées et la règle correspondante ne s'applique pas. Si le - modèle correspond, la condition suivante est examinée et ainsi de - suite jusqu'à la dernière condition. Si toutes les conditions sont - satisfaites, le traitement de la règle en cours se poursuit avec - le remplacement de l'URL par la chaîne de Substitution.

    - -
    -
    -

    Langues Disponibles:  en  | - fr 

    -
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    -
    - \ No newline at end of file diff --git a/docs/manual/rewrite/tech.html.fr.utf8 b/docs/manual/rewrite/tech.html.fr.utf8 new file mode 100644 index 0000000000..4d9b18eafe --- /dev/null +++ b/docs/manual/rewrite/tech.html.fr.utf8 @@ -0,0 +1,223 @@ + + + + + +Détails techniques sur le module Apache mod_rewrite - Serveur HTTP Apache Version 2.5 + + + + + + +
    +

    Modules | Directives | FAQ | Glossaire | Plan du site

    +

    Serveur HTTP Apache Version 2.5

    +
    +
    <-
    +

    Détails techniques sur le module Apache mod_rewrite

    +
    +

    Langues Disponibles:  en  | + fr 

    +
    + +

    Ce document passe en revue certains détails techniques à propos du +module mod_rewrite et de la mise en correspondance des URLs

    +
    + +
    top
    +
    +

    Phases de l'API

    + +

    Le traitement des requêtes par le serveur HTTP Apache se + déroule en plusieurs phases. Au cours de chaque phase, un ou + plusieurs modules peuvent être appelés pour traiter la partie + concernée du cycle de vie de la requête. Les différentes phases + peuvent consister en traduction d'URL en nom de fichier, + authentification, autorisation, gestion de contenu ou journalisation (la + liste n'est pas exhaustive).

    + +

    mod_rewrite agit dans deux de ces phases (ou accroches - hooks - + comme on les nomme souvent) pour la réécriture des URLs.

    + +

    Tout d'abord, il utilise le hook traduction URL vers nom de + fichier qui intervient après la lecture de la requête HTTP, mais + avant le processus d'autorisation. Ensuite, il utilise le hook + Fixup, qui intervient après les phases d'autorisation, après la + lecture des fichiers de configuration de niveau répertoire (fichiers + .htaccess), mais avant l'appel du gestionnaire de + contenu.

    + +

    Lorsqu'une requête arrive et une fois le serveur + correspondant ou le serveur virtuel déterminé, le moteur de + réécriture commence à traiter toute directive apparaissant dans la + configuration de niveau serveur (autrement dit dans le + fichier de configuration principal du serveur et les sections + <Virtualhost>). + Tout ce processus s'exécute au cours de la phase de traduction URL + vers nom de fichier.

    + +

    Quelques étapes plus loin, une fois les répertoires de données + finaux trouvés, les directives de configuration de niveau répertoire + (fichiers .htaccess et sections <Directory>) sont appliquées. Ce processus + s'exécute au cours de la phase Fixup.

    + +

    Dans tous ces cas, mod_rewrite réécrit le + REQUEST_URI soit vers une nouvelle URL, soit vers un + nom de fichier.

    + +

    Dans un contexte de niveau répertoire (autrement dit dans les + fichiers .htaccess et les sections + Directory), les règles de réécriture s'appliquent après + la traduction de l'URL en nom de fichier. C'est pourquoi le chemin + URL auquel mod_rewrite compare initialement les directives + RewriteRule est le + chemin complet vers le nom de fichier traduit amputé de la partie + répertoires (y compris le dernier slash).

    + +

    Un exemple : si les règles se trouvent dans + /var/www/foo/.htaccess et si une requête pour /foo/bar/baz est + traité, une expression comme ^bar/baz$ correspondra.

    + +

    Si une substitution intervient dans un contexte de répertoire, + une nouvelle sous-requête interne est générée avec la nouvelle URL, + ce qui relance le traitement des phases de la requête. Si la + substitution est un chemin relatif, la directive RewriteBase détermine le chemin URL + devant préfixer cette substitution. Dans un contexte de répertoire, + il faut s'assurer de créer des règles qui + n'effectueront pas de substitution au + cours d'une passe ultérieure du processus de réécriture au niveau + répertoire afin d'éviter les bouclages . Voir Bouclage dans le + processus de réécriture pour une discussion plus détaillée à + propos de ce problème.

    + +

    En conséquence de cette manipulation de l'URL , vous devrez + pensez à confectionner différemment vos règles de réécriture dans un + contexte de niveau répertoire. En particulier, rappelez-vous que le + chemin de répertoire sera absent de l'URL que vos règles de + réécriture verront. Voici quelques exemples qui permettront de + clarifier les choses :

    + + + + + + + + + + + + + + + + + + + + + + + +
    Position de la règleRègle
    Section VirtualHostRewriteRule "^/images/(.+)\.jpg" "/images/$1.gif"
    Fichier .htaccess à la racine des documentsRewriteRule "^images/(.+)\.jpg" "images/$1.gif"
    Fichier .htaccess dans le répertoire imagesRewriteRule "^(.+)\.jpg" "$1.gif"
    + +

    Pour une étude plus approfondie de la manière dont mod_rewrite + manipule les URLs dans les différents contextes, vous pouvez + consulter les entrées du + journal générées au cours du processus de réécriture.

    + +
    top
    +
    +

    Traitement du jeu de règles

    + +

    Maintenant, quand mod_rewrite se lance dans ces deux phases de + l'API, il lit le jeu de règles configurées depuis la structure + contenant sa configuration (qui a été elle-même créée soit au + démarrage d'Apache pour le contexte du serveur, soit lors du + parcours des répertoires par le noyau d'Apache pour le contexte de + répertoire). Puis le moteur de réécriture est démarré avec le jeu + de règles contenu (une ou plusieurs règles associées à leurs + conditions). En lui-même, le mode opératoire du moteur de + réécriture d'URLs est exactement le même dans les deux contextes + de configuration. Seul le traitement du résultat final diffère.

    + +

    L'ordre dans lequel les règles sont définies est important car + le moteur de réécriture les traite selon une chronologie + particulière (et pas très évidente). Le principe est le suivant : + le moteur de réécriture traite les règles (les directives RewriteRule) les unes + à la suite des autres, et lorsqu'une règle s'applique, il parcourt + les éventuelles conditions (directives + RewriteConddirectives) associées. + Pour des raisons historiques, les + conditions précèdent les règles, si bien que le déroulement du + contrôle est un peu compliqué. Voir la figure 1 pour plus de + détails.

    +

    + Flux des comparaisons des directives RewriteRule et RewriteCond
    + Figure 1:Déroulement du contrôle à travers le jeu de + règles de réécriture +

    +

    L'URL est tout d'abord comparée au + Modèle de chaque règle. Lorsqu'une règle ne s'applique + pas, mod_rewrite stoppe immédiatement le traitement de cette règle + et passe à la règle suivante. Si l'URL correspond au + Modèle, mod_rewrite recherche la présence de conditions + correspondantes (les directives Rewritecond apparaissant dans la + configuration juste + avant les règles de réécriture). S'il n'y en a pas, mod_rewrite remplace + l'URL par une chaîne élaborée à partir de la chaîne de + Substitution, puis passe à la règle suivante. Si des + conditions sont présentes, mod_rewrite lance un bouclage + secondaire afin de les traiter selon l'ordre dans lequel elles + sont définies. La logique de traitement des conditions est + différente : on ne compare pas l'URL à un modèle. Une chaîne de + test TestString est tout d'abord élaborée en développant + des variables, des références arrières, des recherches dans des + tables de correspondances, etc..., puis cette chaîne de test est + comparée au modèle de condition CondPattern. Si le modèle + ne correspond pas, les autres conditions du jeu ne sont pas + examinées et la règle correspondante ne s'applique pas. Si le + modèle correspond, la condition suivante est examinée et ainsi de + suite jusqu'à la dernière condition. Si toutes les conditions sont + satisfaites, le traitement de la règle en cours se poursuit avec + le remplacement de l'URL par la chaîne de Substitution.

    + +
    +
    +

    Langues Disponibles:  en  | + fr 

    +
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    +
    + \ No newline at end of file diff --git a/docs/manual/rewrite/vhosts.html.en b/docs/manual/rewrite/vhosts.html.en index ef17b45230..0bcfb661ac 100644 --- a/docs/manual/rewrite/vhosts.html.en +++ b/docs/manual/rewrite/vhosts.html.en @@ -24,7 +24,7 @@ Apache > HTTP Server > Documentation > Version 2.5 > Rewrite

    Dynamic mass virtual hosts with mod_rewrite

    Available Languages:  en  | - fr 

    + fr 

    @@ -206,7 +206,7 @@ RewriteRule "^/cgi-bin/(.*)$" "%1/cgi-bin/$1" [H=cgi-scrip

    Available Languages:  en  | - fr 

    + fr 

    top

    Comments

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    - - -
    -

    Modules | Directives | FAQ | Glossaire | Plan du site

    -

    Serveur HTTP Apache Version 2.5

    -
    -
    <-
    -

    Hébergement virtuel de masse avec mod_rewrite

    -
    -

    Langues Disponibles:  en  | - fr 

    -
    - - -

    Ce document est un complément à la documentation de référence du module -mod_rewrite. Il décrit comment créer des serveurs -virtuels dynamiquement configurés en utilisant -mod_rewrite.

    - -
    L'utilisation de mod_rewrite n'est en général pas la -meilleure méthode pour configurer des serveurs virtuels. Vous devez dans un -premier temps tenter de résoudre votre problème via ces d'autres méthodes avant d'avoir recours à -mod_rewrite. Voir aussi le document Comment éviter -il'utilisation de mod_rewrite.
    - - -
    - -
    top
    -
    -

    Serveurs virtuels pour des noms d'hôtes arbitraires

    - - - -
    -
    Description :
    - -
    -

    Nous voulons créer automatiquement un serveur virtuel pour tout - nom d'hôte qui peut être résolu dans notre domaine, sans avoir à - créer de nouvelle section VirtualHost.

    - -

    Dans cet exemple, nous supposons que nous utilisons le nom d'hôte - SITE.example.com pour chaque - utilisateur, et que nous servons leur contenu depuis - /home/SITE/www. Nous souhaitons cependant que - www.example.com n'apparaisse pas dans cette mise en correspondance.

    -
    - -
    Solution :
    - -
    - -
    RewriteEngine on
-
-RewriteMap    lowercase int:tolower
-
-RewriteCond   %{HTTP_HOST} !^www\.
-RewriteCond   ${lowercase:%{HTTP_HOST}}   ^([^.]+)\.example\.com$
-RewriteRule   ^(.*)    /home/%1/www$1
    -
    - -
    Discussion
    -
    - -
    Vous devez vérifier le bon fonctionnement de la - résolution DNS - Apache ne gère pas la résolution de nom. Vous - devrez créer soit des enregistrements CNAME pour chaque nom d'hôte, - soit un enregistrement DNS avec caractères génériques. La création - des enregistrements DNS est en dehors du sujet de ce document.
    - -

    La directive RewriteMap interne tolower permet de -s'assurer que les noms d'hôtes utilisés seront tous en minuscules, de -façon à éviter toute ambiguité dans la structure des répertoires qui -doit être créée.

    - -

    Les contenus des parenthèses utilisées dans une directive RewriteCond sont enregistrés dans les -références arrières %1, %2, etc..., alors que -les contenus des parenthèses utilisées dans une directive RewriteRule le sont dans les -références arrières $1, $2, etc...

    - -

    La première directive RewriteCond vérifie si le nom d'hôte -commence par www. et si c'est le cas, la réécriture est annulée.

    - -

    -Comme c'est le cas pour de nombreuses techniques discutées dans ce -document, mod_rewrite n'est vraiment pas la meilleure méthode pour -accomplir cette tâche. Vous devez plutôt vous tourner vers -mod_vhost_alias, car ce dernier sera bien plus à même -de gérer tout ce qui est au delà du domaine des fichiers statiques, -comme les contenus dynamiques et la résolution des alias. -

    -
    -
    - -
    top
    -
    -

    Configuration dynamique de serveurs -virtuels via mod_rewrite

    - -

    Cet extrait du fichier httpd.conf permet d'obtenir - le même résultat que le premier exemple. - La première moitié est très similaire à la partie correspondante - ci-dessus, excepté quelques modifications requises à des fins de - compatibilité ascendante et pour faire en sorte que la partie - mod_rewrite fonctionne correctement ; la seconde moitié - configure mod_rewrite pour effectuer le travail - proprement dit.

    - -

    Comme mod_rewrite s'exécute avant tout autre module - de traduction d'URI (comme mod_alias), il faut lui - ordonner explicitement d'ignorer toute URL susceptible d'être - traitée par ces autres modules. Et comme ces règles auraient sinon - court-circuité toute directive ScriptAlias, nous devons - faire en sorte que mod_rewrite déclare explicitement - ces correspondances.

    - -
    # extrait le nom de serveur de l'en-tête Host:
-UseCanonicalName Off
-
-# journaux dissociables
-LogFormat "%{Host}i %h %l %u %t \"%r\" %s %b" vcommon
-CustomLog "logs/access_log" vcommon
-
-<Directory "/www/hosts">
-    # ExecCGI est nécessaire ici car on ne peut pas forcer l'exécution
-    # des CGI à la manière de ScriptAlias
-    Options FollowSymLinks ExecCGI
-</Directory>
-
-RewriteEngine On
-
-# un nom de serveur extrait d'un en-tête Host: peut être dans n'importe
-# quelle casse
-RewriteMap  lowercase  "int:tolower"
-
-## on s'occupe tout d'abord des documents normaux :
    
-# permet à Alias /icons/ de fonctionner - répéter pour les autres
-RewriteCond  "%{REQUEST_URI}"  "!^/icons/"
-# permet aux CGIs de fonctionner
-RewriteCond  "%{REQUEST_URI}"  "!^/cgi-bin/"
-# le coeur du traitement
-RewriteRule  "^/(.*)$"  "/www/hosts/${lowercase:%{SERVER_NAME}}/docs/$1"
-
-## on s'occupe maintenant des CGIs - on doit forcer l'utilisation d'un
-# gestionnaire
-RewriteCond  "%{REQUEST_URI}"  "^/cgi-bin/"
-RewriteRule  "^/(.*)$" "/www/hosts/${lowercase:%{SERVER_NAME}}/cgi-bin/$1"  [H=cgi-script]
    - - -
    top
    -
    -

    Utilisation d'un fichier de configuration -du serveur virtuel séparé

    - -

    Cette construction utilise des fonctionnalités plus avancées de - mod_rewrite pour effectuer la traduction depuis le - serveur virtuel vers la racine des documents, à partir d'un fichier - de configuration séparé. Elle est plus souple mais nécessite une - configuration plus compliquée.

    - -

    Le fichier vhost.map devrait ressembler à ceci :

    - -

    -www.client-1.example.com /www/clients/1
    -www.client-2.example.com /www/clients/2
    -# ...
    -www.client-N.example.com /www/clients/N
    -

    - -

    On doit ajouter à httpd.conf :

    - -
    RewriteEngine on
-
-RewriteMap   lowercase  "int:tolower"
-
-# définit le fichier de correspondances
-RewriteMap   vhost      "txt:/www/conf/vhost.map"
-
-# on s'occupe des alias comme ci-dessus
-RewriteCond  "%{REQUEST_URI}"               "!^/icons/"
-RewriteCond  "%{REQUEST_URI}"               "!^/cgi-bin/"
-RewriteCond  "${lowercase:%{SERVER_NAME}}"  "^(.+)$"
-# on effectue ici la remise en correspondance à base de fichier
-RewriteCond  "${vhost:%1}"                  "^(/.*)$"
-RewriteRule  "^/(.*)$"                      "%1/docs/$1"
-
-RewriteCond  "%{REQUEST_URI}"               "^/cgi-bin/"
-RewriteCond  "${lowercase:%{SERVER_NAME}}"  "^(.+)$"
-RewriteCond  "${vhost:%1}"                  "^(/.*)$"
-RewriteRule  "^/cgi-bin/(.*)$"              "%1/cgi-bin/$1" [H=cgi-script]
    - - -
    -
    -

    Langues Disponibles:  en  | - fr 

    -
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    -
    - \ No newline at end of file diff --git a/docs/manual/rewrite/vhosts.html.fr.utf8 b/docs/manual/rewrite/vhosts.html.fr.utf8 new file mode 100644 index 0000000000..4d4dfc4cd3 --- /dev/null +++ b/docs/manual/rewrite/vhosts.html.fr.utf8 @@ -0,0 +1,244 @@ + + + + + +Hébergement virtuel de masse avec mod_rewrite - Serveur HTTP Apache Version 2.5 + + + + + + +
    +

    Modules | Directives | FAQ | Glossaire | Plan du site

    +

    Serveur HTTP Apache Version 2.5

    +
    +
    <-
    +

    Hébergement virtuel de masse avec mod_rewrite

    +
    +

    Langues Disponibles:  en  | + fr 

    +
    + + +

    Ce document est un complément à la documentation de référence du module +mod_rewrite. Il décrit comment créer des serveurs +virtuels dynamiquement configurés en utilisant +mod_rewrite.

    + +
    L'utilisation de mod_rewrite n'est en général pas la +meilleure méthode pour configurer des serveurs virtuels. Vous devez dans un +premier temps tenter de résoudre votre problème via ces d'autres méthodes avant d'avoir recours à +mod_rewrite. Voir aussi le document Comment éviter +il'utilisation de mod_rewrite.
    + + +
    + +
    top
    +
    +

    Serveurs virtuels pour des noms d'hôtes arbitraires

    + + + +
    +
    Description :
    + +
    +

    Nous voulons créer automatiquement un serveur virtuel pour tout + nom d'hôte qui peut être résolu dans notre domaine, sans avoir à + créer de nouvelle section VirtualHost.

    + +

    Dans cet exemple, nous supposons que nous utilisons le nom d'hôte + SITE.example.com pour chaque + utilisateur, et que nous servons leur contenu depuis + /home/SITE/www. Nous souhaitons cependant que + www.example.com n'apparaisse pas dans cette mise en correspondance.

    +
    + +
    Solution :
    + +
    + +
    RewriteEngine on
+
+RewriteMap    lowercase int:tolower
+
+RewriteCond   %{HTTP_HOST} !^www\.
+RewriteCond   ${lowercase:%{HTTP_HOST}}   ^([^.]+)\.example\.com$
+RewriteRule   ^(.*)    /home/%1/www$1
    +
    + +
    Discussion
    +
    + +
    Vous devez vérifier le bon fonctionnement de la + résolution DNS - Apache ne gère pas la résolution de nom. Vous + devrez créer soit des enregistrements CNAME pour chaque nom d'hôte, + soit un enregistrement DNS avec caractères génériques. La création + des enregistrements DNS est en dehors du sujet de ce document.
    + +

    La directive RewriteMap interne tolower permet de +s'assurer que les noms d'hôtes utilisés seront tous en minuscules, de +façon à éviter toute ambiguité dans la structure des répertoires qui +doit être créée.

    + +

    Les contenus des parenthèses utilisées dans une directive RewriteCond sont enregistrés dans les +références arrières %1, %2, etc..., alors que +les contenus des parenthèses utilisées dans une directive RewriteRule le sont dans les +références arrières $1, $2, etc...

    + +

    La première directive RewriteCond vérifie si le nom d'hôte +commence par www. et si c'est le cas, la réécriture est annulée.

    + +

    +Comme c'est le cas pour de nombreuses techniques discutées dans ce +document, mod_rewrite n'est vraiment pas la meilleure méthode pour +accomplir cette tâche. Vous devez plutôt vous tourner vers +mod_vhost_alias, car ce dernier sera bien plus à même +de gérer tout ce qui est au delà du domaine des fichiers statiques, +comme les contenus dynamiques et la résolution des alias. +

    +
    +
    + +
    top
    +
    +

    Configuration dynamique de serveurs +virtuels via mod_rewrite

    + +

    Cet extrait du fichier httpd.conf permet d'obtenir + le même résultat que le premier exemple. + La première moitié est très similaire à la partie correspondante + ci-dessus, excepté quelques modifications requises à des fins de + compatibilité ascendante et pour faire en sorte que la partie + mod_rewrite fonctionne correctement ; la seconde moitié + configure mod_rewrite pour effectuer le travail + proprement dit.

    + +

    Comme mod_rewrite s'exécute avant tout autre module + de traduction d'URI (comme mod_alias), il faut lui + ordonner explicitement d'ignorer toute URL susceptible d'être + traitée par ces autres modules. Et comme ces règles auraient sinon + court-circuité toute directive ScriptAlias, nous devons + faire en sorte que mod_rewrite déclare explicitement + ces correspondances.

    + +
    # extrait le nom de serveur de l'en-tête Host:
+UseCanonicalName Off
+
+# journaux dissociables
+LogFormat "%{Host}i %h %l %u %t \"%r\" %s %b" vcommon
+CustomLog "logs/access_log" vcommon
+
+<Directory "/www/hosts">
+    # ExecCGI est nécessaire ici car on ne peut pas forcer l'exécution
+    # des CGI à la manière de ScriptAlias
+    Options FollowSymLinks ExecCGI
+</Directory>
+
+RewriteEngine On
+
+# un nom de serveur extrait d'un en-tête Host: peut être dans n'importe
+# quelle casse
+RewriteMap  lowercase  "int:tolower"
+
+## on s'occupe tout d'abord des documents normaux :
    
+# permet à Alias /icons/ de fonctionner - répéter pour les autres
+RewriteCond  "%{REQUEST_URI}"  "!^/icons/"
+# permet aux CGIs de fonctionner
+RewriteCond  "%{REQUEST_URI}"  "!^/cgi-bin/"
+# le coeur du traitement
+RewriteRule  "^/(.*)$"  "/www/hosts/${lowercase:%{SERVER_NAME}}/docs/$1"
+
+## on s'occupe maintenant des CGIs - on doit forcer l'utilisation d'un
+# gestionnaire
+RewriteCond  "%{REQUEST_URI}"  "^/cgi-bin/"
+RewriteRule  "^/(.*)$" "/www/hosts/${lowercase:%{SERVER_NAME}}/cgi-bin/$1"  [H=cgi-script]
    + + +
    top
    +
    +

    Utilisation d'un fichier de configuration +du serveur virtuel séparé

    + +

    Cette construction utilise des fonctionnalités plus avancées de + mod_rewrite pour effectuer la traduction depuis le + serveur virtuel vers la racine des documents, à partir d'un fichier + de configuration séparé. Elle est plus souple mais nécessite une + configuration plus compliquée.

    + +

    Le fichier vhost.map devrait ressembler à ceci :

    + +

    +www.client-1.example.com /www/clients/1
    +www.client-2.example.com /www/clients/2
    +# ...
    +www.client-N.example.com /www/clients/N
    +

    + +

    On doit ajouter à httpd.conf :

    + +
    RewriteEngine on
+
+RewriteMap   lowercase  "int:tolower"
+
+# définit le fichier de correspondances
+RewriteMap   vhost      "txt:/www/conf/vhost.map"
+
+# on s'occupe des alias comme ci-dessus
+RewriteCond  "%{REQUEST_URI}"               "!^/icons/"
+RewriteCond  "%{REQUEST_URI}"               "!^/cgi-bin/"
+RewriteCond  "${lowercase:%{SERVER_NAME}}"  "^(.+)$"
+# on effectue ici la remise en correspondance à base de fichier
+RewriteCond  "${vhost:%1}"                  "^(/.*)$"
+RewriteRule  "^/(.*)$"                      "%1/docs/$1"
+
+RewriteCond  "%{REQUEST_URI}"               "^/cgi-bin/"
+RewriteCond  "${lowercase:%{SERVER_NAME}}"  "^(.+)$"
+RewriteCond  "${vhost:%1}"                  "^(/.*)$"
+RewriteRule  "^/cgi-bin/(.*)$"              "%1/cgi-bin/$1" [H=cgi-script]
    + + +
    +
    +

    Langues Disponibles:  en  | + fr 

    +
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    +
    + \ No newline at end of file diff --git a/docs/manual/sections.html.en b/docs/manual/sections.html.en index 6241f1864d..db4f2652dc 100644 --- a/docs/manual/sections.html.en +++ b/docs/manual/sections.html.en @@ -24,10 +24,10 @@ Apache > HTTP Server > Documentation > Version 2.5

    Configuration Sections

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

    + tr 

    Directives in the configuration files may apply to the entire server, or they may be restricted to apply only to particular @@ -567,10 +567,10 @@ other words, order of merging is important, so be careful!

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

    + tr 

    top

    Comments

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    - - -
    -

    Modules | Directives | FAQ | Glossaire | Plan du site

    -

    Serveur HTTP Apache Version 2.5

    -
    -
    <-
    -

    Sections de configuration

    -
    -

    Langues Disponibles:  en  | - fr  | - ja  | - ko  | - tr 

    -
    -

    Les directives des fichiers de configuration peuvent s'appliquer -au serveur dans son ensemble, ou seulement à des répertoires, fichiers, hôtes, -ou URLs particuliers. Ce document décrit comment utiliser les conteneurs de -sections de configuration ou les fichiers .htaccess pour -modifier la portée des directives de configuration.

    -
    - -
    top
    -
    -

    Types de conteneurs de sections de -configuration

    - -
    Modules ApparentésDirectives Apparentées
    - -

    Il existe deux grands types de conteneurs. La plupart des conteneurs sont -évalués pour chaque requête. Les directives qu'ils contiennent s'appliquent -seulement aux requêtes qui sont concernées par le conteneur. En revanche, -les conteneurs -<IfDefine>, <IfModule>, et -<IfVersion> sont -évalués seulement au démarrage et au redémarrage du serveur. -Si leurs conditions sont vérifiées au démarrage, les directives qu'ils contiennent -s'appliqueront à toutes les requêtes. Si leurs conditions ne sont pas vérifiées, les -directives qu'ils contiennent seront ignorées.

    - -

    Le conteneur <IfDefine> -contient des directives qui ne seront appliquées que si un paramètre -approprié a été défini dans la ligne de commande de httpd. -Par exemple, -avec la configuration suivante, toutes les requêtes seront redirigées vers -un autre site si le serveur est démarré en utilisant la ligne de commande : -httpd -DClosedForNow:

    - -
    <IfDefine ClosedForNow>
-    Redirect "/" "http://otherserver.example.com/"
-</IfDefine>
    - - -

    Le conteneur <IfModule> -est similaire; les directives qu'il contient ne s'appliqueront que si -un module particulier est disponible au niveau du serveur. -Le module doit être soit compilé statiquement dans le serveur, soit -dynamiquement et dans ce cas, la ligne LoadModule correspondante doit apparaître -plus haut dans le fichier de configuration. Ce conteneur ne doit être -utilisé que dans le cas où votre fichier de configuration doit fonctionner -indépendamment de la présence ou de l'absence de certains modules. -Il ne doit pas contenir de directives que vous souhaitez voir s'appliquer -systématiquement, car vous pouvez perdre ainsi de précieux messages d'erreur -à propos de modules manquants.

    - -

    Dans l'exemple suivant, la directive MimeMagicFile ne s'appliquera que si le -module mod_mime_magic est disponible.

    - -
    <IfModule mod_mime_magic.c>
-    MimeMagicFile "conf/magic"
-</IfModule>
    - - -

    Le conteneur -<IfVersion> -est similaire aux conteneurs <IfDefine> et <IfModule>; les directives qu'il contient ne -s'appliqueront que si une version particulière du serveur s'exécute. Ce -conteneur a été conçu pour une utilisation dans les suites de tests -et les grands réseaux qui doivent prendre en compte différentes versions -et configurations de httpd.

    - -
    <IfVersion >= 2.4>
-    # les directives situées ici ne s'appliquent que si la version 
    
-    # est supérieure ou égale à 2.4.0.
-</IfVersion>
    - - -

    <IfDefine>, -<IfModule>, et -<IfVersion> -peuvent inverser leur test conditionnel en le faisant précéder d'un "!". -De plus, ces sections peuvent être imbriquées afin de définir des restrictions -plus complexes.

    -
    top
    -
    -

    Système de fichiers, -arborescence du site web et expressions booléennes

    - -

    Les conteneurs de sections de configuration les plus couramment utilisés -sont ceux qui modifient la configuration de points particuliers du système de -fichiers ou de l'arborescence du site web. Tout d'abord, il est important de -comprendre la différence entre les deux. Le système de fichiers est une vue -de vos disques tels qu'ils sont perçus par votre système d'exploitation. -Par exemple, avec une installation par défaut, -Apache httpd est situé dans /usr/local/apache2 pour le système de -fichiers UNIX, ou "c:/Program Files/Apache Group/Apache2" pour -le système de fichiers Windows. (Notez que des slashes directs doivent -toujours être utilisés comme séparateur de chemin -dans les fichiers de configuration d'Apache httpd, même sous -Windows.) Quant à -l'arborescence du site web, il s'agit d'une vue de votre site -tel que présenté par le -serveur web et perçue par le client. Ainsi le chemin /dir/ dans -l'arborescence du site web correspond au chemin -/usr/local/apache2/htdocs/dir/ dans le système de fichiers pour -une installation d'Apache httpd par défaut sous UNIX. -En outre, l'arborescence du site web n'a pas besoin de correspondre en permanence au -système de fichiers, car les pages web peuvent être générées dynamiquement -à partir de bases de données ou d'autres emplacements.

    - -

    Conteneurs de système de fichiers

    - -

    Les conteneurs <Directory> -et <Files>, -ainsi que leurs équivalents acceptant les -expressions rationnelles, -appliquent des directives à certaines parties du système de fichiers. -Les directives contenues dans une section <Directory> s'appliquent au répertoire -précisé, ainsi qu'à tous ses sous-répertoires et aux fichiers que ces -derniers contiennent. -Le même effet peut être obtenu en utilisant les fichiers .htaccess. Par exemple, avec la -configuration suivante, l'indexation sera activée pour le répertoire -/var/web/dir1 et tous ses sous-répertoires.

    - -
    <Directory "/var/web/dir1">
-    Options +Indexes
-</Directory>
    - - -

    Les directives contenues dans une section <Files> s'appliquent à tout fichier -avec le nom spécifié, quel que soit le répertoire dans lequel il se trouve. -Ainsi par exemple, les directives de configuration suivantes, si elles sont -placées dans la section principale du fichier de configuration, vont interdire -l'accès à tout fichier nommé private.html quel que soit -l'endroit où il se trouve.

    - -
    <Files "private.html">
-    Require all denied
-</Files>
    - - -

    Pour faire référence à des fichiers qui se trouvent en des points -particuliers du système de fichiers, les sections -<Files> et -<Directory> -peuvent être combinées. Par exemple, la configuration suivante va interdire -l'accès à /var/web/dir1/private.html, -/var/web/dir1/subdir2/private.html, -/var/web/dir1/subdir3/private.html, ainsi que toute instance de -private.html qui se trouve dans l'arborescence -/var/web/dir1/.

    - -
    <Directory "/var/web/dir1">
-    <Files "private.html">
-        Require all denied
-    </Files>
-</Directory>
    - - - -

    Conteneurs de l'arborescence du site web

    - -

    le conteneur <Location> -et son équivalent acceptant les -expressions rationnelles, modifient quant à eux la -configuration de parties de l'arborescence du site web. Par exemple, la -configuration suivante interdit l'accès à toute URL dont la partie chemin -commence par /private. -En particulier, l'interdiction s'appliquera aux requêtes pour : -http://yoursite.example.com/private, -http://yoursite.example.com/private123, et -http://yoursite.example.com/private/dir/file.html ainsi qu'à -toute requête commençant par la chaîne de caractères /private.

    - -
    <LocationMatch "^/private">
-    Require all denied
-</LocationMatch>
    - - -

    Le conteneur <Location> -n'a pas besoin de faire référence à un élément du système de fichiers. -Par exemple, l'exemple suivant montre comment faire référence à une URL -particulière vers un gestionnaire interne du serveur HTTP Apache fourni par le module -mod_status. -Il n'est pas nécessaire de trouver un fichier nommé server-status -dans le système de fichiers.

    - -
    <Location "/server-status">
-    SetHandler server-status
-</Location>
    - - - -

    Espace web imbriqué

    -

    Pour contrôler deux URLs imbriquées, on doit tenir compte de l'ordre -dans lequel certaines sections ou directives sont évaluées. Pour -<Location>, on doit -avoir :

    -
    <Location "/foo">
-</Location>
-<Location "/foo/bar">
-</Location>
    - -

    Les directives <Alias>, quant à elles, sont évaluées vice-versa :

    -
    Alias "/foo/bar" "/srv/www/uncommon/bar"
-Alias "/foo" "/srv/www/common/foo"
    - -

    Ceci est aussi vrai pour les directives ProxyPass :

    -
    ProxyPass "/special-area" "http://special.example.com" smax=5 max=10
-ProxyPass "/" "balancer://mycluster/" stickysession=JSESSIONID|jsessionid nofailover=On
    - - - - -

    Caractères de remplacement -et expressions rationnelles

    - -

    Les conteneurs -<Directory>, -<Files>, et -<Location> -peuvent utiliser des caractères de remplacement de style shell comme dans -la fonction fnmatch de la bibliothèque C standard. -Le caractère "*" -correspond à toute séquence de caractères, "?" à un caractère seul, -et "[seq]" à tout caractère contenu dans seq. -Le caractère "/" -ne peut pas faire l'objet d'un remplacement; -il doit être spécifié explicitement.

    - -

    Si une définition des critères de correspondance -encore plus souple est nécessaire, chaque conteneur -possède son équivalent acceptant les expressions rationnelles : <DirectoryMatch>, <FilesMatch>, et <LocationMatch> acceptent les -expressions rationnelles compatibles Perl -pour définir les critères de correspondance. Mais voyez plus loin la section -à propos de la combinaison des sections de configuration -pour comprendre comment l'utilisation de -conteneurs avec des expressions rationnelles va modifier la manière -dont les directives sont appliquées.

    - -

    Un conteneur qui modifie la configuration de tous les -répertoires utilisateurs à l'aide de caractères de remplacement -mais sans utiliser -les expressions rationnelles pourrait ressembler à ceci :

    - -
    <Directory "/home/*/public_html">
-    Options Indexes
-</Directory>
    - - -

    Avec les conteneurs utilisant les expressions rationnelles, -on peut interdire l'accès à de nombreux types de fichiers d'images -simultanément :

    -
    +<FilesMatch "\.(?i:gif|jpe?g|png)$">
-    Require all denied
-</FilesMatch>
    - - -

    Les expressions rationnelles contenant des groupes nommés et -des références arrières sont ajoutées à l'environnement avec -leur nom en majuscules. Ceci permet de référencer des éléments de -chemins de fichiers et d'URLs depuis une expression et au sein de modules comme -mod_rewrite.

    - -
    <DirectoryMatch "^/var/www/combined/(?<SITENAME>[^/]+)">
-    require ldap-group "cn=%{env:MATCH_SITENAME},ou=combined,o=Example"
-</DirectoryMatch>
    - - - - -

    Expressions booléennes

    -

    La directive <If> -permet de modifier la configuration en fonction d'une condition qui peut -être définie sous la forme d'une expression booléenne. Dans l'exemple -suivant, l'accès est interdit si l'en-tête HTTP Referer ne commence pas -par "http://www.example.com/".

    -
    <If "!(%{HTTP_REFERER} -strmatch 'http://www.example.com/*')">
-    Require all denied
-</If>
    - - - - -

    Que faut-il utiliser et quand ?

    - -

    Choisir entre des conteneurs de système de fichiers et des conteneurs -d'arborescence du site web est vraiment très simple. -Pour appliquer des directives à des objets qui résident dans le système de -fichiers, utilisez toujours un conteneur <Directory> ou <Files>. Pour appliquer des directives à des objets -qui ne résident pas dans le système de fichiers (comme une page web générée -par une base de données), utilisez un conteneur <Location>.

    - -

    Il ne faut jamais utiliser un conteneur <Location> pour restreindre l'accès à des -objets du système de fichiers, car plusieurs localisations de -l'arborescence du site web (URLs) peuvent correspondre à la même localisation -du système de fichier, ce qui peut permettre de contourner vos restrictions. -Par exemple, imaginez la configuration suivante :

    - -
    <Location "/dir/">
-    Require all denied
-</Location>
    - - -

    Elle fonctionne correctement si la requête appelle -http://yoursite.example.com/dir/. Mais que va-t-il se passer si -votre système de fichiers est insensible à la casse ? -Votre restriction va pouvoir être tout simplement contournée en envoyant une -requête sur -http://yoursite.example.com/DIR/. Le conteneur <Directory>, quant à lui, s'appliquera -à tout contenu servi à partir de cette localisation, -sans tenir compte de la manière dont il est appelé. -(Les liens du système de fichiers constituent une exception. -Le même répertoire peut être placé dans plusieurs parties du système de -fichiers en utilisant des liens symboliques. Le conteneur -<Directory> va suivre le -lien symbolique sans modifier le nom du chemin. Par conséquent, pour plus de -sécurité, les liens symboliques doivent être désactivés à l'aide de la -directive -Options appropriée.)

    - -

    Si vous pensez que vous n'êtes pas concerné par ce problème -parceque vous utilisez un système de fichiers sensible à la casse, -gardez à l'esprit qu'il y a de nombreuses autres manières pour faire -correspondre plusieurs localisations de l'arborescence du site web à la même -localisation du système de fichiers. C'est pourquoi vous devez autant que -possible toujours utiliser les conteneurs de système de fichiers. -Il y a cependant une exception à cette règle. Placer des restrictions de -configuration dans un conteneur <Location -"/"> est tout à fait sans rique car ce conteneur va s'appliquer à -toutes les requêtes sans tenir compte de l'URL spécifique.

    - - -

    Imbrication des sections

    - -

    Certains types de sections peuvent être imbriqués : d'une part, on peut -utiliser les sections <Files> -à l'intérieur des sections <Directory>, d'autre part, on peut utiliser les -directives <If> à l'intérieur -des sections <Directory>, -<Location> et <Files> (mais pas à l'intérieur d'une -autre section <If>). Les -valeurs des expressions rationnelles correspondant aux sections nommées se -comportent de manière identique.

    - -

    Les sections imbriquées sont fusionnées après les sections -non-imbriquées de même type.

    - - - -
    top
    -
    -

    Hôtes virtuels

    - -

    Le conteneur <VirtualHost> -contient des directives qui s'appliquent à des hôtes spécifiques. -Ceci s'avère utile pour servir des hôtes multiples à partir de la même machine, -chacun d'entre eux possédant une configuration différente. Pour de plus amples -informations, -voir la Documentation sur les hôtes virtuels.

    -
    top
    -
    -

    Mandataire

    - -

    Les conteneurs -<Proxy> -et <ProxyMatch> -appliquent les directives de configuration qu'ils contiennent uniquement aux -sites qui correspondent à l'URL spécifiée et auxquels on a -accédé via le serveur mandataire du module mod_proxy. -Par exemple, la configuration suivante n'autorisera qu'un sous-ensemble de -clients à accéder au site www.example.com en passant par le serveur -mandataire :.

    - -
    <Proxy "http://www.example.com/*">
-    Require host yournetwork.example.com
-</Proxy>
    - -
    top
    -
    -

    Quelles sont les directives autorisées ?

    - -

    Pour déterminer quelles sont les directives autorisées pour tel type de -section de configuration, vérifiez le Contexte de la directive. -Tout ce qui est autorisé dans les sections -<Directory> -l'est aussi d'un point de vue syntaxique dans les sections -<DirectoryMatch>, -<Files>, -<FilesMatch>, -<Location>, -<LocationMatch>, -<Proxy>, -et <ProxyMatch>. -Il y a cependant quelques exceptions :

    - - -
    top
    -
    -

    Comment les sections sont combinées entre elles

    - -

    Les sections de configuration sont appliquées dans un ordre très particulier. -Il est important de savoir comment cet ordre est défini car il peut avoir -des effets importants sur la manière dont les directives de configuration -sont interprétées.

    - -

    L'ordre dans lequel les sections sont combinées est :

    - -
      -
    1. Les sections <Directory> (à l'exception des - expressions rationnelles) - et les fichiers .htaccess sont appliqués simultanément (avec - la possibilité pour .htaccess, s'il y est autorisé, de - prévaloir sur - <Directory>)
      2. - -
    2. Les sections - <DirectoryMatch> - (et <Directory "~">)
      3. - -
    3. Les sections <Files> et <FilesMatch> sont appliquées - simultanément
      4. - -
    4. Les sections - <Location> - et <LocationMatch> sont appliquées - simultanément
      5. - -
    5. Les directives <If> -
      6. -
    - -

    Quelques remarques importantes :

    -
      -
    • Mises à part les sections <Directory>, dans chaque groupe, les sections sont - traitées selon - l'ordre dans lequel elles apparaissent dans les fichiers de configuration. - Par exemple, une requête pour /foo/bar correspondra à - <Location "/foo/bar"> et <Location - "/foo"> (dans ce cas le groupe 4) : les deux sections seront - évaluées mais selon l'ordre dans lequel elles apparaissent dans le fichier - de configuration..
      • -
    • Les sections <Directory> (groupe 1 ci-dessus) - sont traitées dans l'ordre du répertoire le plus court vers le plus long. - Par exemple, <Directory "/var/web/dir"> sera - traité avant <Directory - "/var/web/dir/subdir">.
      • -
    • Si plusieurs sections <Directory> s'appliquent au même - répertoire, elles sont traitées selon l'ordre dans lequel elles - apparaissent dans le fichier de configuration.
      • -
    • Les sections de configuration incluses via la directive Include sont traitées comme si elles se - trouvaient réellement dans le fichier qui les inclut à la position de la - directive - Include.
      • -
    • Les sections situées à l'intérieur de sections <VirtualHost> - sont appliquées après les sections correspondantes situées en - dehors de la définition de l'hôte virtuel, ce qui permet à l'hôte virtuel - de prévaloir sur la configuration du serveur principal.
      • -
    • Quand la requête est servie par le module mod_proxy, - le conteneur <Proxy> - prend la place du conteneur <Directory> dans l'ordre de traitement.
      • -
    - -

    Note technique

    - Une séquence <Location>/<LocationMatch> - est réellement traitée juste avant la phase de traduction du nom - (où Aliases et DocumentRoots - sont utilisés pour faire correspondre les URLs aux noms de fichiers). - Les effets de cette séquence disparaissent totalement lorsque - la traduction est terminée. -
    - -

    Interactions entre -modules et sections de configuration

    -

    Une question se pose souvent après avoir lu comment les sections de - configuration sont fusionnées : comment et quand les directives de modules - particuliers comme mod_rewrite sont-elles interprétées ? La - réponse n'est pas triviale et nécessite un approfondissement. Chaque module - httpd gère sa propre configuration, et chacune de ses directives dans - httpd.conf définit un élément de configuration dans un contexte particulier. - httpd n'exécute pas un commande au moment où elle est lue.

    -

    A l'exécution, le noyau de httpd parcours les sections de configuration - dans l'ordre décrit ci-dessus afin de déterminer lesquelles s'appliquent à - la requête courante. Lorsqu'une première section s'applique, elle est - considérée comme la configuration courante pour cette requête. Si une - section suivante s'applique aussi, chaque module qui possède des directives - dans chacune de ces sections a la possibilité de fusionner sa configuration - entre ces deux sections. Il en résulte une troisième configuration et le - processus de fusion se poursuit jusqu'à ce que toutes les sections de - configuration aient été évaluées.

    -

    Après l'étape précédente, le traitement proprement dit de la requête HTTP - peut commencer : chaque module peut effectuer toute tâche qui lui incombe, - et pour déterminer de quelle manière dont il doit agir, il peut s'appuyer - sur le noyau de httpd pour retrouver sa configuration globale issue de la - fusion précédente.

    -

    Un exemple permet de mieux visualiser l'ensemble du processus. la - configuration suivante utilise la directive Header du module - mod_headers pour définir un en-tête HTTP spécifique. Quelle - valeur httpd va-t-il affecter à l'en-tête CustomHeaderName pour - une requête vers /example/index.html ? -

    - 
    <Directory "/">
-    Header set CustomHeaderName one
-    <FilesMatch ".*">
-        Header set CustomHeaderName three
-    </FilesMatch>
-</Directory>
-
-<Directory "/example">
-    Header set CustomHeaderName two
-</Directory>
    - -
      -
    • Directory "/" s'applique, et une configuration - initiale est créée qui définit l'en-tête CustomHeaderName - avec la valeur one.
      • -
    • Directory "/example" s'applique, et comme - mod_headers spécifie dans son code que - la valeur d'un en-tête doit être écrasée si ce dernier est défini à - nouveau, une nouvelle configuration est créée qui définit l'en-tête - CustomHeaderName avec la valeur two.
      • -
    • FilesMatch ".*" s'applique, une nouvelle - opportunité de fusion surgit, et l'en-tête CustomHeaderName - est défini à la valeur three.
      • -
    • Finalement, au cours des étapes suivantes du traitement de la - requête HTTP, mod_headers sera sollicité, et il se - basera sur la configuration qui a défini l'en-tête - CustomHeaderName à la valeur three. - mod_headers utilise normalement cette configuration pour - accomplir sa tâche, à savoir définir des en-têtes HTTP. Cela ne veut - cependant pas dire qu'un module ne peut pas effectuer des actions plus - complexes comme désactiver des directives car elle ne sont pas - nécessaires ou obsolètes, etc...
      • -
    - -

    Ceci est aussi vrai pour les fichiers .htaccess car ils possèdent la même - priorité que les sections Directory dans l'ordre de - fusion. Il faut bien comprendre que les sections de configuration comme - Directory et FilesMatch ne - sont pas comparables avec les directives spécifiques de modules comme - Header ou RewriteRule car elles agissent à des - niveaux différents. -

    - - -

    Quelques exemples utiles

    - -

    Voici un exemple imaginaire qui montre l'ordre de combinaison des sections. -En supposant qu'elles s'appliquent toutes à la requête, les directives de -cet exemple seront appliquées dans l'ordre suivant : A > B > C > D > -E.

    - -
    <Location "/">
-    E
-</Location>
-
-<Files "f.html">
-    D
-</Files>
-
-<VirtualHost *>
-   <Directory "/a/">
-        B
-   </Directory>
-</VirtualHost>
-
-<DirectoryMatch "^.*b$">
-    C
-</DirectoryMatch>
-
-<Directory "/a/b">
-    A
-</Directory>
    - - -

    Pour un exemple plus concret, considérez ce qui suit. Sans tenir compte -de toute restriction d'accès placée dans les sections <Directory>, la section <Location> sera -évaluée en dernier et permettra un accès au serveur sans aucune restriction. -En d'autres termes, l'ordre de la combinaison des sections est important, -soyez donc prudent !

    - -
    <Location "/">
-    Require all granted
-</Location>
-
-# Arrghs!  Cette section <Directory> n'aura aucun effet
-<Directory "/">
-    <RequireAll>
-        Require all granted
-        Require not host badguy.example.com
-    </RequireAll>
-</Directory>
    - - - - -
    -
    -

    Langues Disponibles:  en  | - fr  | - ja  | - ko  | - tr 

    -
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    -
    - \ No newline at end of file diff --git a/docs/manual/sections.html.fr.utf8 b/docs/manual/sections.html.fr.utf8 new file mode 100644 index 0000000000..0211a38906 --- /dev/null +++ b/docs/manual/sections.html.fr.utf8 @@ -0,0 +1,676 @@ + + + + + +Sections de configuration - Serveur HTTP Apache Version 2.5 + + + + + + +
    +

    Modules | Directives | FAQ | Glossaire | Plan du site

    +

    Serveur HTTP Apache Version 2.5

    +
    +
    <-
    +

    Sections de configuration

    +
    +

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

    +
    +

    Les directives des fichiers de configuration peuvent s'appliquer +au serveur dans son ensemble, ou seulement à des répertoires, fichiers, hôtes, +ou URLs particuliers. Ce document décrit comment utiliser les conteneurs de +sections de configuration ou les fichiers .htaccess pour +modifier la portée des directives de configuration.

    +
    + +
    top
    +
    +

    Types de conteneurs de sections de +configuration

    + +
    Modules ApparentésDirectives Apparentées
    + +

    Il existe deux grands types de conteneurs. La plupart des conteneurs sont +évalués pour chaque requête. Les directives qu'ils contiennent s'appliquent +seulement aux requêtes qui sont concernées par le conteneur. En revanche, +les conteneurs +<IfDefine>, <IfModule>, et +<IfVersion> sont +évalués seulement au démarrage et au redémarrage du serveur. +Si leurs conditions sont vérifiées au démarrage, les directives qu'ils contiennent +s'appliqueront à toutes les requêtes. Si leurs conditions ne sont pas vérifiées, les +directives qu'ils contiennent seront ignorées.

    + +

    Le conteneur <IfDefine> +contient des directives qui ne seront appliquées que si un paramètre +approprié a été défini dans la ligne de commande de httpd. +Par exemple, +avec la configuration suivante, toutes les requêtes seront redirigées vers +un autre site si le serveur est démarré en utilisant la ligne de commande : +httpd -DClosedForNow:

    + +
    <IfDefine ClosedForNow>
+    Redirect "/" "http://otherserver.example.com/"
+</IfDefine>
    + + +

    Le conteneur <IfModule> +est similaire; les directives qu'il contient ne s'appliqueront que si +un module particulier est disponible au niveau du serveur. +Le module doit être soit compilé statiquement dans le serveur, soit +dynamiquement et dans ce cas, la ligne LoadModule correspondante doit apparaître +plus haut dans le fichier de configuration. Ce conteneur ne doit être +utilisé que dans le cas où votre fichier de configuration doit fonctionner +indépendamment de la présence ou de l'absence de certains modules. +Il ne doit pas contenir de directives que vous souhaitez voir s'appliquer +systématiquement, car vous pouvez perdre ainsi de précieux messages d'erreur +à propos de modules manquants.

    + +

    Dans l'exemple suivant, la directive MimeMagicFile ne s'appliquera que si le +module mod_mime_magic est disponible.

    + +
    <IfModule mod_mime_magic.c>
+    MimeMagicFile "conf/magic"
+</IfModule>
    + + +

    Le conteneur +<IfVersion> +est similaire aux conteneurs <IfDefine> et <IfModule>; les directives qu'il contient ne +s'appliqueront que si une version particulière du serveur s'exécute. Ce +conteneur a été conçu pour une utilisation dans les suites de tests +et les grands réseaux qui doivent prendre en compte différentes versions +et configurations de httpd.

    + +
    <IfVersion >= 2.4>
+    # les directives situées ici ne s'appliquent que si la version 
    
+    # est supérieure ou égale à 2.4.0.
+</IfVersion>
    + + +

    <IfDefine>, +<IfModule>, et +<IfVersion> +peuvent inverser leur test conditionnel en le faisant précéder d'un "!". +De plus, ces sections peuvent être imbriquées afin de définir des restrictions +plus complexes.

    +
    top
    +
    +

    Système de fichiers, +arborescence du site web et expressions booléennes

    + +

    Les conteneurs de sections de configuration les plus couramment utilisés +sont ceux qui modifient la configuration de points particuliers du système de +fichiers ou de l'arborescence du site web. Tout d'abord, il est important de +comprendre la différence entre les deux. Le système de fichiers est une vue +de vos disques tels qu'ils sont perçus par votre système d'exploitation. +Par exemple, avec une installation par défaut, +Apache httpd est situé dans /usr/local/apache2 pour le système de +fichiers UNIX, ou "c:/Program Files/Apache Group/Apache2" pour +le système de fichiers Windows. (Notez que des slashes directs doivent +toujours être utilisés comme séparateur de chemin +dans les fichiers de configuration d'Apache httpd, même sous +Windows.) Quant à +l'arborescence du site web, il s'agit d'une vue de votre site +tel que présenté par le +serveur web et perçue par le client. Ainsi le chemin /dir/ dans +l'arborescence du site web correspond au chemin +/usr/local/apache2/htdocs/dir/ dans le système de fichiers pour +une installation d'Apache httpd par défaut sous UNIX. +En outre, l'arborescence du site web n'a pas besoin de correspondre en permanence au +système de fichiers, car les pages web peuvent être générées dynamiquement +à partir de bases de données ou d'autres emplacements.

    + +

    Conteneurs de système de fichiers

    + +

    Les conteneurs <Directory> +et <Files>, +ainsi que leurs équivalents acceptant les +expressions rationnelles, +appliquent des directives à certaines parties du système de fichiers. +Les directives contenues dans une section <Directory> s'appliquent au répertoire +précisé, ainsi qu'à tous ses sous-répertoires et aux fichiers que ces +derniers contiennent. +Le même effet peut être obtenu en utilisant les fichiers .htaccess. Par exemple, avec la +configuration suivante, l'indexation sera activée pour le répertoire +/var/web/dir1 et tous ses sous-répertoires.

    + +
    <Directory "/var/web/dir1">
+    Options +Indexes
+</Directory>
    + + +

    Les directives contenues dans une section <Files> s'appliquent à tout fichier +avec le nom spécifié, quel que soit le répertoire dans lequel il se trouve. +Ainsi par exemple, les directives de configuration suivantes, si elles sont +placées dans la section principale du fichier de configuration, vont interdire +l'accès à tout fichier nommé private.html quel que soit +l'endroit où il se trouve.

    + +
    <Files "private.html">
+    Require all denied
+</Files>
    + + +

    Pour faire référence à des fichiers qui se trouvent en des points +particuliers du système de fichiers, les sections +<Files> et +<Directory> +peuvent être combinées. Par exemple, la configuration suivante va interdire +l'accès à /var/web/dir1/private.html, +/var/web/dir1/subdir2/private.html, +/var/web/dir1/subdir3/private.html, ainsi que toute instance de +private.html qui se trouve dans l'arborescence +/var/web/dir1/.

    + +
    <Directory "/var/web/dir1">
+    <Files "private.html">
+        Require all denied
+    </Files>
+</Directory>
    + + + +

    Conteneurs de l'arborescence du site web

    + +

    le conteneur <Location> +et son équivalent acceptant les +expressions rationnelles, modifient quant à eux la +configuration de parties de l'arborescence du site web. Par exemple, la +configuration suivante interdit l'accès à toute URL dont la partie chemin +commence par /private. +En particulier, l'interdiction s'appliquera aux requêtes pour : +http://yoursite.example.com/private, +http://yoursite.example.com/private123, et +http://yoursite.example.com/private/dir/file.html ainsi qu'à +toute requête commençant par la chaîne de caractères /private.

    + +
    <LocationMatch "^/private">
+    Require all denied
+</LocationMatch>
    + + +

    Le conteneur <Location> +n'a pas besoin de faire référence à un élément du système de fichiers. +Par exemple, l'exemple suivant montre comment faire référence à une URL +particulière vers un gestionnaire interne du serveur HTTP Apache fourni par le module +mod_status. +Il n'est pas nécessaire de trouver un fichier nommé server-status +dans le système de fichiers.

    + +
    <Location "/server-status">
+    SetHandler server-status
+</Location>
    + + + +

    Espace web imbriqué

    +

    Pour contrôler deux URLs imbriquées, on doit tenir compte de l'ordre +dans lequel certaines sections ou directives sont évaluées. Pour +<Location>, on doit +avoir :

    +
    <Location "/foo">
+</Location>
+<Location "/foo/bar">
+</Location>
    + +

    Les directives <Alias>, quant à elles, sont évaluées vice-versa :

    +
    Alias "/foo/bar" "/srv/www/uncommon/bar"
+Alias "/foo" "/srv/www/common/foo"
    + +

    Ceci est aussi vrai pour les directives ProxyPass :

    +
    ProxyPass "/special-area" "http://special.example.com" smax=5 max=10
+ProxyPass "/" "balancer://mycluster/" stickysession=JSESSIONID|jsessionid nofailover=On
    + + + + +

    Caractères de remplacement +et expressions rationnelles

    + +

    Les conteneurs +<Directory>, +<Files>, et +<Location> +peuvent utiliser des caractères de remplacement de style shell comme dans +la fonction fnmatch de la bibliothèque C standard. +Le caractère "*" +correspond à toute séquence de caractères, "?" à un caractère seul, +et "[seq]" à tout caractère contenu dans seq. +Le caractère "/" +ne peut pas faire l'objet d'un remplacement; +il doit être spécifié explicitement.

    + +

    Si une définition des critères de correspondance +encore plus souple est nécessaire, chaque conteneur +possède son équivalent acceptant les expressions rationnelles : <DirectoryMatch>, <FilesMatch>, et <LocationMatch> acceptent les +expressions rationnelles compatibles Perl +pour définir les critères de correspondance. Mais voyez plus loin la section +à propos de la combinaison des sections de configuration +pour comprendre comment l'utilisation de +conteneurs avec des expressions rationnelles va modifier la manière +dont les directives sont appliquées.

    + +

    Un conteneur qui modifie la configuration de tous les +répertoires utilisateurs à l'aide de caractères de remplacement +mais sans utiliser +les expressions rationnelles pourrait ressembler à ceci :

    + +
    <Directory "/home/*/public_html">
+    Options Indexes
+</Directory>
    + + +

    Avec les conteneurs utilisant les expressions rationnelles, +on peut interdire l'accès à de nombreux types de fichiers d'images +simultanément :

    +
    +<FilesMatch "\.(?i:gif|jpe?g|png)$">
+    Require all denied
+</FilesMatch>
    + + +

    Les expressions rationnelles contenant des groupes nommés et +des références arrières sont ajoutées à l'environnement avec +leur nom en majuscules. Ceci permet de référencer des éléments de +chemins de fichiers et d'URLs depuis une expression et au sein de modules comme +mod_rewrite.

    + +
    <DirectoryMatch "^/var/www/combined/(?<SITENAME>[^/]+)">
+    require ldap-group "cn=%{env:MATCH_SITENAME},ou=combined,o=Example"
+</DirectoryMatch>
    + + + + +

    Expressions booléennes

    +

    La directive <If> +permet de modifier la configuration en fonction d'une condition qui peut +être définie sous la forme d'une expression booléenne. Dans l'exemple +suivant, l'accès est interdit si l'en-tête HTTP Referer ne commence pas +par "http://www.example.com/".

    +
    <If "!(%{HTTP_REFERER} -strmatch 'http://www.example.com/*')">
+    Require all denied
+</If>
    + + + + +

    Que faut-il utiliser et quand ?

    + +

    Choisir entre des conteneurs de système de fichiers et des conteneurs +d'arborescence du site web est vraiment très simple. +Pour appliquer des directives à des objets qui résident dans le système de +fichiers, utilisez toujours un conteneur <Directory> ou <Files>. Pour appliquer des directives à des objets +qui ne résident pas dans le système de fichiers (comme une page web générée +par une base de données), utilisez un conteneur <Location>.

    + +

    Il ne faut jamais utiliser un conteneur <Location> pour restreindre l'accès à des +objets du système de fichiers, car plusieurs localisations de +l'arborescence du site web (URLs) peuvent correspondre à la même localisation +du système de fichier, ce qui peut permettre de contourner vos restrictions. +Par exemple, imaginez la configuration suivante :

    + +
    <Location "/dir/">
+    Require all denied
+</Location>
    + + +

    Elle fonctionne correctement si la requête appelle +http://yoursite.example.com/dir/. Mais que va-t-il se passer si +votre système de fichiers est insensible à la casse ? +Votre restriction va pouvoir être tout simplement contournée en envoyant une +requête sur +http://yoursite.example.com/DIR/. Le conteneur <Directory>, quant à lui, s'appliquera +à tout contenu servi à partir de cette localisation, +sans tenir compte de la manière dont il est appelé. +(Les liens du système de fichiers constituent une exception. +Le même répertoire peut être placé dans plusieurs parties du système de +fichiers en utilisant des liens symboliques. Le conteneur +<Directory> va suivre le +lien symbolique sans modifier le nom du chemin. Par conséquent, pour plus de +sécurité, les liens symboliques doivent être désactivés à l'aide de la +directive +Options appropriée.)

    + +

    Si vous pensez que vous n'êtes pas concerné par ce problème +parceque vous utilisez un système de fichiers sensible à la casse, +gardez à l'esprit qu'il y a de nombreuses autres manières pour faire +correspondre plusieurs localisations de l'arborescence du site web à la même +localisation du système de fichiers. C'est pourquoi vous devez autant que +possible toujours utiliser les conteneurs de système de fichiers. +Il y a cependant une exception à cette règle. Placer des restrictions de +configuration dans un conteneur <Location +"/"> est tout à fait sans rique car ce conteneur va s'appliquer à +toutes les requêtes sans tenir compte de l'URL spécifique.

    + + +

    Imbrication des sections

    + +

    Certains types de sections peuvent être imbriqués : d'une part, on peut +utiliser les sections <Files> +à l'intérieur des sections <Directory>, d'autre part, on peut utiliser les +directives <If> à l'intérieur +des sections <Directory>, +<Location> et <Files> (mais pas à l'intérieur d'une +autre section <If>). Les +valeurs des expressions rationnelles correspondant aux sections nommées se +comportent de manière identique.

    + +

    Les sections imbriquées sont fusionnées après les sections +non-imbriquées de même type.

    + + + +
    top
    +
    +

    Hôtes virtuels

    + +

    Le conteneur <VirtualHost> +contient des directives qui s'appliquent à des hôtes spécifiques. +Ceci s'avère utile pour servir des hôtes multiples à partir de la même machine, +chacun d'entre eux possédant une configuration différente. Pour de plus amples +informations, +voir la Documentation sur les hôtes virtuels.

    +
    top
    +
    +

    Mandataire

    + +

    Les conteneurs +<Proxy> +et <ProxyMatch> +appliquent les directives de configuration qu'ils contiennent uniquement aux +sites qui correspondent à l'URL spécifiée et auxquels on a +accédé via le serveur mandataire du module mod_proxy. +Par exemple, la configuration suivante n'autorisera qu'un sous-ensemble de +clients à accéder au site www.example.com en passant par le serveur +mandataire :.

    + +
    <Proxy "http://www.example.com/*">
+    Require host yournetwork.example.com
+</Proxy>
    + +
    top
    +
    +

    Quelles sont les directives autorisées ?

    + +

    Pour déterminer quelles sont les directives autorisées pour tel type de +section de configuration, vérifiez le Contexte de la directive. +Tout ce qui est autorisé dans les sections +<Directory> +l'est aussi d'un point de vue syntaxique dans les sections +<DirectoryMatch>, +<Files>, +<FilesMatch>, +<Location>, +<LocationMatch>, +<Proxy>, +et <ProxyMatch>. +Il y a cependant quelques exceptions :

    + + +
    top
    +
    +

    Comment les sections sont combinées entre elles

    + +

    Les sections de configuration sont appliquées dans un ordre très particulier. +Il est important de savoir comment cet ordre est défini car il peut avoir +des effets importants sur la manière dont les directives de configuration +sont interprétées.

    + +

    L'ordre dans lequel les sections sont combinées est :

    + +
      +
    1. Les sections <Directory> (à l'exception des + expressions rationnelles) + et les fichiers .htaccess sont appliqués simultanément (avec + la possibilité pour .htaccess, s'il y est autorisé, de + prévaloir sur + <Directory>)
      2. + +
    2. Les sections + <DirectoryMatch> + (et <Directory "~">)
      3. + +
    3. Les sections <Files> et <FilesMatch> sont appliquées + simultanément
      4. + +
    4. Les sections + <Location> + et <LocationMatch> sont appliquées + simultanément
      5. + +
    5. Les directives <If> +
      6. +
    + +

    Quelques remarques importantes :

    +
      +
    • Mises à part les sections <Directory>, dans chaque groupe, les sections sont + traitées selon + l'ordre dans lequel elles apparaissent dans les fichiers de configuration. + Par exemple, une requête pour /foo/bar correspondra à + <Location "/foo/bar"> et <Location + "/foo"> (dans ce cas le groupe 4) : les deux sections seront + évaluées mais selon l'ordre dans lequel elles apparaissent dans le fichier + de configuration..
      • +
    • Les sections <Directory> (groupe 1 ci-dessus) + sont traitées dans l'ordre du répertoire le plus court vers le plus long. + Par exemple, <Directory "/var/web/dir"> sera + traité avant <Directory + "/var/web/dir/subdir">.
      • +
    • Si plusieurs sections <Directory> s'appliquent au même + répertoire, elles sont traitées selon l'ordre dans lequel elles + apparaissent dans le fichier de configuration.
      • +
    • Les sections de configuration incluses via la directive Include sont traitées comme si elles se + trouvaient réellement dans le fichier qui les inclut à la position de la + directive + Include.
      • +
    • Les sections situées à l'intérieur de sections <VirtualHost> + sont appliquées après les sections correspondantes situées en + dehors de la définition de l'hôte virtuel, ce qui permet à l'hôte virtuel + de prévaloir sur la configuration du serveur principal.
      • +
    • Quand la requête est servie par le module mod_proxy, + le conteneur <Proxy> + prend la place du conteneur <Directory> dans l'ordre de traitement.
      • +
    + +

    Note technique

    + Une séquence <Location>/<LocationMatch> + est réellement traitée juste avant la phase de traduction du nom + (où Aliases et DocumentRoots + sont utilisés pour faire correspondre les URLs aux noms de fichiers). + Les effets de cette séquence disparaissent totalement lorsque + la traduction est terminée. +
    + +

    Interactions entre +modules et sections de configuration

    +

    Une question se pose souvent après avoir lu comment les sections de + configuration sont fusionnées : comment et quand les directives de modules + particuliers comme mod_rewrite sont-elles interprétées ? La + réponse n'est pas triviale et nécessite un approfondissement. Chaque module + httpd gère sa propre configuration, et chacune de ses directives dans + httpd.conf définit un élément de configuration dans un contexte particulier. + httpd n'exécute pas un commande au moment où elle est lue.

    +

    A l'exécution, le noyau de httpd parcours les sections de configuration + dans l'ordre décrit ci-dessus afin de déterminer lesquelles s'appliquent à + la requête courante. Lorsqu'une première section s'applique, elle est + considérée comme la configuration courante pour cette requête. Si une + section suivante s'applique aussi, chaque module qui possède des directives + dans chacune de ces sections a la possibilité de fusionner sa configuration + entre ces deux sections. Il en résulte une troisième configuration et le + processus de fusion se poursuit jusqu'à ce que toutes les sections de + configuration aient été évaluées.

    +

    Après l'étape précédente, le traitement proprement dit de la requête HTTP + peut commencer : chaque module peut effectuer toute tâche qui lui incombe, + et pour déterminer de quelle manière dont il doit agir, il peut s'appuyer + sur le noyau de httpd pour retrouver sa configuration globale issue de la + fusion précédente.

    +

    Un exemple permet de mieux visualiser l'ensemble du processus. la + configuration suivante utilise la directive Header du module + mod_headers pour définir un en-tête HTTP spécifique. Quelle + valeur httpd va-t-il affecter à l'en-tête CustomHeaderName pour + une requête vers /example/index.html ? +

    + 
    <Directory "/">
+    Header set CustomHeaderName one
+    <FilesMatch ".*">
+        Header set CustomHeaderName three
+    </FilesMatch>
+</Directory>
+
+<Directory "/example">
+    Header set CustomHeaderName two
+</Directory>
    + +
      +
    • Directory "/" s'applique, et une configuration + initiale est créée qui définit l'en-tête CustomHeaderName + avec la valeur one.
      • +
    • Directory "/example" s'applique, et comme + mod_headers spécifie dans son code que + la valeur d'un en-tête doit être écrasée si ce dernier est défini à + nouveau, une nouvelle configuration est créée qui définit l'en-tête + CustomHeaderName avec la valeur two.
      • +
    • FilesMatch ".*" s'applique, une nouvelle + opportunité de fusion surgit, et l'en-tête CustomHeaderName + est défini à la valeur three.
      • +
    • Finalement, au cours des étapes suivantes du traitement de la + requête HTTP, mod_headers sera sollicité, et il se + basera sur la configuration qui a défini l'en-tête + CustomHeaderName à la valeur three. + mod_headers utilise normalement cette configuration pour + accomplir sa tâche, à savoir définir des en-têtes HTTP. Cela ne veut + cependant pas dire qu'un module ne peut pas effectuer des actions plus + complexes comme désactiver des directives car elle ne sont pas + nécessaires ou obsolètes, etc...
      • +
    + +

    Ceci est aussi vrai pour les fichiers .htaccess car ils possèdent la même + priorité que les sections Directory dans l'ordre de + fusion. Il faut bien comprendre que les sections de configuration comme + Directory et FilesMatch ne + sont pas comparables avec les directives spécifiques de modules comme + Header ou RewriteRule car elles agissent à des + niveaux différents. +

    + + +

    Quelques exemples utiles

    + +

    Voici un exemple imaginaire qui montre l'ordre de combinaison des sections. +En supposant qu'elles s'appliquent toutes à la requête, les directives de +cet exemple seront appliquées dans l'ordre suivant : A > B > C > D > +E.

    + +
    <Location "/">
+    E
+</Location>
+
+<Files "f.html">
+    D
+</Files>
+
+<VirtualHost *>
+   <Directory "/a/">
+        B
+   </Directory>
+</VirtualHost>
+
+<DirectoryMatch "^.*b$">
+    C
+</DirectoryMatch>
+
+<Directory "/a/b">
+    A
+</Directory>
    + + +

    Pour un exemple plus concret, considérez ce qui suit. Sans tenir compte +de toute restriction d'accès placée dans les sections <Directory>, la section <Location> sera +évaluée en dernier et permettra un accès au serveur sans aucune restriction. +En d'autres termes, l'ordre de la combinaison des sections est important, +soyez donc prudent !

    + +
    <Location "/">
+    Require all granted
+</Location>
+
+# Arrghs!  Cette section <Directory> n'aura aucun effet
+<Directory "/">
+    <RequireAll>
+        Require all granted
+        Require not host badguy.example.com
+    </RequireAll>
+</Directory>
    + + + + +
    +
    +

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

    +
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    +
    + \ No newline at end of file diff --git a/docs/manual/server-wide.html.en b/docs/manual/server-wide.html.en index 0d6308b3df..4049ab82e5 100644 --- a/docs/manual/server-wide.html.en +++ b/docs/manual/server-wide.html.en @@ -24,10 +24,10 @@ Apache > HTTP Server > Documentation > Version 2.5

    Server-Wide Configuration

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

    + tr 

    This document explains some of the directives provided by @@ -111,10 +111,10 @@ the basic operations of the server.

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

    + tr 

    top

    Comments

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    - - -
    -

    Modules | Directives | FAQ | Glossaire | Plan du site

    -

    Serveur HTTP Apache Version 2.5

    -
    -
    <-
    -

    Configuration à l'échelle du serveur

    -
    -

    Langues Disponibles:  en  | - fr  | - ja  | - ko  | - tr 

    -
    - -

    Ce document explique le fonctionnement de certaines directives du serveur -de base qui sont utilisées pour configurer les opérations élémentaires du -serveur.

    -
    - -
    top
    -
    -

    Identification du serveur

    - - -
    Modules ApparentésDirectives Apparentées
    - -

    Les directives ServerAdmin et - ServerTokens contrôlent la nature des - informations à propos du serveur qui seront affichées dans les documents - générés par le serveur comme les messages d'erreur. La directive - ServerTokens définit la valeur du - champ d'en-tête de la réponse du serveur HTTP.

    - -

    Le serveur utilise les directives - ServerName, - UseCanonicalName et - UseCanonicalPhysicalPort pour - déterminer la manière de construire des URLs vers ses propres ressources. - Par exemple, quand un client émet une requête vers un répertoire, mais - n'ajoute pas le slash final au nom du répertoire, httpd doit rediriger le - client vers le nom complet incluant le slash final afin que le client - puisse résoudre correctement les références relatives présentes dans - le document.

    -
    top
    -
    -

    Localisation des fichiers

    - - -
    Modules ApparentésDirectives Apparentées
    - -

    Ces directives contrôlent la localisation des différents fichiers - nécessaires au bon fonctionnement de httpd. Quand le chemin utilisé ne - commence pas par un slash (/), la localisation des fichiers est relative - à la valeur de la directive - ServerRoot. Soyez prudent avec la - localisation de fichiers dans des répertoires où les utilisateurs non root - ont les droits en écriture. Voir la documention sur les - Conseils à propos - de la sécurité pour plus de détails.

    -
    top
    -
    -

    Limitation de l'utilisation des ressources

    - - -
    Modules ApparentésDirectives Apparentées
    - -

    Les directives LimitRequest* permettent de - limiter la quantité de ressources consommées par httpd pour le traitement - des requêtes des clients. Cette limitation permet de minimiser les effets - de certains types d'attaques par déni de service.

    - -

    Les directives RLimit* permettent de limiter la - quantité de ressources utilisable par les processus initiés (forked) par - les processus enfants httpd. Elles permettent en particulier de contrôler - les ressources utilisées par les scripts CGI et les commandes exec des - "Inclusions côté serveur" (Server Side Includes ou SSI).

    - -

    La directive ThreadStackSize - permet sur certaines plates-formes de contrôler la taille de la pile.

    -
    top
    -
    -

    Choix d'implémentation

    - - -
    Modules ApparentésDirectives Apparentées
    - -

    La directive Mutex permet de modifier - l'implémentation sous-jacente des mutex, afin de résoudre les - problèmes de fonctionnement ou de performance dus au choix par - défaut d'APR.

    -
    -
    -

    Langues Disponibles:  en  | - fr  | - ja  | - ko  | - tr 

    -
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    -
    - \ No newline at end of file diff --git a/docs/manual/server-wide.html.fr.utf8 b/docs/manual/server-wide.html.fr.utf8 new file mode 100644 index 0000000000..d8a1ba7f1a --- /dev/null +++ b/docs/manual/server-wide.html.fr.utf8 @@ -0,0 +1,144 @@ + + + + + +Configuration à l'échelle du serveur - Serveur HTTP Apache Version 2.5 + + + + + + +
    +

    Modules | Directives | FAQ | Glossaire | Plan du site

    +

    Serveur HTTP Apache Version 2.5

    +
    +
    <-
    +

    Configuration à l'échelle du serveur

    +
    +

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

    +
    + +

    Ce document explique le fonctionnement de certaines directives du serveur +de base qui sont utilisées pour configurer les opérations élémentaires du +serveur.

    +
    + +
    top
    +
    +

    Identification du serveur

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

    Les directives ServerAdmin et + ServerTokens contrôlent la nature des + informations à propos du serveur qui seront affichées dans les documents + générés par le serveur comme les messages d'erreur. La directive + ServerTokens définit la valeur du + champ d'en-tête de la réponse du serveur HTTP.

    + +

    Le serveur utilise les directives + ServerName, + UseCanonicalName et + UseCanonicalPhysicalPort pour + déterminer la manière de construire des URLs vers ses propres ressources. + Par exemple, quand un client émet une requête vers un répertoire, mais + n'ajoute pas le slash final au nom du répertoire, httpd doit rediriger le + client vers le nom complet incluant le slash final afin que le client + puisse résoudre correctement les références relatives présentes dans + le document.

    +
    top
    +
    +

    Localisation des fichiers

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

    Ces directives contrôlent la localisation des différents fichiers + nécessaires au bon fonctionnement de httpd. Quand le chemin utilisé ne + commence pas par un slash (/), la localisation des fichiers est relative + à la valeur de la directive + ServerRoot. Soyez prudent avec la + localisation de fichiers dans des répertoires où les utilisateurs non root + ont les droits en écriture. Voir la documention sur les + Conseils à propos + de la sécurité pour plus de détails.

    +
    top
    +
    +

    Limitation de l'utilisation des ressources

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

    Les directives LimitRequest* permettent de + limiter la quantité de ressources consommées par httpd pour le traitement + des requêtes des clients. Cette limitation permet de minimiser les effets + de certains types d'attaques par déni de service.

    + +

    Les directives RLimit* permettent de limiter la + quantité de ressources utilisable par les processus initiés (forked) par + les processus enfants httpd. Elles permettent en particulier de contrôler + les ressources utilisées par les scripts CGI et les commandes exec des + "Inclusions côté serveur" (Server Side Includes ou SSI).

    + +

    La directive ThreadStackSize + permet sur certaines plates-formes de contrôler la taille de la pile.

    +
    top
    +
    +

    Choix d'implémentation

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

    La directive Mutex permet de modifier + l'implémentation sous-jacente des mutex, afin de résoudre les + problèmes de fonctionnement ou de performance dus au choix par + défaut d'APR.

    +
    +
    +

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

    +
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    +
    + \ No newline at end of file diff --git a/docs/manual/sitemap.html b/docs/manual/sitemap.html index a3f557daa3..cdad2c7335 100644 --- a/docs/manual/sitemap.html +++ b/docs/manual/sitemap.html @@ -10,7 +10,7 @@ Content-type: text/html; charset=ISO-8859-1 URI: sitemap.html.es Content-Language: es -Content-type: text/html; charset=ISO-8859-1 +Content-type: text/html; charset=UTF-8 URI: sitemap.html.fr Content-Language: fr diff --git a/docs/manual/sitemap.html.en b/docs/manual/sitemap.html.en index 5557cd3f56..eba7a4f445 100644 --- a/docs/manual/sitemap.html.en +++ b/docs/manual/sitemap.html.en @@ -27,11 +27,11 @@

    Available Languages:  de  |  en  | - es  | - fr  | + es  | + fr  |  ja  |  ko  | - tr  | + tr  |  zh-cn 

    @@ -351,11 +351,11 @@ log_server_status

    Available Languages:  de  |  en  | - es  | - fr  | + es  | + fr  |  ja  |  ko  | - tr  | + tr  |  zh-cn 

    top

    Comments

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    - - - -
    -

    Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

    -

    Versin 2.5 del Servidor HTTP Apache

    -
    -
    <-
    - -

    Mapa de este sitio web

    -
    -

    Idiomas disponibles:  de  | - en  | - es  | - fr  | - ja  | - ko  | - tr  | - zh-cn 

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

    Esta pgina contiene la lista con los documentos actualmente -disponibles de la Versin 2.5 de la -Documentacin del Servidor HTTP Apache.

    -
    - -
    top
    -

    Notas de la Versin

    - -
    top
    -

    Utilizacin del Servidor HTTP Apache

    - -
    top
    -

    Documentacin sobre Hosting Virtual en Apache

    - -
    top
    -

    Gua de Reescritura de URLs

    - -
    top
    -

    Cifrado SSL/TLS con Apache

    - -
    top
    -

    Guas, Tutoriales y How-Tos

    - -
    top
    -

    Notas especficas sobre plataformas

    - -
    top
    -

    Programas de soporte y el Servidor HTTP Apache

    - -
    top
    -

    Documentacin adicional sobre Apache

    - -
    top
    -

    Mdulos de Apache

    - -
    top
    -

    Documentacin para desarrolladores

    - -
    top
    -

    Glosario e ndice

    - -
    -
    -

    Idiomas disponibles:  de  | - en  | - es  | - fr  | - ja  | - ko  | - tr  | - zh-cn 

    -
    top

    Comentarios

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    -
    - \ No newline at end of file diff --git a/docs/manual/sitemap.html.es.utf8 b/docs/manual/sitemap.html.es.utf8 new file mode 100644 index 0000000000..7c1e34c3b2 --- /dev/null +++ b/docs/manual/sitemap.html.es.utf8 @@ -0,0 +1,391 @@ + + + + + +Mapa de este sitio web - Servidor HTTP Apache Versin 2.5 + + + + + + + +
    +

    Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

    +

    Versin 2.5 del Servidor HTTP Apache

    +
    +
    <-
    + +

    Mapa de este sitio web

    +
    +

    Idiomas disponibles:  de  | + en  | + es  | + fr  | + ja  | + ko  | + tr  | + zh-cn 

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

    Esta pgina contiene la lista con los documentos actualmente +disponibles de la Versin 2.5 de la +Documentacin del Servidor HTTP Apache.

    +
    + +
    top
    +

    Notas de la Versin

    + +
    top
    +

    Utilizacin del Servidor HTTP Apache

    + +
    top
    +

    Documentacin sobre Hosting Virtual en Apache

    + +
    top
    +

    Gua de Reescritura de URLs

    + +
    top
    +

    Cifrado SSL/TLS con Apache

    + +
    top
    +

    Guas, Tutoriales y How-Tos

    + +
    top
    +

    Notas especficas sobre plataformas

    + +
    top
    +

    Programas de soporte y el Servidor HTTP Apache

    + +
    top
    +

    Documentacin adicional sobre Apache

    + +
    top
    +

    Mdulos de Apache

    + +
    top
    +

    Documentacin para desarrolladores

    + +
    top
    +

    Glosario e ndice

    + +
    +
    +

    Idiomas disponibles:  de  | + en  | + es  | + fr  | + ja  | + ko  | + tr  | + zh-cn 

    +
    top

    Comentarios

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    +
    + \ No newline at end of file diff --git a/docs/manual/sitemap.html.fr b/docs/manual/sitemap.html.fr deleted file mode 100644 index 3cd4184be4..0000000000 --- a/docs/manual/sitemap.html.fr +++ /dev/null @@ -1,406 +0,0 @@ - - - - - -Plan du site - Serveur HTTP Apache Version 2.5 - - - - - - - -
    -

    Modules | Directives | FAQ | Glossaire | Plan du site

    -

    Serveur HTTP Apache Version 2.5

    -
    -
    <-
    - -

    Plan du site

    -
    -

    Langues Disponibles:  de  | - en  | - es  | - fr  | - ja  | - ko  | - tr  | - zh-cn 

    -
    - -

    Cette page contient la liste des éléments actuellement disponibles de -la Documentation du serveur HTTP Apache Version -2.5.

    -
    - -
    top
    -

    Notes de version

    - -
    top
    -

    Utilisation du serveur HTTP Apache

    - -
    top
    -

    Documentation des serveurs virtuels Apache

    - -
    top
    -

    Guide de réécriture d'URLs

    - -
    top
    -

    Chiffrement SSL/TLS avec Apache

    - -
    top
    -

    Guides, Tutoriels, and Recettes

    - -
    top
    -

    Notes spécifiques à certains systèmes

    - -
    top
    -

    Le serveur HTTP Apache et ses programmes associés

    - -
    top
    -

    Documentations diverses sur Apache

    - -
    top
    -

    Modules Apache

    - -
    top
    -

    Documentation du développeur

    - -
    top
    -

    Glossaire et Index

    - -
    -
    -

    Langues Disponibles:  de  | - en  | - es  | - fr  | - ja  | - ko  | - tr  | - zh-cn 

    -
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    -
    - \ No newline at end of file diff --git a/docs/manual/sitemap.html.fr.utf8 b/docs/manual/sitemap.html.fr.utf8 new file mode 100644 index 0000000000..3cd4184be4 --- /dev/null +++ b/docs/manual/sitemap.html.fr.utf8 @@ -0,0 +1,406 @@ + + + + + +Plan du site - Serveur HTTP Apache Version 2.5 + + + + + + + +
    +

    Modules | Directives | FAQ | Glossaire | Plan du site

    +

    Serveur HTTP Apache Version 2.5

    +
    +
    <-
    + +

    Plan du site

    +
    +

    Langues Disponibles:  de  | + en  | + es  | + fr  | + ja  | + ko  | + tr  | + zh-cn 

    +
    + +

    Cette page contient la liste des éléments actuellement disponibles de +la Documentation du serveur HTTP Apache Version +2.5.

    +
    + +
    top
    +

    Notes de version

    + +
    top
    +

    Utilisation du serveur HTTP Apache

    + +
    top
    +

    Documentation des serveurs virtuels Apache

    + +
    top
    +

    Guide de réécriture d'URLs

    + +
    top
    +

    Chiffrement SSL/TLS avec Apache

    + +
    top
    +

    Guides, Tutoriels, and Recettes

    + +
    top
    +

    Notes spécifiques à certains systèmes

    + +
    top
    +

    Le serveur HTTP Apache et ses programmes associés

    + +
    top
    +

    Documentations diverses sur Apache

    + +
    top
    +

    Modules Apache

    + +
    top
    +

    Documentation du développeur

    + +
    top
    +

    Glossaire et Index

    + +
    +
    +

    Langues Disponibles:  de  | + en  | + es  | + fr  | + ja  | + ko  | + tr  | + zh-cn 

    +
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    +
    + \ No newline at end of file diff --git a/docs/manual/socache.html.en b/docs/manual/socache.html.en index f533426109..7ae74ce875 100644 --- a/docs/manual/socache.html.en +++ b/docs/manual/socache.html.en @@ -24,7 +24,7 @@ Apache > HTTP Server > Documentation > Version 2.5

    Shared Object Cache in Apache HTTP Server

    Available Languages:  en  | - fr 

    + fr 

    The Shared Object Cache provides a means to share simple data @@ -120,7 +120,7 @@

    Available Languages:  en  | - fr 

    + fr 

    top

    Comments

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    - - -
    -

    Modules | Directives | FAQ | Glossaire | Plan du site

    -

    Serveur HTTP Apache Version 2.5

    -
    -
    <-
    -

    Le cache des objets partagés du serveur HTTP Apache

    -
    -

    Langues Disponibles:  en  | - fr 

    -
    - -

    Le cache des objets partagés est un concept de partage de données - de base entre tous les processus d'un serveur, sans se préoccuper du - modèle de threads et de processus. On - l'utilise lorsque les avantages apportés par le partage de données - entre processus contrebalance la perte de performances consécutive à - la communication interprocessus.

    -
    -
    top
    -
    -

    Fournisseurs du cache d'objets partagés

    - -

    Le cache d'objets partagés en tant que tel est une abstraction. - Il est implémenté par quatre modules différents. Pour pouvoir - utiliser le cache, un ou plusieurs de ces modules doivent être - présents et configurés.

    -

    Le seul élément de configuration consiste à définir le - fournisseur de cache à utiliser. Ceci est de la responsabilité des - modules qui utilisent le cache, et pour cela, ils activent la - sélection via des directives telles que CacheSocache, AuthnCacheSOCache, SSLSessionCache, et SSLStaplingCache.

    -

    Les fournisseurs actuellement disponibles sont :

    -
    -
    "dbm" (mod_socache_dbm)
    -
    Celui-ci utilise un fichier de hashage DBM. Le choix de la - DBM sous-jacente peut être configurable si la version - d'APR installée supporte de multiples implémentations de DBM.
    -
    "dc" (mod_socache_dc)
    -
    Celui-ci utilise les bibliothèques de mise en cache de sessions - distribuées distcache.
    -
    "memcache" (mod_socache_memcache)
    -
    Celui-ci utilise le système à hautes performances de mise en - cache d'objets de mémoire distribuée memcached.
    -
    "redis" (mod_socache_redis)
    -
    Celui-ci utilise le système de mise en cache d'objets de mémoire - distribuée à hautes performances Redis.
    -
    "shmcb" (mod_socache_shmcb)
    -
    Celui-ci utilise un tampon cyclique à hautes performances au - sein d'un segment de mémoire partagée.
    -
    - -

    L'API fournit les fonctions suivantes :

    - -
    -
    const char *create(ap_socache_instance_t **instance, const char *arg, - apr_pool_t *tmp, apr_pool_t *p);
    -
    Cette fonction permet de créer un cache de session basé sur - la chaîne de configuration spécifiée. Le pointeur d'instance - renvoyé dans le paramètre instance sera passé comme premier - argument des invocations subséquentes.
    - -
    apr_status_t init(ap_socache_instance_t *instance, const char *cname, - const struct ap_socache_hints *hints, - server_rec *s, apr_pool_t *pool)
    -
    Cette fonction permet d'initialiser le cache. L'argument cname - doit avoir une longueur maximale de 16 caractères et permet - d'identifier de manière unique l'utilisateur du cache au sein du - serveur ; il est recommandé d'utiliser le nom du module, par - exemple "mod_ssl-sess". Comme cette chaîne peut être utilisée au - sein d'un système de fichiers, il est conseillé de n'utiliser que - des caractères alphanumériques [a-z0-9_-]. Si l'argument hints - n'est pas égal à NULL, il fournit un ensemble d'indications au - fournisseur. La valeur retournée est le code d'erreur APR.
    - -
    void destroy(ap_socache_instance_t *instance, server_rec *s)
    -
    Cette fonction permet de détruire l'instance de cache - spécifiée.
    - -
    apr_status_t store(ap_socache_instance_t *instance, server_rec *s, - const unsigned char *id, unsigned int idlen, - apr_time_t expiry, - unsigned char *data, unsigned int datalen, - apr_pool_t *pool)
    -
    Cette fonction permet de stocker un objet dans une instance de - cache.
    - -
    apr_status_t retrieve(ap_socache_instance_t *instance, server_rec *s, - const unsigned char *id, unsigned int idlen, - unsigned char *data, unsigned int *datalen, - apr_pool_t *pool)
    -
    Cette fonction permet d'extraire un objet du cache.
    - -
    apr_status_t remove(ap_socache_instance_t *instance, server_rec *s, - const unsigned char *id, unsigned int idlen, - apr_pool_t *pool)
    -
    Supprime un objet du cache.
    - -
    void status(ap_socache_instance_t *instance, request_rec *r, int flags)
    -
    Descend le détail d'une instance de cache à destination de mod_status.
    - -
    apr_status_t iterate(ap_socache_instance_t *instance, server_rec *s, - void *userctx, ap_socache_iterator_t *iterator, - apr_pool_t *pool)
    -
    Descend tous les objets en cache à destination d'une fonction iterator callback.
    -
    - -
    -
    -

    Langues Disponibles:  en  | - fr 

    -
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    -
    - \ No newline at end of file diff --git a/docs/manual/socache.html.fr.utf8 b/docs/manual/socache.html.fr.utf8 new file mode 100644 index 0000000000..e6d5863732 --- /dev/null +++ b/docs/manual/socache.html.fr.utf8 @@ -0,0 +1,152 @@ + + + + + +Le cache des objets partagés du serveur HTTP Apache - Serveur HTTP Apache Version 2.5 + + + + + + +
    +

    Modules | Directives | FAQ | Glossaire | Plan du site

    +

    Serveur HTTP Apache Version 2.5

    +
    +
    <-
    +

    Le cache des objets partagés du serveur HTTP Apache

    +
    +

    Langues Disponibles:  en  | + fr 

    +
    + +

    Le cache des objets partagés est un concept de partage de données + de base entre tous les processus d'un serveur, sans se préoccuper du + modèle de threads et de processus. On + l'utilise lorsque les avantages apportés par le partage de données + entre processus contrebalance la perte de performances consécutive à + la communication interprocessus.

    +
    +
    top
    +
    +

    Fournisseurs du cache d'objets partagés

    + +

    Le cache d'objets partagés en tant que tel est une abstraction. + Il est implémenté par quatre modules différents. Pour pouvoir + utiliser le cache, un ou plusieurs de ces modules doivent être + présents et configurés.

    +

    Le seul élément de configuration consiste à définir le + fournisseur de cache à utiliser. Ceci est de la responsabilité des + modules qui utilisent le cache, et pour cela, ils activent la + sélection via des directives telles que CacheSocache, AuthnCacheSOCache, SSLSessionCache, et SSLStaplingCache.

    +

    Les fournisseurs actuellement disponibles sont :

    +
    +
    "dbm" (mod_socache_dbm)
    +
    Celui-ci utilise un fichier de hashage DBM. Le choix de la + DBM sous-jacente peut être configurable si la version + d'APR installée supporte de multiples implémentations de DBM.
    +
    "dc" (mod_socache_dc)
    +
    Celui-ci utilise les bibliothèques de mise en cache de sessions + distribuées distcache.
    +
    "memcache" (mod_socache_memcache)
    +
    Celui-ci utilise le système à hautes performances de mise en + cache d'objets de mémoire distribuée memcached.
    +
    "redis" (mod_socache_redis)
    +
    Celui-ci utilise le système de mise en cache d'objets de mémoire + distribuée à hautes performances Redis.
    +
    "shmcb" (mod_socache_shmcb)
    +
    Celui-ci utilise un tampon cyclique à hautes performances au + sein d'un segment de mémoire partagée.
    +
    + +

    L'API fournit les fonctions suivantes :

    + +
    +
    const char *create(ap_socache_instance_t **instance, const char *arg, + apr_pool_t *tmp, apr_pool_t *p);
    +
    Cette fonction permet de créer un cache de session basé sur + la chaîne de configuration spécifiée. Le pointeur d'instance + renvoyé dans le paramètre instance sera passé comme premier + argument des invocations subséquentes.
    + +
    apr_status_t init(ap_socache_instance_t *instance, const char *cname, + const struct ap_socache_hints *hints, + server_rec *s, apr_pool_t *pool)
    +
    Cette fonction permet d'initialiser le cache. L'argument cname + doit avoir une longueur maximale de 16 caractères et permet + d'identifier de manière unique l'utilisateur du cache au sein du + serveur ; il est recommandé d'utiliser le nom du module, par + exemple "mod_ssl-sess". Comme cette chaîne peut être utilisée au + sein d'un système de fichiers, il est conseillé de n'utiliser que + des caractères alphanumériques [a-z0-9_-]. Si l'argument hints + n'est pas égal à NULL, il fournit un ensemble d'indications au + fournisseur. La valeur retournée est le code d'erreur APR.
    + +
    void destroy(ap_socache_instance_t *instance, server_rec *s)
    +
    Cette fonction permet de détruire l'instance de cache + spécifiée.
    + +
    apr_status_t store(ap_socache_instance_t *instance, server_rec *s, + const unsigned char *id, unsigned int idlen, + apr_time_t expiry, + unsigned char *data, unsigned int datalen, + apr_pool_t *pool)
    +
    Cette fonction permet de stocker un objet dans une instance de + cache.
    + +
    apr_status_t retrieve(ap_socache_instance_t *instance, server_rec *s, + const unsigned char *id, unsigned int idlen, + unsigned char *data, unsigned int *datalen, + apr_pool_t *pool)
    +
    Cette fonction permet d'extraire un objet du cache.
    + +
    apr_status_t remove(ap_socache_instance_t *instance, server_rec *s, + const unsigned char *id, unsigned int idlen, + apr_pool_t *pool)
    +
    Supprime un objet du cache.
    + +
    void status(ap_socache_instance_t *instance, request_rec *r, int flags)
    +
    Descend le détail d'une instance de cache à destination de mod_status.
    + +
    apr_status_t iterate(ap_socache_instance_t *instance, server_rec *s, + void *userctx, ap_socache_iterator_t *iterator, + apr_pool_t *pool)
    +
    Descend tous les objets en cache à destination d'une fonction iterator callback.
    +
    + +
    +
    +

    Langues Disponibles:  en  | + fr 

    +
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    +
    + \ No newline at end of file diff --git a/docs/manual/ssl/index.html b/docs/manual/ssl/index.html index 35774405b7..07582ff501 100644 --- a/docs/manual/ssl/index.html +++ b/docs/manual/ssl/index.html @@ -6,7 +6,7 @@ Content-type: text/html; charset=ISO-8859-1 URI: index.html.es Content-Language: es -Content-type: text/html; charset=ISO-8859-1 +Content-type: text/html; charset=UTF-8 URI: index.html.fr Content-Language: fr diff --git a/docs/manual/ssl/index.html.en b/docs/manual/ssl/index.html.en index 1e2fd6c3ec..9fb3e341b3 100644 --- a/docs/manual/ssl/index.html.en +++ b/docs/manual/ssl/index.html.en @@ -24,10 +24,10 @@ Apache > HTTP Server > Documentation > Version 2.5

    Apache SSL/TLS Encryption

    Available Languages:  en  | - es  | - fr  | + es  | + fr  |  ja  | - tr  | + tr  |  zh-cn 

    @@ -58,10 +58,10 @@ provided by this module is provided in the mod_ssl

    Available Languages:  en  | - es  | - fr  | + es  | + fr  |  ja  | - tr  | + tr  |  zh-cn 

    SSL/TLS Strong Encryption: Compatibility

    Available Languages:  en  | - es  | - fr 

    + es  | + fr 

    @@ -221,8 +221,8 @@ are listed in Table 3.

    Available Languages:  en  | - es  | - fr 

    + es  | + fr 

    top

    Comments

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    - - -
    -

    Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

    -

    Versin 2.5 del Servidor HTTP Apache

    -
    -
    <-
    -

    Cifrado Robusto SSL/TLS: Compatibilidad

    -
    -

    Idiomas disponibles:  en  | - es  | - fr 

    -
    - -

    -En esta pgina se cubre la compatibilidad entre el mdulo mod_ssl -y otras soluciones SSL. -mod_ssl no es la nica solucin de SSL para Apache HTTPD Server; -Para productos adicionales que estn (o estaban) disponibles como Ben Laurie's -en su web, que ahora no existe (http://www.apache-ssl.org/), donde fue la -derivacin original en 1998 del mdulo. -Tanto el sistema de Red Hat -Secure Web Server se bas en mod_ssl as como la versin comercial del - - mdulo SSL de Covalent's Raven, y por ltimo, C2Net (ahora de Red Hat) - basado en una rama de evaluacin del proyecto llamado Sioux con un - "Stronghold 2.x" y basado en mod_ssl desde la versin "Stronghold 3.x". - - - -

    - -

    -mod_ssl proporciona un superconjunto de la funcionalidad de todas las dems -soluciones, por lo que ser simple la migracin de mdulos antiguos al -mod_ssl. -Las directivas de configuracin y nombres de variables de entorno usadas -por mdulos antiguos de SSL varan mucho de mod_ssl; -tablas de correspondencia con lo usado por mod_ssl, se detallan a continuacin. -

    -
    - -
    top
    -
    -

    Directivas de Configuracin

    -

    La correspondencia entre las directivas de configuracin usadas por -Apache-SSL 1.x y mod_ssl 2.0.x se dan en la Tabla -1. La correspondencia de Sioux 1.x y Stronghold 2.x es solo parcial -debido a funcionalidades especiales en estas interfaces que mod_ssl no proporciona. -

    - - -

    Table 1: Correspondencia de Directivas de Configuracin

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Directivas AntiguasDirectivas mod_ssl Comentarios
    Compatibilidad de Apache-SSL 1.x & mod_ssl 2.0.x:
    SSLEnableSSLEngine oncompactified
    SSLDisableSSLEngine offcompactified
    SSLLogFile ficheroUse per-module LogLevel setting instead.
    SSLRequiredCiphers specSSLCipherSuite specrenombrada
    SSLRequireCipher c1 ...SSLRequire %{SSL_CIPHER} in {"c1", -...}generalized
    SSLBanCipher c1 ...SSLRequire not (%{SSL_CIPHER} in {"c1", -...})generalized
    SSLFakeBasicAuthSSLOptions +FakeBasicAuthmerged
    SSLCacheServerPath dir-functionality removed
    SSLCacheServerPort integer-functionality removed
    Compatibilidad Apache-SSL 1.x :
    SSLExportClientCertificatesSSLOptions +ExportCertDatamerged
    SSLCacheServerRunDir dir-funcionalidad no soportada
    Compatibilidad Sioux 1.x :
    SSL_CertFile ficheroSSLCertificateFile ficherorenombrada
    SSL_KeyFile ficheroSSLCertificateKeyFile ficherorenombrada
    SSL_CipherSuite argSSLCipherSuite argrenombrada
    SSL_X509VerifyDir argSSLCACertificatePath argrenombrada
    SSL_Log fichero-Use per-module LogLevel setting instead.
    SSL_Connect flagSSLEngine flagrenombrada
    SSL_ClientAuth argSSLVerifyClient argrenombrada
    SSL_X509VerifyDepth argSSLVerifyDepth argrenombrada
    SSL_FetchKeyPhraseFrom arg-not directly mappable; use SSLPassPhraseDialog
    SSL_SessionDir dir-not directly mappable; use SSLSessionCache
    SSL_Require expr-not directly mappable; use SSLRequire
    SSL_CertFileType arg-funcionalidad no soportada
    SSL_KeyFileType arg-funcionalidad no soportada
    SSL_X509VerifyPolicy arg-funcionalidad no soportada
    SSL_LogX509Attributes arg-funcionalidad no soportada
    Compatibilidad Stronghold 2.x :
    StrongholdAccelerator engineSSLCryptoDevice enginerenombrada
    StrongholdKey dir-funcionalidad no requerida
    StrongholdLicenseFile dir-funcionalidad no requerida
    SSLFlag flagSSLEngine flagrenombrada
    SSLSessionLockFile ficheroSSLMutex ficherorenombrada
    SSLCipherList specSSLCipherSuite specrenombrada
    RequireSSLSSLRequireSSLrenombrada
    SSLErrorFile fichero-funcionalidad no soportada
    SSLRoot dir-funcionalidad no soportada
    SSL_CertificateLogDir dir-funcionalidad no soportada
    AuthCertDir dir-funcionalidad no soportada
    SSL_Group name-funcionalidad no soportada
    SSLProxyMachineCertPath dirSSLProxyMachineCertificatePath dirrenombrada
    SSLProxyMachineCertFile ficheroSSLProxyMachineCertificateFile ficherorenombrada
    SSLProxyCipherList specSSLProxyCipherSpec specrenombrada
    - -
    top
    -
    -

    Variables de Entorno

    - -

    Correlacin entre las variables de entorno usadas por soluciones antiguas de SSL y las usadas -por mod_ssl que se muestran en la Table 2.

    - -

    Tabla 2: Derivacin de las Variables de Entorno

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Variable AntiguaVariable mod_sslComentario
    SSL_PROTOCOL_VERSIONSSL_PROTOCOLrenombrada
    SSLEAY_VERSIONSSL_VERSION_LIBRARYrenombrada
    HTTPS_SECRETKEYSIZESSL_CIPHER_USEKEYSIZErenombrada
    HTTPS_KEYSIZESSL_CIPHER_ALGKEYSIZErenombrada
    HTTPS_CIPHERSSL_CIPHERrenombrada
    HTTPS_EXPORTSSL_CIPHER_EXPORTrenombrada
    SSL_SERVER_KEY_SIZESSL_CIPHER_ALGKEYSIZErenombrada
    SSL_SERVER_CERTIFICATESSL_SERVER_CERTrenombrada
    SSL_SERVER_CERT_STARTSSL_SERVER_V_STARTrenombrada
    SSL_SERVER_CERT_ENDSSL_SERVER_V_ENDrenombrada
    SSL_SERVER_CERT_SERIALSSL_SERVER_M_SERIALrenombrada
    SSL_SERVER_SIGNATURE_ALGORITHMSSL_SERVER_A_SIGrenombrada
    SSL_SERVER_DNSSL_SERVER_S_DNrenombrada
    SSL_SERVER_CNSSL_SERVER_S_DN_CNrenombrada
    SSL_SERVER_EMAILSSL_SERVER_S_DN_Emailrenombrada
    SSL_SERVER_OSSL_SERVER_S_DN_Orenombrada
    SSL_SERVER_OUSSL_SERVER_S_DN_OUrenombrada
    SSL_SERVER_CSSL_SERVER_S_DN_Crenombrada
    SSL_SERVER_SPSSL_SERVER_S_DN_SPrenombrada
    SSL_SERVER_LSSL_SERVER_S_DN_Lrenombrada
    SSL_SERVER_IDNSSL_SERVER_I_DNrenombrada
    SSL_SERVER_ICNSSL_SERVER_I_DN_CNrenombrada
    SSL_SERVER_IEMAILSSL_SERVER_I_DN_Emailrenombrada
    SSL_SERVER_IOSSL_SERVER_I_DN_Orenombrada
    SSL_SERVER_IOUSSL_SERVER_I_DN_OUrenombrada
    SSL_SERVER_ICSSL_SERVER_I_DN_Crenombrada
    SSL_SERVER_ISPSSL_SERVER_I_DN_SPrenombrada
    SSL_SERVER_ILSSL_SERVER_I_DN_Lrenombrada
    SSL_CLIENT_CERTIFICATESSL_CLIENT_CERTrenombrada
    SSL_CLIENT_CERT_STARTSSL_CLIENT_V_STARTrenombrada
    SSL_CLIENT_CERT_ENDSSL_CLIENT_V_ENDrenombrada
    SSL_CLIENT_CERT_SERIALSSL_CLIENT_M_SERIALrenombrada
    SSL_CLIENT_SIGNATURE_ALGORITHMSSL_CLIENT_A_SIGrenombrada
    SSL_CLIENT_DNSSL_CLIENT_S_DNrenombrada
    SSL_CLIENT_CNSSL_CLIENT_S_DN_CNrenombrada
    SSL_CLIENT_EMAILSSL_CLIENT_S_DN_Emailrenombrada
    SSL_CLIENT_OSSL_CLIENT_S_DN_Orenombrada
    SSL_CLIENT_OUSSL_CLIENT_S_DN_OUrenombrada
    SSL_CLIENT_CSSL_CLIENT_S_DN_Crenombrada
    SSL_CLIENT_SPSSL_CLIENT_S_DN_SPrenombrada
    SSL_CLIENT_LSSL_CLIENT_S_DN_Lrenombrada
    SSL_CLIENT_IDNSSL_CLIENT_I_DNrenombrada
    SSL_CLIENT_ICNSSL_CLIENT_I_DN_CNrenombrada
    SSL_CLIENT_IEMAILSSL_CLIENT_I_DN_Emailrenombrada
    SSL_CLIENT_IOSSL_CLIENT_I_DN_Orenombrada
    SSL_CLIENT_IOUSSL_CLIENT_I_DN_OUrenombrada
    SSL_CLIENT_ICSSL_CLIENT_I_DN_Crenombrada
    SSL_CLIENT_ISPSSL_CLIENT_I_DN_SPrenombrada
    SSL_CLIENT_ILSSL_CLIENT_I_DN_Lrenombrada
    SSL_EXPORTSSL_CIPHER_EXPORTrenombrada
    SSL_KEYSIZESSL_CIPHER_ALGKEYSIZErenombrada
    SSL_SECKEYSIZESSL_CIPHER_USEKEYSIZErenombrada
    SSL_SSLEAY_VERSIONSSL_VERSION_LIBRARYrenombrada
    SSL_STRONG_CRYPTO-No soportado por mod_ssl
    SSL_SERVER_KEY_EXP-No soportado por mod_ssl
    SSL_SERVER_KEY_ALGORITHM-No soportado por mod_ssl
    SSL_SERVER_KEY_SIZE-No soportado por mod_ssl
    SSL_SERVER_SESSIONDIR-No soportado por mod_ssl
    SSL_SERVER_CERTIFICATELOGDIR-No soportado por mod_ssl
    SSL_SERVER_CERTFILE-No soportado por mod_ssl
    SSL_SERVER_KEYFILE-No soportado por mod_ssl
    SSL_SERVER_KEYFILETYPE-No soportado por mod_ssl
    SSL_CLIENT_KEY_EXP-No soportado por mod_ssl
    SSL_CLIENT_KEY_ALGORITHM-No soportado por mod_ssl
    SSL_CLIENT_KEY_SIZE-No soportado por mod_ssl
    - -
    top
    -
    -

    Funciones Personalizadas de Log

    -

    -Cuando est habilitado el mdulo mod_ssl, existen funciones adicionales -para el Formato de Log Personalizado -mod_log_config como se documenta en el captulo referenciado. -Junto con la funcin de formato de eXtensin ``%{varname}x'' -la cual puede ser usada para extender cualquier variable proporcionada por cualquier mdulo, -una funcin criptogrfica de formato adicional -``%{name}c'' cryptography format function -exists for backward compatibility. The currently implemented function calls -are listed in Table 3.

    - -

    Table 3: Funciones criptogrficas de Log Personalizado

    - - - - - - - - - - - -
    Llamada a la FuncinDescripcin
    %...{version}c SSL protocol version
    %...{cipher}c SSL cipher
    %...{subjectdn}c Client Certificate Subject Distinguished Name
    %...{issuerdn}c Client Certificate Issuer Distinguished Name
    %...{errcode}c Certificate Verification Error (numerical)
    %...{errstr}c Certificate Verification Error (string)
    - -
    -
    -

    Idiomas disponibles:  en  | - es  | - fr 

    -
    top

    Comentarios

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    -
    - \ No newline at end of file diff --git a/docs/manual/ssl/ssl_compat.html.es.utf8 b/docs/manual/ssl/ssl_compat.html.es.utf8 new file mode 100644 index 0000000000..0db2571e64 --- /dev/null +++ b/docs/manual/ssl/ssl_compat.html.es.utf8 @@ -0,0 +1,258 @@ + + + + + +Cifrado Robusto SSL/TLS: Compatibilidad - Servidor HTTP Apache Versin 2.5 + + + + + + +
    +

    Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

    +

    Versin 2.5 del Servidor HTTP Apache

    +
    +
    <-
    +

    Cifrado Robusto SSL/TLS: Compatibilidad

    +
    +

    Idiomas disponibles:  en  | + es  | + fr 

    +
    + +

    +En esta pgina se cubre la compatibilidad entre el mdulo mod_ssl +y otras soluciones SSL. +mod_ssl no es la nica solucin de SSL para Apache HTTPD Server; +Para productos adicionales que estn (o estaban) disponibles como Ben Laurie's +en su web, que ahora no existe (http://www.apache-ssl.org/), donde fue la +derivacin original en 1998 del mdulo. +Tanto el sistema de Red Hat +Secure Web Server se bas en mod_ssl as como la versin comercial del + + mdulo SSL de Covalent's Raven, y por ltimo, C2Net (ahora de Red Hat) + basado en una rama de evaluacin del proyecto llamado Sioux con un + "Stronghold 2.x" y basado en mod_ssl desde la versin "Stronghold 3.x". + + + +

    + +

    +mod_ssl proporciona un superconjunto de la funcionalidad de todas las dems +soluciones, por lo que ser simple la migracin de mdulos antiguos al +mod_ssl. +Las directivas de configuracin y nombres de variables de entorno usadas +por mdulos antiguos de SSL varan mucho de mod_ssl; +tablas de correspondencia con lo usado por mod_ssl, se detallan a continuacin. +

    +
    + +
    top
    +
    +

    Directivas de Configuracin

    +

    La correspondencia entre las directivas de configuracin usadas por +Apache-SSL 1.x y mod_ssl 2.0.x se dan en la Tabla +1. La correspondencia de Sioux 1.x y Stronghold 2.x es solo parcial +debido a funcionalidades especiales en estas interfaces que mod_ssl no proporciona. +

    + + +

    Table 1: Correspondencia de Directivas de Configuracin

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Directivas AntiguasDirectivas mod_ssl Comentarios
    Compatibilidad de Apache-SSL 1.x & mod_ssl 2.0.x:
    SSLEnableSSLEngine oncompactified
    SSLDisableSSLEngine offcompactified
    SSLLogFile ficheroUse per-module LogLevel setting instead.
    SSLRequiredCiphers specSSLCipherSuite specrenombrada
    SSLRequireCipher c1 ...SSLRequire %{SSL_CIPHER} in {"c1", +...}generalized
    SSLBanCipher c1 ...SSLRequire not (%{SSL_CIPHER} in {"c1", +...})generalized
    SSLFakeBasicAuthSSLOptions +FakeBasicAuthmerged
    SSLCacheServerPath dir-functionality removed
    SSLCacheServerPort integer-functionality removed
    Compatibilidad Apache-SSL 1.x :
    SSLExportClientCertificatesSSLOptions +ExportCertDatamerged
    SSLCacheServerRunDir dir-funcionalidad no soportada
    Compatibilidad Sioux 1.x :
    SSL_CertFile ficheroSSLCertificateFile ficherorenombrada
    SSL_KeyFile ficheroSSLCertificateKeyFile ficherorenombrada
    SSL_CipherSuite argSSLCipherSuite argrenombrada
    SSL_X509VerifyDir argSSLCACertificatePath argrenombrada
    SSL_Log fichero-Use per-module LogLevel setting instead.
    SSL_Connect flagSSLEngine flagrenombrada
    SSL_ClientAuth argSSLVerifyClient argrenombrada
    SSL_X509VerifyDepth argSSLVerifyDepth argrenombrada
    SSL_FetchKeyPhraseFrom arg-not directly mappable; use SSLPassPhraseDialog
    SSL_SessionDir dir-not directly mappable; use SSLSessionCache
    SSL_Require expr-not directly mappable; use SSLRequire
    SSL_CertFileType arg-funcionalidad no soportada
    SSL_KeyFileType arg-funcionalidad no soportada
    SSL_X509VerifyPolicy arg-funcionalidad no soportada
    SSL_LogX509Attributes arg-funcionalidad no soportada
    Compatibilidad Stronghold 2.x :
    StrongholdAccelerator engineSSLCryptoDevice enginerenombrada
    StrongholdKey dir-funcionalidad no requerida
    StrongholdLicenseFile dir-funcionalidad no requerida
    SSLFlag flagSSLEngine flagrenombrada
    SSLSessionLockFile ficheroSSLMutex ficherorenombrada
    SSLCipherList specSSLCipherSuite specrenombrada
    RequireSSLSSLRequireSSLrenombrada
    SSLErrorFile fichero-funcionalidad no soportada
    SSLRoot dir-funcionalidad no soportada
    SSL_CertificateLogDir dir-funcionalidad no soportada
    AuthCertDir dir-funcionalidad no soportada
    SSL_Group name-funcionalidad no soportada
    SSLProxyMachineCertPath dirSSLProxyMachineCertificatePath dirrenombrada
    SSLProxyMachineCertFile ficheroSSLProxyMachineCertificateFile ficherorenombrada
    SSLProxyCipherList specSSLProxyCipherSpec specrenombrada
    + +
    top
    +
    +

    Variables de Entorno

    + +

    Correlacin entre las variables de entorno usadas por soluciones antiguas de SSL y las usadas +por mod_ssl que se muestran en la Table 2.

    + +

    Tabla 2: Derivacin de las Variables de Entorno

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Variable AntiguaVariable mod_sslComentario
    SSL_PROTOCOL_VERSIONSSL_PROTOCOLrenombrada
    SSLEAY_VERSIONSSL_VERSION_LIBRARYrenombrada
    HTTPS_SECRETKEYSIZESSL_CIPHER_USEKEYSIZErenombrada
    HTTPS_KEYSIZESSL_CIPHER_ALGKEYSIZErenombrada
    HTTPS_CIPHERSSL_CIPHERrenombrada
    HTTPS_EXPORTSSL_CIPHER_EXPORTrenombrada
    SSL_SERVER_KEY_SIZESSL_CIPHER_ALGKEYSIZErenombrada
    SSL_SERVER_CERTIFICATESSL_SERVER_CERTrenombrada
    SSL_SERVER_CERT_STARTSSL_SERVER_V_STARTrenombrada
    SSL_SERVER_CERT_ENDSSL_SERVER_V_ENDrenombrada
    SSL_SERVER_CERT_SERIALSSL_SERVER_M_SERIALrenombrada
    SSL_SERVER_SIGNATURE_ALGORITHMSSL_SERVER_A_SIGrenombrada
    SSL_SERVER_DNSSL_SERVER_S_DNrenombrada
    SSL_SERVER_CNSSL_SERVER_S_DN_CNrenombrada
    SSL_SERVER_EMAILSSL_SERVER_S_DN_Emailrenombrada
    SSL_SERVER_OSSL_SERVER_S_DN_Orenombrada
    SSL_SERVER_OUSSL_SERVER_S_DN_OUrenombrada
    SSL_SERVER_CSSL_SERVER_S_DN_Crenombrada
    SSL_SERVER_SPSSL_SERVER_S_DN_SPrenombrada
    SSL_SERVER_LSSL_SERVER_S_DN_Lrenombrada
    SSL_SERVER_IDNSSL_SERVER_I_DNrenombrada
    SSL_SERVER_ICNSSL_SERVER_I_DN_CNrenombrada
    SSL_SERVER_IEMAILSSL_SERVER_I_DN_Emailrenombrada
    SSL_SERVER_IOSSL_SERVER_I_DN_Orenombrada
    SSL_SERVER_IOUSSL_SERVER_I_DN_OUrenombrada
    SSL_SERVER_ICSSL_SERVER_I_DN_Crenombrada
    SSL_SERVER_ISPSSL_SERVER_I_DN_SPrenombrada
    SSL_SERVER_ILSSL_SERVER_I_DN_Lrenombrada
    SSL_CLIENT_CERTIFICATESSL_CLIENT_CERTrenombrada
    SSL_CLIENT_CERT_STARTSSL_CLIENT_V_STARTrenombrada
    SSL_CLIENT_CERT_ENDSSL_CLIENT_V_ENDrenombrada
    SSL_CLIENT_CERT_SERIALSSL_CLIENT_M_SERIALrenombrada
    SSL_CLIENT_SIGNATURE_ALGORITHMSSL_CLIENT_A_SIGrenombrada
    SSL_CLIENT_DNSSL_CLIENT_S_DNrenombrada
    SSL_CLIENT_CNSSL_CLIENT_S_DN_CNrenombrada
    SSL_CLIENT_EMAILSSL_CLIENT_S_DN_Emailrenombrada
    SSL_CLIENT_OSSL_CLIENT_S_DN_Orenombrada
    SSL_CLIENT_OUSSL_CLIENT_S_DN_OUrenombrada
    SSL_CLIENT_CSSL_CLIENT_S_DN_Crenombrada
    SSL_CLIENT_SPSSL_CLIENT_S_DN_SPrenombrada
    SSL_CLIENT_LSSL_CLIENT_S_DN_Lrenombrada
    SSL_CLIENT_IDNSSL_CLIENT_I_DNrenombrada
    SSL_CLIENT_ICNSSL_CLIENT_I_DN_CNrenombrada
    SSL_CLIENT_IEMAILSSL_CLIENT_I_DN_Emailrenombrada
    SSL_CLIENT_IOSSL_CLIENT_I_DN_Orenombrada
    SSL_CLIENT_IOUSSL_CLIENT_I_DN_OUrenombrada
    SSL_CLIENT_ICSSL_CLIENT_I_DN_Crenombrada
    SSL_CLIENT_ISPSSL_CLIENT_I_DN_SPrenombrada
    SSL_CLIENT_ILSSL_CLIENT_I_DN_Lrenombrada
    SSL_EXPORTSSL_CIPHER_EXPORTrenombrada
    SSL_KEYSIZESSL_CIPHER_ALGKEYSIZErenombrada
    SSL_SECKEYSIZESSL_CIPHER_USEKEYSIZErenombrada
    SSL_SSLEAY_VERSIONSSL_VERSION_LIBRARYrenombrada
    SSL_STRONG_CRYPTO-No soportado por mod_ssl
    SSL_SERVER_KEY_EXP-No soportado por mod_ssl
    SSL_SERVER_KEY_ALGORITHM-No soportado por mod_ssl
    SSL_SERVER_KEY_SIZE-No soportado por mod_ssl
    SSL_SERVER_SESSIONDIR-No soportado por mod_ssl
    SSL_SERVER_CERTIFICATELOGDIR-No soportado por mod_ssl
    SSL_SERVER_CERTFILE-No soportado por mod_ssl
    SSL_SERVER_KEYFILE-No soportado por mod_ssl
    SSL_SERVER_KEYFILETYPE-No soportado por mod_ssl
    SSL_CLIENT_KEY_EXP-No soportado por mod_ssl
    SSL_CLIENT_KEY_ALGORITHM-No soportado por mod_ssl
    SSL_CLIENT_KEY_SIZE-No soportado por mod_ssl
    + +
    top
    +
    +

    Funciones Personalizadas de Log

    +

    +Cuando est habilitado el mdulo mod_ssl, existen funciones adicionales +para el Formato de Log Personalizado +mod_log_config como se documenta en el captulo referenciado. +Junto con la funcin de formato de eXtensin ``%{varname}x'' +la cual puede ser usada para extender cualquier variable proporcionada por cualquier mdulo, +una funcin criptogrfica de formato adicional +``%{name}c'' cryptography format function +exists for backward compatibility. The currently implemented function calls +are listed in Table 3.

    + +

    Table 3: Funciones criptogrficas de Log Personalizado

    + + + + + + + + + + + +
    Llamada a la FuncinDescripcin
    %...{version}c SSL protocol version
    %...{cipher}c SSL cipher
    %...{subjectdn}c Client Certificate Subject Distinguished Name
    %...{issuerdn}c Client Certificate Issuer Distinguished Name
    %...{errcode}c Certificate Verification Error (numerical)
    %...{errstr}c Certificate Verification Error (string)
    + +
    +
    +

    Idiomas disponibles:  en  | + es  | + fr 

    +
    top

    Comentarios

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    +
    + \ No newline at end of file diff --git a/docs/manual/ssl/ssl_compat.html.fr b/docs/manual/ssl/ssl_compat.html.fr deleted file mode 100644 index d8c2ed0080..0000000000 --- a/docs/manual/ssl/ssl_compat.html.fr +++ /dev/null @@ -1,259 +0,0 @@ - - - - - -Chiffrement fort SSL/TLS : Compatibilité - Serveur HTTP Apache Version 2.5 - - - - - - -
    -

    Modules | Directives | FAQ | Glossaire | Plan du site

    -

    Serveur HTTP Apache Version 2.5

    -
    -
    <-
    -

    Chiffrement fort SSL/TLS : Compatibilité

    -
    -

    Langues Disponibles:  en  | - es  | - fr 

    -
    - - -

    Ce document couvre la compatibilité ascendante entre mod_ssl et -d'autres solutions SSL. mod_ssl n'est pas la seule solution SSL pour Apache ; -quatre autres produits sont (ou ont été) également disponibles : -Apache-SSL, le produit libre de -Ben Laurie (d'où mod_ssl est issu à l'origine en 1998), Secure -Web Server, un produit commercial de Red Hat (basé sur mod_ssl), -Raven SSL Module, un produit commercial -de Covalent (basé lui aussi sur mod_ssl), et enfin Stronghold, produit -commercial de C2Net et maintenant de Red Hat, (basé sur une branche -d'évolution différente appelée Sioux jusqu'à Stronghold 2.x et basé sur -mod_ssl depuis Stronghold 3.x).

    - -

    En plus de ses fonctionnalités propres, mod_ssl rassemble la plupart de -celles des autres solutions SSL, si bien qu'il est très simple de -migrer depuis un module plus ancien vers mod_ssl. Les directives de -configuration et les noms des variables d'environnement utilisés par les -solutions SSL plus anciennes diffèrent de ceux qu'utilise mod_ssl ; -les tableaux de correspondance ci-dessous fournissent les équivalences -de termes utilisés par mod_ssl.

    -
    - -
    top
    -
    -

    Directives de configuration

    -

    La correspondance entre les directives de configuration qu'utilise -Apache-SSL 1.x et mod_ssl 2.0.x est fournie dans le Tableau -1. La correspondance depuis Sioux 1.x et Stronghold 2.x n'est que -partielle car certaines fonctionnalités de ces interfaces ne sont pas -supportées par mod_ssl.

    - - -

    Tableau 1: Correspondance entre les directives de configuration

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Ancienne directiveDirective mod_sslCommentaires
    Compatibilité entre Apache-SSL 1.x et mod_ssl 2.0.x :
    SSLEnableSSLEngine onplus compacte
    SSLDisableSSLEngine offplus compacte
    SSLLogFile -fileUtilisez plutôt la directive -de niveau module LogLevel.
    SSLRequiredCiphers specSSLCipherSuite specrenommée
    SSLRequireCipher c1 ...SSLRequire %{SSL_CIPHER} in {"c1", -...}plus générale
    SSLBanCipher c1 ...SSLRequire not (%{SSL_CIPHER} in {"c1", -...})plus générale
    SSLFakeBasicAuthSSLOptions +FakeBasicAuthrassemblées
    SSLCacheServerPath dir-fonctionnalité supprimée
    SSLCacheServerPort integer-fonctionnalité supprimée
    Compatibilité avec Apache-SSL 1.x :
    SSLExportClientCertificatesSSLOptions +ExportCertDatarassemblées
    SSLCacheServerRunDir dir-fonctionnalité non supportée
    Compatibilité avec Sioux 1.x :
    SSL_CertFile fileSSLCertificateFile filerenommée
    SSL_KeyFile fileSSLCertificateKeyFile filerenommée
    SSL_CipherSuite argSSLCipherSuite argrenommée
    SSL_X509VerifyDir argSSLCACertificatePath argrenommée
    SSL_Log -file-Utilisez plutôt la directive -de niveau module LogLevel
    SSL_Connect flagSSLEngine flagrenommée
    SSL_ClientAuth argSSLVerifyClient argrenommée
    SSL_X509VerifyDepth argSSLVerifyDepth argrenommée
    SSL_FetchKeyPhraseFrom arg-pas de véritable équivalent ; utiliser SSLPassPhraseDialog
    SSL_SessionDir dir-pas de véritable équivalent ; utiliser SSLSessionCache
    SSL_Require expr-pas de véritable équivalent ; utiliser SSLRequire
    SSL_CertFileType arg-fonctionnalité non supportée
    SSL_KeyFileType arg-fonctionnalité non supportée
    SSL_X509VerifyPolicy arg-fonctionnalité non supportée
    SSL_LogX509Attributes arg-fonctionnalité non supportée
    Compatibilité avec Stronghold 2.x :
    StrongholdAccelerator engineSSLCryptoDevice enginerenommée
    StrongholdKey dir-sans objet
    StrongholdLicenseFile dir-sans objet
    SSLFlag flagSSLEngine flagrenommée
    SSLSessionLockFile fileSSLMutex filerenommée
    SSLCipherList specSSLCipherSuite specrenommée
    RequireSSLSSLRequireSSLrenommée
    SSLErrorFile file-fonctionnalité non supportée
    SSLRoot dir-fonctionnalité non supportée
    SSL_CertificateLogDir dir-fonctionnalité non supportée
    AuthCertDir dir-fonctionnalité non supportée
    SSL_Group name-fonctionnalité non supportée
    SSLProxyMachineCertPath dirSSLProxyMachineCertificatePath dirrenommée
    SSLProxyMachineCertFile fileSSLProxyMachineCertificateFile filerenommée
    SSLProxyCipherList specSSLProxyCipherSpec specrenommée
    - -
    top
    -
    -

    Variables d'environnement

    - -

    La correspondance entre les noms des variables d'environnement utilisés par -les solutions SSL plus anciennes et les noms utilisés par mod_ssl est fournie -dans le Tableau 2.

    - -

    Tableau 2: Dérivation des variables d'environnement

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Ancienne variableVariable mod_sslCommentaires
    SSL_PROTOCOL_VERSIONSSL_PROTOCOLrenommée
    SSLEAY_VERSIONSSL_VERSION_LIBRARYrenommée
    HTTPS_SECRETKEYSIZESSL_CIPHER_USEKEYSIZErenommée
    HTTPS_KEYSIZESSL_CIPHER_ALGKEYSIZErenommée
    HTTPS_CIPHERSSL_CIPHERrenommée
    HTTPS_EXPORTSSL_CIPHER_EXPORTrenommée
    SSL_SERVER_KEY_SIZESSL_CIPHER_ALGKEYSIZErenommée
    SSL_SERVER_CERTIFICATESSL_SERVER_CERTrenommée
    SSL_SERVER_CERT_STARTSSL_SERVER_V_STARTrenommée
    SSL_SERVER_CERT_ENDSSL_SERVER_V_ENDrenommée
    SSL_SERVER_CERT_SERIALSSL_SERVER_M_SERIALrenommée
    SSL_SERVER_SIGNATURE_ALGORITHMSSL_SERVER_A_SIGrenommée
    SSL_SERVER_DNSSL_SERVER_S_DNrenommée
    SSL_SERVER_CNSSL_SERVER_S_DN_CNrenommée
    SSL_SERVER_EMAILSSL_SERVER_S_DN_Emailrenommée
    SSL_SERVER_OSSL_SERVER_S_DN_Orenommée
    SSL_SERVER_OUSSL_SERVER_S_DN_OUrenommée
    SSL_SERVER_CSSL_SERVER_S_DN_Crenommée
    SSL_SERVER_SPSSL_SERVER_S_DN_SPrenommée
    SSL_SERVER_LSSL_SERVER_S_DN_Lrenommée
    SSL_SERVER_IDNSSL_SERVER_I_DNrenommée
    SSL_SERVER_ICNSSL_SERVER_I_DN_CNrenommée
    SSL_SERVER_IEMAILSSL_SERVER_I_DN_Emailrenommée
    SSL_SERVER_IOSSL_SERVER_I_DN_Orenommée
    SSL_SERVER_IOUSSL_SERVER_I_DN_OUrenommée
    SSL_SERVER_ICSSL_SERVER_I_DN_Crenommée
    SSL_SERVER_ISPSSL_SERVER_I_DN_SPrenommée
    SSL_SERVER_ILSSL_SERVER_I_DN_Lrenommée
    SSL_CLIENT_CERTIFICATESSL_CLIENT_CERTrenommée
    SSL_CLIENT_CERT_STARTSSL_CLIENT_V_STARTrenommée
    SSL_CLIENT_CERT_ENDSSL_CLIENT_V_ENDrenommée
    SSL_CLIENT_CERT_SERIALSSL_CLIENT_M_SERIALrenommée
    SSL_CLIENT_SIGNATURE_ALGORITHMSSL_CLIENT_A_SIGrenommée
    SSL_CLIENT_DNSSL_CLIENT_S_DNrenommée
    SSL_CLIENT_CNSSL_CLIENT_S_DN_CNrenommée
    SSL_CLIENT_EMAILSSL_CLIENT_S_DN_Emailrenommée
    SSL_CLIENT_OSSL_CLIENT_S_DN_Orenommée
    SSL_CLIENT_OUSSL_CLIENT_S_DN_OUrenommée
    SSL_CLIENT_CSSL_CLIENT_S_DN_Crenommée
    SSL_CLIENT_SPSSL_CLIENT_S_DN_SPrenommée
    SSL_CLIENT_LSSL_CLIENT_S_DN_Lrenommée
    SSL_CLIENT_IDNSSL_CLIENT_I_DNrenommée
    SSL_CLIENT_ICNSSL_CLIENT_I_DN_CNrenommée
    SSL_CLIENT_IEMAILSSL_CLIENT_I_DN_Emailrenommée
    SSL_CLIENT_IOSSL_CLIENT_I_DN_Orenommée
    SSL_CLIENT_IOUSSL_CLIENT_I_DN_OUrenommée
    SSL_CLIENT_ICSSL_CLIENT_I_DN_Crenommée
    SSL_CLIENT_ISPSSL_CLIENT_I_DN_SPrenommée
    SSL_CLIENT_ILSSL_CLIENT_I_DN_Lrenommée
    SSL_EXPORTSSL_CIPHER_EXPORTrenommée
    SSL_KEYSIZESSL_CIPHER_ALGKEYSIZErenommée
    SSL_SECKEYSIZESSL_CIPHER_USEKEYSIZErenommée
    SSL_SSLEAY_VERSIONSSL_VERSION_LIBRARYrenommée
    SSL_STRONG_CRYPTO-Non supportée par mod_ssl
    SSL_SERVER_KEY_EXP-Non supportée par mod_ssl
    SSL_SERVER_KEY_ALGORITHM-Non supportée par mod_ssl
    SSL_SERVER_KEY_SIZE-Non supportée par mod_ssl
    SSL_SERVER_SESSIONDIR-Non supportée par mod_ssl
    SSL_SERVER_CERTIFICATELOGDIR-Non supportée par mod_ssl
    SSL_SERVER_CERTFILE-Non supportée par mod_ssl
    SSL_SERVER_KEYFILE-Non supportée par mod_ssl
    SSL_SERVER_KEYFILETYPE-Non supportée par mod_ssl
    SSL_CLIENT_KEY_EXP-Non supportée par mod_ssl
    SSL_CLIENT_KEY_ALGORITHM-Non supportée par mod_ssl
    SSL_CLIENT_KEY_SIZE-Non supportée par mod_ssl
    - -
    top
    -
    -

    Fonctions de personnalisation des journaux

    -

    Quand mod_ssl est activé, le Format de journal courant -(Custom Log Format) du module mod_log_config possède -des fonctions supplémentaires comme indiqué dans le chapitre de référence. -En plus de la fonction de format étendu -``%{varname}x'' que l'on peut utiliser pour -extraire le contenu d'une variable fournie par n'importe quel module, -la fonction -de format cryptographique ``%{name}c'' a -été ajoutée à des fins de compatibilité ascendante. Les appels de fonctions -actuellement implémentés sont énumérés dans le -Tableau 3.

    - -

    Table 3: Fonctions cryptographiques du format de journal courant

    - - - - - - - - - - - - -
    Appel de fonctionDescription
    %...{version}c Version du protocole SSL
    %...{cipher}c Chiffrement SSL
    %...{subjectdn}c Nom distinctif du sujet du certificat du client
    %...{issuerdn}c Nom distinctif de l'émetteur du certificat du client
    %...{errcode}c Erreur lors de la vérification du certificat (numérique)
    %...{errstr}c Erreur lors de la vérification du certificat (chaîne de caractères)
    - -
    -
    -

    Langues Disponibles:  en  | - es  | - fr 

    -
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    -
    - \ No newline at end of file diff --git a/docs/manual/ssl/ssl_compat.html.fr.utf8 b/docs/manual/ssl/ssl_compat.html.fr.utf8 new file mode 100644 index 0000000000..d8c2ed0080 --- /dev/null +++ b/docs/manual/ssl/ssl_compat.html.fr.utf8 @@ -0,0 +1,259 @@ + + + + + +Chiffrement fort SSL/TLS : Compatibilité - Serveur HTTP Apache Version 2.5 + + + + + + +
    +

    Modules | Directives | FAQ | Glossaire | Plan du site

    +

    Serveur HTTP Apache Version 2.5

    +
    +
    <-
    +

    Chiffrement fort SSL/TLS : Compatibilité

    +
    +

    Langues Disponibles:  en  | + es  | + fr 

    +
    + + +

    Ce document couvre la compatibilité ascendante entre mod_ssl et +d'autres solutions SSL. mod_ssl n'est pas la seule solution SSL pour Apache ; +quatre autres produits sont (ou ont été) également disponibles : +Apache-SSL, le produit libre de +Ben Laurie (d'où mod_ssl est issu à l'origine en 1998), Secure +Web Server, un produit commercial de Red Hat (basé sur mod_ssl), +Raven SSL Module, un produit commercial +de Covalent (basé lui aussi sur mod_ssl), et enfin Stronghold, produit +commercial de C2Net et maintenant de Red Hat, (basé sur une branche +d'évolution différente appelée Sioux jusqu'à Stronghold 2.x et basé sur +mod_ssl depuis Stronghold 3.x).

    + +

    En plus de ses fonctionnalités propres, mod_ssl rassemble la plupart de +celles des autres solutions SSL, si bien qu'il est très simple de +migrer depuis un module plus ancien vers mod_ssl. Les directives de +configuration et les noms des variables d'environnement utilisés par les +solutions SSL plus anciennes diffèrent de ceux qu'utilise mod_ssl ; +les tableaux de correspondance ci-dessous fournissent les équivalences +de termes utilisés par mod_ssl.

    +
    + +
    top
    +
    +

    Directives de configuration

    +

    La correspondance entre les directives de configuration qu'utilise +Apache-SSL 1.x et mod_ssl 2.0.x est fournie dans le Tableau +1. La correspondance depuis Sioux 1.x et Stronghold 2.x n'est que +partielle car certaines fonctionnalités de ces interfaces ne sont pas +supportées par mod_ssl.

    + + +

    Tableau 1: Correspondance entre les directives de configuration

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Ancienne directiveDirective mod_sslCommentaires
    Compatibilité entre Apache-SSL 1.x et mod_ssl 2.0.x :
    SSLEnableSSLEngine onplus compacte
    SSLDisableSSLEngine offplus compacte
    SSLLogFile +fileUtilisez plutôt la directive +de niveau module LogLevel.
    SSLRequiredCiphers specSSLCipherSuite specrenommée
    SSLRequireCipher c1 ...SSLRequire %{SSL_CIPHER} in {"c1", +...}plus générale
    SSLBanCipher c1 ...SSLRequire not (%{SSL_CIPHER} in {"c1", +...})plus générale
    SSLFakeBasicAuthSSLOptions +FakeBasicAuthrassemblées
    SSLCacheServerPath dir-fonctionnalité supprimée
    SSLCacheServerPort integer-fonctionnalité supprimée
    Compatibilité avec Apache-SSL 1.x :
    SSLExportClientCertificatesSSLOptions +ExportCertDatarassemblées
    SSLCacheServerRunDir dir-fonctionnalité non supportée
    Compatibilité avec Sioux 1.x :
    SSL_CertFile fileSSLCertificateFile filerenommée
    SSL_KeyFile fileSSLCertificateKeyFile filerenommée
    SSL_CipherSuite argSSLCipherSuite argrenommée
    SSL_X509VerifyDir argSSLCACertificatePath argrenommée
    SSL_Log +file-Utilisez plutôt la directive +de niveau module LogLevel
    SSL_Connect flagSSLEngine flagrenommée
    SSL_ClientAuth argSSLVerifyClient argrenommée
    SSL_X509VerifyDepth argSSLVerifyDepth argrenommée
    SSL_FetchKeyPhraseFrom arg-pas de véritable équivalent ; utiliser SSLPassPhraseDialog
    SSL_SessionDir dir-pas de véritable équivalent ; utiliser SSLSessionCache
    SSL_Require expr-pas de véritable équivalent ; utiliser SSLRequire
    SSL_CertFileType arg-fonctionnalité non supportée
    SSL_KeyFileType arg-fonctionnalité non supportée
    SSL_X509VerifyPolicy arg-fonctionnalité non supportée
    SSL_LogX509Attributes arg-fonctionnalité non supportée
    Compatibilité avec Stronghold 2.x :
    StrongholdAccelerator engineSSLCryptoDevice enginerenommée
    StrongholdKey dir-sans objet
    StrongholdLicenseFile dir-sans objet
    SSLFlag flagSSLEngine flagrenommée
    SSLSessionLockFile fileSSLMutex filerenommée
    SSLCipherList specSSLCipherSuite specrenommée
    RequireSSLSSLRequireSSLrenommée
    SSLErrorFile file-fonctionnalité non supportée
    SSLRoot dir-fonctionnalité non supportée
    SSL_CertificateLogDir dir-fonctionnalité non supportée
    AuthCertDir dir-fonctionnalité non supportée
    SSL_Group name-fonctionnalité non supportée
    SSLProxyMachineCertPath dirSSLProxyMachineCertificatePath dirrenommée
    SSLProxyMachineCertFile fileSSLProxyMachineCertificateFile filerenommée
    SSLProxyCipherList specSSLProxyCipherSpec specrenommée
    + +
    top
    +
    +

    Variables d'environnement

    + +

    La correspondance entre les noms des variables d'environnement utilisés par +les solutions SSL plus anciennes et les noms utilisés par mod_ssl est fournie +dans le Tableau 2.

    + +

    Tableau 2: Dérivation des variables d'environnement

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Ancienne variableVariable mod_sslCommentaires
    SSL_PROTOCOL_VERSIONSSL_PROTOCOLrenommée
    SSLEAY_VERSIONSSL_VERSION_LIBRARYrenommée
    HTTPS_SECRETKEYSIZESSL_CIPHER_USEKEYSIZErenommée
    HTTPS_KEYSIZESSL_CIPHER_ALGKEYSIZErenommée
    HTTPS_CIPHERSSL_CIPHERrenommée
    HTTPS_EXPORTSSL_CIPHER_EXPORTrenommée
    SSL_SERVER_KEY_SIZESSL_CIPHER_ALGKEYSIZErenommée
    SSL_SERVER_CERTIFICATESSL_SERVER_CERTrenommée
    SSL_SERVER_CERT_STARTSSL_SERVER_V_STARTrenommée
    SSL_SERVER_CERT_ENDSSL_SERVER_V_ENDrenommée
    SSL_SERVER_CERT_SERIALSSL_SERVER_M_SERIALrenommée
    SSL_SERVER_SIGNATURE_ALGORITHMSSL_SERVER_A_SIGrenommée
    SSL_SERVER_DNSSL_SERVER_S_DNrenommée
    SSL_SERVER_CNSSL_SERVER_S_DN_CNrenommée
    SSL_SERVER_EMAILSSL_SERVER_S_DN_Emailrenommée
    SSL_SERVER_OSSL_SERVER_S_DN_Orenommée
    SSL_SERVER_OUSSL_SERVER_S_DN_OUrenommée
    SSL_SERVER_CSSL_SERVER_S_DN_Crenommée
    SSL_SERVER_SPSSL_SERVER_S_DN_SPrenommée
    SSL_SERVER_LSSL_SERVER_S_DN_Lrenommée
    SSL_SERVER_IDNSSL_SERVER_I_DNrenommée
    SSL_SERVER_ICNSSL_SERVER_I_DN_CNrenommée
    SSL_SERVER_IEMAILSSL_SERVER_I_DN_Emailrenommée
    SSL_SERVER_IOSSL_SERVER_I_DN_Orenommée
    SSL_SERVER_IOUSSL_SERVER_I_DN_OUrenommée
    SSL_SERVER_ICSSL_SERVER_I_DN_Crenommée
    SSL_SERVER_ISPSSL_SERVER_I_DN_SPrenommée
    SSL_SERVER_ILSSL_SERVER_I_DN_Lrenommée
    SSL_CLIENT_CERTIFICATESSL_CLIENT_CERTrenommée
    SSL_CLIENT_CERT_STARTSSL_CLIENT_V_STARTrenommée
    SSL_CLIENT_CERT_ENDSSL_CLIENT_V_ENDrenommée
    SSL_CLIENT_CERT_SERIALSSL_CLIENT_M_SERIALrenommée
    SSL_CLIENT_SIGNATURE_ALGORITHMSSL_CLIENT_A_SIGrenommée
    SSL_CLIENT_DNSSL_CLIENT_S_DNrenommée
    SSL_CLIENT_CNSSL_CLIENT_S_DN_CNrenommée
    SSL_CLIENT_EMAILSSL_CLIENT_S_DN_Emailrenommée
    SSL_CLIENT_OSSL_CLIENT_S_DN_Orenommée
    SSL_CLIENT_OUSSL_CLIENT_S_DN_OUrenommée
    SSL_CLIENT_CSSL_CLIENT_S_DN_Crenommée
    SSL_CLIENT_SPSSL_CLIENT_S_DN_SPrenommée
    SSL_CLIENT_LSSL_CLIENT_S_DN_Lrenommée
    SSL_CLIENT_IDNSSL_CLIENT_I_DNrenommée
    SSL_CLIENT_ICNSSL_CLIENT_I_DN_CNrenommée
    SSL_CLIENT_IEMAILSSL_CLIENT_I_DN_Emailrenommée
    SSL_CLIENT_IOSSL_CLIENT_I_DN_Orenommée
    SSL_CLIENT_IOUSSL_CLIENT_I_DN_OUrenommée
    SSL_CLIENT_ICSSL_CLIENT_I_DN_Crenommée
    SSL_CLIENT_ISPSSL_CLIENT_I_DN_SPrenommée
    SSL_CLIENT_ILSSL_CLIENT_I_DN_Lrenommée
    SSL_EXPORTSSL_CIPHER_EXPORTrenommée
    SSL_KEYSIZESSL_CIPHER_ALGKEYSIZErenommée
    SSL_SECKEYSIZESSL_CIPHER_USEKEYSIZErenommée
    SSL_SSLEAY_VERSIONSSL_VERSION_LIBRARYrenommée
    SSL_STRONG_CRYPTO-Non supportée par mod_ssl
    SSL_SERVER_KEY_EXP-Non supportée par mod_ssl
    SSL_SERVER_KEY_ALGORITHM-Non supportée par mod_ssl
    SSL_SERVER_KEY_SIZE-Non supportée par mod_ssl
    SSL_SERVER_SESSIONDIR-Non supportée par mod_ssl
    SSL_SERVER_CERTIFICATELOGDIR-Non supportée par mod_ssl
    SSL_SERVER_CERTFILE-Non supportée par mod_ssl
    SSL_SERVER_KEYFILE-Non supportée par mod_ssl
    SSL_SERVER_KEYFILETYPE-Non supportée par mod_ssl
    SSL_CLIENT_KEY_EXP-Non supportée par mod_ssl
    SSL_CLIENT_KEY_ALGORITHM-Non supportée par mod_ssl
    SSL_CLIENT_KEY_SIZE-Non supportée par mod_ssl
    + +
    top
    +
    +

    Fonctions de personnalisation des journaux

    +

    Quand mod_ssl est activé, le Format de journal courant +(Custom Log Format) du module mod_log_config possède +des fonctions supplémentaires comme indiqué dans le chapitre de référence. +En plus de la fonction de format étendu +``%{varname}x'' que l'on peut utiliser pour +extraire le contenu d'une variable fournie par n'importe quel module, +la fonction +de format cryptographique ``%{name}c'' a +été ajoutée à des fins de compatibilité ascendante. Les appels de fonctions +actuellement implémentés sont énumérés dans le +Tableau 3.

    + +

    Table 3: Fonctions cryptographiques du format de journal courant

    + + + + + + + + + + + + +
    Appel de fonctionDescription
    %...{version}c Version du protocole SSL
    %...{cipher}c Chiffrement SSL
    %...{subjectdn}c Nom distinctif du sujet du certificat du client
    %...{issuerdn}c Nom distinctif de l'émetteur du certificat du client
    %...{errcode}c Erreur lors de la vérification du certificat (numérique)
    %...{errstr}c Erreur lors de la vérification du certificat (chaîne de caractères)
    + +
    +
    +

    Langues Disponibles:  en  | + es  | + fr 

    +
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    +
    + \ No newline at end of file diff --git a/docs/manual/ssl/ssl_faq.html.en b/docs/manual/ssl/ssl_faq.html.en index e907e87c6c..632bb09d52 100644 --- a/docs/manual/ssl/ssl_faq.html.en +++ b/docs/manual/ssl/ssl_faq.html.en @@ -24,7 +24,7 @@ Apache > HTTP Server > Documentation > Version 2.5 > SSL/TLS

    SSL/TLS Strong Encryption: FAQ

    Available Languages:  en  | - fr 

    + fr 

    @@ -906,7 +906,7 @@ the reason for my core dump?

    Available Languages:  en  | - fr 

    + fr 

    top

    Comments

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    - - -
    -

    Modules | Directives | FAQ | Glossaire | Plan du site

    -

    Serveur HTTP Apache Version 2.5

    -
    -
    <-
    -

    Chiffrement SSL/TLS fort: foire aux questions

    -
    -

    Langues Disponibles:  en  | - fr 

    -
    - -
    -

    Le sage n'apporte pas de bonnes réponses, il pose les bonnes questions

    -

    -- Claude Levi-Strauss

    - -
    -
    - -
    top
    -
    -

    Installation

    - - -

    Pourquoi le démarrage d'Apache provoque-t-il des -erreurs de permission en rapport avec SSLMutex ?

    -

    Des erreurs telles que ``mod_ssl: Child could not open - SSLMutex lockfile /opt/apache/logs/ssl_mutex.18332 (avec l'erreur - système qui suit) [...] System: Permission denied (errno: 13)'' - sont souvent provoquées par des permissions trop restrictives sur les - répertoires parents. Assurez-vous que tous les répertoires - parents (ici /opt, /opt/apache et - /opt/apache/logs) ont le bit x positionné au moins pour - l'UID sous lequel les processus enfants d'Apache s'exécutent (voir la - directive User).

    - - -

    Pourquoi mod_ssl s'arrête-t-il avec l'erreur -"Failed to generate temporary 512 bit RSA private key" au démarrage -d'Apache ?

    -

    Pour fonctionner correctement, les logiciels de cryptographie ont - besoin d'une source de données aléatoires. De nombreux systèmes - d'exploitation libres proposent un "périphérique source d'entropie" - qui fournit ce service (il se nomme en général - /dev/random). Sur d'autres systèmes, les applications - doivent amorcer manuellement - le Générateur de Nombres Pseudo-Aléatoires d'OpenSSL - (Pseudo Random Number Generator -PRNG) à l'aide de données appropriées - avant de générer des clés ou d'effectuer un chiffrement à clé - publique. Depuis la version 0.9.5, les fonctions d'OpenSSL qui nécessitent - des données aléatoires provoquent une erreur si le PRNG n'a pas été amorcé - avec une source de données aléatoires d'au moins 128 bits.

    -

    Pour éviter cette erreur, mod_ssl doit fournir - suffisamment d'entropie au PRNG pour lui permettre de fonctionner - correctement. Ce niveau d'entropie est défini par la directive - SSLRandomSeed.

    - -
    top
    -
    -

    Configuration

    - - -

    Peut-on faire cohabiter HTTP et HTTPS sur le même -serveur ?

    -

    Oui. HTTP et HTTPS utilisent des ports différents (HTTP écoute le port - 80 et HTTPS le port 443), si bien qu'il n'y a pas de conflit direct entre - les deux. Vous pouvez soit exécuter deux instances séparées du serveur, - chacune d'entre elles écoutant l'un de ces ports, soit utiliser l'élégante - fonctionnalité d'Apache que constituent les hôtes virtuels pour créer - deux serveurs virtuels gérés par la même instance d'Apache - le - premier serveur répondant en HTTP aux requêtes sur le port 80, - le second répondant en HTTPS aux requêtes sur le port - 443.

    - - -

    Quel port HTTPS utilise-t-il ?

    -

    Vous pouvez associer le protocole HTTPS à n'importe quel port, mais le port -standard est le port 443, que tout navigateur compatible HTTPS va utiliser par -défaut. Vous pouvez forcer votre navigateur à utiliser un port différent en le -précisant dans l'URL. Par exemple, si votre serveur est configuré pour -servir des pages en HTTPS sur le port 8080, vous pourrez y accéder par -l'adresse https://example.com:8080/.

    - - -

    Comment s'exprimer en langage HTTPS à des fins -de test ?

    -

    Alors que vous utilisez simplement

    - -

    $ telnet localhost 80
    - GET / HTTP/1.0

    - -

    pour tester facilement Apache via HTTP, les choses ne sont pas si - simples pour HTTPS à cause du protocole SSL situé entre TCP et HTTP. - La commande OpenSSL s_client vous permet cependant - d'effectuer un test similaire via HTTPS :

    - -

    $ openssl s_client -connect localhost:443 -state -debug
    - GET / HTTP/1.0

    - -

    Avant la véritable réponse HTTP, vous recevrez des informations - détaillées à propos de l'établissement de la connexion SSL. Si vous - recherchez un client en ligne de commande à usage plus général qui comprend - directement HTTP et HTTPS, qui peut effectuer des opérations GET et POST, - peut utiliser un mandataire, supporte les requêtes portant sur une partie - d'un fichier (byte-range), etc..., vous devriez vous tourner vers - l'excellent outil cURL. Grâce à lui, - vous pouvez vérifier si Apache répond correctement aux requêtes via - HTTP et HTTPS comme suit :

    - -

    $ curl http://localhost/
    - $ curl https://localhost/

    - - -

    Pourquoi la communication se bloque-t-elle lorsque je -me connecte à mon serveur Apache configuré pour SSL ?

    -

    Ceci peut arriver si vous vous connectez à un serveur HTTPS (ou à -un serveur virtuel) via HTTP (par exemple, en utilisant -http://example.com/ au lieu de https://example.com). -Cela peut aussi arriver en essayant de vous connecter via HTTPS à un -serveur HTTP (par exemple, en utilisant https://example.com/ -avec un serveur qui ne supporte pas HTTPS, ou le supporte, mais sur un -port non standard). Assurez-vous que vous vous connectez bien à un -serveur (virtuel) qui supporte SSL.

    - - -

    Pourquoi, lorsque je tente d'accéder en HTTPS à mon -serveur Apache+mod_ssl fraîchement installé, l'erreur ``Connection Refused'' -s'affiche-t-elle ?

    -

    Une configuration incorrecte peut provoquer ce type d'erreur. -Assurez-vous que vos directives Listen s'accordent avec vos directives - <VirtualHost>. Si - l'erreur persiste, recommencez depuis le début en restaurant la - configuration par défaut fournie parmod_ssl.

    - - -

    Pourquoi les variables SSL_XXX -ne sont-elles pas disponibles dans mes scripts CGI et SSI ?

    -

    Assurez-vous que la directive ``SSLOptions +StdEnvVars'' est -bien présente dans le contexte de vos requêtes CGI/SSI.

    - - -

    Comment puis-je basculer entre les protocoles HTTP et -HTTPS dans les hyperliens relatifs ?

    - -

    Normalement, pour basculer entre HTTP et HTTPS, vous devez utiliser des -hyperliens pleinement qualifiés (car vous devez modifier le schéma de l'URL). -Cependant, à l'aide du module mod_rewrite, vous pouvez -manipuler des hyperliens relatifs, pour obtenir le même effet.

    - 
    RewriteEngine on
-RewriteRule   "^/(.*)_SSL$"   "https://%{SERVER_NAME}/$1" [R,L]
-RewriteRule   "^/(.*)_NOSSL$" "http://%{SERVER_NAME}/$1"  [R,L]
    - - -

    Ce jeu de règles rewrite vous permet d'utiliser des hyperliens de la - forme <a href="document.html_SSL"> pour passer en HTTPS - dans les liens relatifs. (Remplacez SSL par NOSSL pour passer en HTTP.)

    - -
    top
    -
    -

    Certificats

    - - -

    Qu'est-ce qu'un clé privée RSA, un certificat, -une demande de signature de certificat (CSR) ?

    -

    Un fichier de clé privée RSA est un fichier numérique que vous pouvez -utiliser pour déchiffrer des messages que l'on vous a envoyés. Il a son -pendant à caractère public que vous pouvez distribuer (par le biais de votre -certificat), ce qui permet aux utilisateurs de chiffrer les messages qu'ils -vous envoient.

    -

    Une Demande de Signature de Certificat (CSR) est un fichier numérique - qui contient votre clé publique et votre nom. La CSR doit être envoyée à - une Autorité de Certification (CA), qui va la convertir en vrai certificat - en la signant.

    -

    Un certificat contient votre clé publique RSA, votre nom, le nom - de la CA, et est signé numériquement par cette dernière. Les navigateurs - qui reconnaissent la CA peuvent vérifier la signature du certificat, et - ainsi en extraire votre clé publique RSA. Ceci leur permet de vous envoyer - des messages chiffrés que vous seul pourrez déchiffrer.

    -

    Se référer au chapitre Introduction - pour une description générale du protocole SSL.

    - - -

    Y a-t-il une différence au démarrage entre un serveur -Apache non SSL et un serveur Apache supportant SSL ?

    -

    Oui. En général, avec ou sans mod_ssl intégré, le démarrage -d'Apache ne présente pas de différences. Cependant, si votre fichier de clé -privée SSL possède un mot de passe, vous devrez le taper au démarrage -d'Apache.

    - -

    Devoir entrer manuellement le mot de passe au démarrage du serveur peut - poser quelques problèmes - par exemple, quand le serveur est démarré au - moyen de scripts au lancement du système. Dans ce cas, vous pouvez suivre - les étapes ci-dessous pour supprimer le - mot de passe de votre clé privée. Gardez à l'esprit qu'agir ainsi augmente - les risques de sécurité - agissez avec précaution !

    - - -

    Comment créer un certificat auto-signé SSL à des -fins de test ?

    -
      -
    1. Vérifiez qu'OpenSSL est installé et l'exécutable openssl dans votre - PATH.
      -
      -
      2. -
    2. Exécuter la commande suivante pour créer les fichiers - server.key et server.crt :
      - $ openssl req -new -x509 -nodes -out server.crt - -keyout server.key
      - Ces fichiers seront utilisés comme suit dans votre - httpd.conf : - 
      SSLCertificateFile    /path/to/this/server.crt
-SSLCertificateKeyFile /path/to/this/server.key
      - -
      3. -
    3. Il est important de savoir que le fichier server.key n'a - pas de mot de passe. Pour ajouter un mot de passe à la clé, vous - devez exécuter la commande suivante et confirmer le mot de passe comme - demandé.
      -

      $ openssl rsa -des3 -in server.key -out - server.key.new
      - $ mv server.key.new server.key

      - Sauvegardez le fichier server.key ainsi que son mot de - passe en lieu sûr. -
      4. -
    - - -

    Comment créer un vrai certificat SSL ?

    -

    Voici la marche à suivre pas à pas :

    -
      -
    1. Assurez-vous qu'OpenSSL est bien installé et dans votre PATH. -
      -
      -
      2. -
    2. Créez une clé privée RSA pour votre serveur Apache - (elle sera au format PEM et chiffrée en Triple-DES):
      -
      - $ openssl genrsa -des3 -out server.key 2048
      -
      - Enregistrez le fichier server.key et le mot de passe - éventuellement défini en lieu sûr. - Vous pouvez afficher les détails de cette clé privée RSA à l'aide de la - commande :
      - -
      - $ openssl rsa -noout -text -in server.key
      -
      - Si nécessaire, vous pouvez aussi créer une version PEM non chiffrée - (non recommandé) de clé privée RSA avec :
      -
      - $ openssl rsa -in server.key -out server.key.unsecure
      -
      - -
      3. -
    3. Créez une Demande de signature de Certificat (CSR) à l'aide de la - clé privée précédemment générée (la sortie sera au format PEM):
      -
      - $ openssl req -new -key server.key -out server.csr
      -
      - Vous devez entrer le Nom de Domaine Pleinement Qualifié - ("Fully Qualified Domain Name" ou FQDN) de votre serveur lorsqu'OpenSSL - vous demande le "CommonName", c'est à dire que si vous générez une CSR - pour un site web auquel on accèdera par l'URL - https://www.foo.dom/, le FQDN sera "www.foo.dom". Vous - pouvez afficher les détails de ce CSR avec :
      - -
      - $ openssl req -noout -text -in server.csr
      -
      -
      4. -
    4. Vous devez maintenant envoyer la CSR à une Autorité de Certification - (CA), afin que cette dernière puisse la signer. Une fois la CSR signée, - vous disposerez d'un véritable certificat que vous pourrez utiliser avec - Apache. Vous pouvez faire signer votre CSR par une CA commerciale ou par - votre propre CA.
      - Les CAs commerciales vous demandent en général de leur envoyer la CSR - par l'intermédiaire d'un formulaire web, de régler le montant de la - signature, puis vous envoient un certificat signé que vous pouvez - enregistrer dans un fichier server.crt. - - Pour plus de détails sur la manière de créer sa propre CA, et de - l'utiliser pour signer une CSR, voir ci-dessous.
      - - Une fois la CSR signée, vous pouvez afficher les détails du certificat - comme suit :
      -
      - $ openssl x509 -noout -text -in server.crt
      - -
      5. -
    5. Vous devez maintenant disposer de deux fichiers : - server.key et server.crt. Ils sont précisés dans - votre fichier httpd.conf comme suit : - 
      SSLCertificateFile    /path/to/this/server.crt
-SSLCertificateKeyFile /path/to/this/server.key
      - - Le fichier server.csr n'est plus nécessaire. -
      6. - -
    - - -

    Comment créer et utiliser sa propre Autorité de -certification (CA) ?

    -

    La solution la plus simple consiste à utiliser les scripts - CA.sh ou CA.pl fournis avec OpenSSL. De - préférence, utilisez cette solution, à moins que vous ayez de bonnes - raisons de ne pas le faire. Dans ce dernier cas, vous pouvez créer un - certificat auto-signé comme suit :

    - -
      -
    1. Créez une clé privée RSA pour votre serveur - (elle sera au format PEM et chiffrée en Triple-DES) :
      -
      - $ openssl genrsa -des3 -out server.key 2048
      -
      - Sauvegardez le fichier server.key et le mot de passe - éventuellement défini en lieu sûr. - Vous pouvez afficher les détails de cette clé privée RSA à l'aide de la - commande :
      -
      - $ openssl rsa -noout -text -in server.key
      -
      - Si nécessaire, vous pouvez aussi créer une version PEM non chiffrée - (non recommandé) de cette clé privée RSA avec :
      -
      - $ openssl rsa -in server.key -out server.key.unsecure
      -
      -
      2. -
    2. Créez un certificat auto-signé (structure X509) à l'aide de la clé RSA - que vous venez de générer (la sortie sera au format PEM) :
      -
      - $ openssl req -new -x509 -nodes -sha1 -days 365 - -key server.key -out server.crt -extensions usr_cert
      -
      - Cette commande signe le certificat du serveur et produit un fichier - server.crt. Vous pouvez afficher les détails de ce - certificat avec :
      -
      - $ openssl x509 -noout -text -in server.crt
      -
      -
      3. -
    - - -

    Comment modifier le mot de passe -de ma clé privée ?

    -

    Vous devez simplement lire la clé avec l'ancien mot de passe et la -réécrire en spécifiant le nouveau mot de passe. Pour cela, vous pouvez -utiliser les commandes suivantes :

    - - -

    $ openssl rsa -des3 -in server.key -out server.key.new
    - $ mv server.key.new server.key

    - -

    La première fois qu'il vous est demandé un mot de passe PEM, vous - devez entrer l'ancien mot de passe. Ensuite, on vous demandera d'entrer - encore un mot de passe - cette fois, entrez le nouveau mot de passe. Si on - vous demande de vérifier le mot de passe, vous devrez entrer le nouveau - mot de passe une seconde fois.

    - - -

    Comment démarrer Apache sans avoir à entrer de -mot de passe ?

    -

    L'apparition de ce dialogue au démarrage et à chaque redémarrage provient -du fait que la clé privée RSA contenue dans votre fichier server.key est -enregistrée sous forme chiffrée pour des raisons de sécurité. Le -déchiffrement de ce fichier nécessite un mot de passe, afin de pouvoir être -lu et interprété. Cependant, La suppression du mot de passe diminue le niveau de -sécurité du serveur - agissez avec précautions !

    -
      -
    1. Supprimer le chiffrement de la clé privée RSA (tout en conservant une - copie de sauvegarde du fichier original) :
      -
      - $ cp server.key server.key.org
      - $ openssl rsa -in server.key.org -out server.key
      - -
      -
      2. -
    2. Assurez-vous que le fichier server.key n'est lisible que par root :
      -
      - $ chmod 400 server.key
      -
      -
      3. -
    - -

    Maintenant, server.key contient une copie non chiffrée de - la clé. Si vous utilisez ce fichier pour votre serveur, il ne vous - demandera plus de mot de passe. CEPENDANT, si quelqu'un arrive à obtenir - cette clé, il sera en mesure d'usurper votre identité sur le réseau. - Vous DEVEZ par conséquent vous assurer que seuls root ou le serveur web - peuvent lire ce fichier (de préférence, démarrez le serveur web sous - root et faites le s'exécuter sous un autre utilisateur, en n'autorisant - la lecture de la clé que par root).

    - -

    Une autre alternative consiste à utiliser la directive - ``SSLPassPhraseDialog exec:/chemin/vers/programme''. Gardez - cependant à l'esprit que ce n'est bien entendu ni plus ni moins - sécurisé.

    - - -

    Comment vérifier si une clé privée correspond bien -à son certificat ?

    -

    Une clé privée contient une série de nombres. Deux de ces nombres forment la -"clé publique", les autres appartiennent à la "clé privée". Les bits de la -"clé publique" sont inclus quand vous générez une CSR, et font par -conséquent partie du certificat associé.

    -

    Pour vérifier que la clé publique contenue dans votre certificat - correspond bien à la partie publique de votre clé privée, il vous suffit - de comparer ces nombres. Pour afficher le certificat et la clé, - utilisez cette commande :

    - -

    $ openssl x509 -noout -text -in server.crt
    - $ openssl rsa -noout -text -in server.key

    - -

    Les parties `modulus' et `public exponent' doivent être identiques dans - la clé et le certificat. Comme le `public exponent' est habituellement - 65537, et comme il est difficile de vérifier visuellement que les nombreux - nombres du `modulus' sont identiques, vous pouvez utiliser l'approche - suivante :

    - -

    $ openssl x509 -noout -modulus -in server.crt | openssl md5
    - $ openssl rsa -noout -modulus -in server.key | openssl md5

    - -

    Il ne vous reste ainsi que deux nombres relativement courts à comparer. - Il est possible, en théorie que ces deux nombres soient les mêmes, sans que - les nombres du modulus soient identiques, mais les chances en sont infimes.

    -

    Si vous souhaitez vérifier à quelle clé ou certificat appartient une CSR - particulière, vous pouvez effectuer le même calcul - sur la CSR comme suit :

    - -

    $ openssl req -noout -modulus -in server.csr | openssl md5

    - - -

    Comment convertir un certificat du format PEM -au format DER ?

    -

    Le format des certificats par défaut pour OpenSSL est le format PEM, -qui est tout simplement un format DER codé en Base64, avec des lignes -d'en-têtes et des annotations. Certaines applications, comme -Microsoft Internet Explorer, ont besoin d'un certificat au format DER de base. -Vous pouvez convertir un fichier PEM cert.pem en son équivalent -au format DER cert.der à l'aide de la commande suivante : -$ openssl x509 -in cert.pem -out cert.der --outform DER

    - - -

    Pourquoi les navigateurs se plaignent-ils de ne pas pouvoir -vérifier mon certificat de serveur ?

    - -

    Ceci peut se produire si votre certificat de serveur est signé - par une autorité de certification intermédiaire. Plusieurs CAs, - comme Verisign ou Thawte, ont commencé à signer les certificats avec - des certificats intermédiaires au lieu de leur certificat racine.

    - -

    Les certificats de CA intermédiaires se situe à un niveau - intermédiaire entre le certificat racine de la CA (qui est installé dans les - navigateurs) et le certificat du serveur (que vous avez installé sur - votre serveur). Pour que le navigateur puisse traverser et vérifier - la chaîne de confiance depuis le certificat du serveur jusqu'au - certificat racine, il faut lui fournir les certificats - intermédiaires. Les CAs devraient pouvoir fournir de tels - paquetages de certificats intermédiaires à installer sur les - serveurs.

    - -

    Vous devez inclure ces certificats intermédiaires via la - directive SSLCertificateChainFile.

    - -
    top
    -
    -

    Le protocole SSL

    - - -

    Pourquoi de nombreuses et aléatoires erreurs de -protocole SSL apparaissent-elles en cas de forte charge du serveur ?

    -

    Ce problème peut avoir plusieurs causes, mais la principale réside dans le -cache de session SSL défini par la directive -SSLSessionCache. Le cache de session -DBM est souvent à la source du problème qui peut être résolu en utilisant le -cache de session SHM (ou en n'utilisant tout simplement pas de cache).

    - - -

    Pourquoi la charge de mon serveur est-elle plus -importante depuis qu'il sert des ressources chiffrées en SSL ?

    -

    SSL utilise un procédé de chiffrement fort qui nécessite la manipulation -d'une quantité très importante de nombres. Lorsque vous effectuez une requête -pour une page web via HTTPS, tout (même les images) est chiffré avant d'être -transmis. C'est pourquoi un accroissement du traffic HTTPS entraîne une -augmentation de la charge.

    - - -

    Pourquoi les connexions en HTTPS à mon serveur -prennent-elles parfois jusqu'à 30 secondes pour s'établir ?

    -

    Ce problème provient en général d'un périphérique /dev/random -qui bloque l'appel système read(2) jusqu'à ce que suffisamment d'entropie -soit disponible pour servir la requête. Pour plus d'information, se référer au -manuel de référence de la directive -SSLRandomSeed.

    - - -

    Quels sont les algorithmes de chiffrement -supportés par mod_ssl ?

    -

    En général, tous les algorithmes de chiffrement supportés par la version -d'OpenSSL installée, le sont aussi par mod_ssl. La liste des -algorithmes disponibles peut dépendre de la manière dont vous avez installé -OpenSSL. Typiquement, au moins les algorithmes suivants sont supportés :

    - -
      -
    1. RC4 avec SHA1
      2. -
    2. AES avec SHA1
      3. -
    3. Triple-DES avec SHA1
      4. -
    - -

    Pour déterminer la liste réelle des algorithmes disponibles, vous - pouvez utiliser la commande suivante :

    -

    $ openssl ciphers -v

    - - -

    Pourquoi une erreur ``no shared cipher'' apparaît-elle -quand j'essaie d'utiliser un algorithme de chiffrement -Diffie-Hellman anonyme (ADH) ?

    -

    Par défaut et pour des raisons de sécurité, OpenSSl ne permet pas -l'utilisation des algorithmes de chiffrements ADH. Veuillez vous informer -sur les effets pervers potentiels si vous choisissez d'activer le support -de ces algorithmes de chiffrements.

    -

    Pour pouvoir utiliser les algorithmes de chiffrements Diffie-Hellman -anonymes (ADH), vous devez compiler OpenSSL avec -``-DSSL_ALLOW_ADH'', puis ajouter ``ADH'' à votre -directive SSLCipherSuite.

    - - -

    Pourquoi une erreur ``no shared cipher'' -apparaît-elle lorsqu'on se connecte à mon serveur -fraîchement installé ?

    -

    Soit vous avez fait une erreur en définissant votre directive -SSLCipherSuite (comparez-la avec -l'exemple préconfiguré dans extra/httpd-ssl.conf), soit vous avez -choisi d'utiliser des algorithmes DSA/DH au lieu de RSA lorsque vous avez -généré votre clé privée, et avez ignoré ou êtes passé outre les -avertissements. Si vous avez choisi DSA/DH, votre serveur est incapable de -communiquer en utilisant des algorithmes de chiffrements SSL basés sur RSA -(du moins tant que vous n'aurez pas configuré une paire clé/certificat RSA -additionnelle). Les navigateurs modernes tels que NS ou IE ne peuvent -communiquer par SSL qu'avec des algorithmes RSA. C'est ce qui provoque l'erreur -"no shared ciphers". Pour la corriger, générez une nouvelle paire -clé/certificat pour le serveur en utilisant un algorithme de chiffrement -RSA.

    - - -

    Pourquoi ne peut-on pas utiliser SSL avec des hôtes -virtuels identifiés par un nom et non par une adresse IP ?

    -

    La raison est très technique, et s'apparente au problème de la primauté de -l'oeuf ou de la poule. La couche du protocole SSL se trouve en dessous de la -couche de protocole HTTP qu'elle encapsule. Lors de l'établissement d'une -connexion SSL (HTTPS), Apache/mod_ssl doit négocier les paramètres du -protocole SSL avec le client. Pour cela, mod_ssl doit consulter la -configuration du serveur virtuel (par exemple, il doit accéder à la suite -d'algorithmes de chiffrement, au certificat du serveur, etc...). Mais afin de -sélectionner le bon serveur virtuel, Apache doit connaître le contenu du champ -d'en-tête HTTP Host. Pour cela, il doit lire l'en-tête de la -requête HTTP. Mais il ne peut le faire tant que la négociation SSL n'est pas -terminée, or, la phase de négociation SSL a besoin du nom d'hôte contenu -dans l'en-tête de la requête. Voir la question suivante pour -contourner ce problème.

    - -

    Notez que si votre certificat comporte un nom de serveur avec - caractères génériques, ou des noms de serveurs multiples dans le - champ subjectAltName, vous pouvez utiliser SSL avec les serveurs - virtuels à base de noms sans avoir à contourner ce problème.

    - - -

    Est-il possible d'utiliser -l'hébergement virtuel basé sur le nom d'hôte -pour différencier plusieurs hôtes virtuels ?

    -

    L'hébergement virtuel basé sur le nom est une méthode très populaire - d'identification des différents hôtes virtuels. Il permet d'utiliser la - même adresse IP et le même numéro de port pour de nombreux sites - différents. Lorsqu'on se tourne vers SSL, il semble tout naturel de penser - que l'on peut appliquer la même méthode pour gérer plusieurs hôtes - virtuels SSL sur le même serveur.

    - -

    C'est possible, mais seulement si on utilise une version 2.2.12 - ou supérieure du serveur web compilée avec OpenSSL - version 0.9.8j ou supérieure. Ceci est du au fait que - l'utilisation de l'hébergement virtuel à base de nom - avec SSL nécessite une fonctionnalité appelée - Indication du Nom de Serveur (Server Name Indication - SNI) que - seules les révisions les plus récentes de la - spécification SSL supportent.

    - -

    Notez que si votre certificat comporte un nom de serveur avec - caractères génériques, ou des noms de serveurs multiples dans le - champ subjectAltName, vous pouvez utiliser SSL avec les serveurs - virtuels à base de noms sans avoir à contourner ce problème.

    - -

    La raison en est que le protocole SSL constitue une couche séparée qui - encapsule le protocole HTTP. Aini, la session SSL nécessite une - transaction séparée qui prend place avant que la session HTTP n'ait débuté. - Le serveur reçoit une requête SSL sur l'adresse IP X et le port Y - (habituellement 443). Comme la requête SSL ne contenait aucun - en-tête Host:, le serveur n'avait aucun moyen de déterminer quel hôte virtuel SSL il - devait utiliser. En général, il utilisait le premier - qu'il trouvait et qui - correspondait à l'adresse IP et au port spécifiés.

    - -

    Par contre, si vous utilisez des versions du serveur web et - d'OpenSSL qui supportent SNI, et si le navigateur du client le - supporte aussi, alors le nom d'hôte sera inclus dans la - requête SSL originale, et le serveur web pourra - sélectionner le bon serveur virtuel SSL.

    - -

    Bien entendu, vous pouvez utiliser l'hébergement virtuel basé sur le nom - pour identifier de nombreux hôtes virtuels non-SSL - (tous sur le port 80 par exemple), et ne gérer qu'un seul hôte virtuel SSL - (sur le port 443). Mais dans ce cas, vous devez définir le numéro de port - non-SSL à l'aide de la directive NameVirtualHost dans ce style :

    - - 
    NameVirtualHost 192.168.1.1:80
    - - -

    il existe d'autres solutions alternatives comme :

    - -

    Utiliser des adresses IP différentes pour chaque hôte SSL. - Utiliser des numéros de port différents pour chaque hôte SSL.

    - - -

    Comment mettre en oeuvre la compression SSL ?

    -

    Bien que la négociation pour la compression SSL ait été définie dans la -spécification de SSLv2 et TLS, ce n'est qu'en mai 2004 que la RFC 3749 a -défini DEFLATE comme une méthode de compression standard négociable. -

    -

    Depuis la version 0.9.8, OpenSSL supporte cette compression par défaut -lorsqu'il est compilé avec l'option zlib. Si le client et le -serveur supportent la compression, elle sera utilisée. Cependant, la -plupart des clients essaient encore de se connecter avec un Hello SSLv2. -Comme SSLv2 ne comportait pas de table des algorithmes de compression préférés -dans sa négociation, la compression ne peut pas être négociée avec ces clients. -Si le client désactive le support SSLv2, un Hello SSLv3 ou TLS peut être -envoyé, selon la bibliothèque SSL utilisée, et la compression peut être mise -en oeuvre. Vous pouvez vérifier si un client utilise la compression SSL en -journalisant la variable %{SSL_COMPRESS_METHOD}x. -

    - - -

    Lorsque j'utilise l'authentification de base sur HTTPS, -l'icône de verrouillage des navigateurs Netscape reste ouverte quand la boîte -de dialogue d'authentification apparaît. Cela signifie-t-il que les utilisateur -et mot de passe sont envoyés en clair ?

    -

    Non, le couple utilisateur/mot de passe est transmis sous forme chiffrée. - L'icône de chiffrement dans les navigateurs Netscape n'est pas vraiment - synchronisé avec la couche SSL/TLS. Il ne passe à l'état verrouillé - qu'au moment où la première partie des données relatives à la page web - proprement dite sont transférées, ce qui peut prêter à confusion. Le - dispositif d'authentification de base appartient à la couche HTTP, qui - est située au dessus de la couche SSL/TLS dans HTTPS. Avant tout - transfert de données HTTP sous HTTPS, la couche SSL/TLS a déjà achevé - sa phase de négociation et basculé dans le mode de communication - chiffrée. Ne vous laissez donc pas abuser par l'état de cet icône.

    - - -

    Pourquoi des erreurs d'entrée/sortie apparaissent-elles -lorsqu'on se connecte via HTTPS à un serveur Apache+mod_ssl avec des -versions anciennes de -Microsoft Internet Explorer (MSIE) ?

    -

    La première raison en est la présence dans l'implémentation SSL de -certaines versions de MSIE de bogues subtils en rapport avec le -dispositif de "maintien en vie" (keep-alive) HTTP, et les alertes de -notification de fermeture de session SSL en cas de coupure de la -connexion au point d'entrée (socket). De plus, l'interaction entre -SSL et les fonctionnalités HTTP/1.1 pose problème avec certaines -versions de MSIE. Vous pouvez contourner ces problèmes en interdisant -à Apache l'utilisation de HTTP/1.1, les connexions avec maintien en vie -ou l'envoi de messages de notification de fermeture de session SSL aux -clients MSIE. Pour cela, vous pouvez utiliser la directive suivante -dans votre section d'hôte virtuel avec support SSL :

    - 
    SetEnvIf User-Agent "MSIE [2-5]" \
-         nokeepalive ssl-unclean-shutdown \
-         downgrade-1.0 force-response-1.0
    - -

    En outre, certaines versions de MSIE ont des problèmes avec des - algorithmes de chiffrement particuliers. Hélas, il n'est pas - possible d'apporter une solution spécifique à MSIE pour ces - problèmes, car les algorithmes de chiffrement sont utilisés dès la - phase de négociation SSL. Ainsi, une directive - SetEnvIf spécifique - à MSIE ne peut être d'aucun secours. Par contre, vous devrez - ajuster les paramètres généraux de manière drastique. Avant de - vous décider, soyez sûr que vos clients rencontrent vraiment des - problèmes. Dans la négative, n'effectuez pas ces ajustements car - ils affecteront tous vos clients, ceux utilisant MSIE, - mais aussi les autres.

    - - - -

    Comment activer TLS-SRP ?

    -

    TLS-SRP (Echange de clés avec mot de passe distant sécurisé, - défini dans la RFC 5054) peut compléter ou même remplacer les - certificats au cours de l'authentification d'une connexion SSL. Pour - utiliser TLS-SRP, affectez à la directive SSLSRPVerifierFile un fichier de - vérification OpenSSL SRP. Pour créer ce fichier de vérification, - utilisez l'outil openssl :

    -

    - openssl srp -srpvfile passwd.srpv -add username -

    -

    Une fois ce fichier créé, spécifiez-le dans la configuration SSL - du serveur :

    -

    - SSLSRPVerifierFile /path/to/passwd.srpv -

    -

    Pour forcer les clients à utiliser des algorithmes de chiffrement - non basés sur les certificats, utilisez la directive suivante :

    -

    - SSLCipherSuite "!DSS:!aRSA:SRP" -

    - - -

    Pourquoi des erreurs de négociation apparaissent -avec les clients basés sur Java lorsqu'on utilise un certificat de plus -de 1024 bits ?

    -

    Depuis la version 2.5.0-dev et à/c du 29/09/2013, - mod_ssl utilise des paramètres DH qui comportent - des nombres premiers de plus de 1024 bits. Cependant, java 7 et ses versions - antérieures ne supportent que les nombres premiers DH d'une longueur - maximale de 1024 bits.

    - -

    Si votre client basé sur Java s'arrête avec une exception telle - que java.lang.RuntimeException: Could not generate DH - keypair et - java.security.InvalidAlgorithmParameterException: Prime size - must be multiple of 64, and can only range from 512 to 1024 - (inclusive), et si httpd enregistre le message tlsv1 - alert internal error (SSL alert number 80) dans son journal - des erreurs (avec un LogLevel - info ou supérieur), vous pouvez soit réarranger la - liste d'algorithmes de mod_ssl via la directive SSLCipherSuite (éventuellement en - conjonction avec la directive SSLHonorCipherOrder), soit utiliser des - paramètres DH personnalisés avec un nombre - premier de 1024 bits, paramètres qui seront toujours prioritaires - par rapport à tout autre paramètre DH par défaut.

    - -

    Pour générer des paramètres DH personnalisés, utilisez la - commande openssl dhparam 1024. Vous pouvez aussi - utiliser les paramètres DH standards issus de la RFC 2409, section 6.2 :

    - 
    -----BEGIN DH PARAMETERS-----
-MIGHAoGBAP//////////yQ/aoiFowjTExmKLgNwc0SkCTgiKZ8x0Agu+pjsTmyJR
-Sgh5jjQE3e+VGbPNOkMbMCsKbfJfFDdP4TVtbVHCReSFtXZiXn7G9ExC6aY37WsL
-/1y29Aa37e44a/taiZ+lrp8kEXxLH+ZJKGZR7OZTgf//////////AgEC
------END DH PARAMETERS-----
    -

    Ajoute les paramètres personnalisés incluant les lignes "BEGIN DH - PARAMETERS" et "END DH PARAMETERS" à la fin du premier fichier de - certificat défini via la directive SSLCertificateFile.

    - - - -
    top
    -
    -

    Support de mod_ssl

    - - -

    Quelles sont les sources d'informations -disponibles en cas de problème avec mod_ssl ?

    -

    Voici les sources d'informations disponibles ; vous devez chercher -ici en cas de problème.

    - -
    -
    Vous trouverez des réponses dans la Foire Aux Questions du - manuel utilisateur (ce document)
    -
    - http://httpd.apache.org/docs/trunk/ssl/ssl_faq.html
    - Cherchez tout d'abord dans la foire aux questions - (ce document). Si votre question est courante, on a déjà dû y - répondre de nombreuses fois, et elle fait probablement partie - de ce document. -
    -
    - - -

    Qui peut-on contacter pour un support en cas de -problème avec mod_ssl ?

    -

    Voici toutes les possibilités de support pour mod_ssl, par ordre - de préférence. Merci d'utiliser ces possibilités - dans cet ordre - ne vous précipitez pas sur celle qui vous - paraît la plus alléchante.

    -
      -
    1. Envoyez un rapport de problème à la liste de diffusion de - support des utilisateurs d'Apache httpd
      - - users@httpd.apache.org
      - C'est la deuxième manière de soumettre votre rapport de - problème. Ici aussi, vous devez d'abord vous abonner à la - liste, mais vous pourrez ensuite discuter facilement de votre - problème avec l'ensemble de la communauté d'utilisateurs - d'Apache httpd. -
      2. - -
    2. Ecrire un rapport de problème dans la base de données des - bogues
      - - http://httpd.apache.org/bug_report.html
      - C'est la dernière manière de soumettre votre rapport de - problème. Vous ne devez utiliser cette solution que si vous - avez déjà écrit aux listes de diffusion, et n'avez pas trouvé - de solution. Merci de suivre les instructions de la page - mentionnée ci-dessus avec soin. -
      3. -
    - - -

    Quelles informations dois-je fournir lors -de l'écriture d'un rapport de bogue ?

    -

    Vous devez toujours fournir au moins les informations -suivantes :

    - -
    -
    Les versions d'Apache httpd et OpenSSL installées
    -
    La version d'Apache peut être déterminée en exécutant - httpd -v. La version d'OpenSSL peut être déterminée - en exécutant openssl version. Si Lynx est installé, - vous pouvez aussi exécuter la commandelynx -mime_header - http://localhost/ | grep Server et ainsi obtenir ces - informations en une seule fois. -
    - -
    Les détails de votre installation d'Apache httpd et OpenSSL
    -
    A cet effet, vous pouvez fournir un fichier journal de votre - session de terminal qui montre les étapes de la configuration et - de l'installation. En cas d'impossibilité, vous devez au moins - fournir la ligne de commande configure que - vous avez utilisée. -
    - -
    En cas de vidage mémoire, inclure une trace de ce qui s'est - passé
    -
    Si votre serveur Apache httpd fait un vidage de sa - mémoire, merci de fournir en pièce jointe un fichier contenant - une trace de la zone dédiée à la pile (voir - ci-dessous pour des informations sur la manière - de l'obtenir). Il est nécessaire de disposer de ces informations - afin de pouvoir déterminer la raison de votre vidage mémoire. -
    - -
    Une description détaillée de votre problème
    - -
    Ne riez pas, nous sommes sérieux ! De nombreux rapports - n'incluent pas de description de la véritable nature du problème. - Sans ces informations, il est très difficile pour quiconque de - vous aider. Donc, et c'est votre propre intérêt (vous souhaitez - que le problème soit résolu, n'est-ce pas ?), fournissez, s'il vous - plait, le maximum de détails possible. Bien entendu, vous devez - aussi inclure tout ce qui a été dit précédemment. -
    -
    - - -

    Un vidage mémoire s'est produit, -pouvez-vous m'aider ?

    -

    En général non, du moins tant que vous n'aurez pas fourni plus de -détails à propos de la localisation dans le code où Apache a effectué -son vidage mémoire. Ce dont nous avons en général besoin pour vous -aider est une trace de ce qui s'est passé (voir la question suivante). -Sans cette information, il est pratiquement impossible de déterminer -la nature du problème et de vous aider à le résoudre.

    - - -

    Comment puis-je obtenir une journalisation de -ce qui s'est passé, pour m'aider à trouver la raison de ce vidage -mémoire ?

    -

    Vous trouverez ci-dessous les différentes étapes permettant -d'obtenir une journalisation des évènements (backtrace) :

    -
      -
    1. Assurez-vous que les symboles de débogage sont disponibles, au - moins pour Apache. Pour cela, sur les plates-formes où GCC/GDB est - utilisé, vous devez compiler Apache+mod_ssl avec l'option - ``OPTIM="-g -ggdb3"''. Sur les autres plates-formes, - l'option ``OPTIM="-g"'' est un minimum. -
      2. - -
    2. Démarrez le serveur et essayez de reproduire le vidage mémoire. - A cet effet, vous pouvez utiliser une directive du style - ``CoreDumpDirectory /tmp'' pour être sûr que le - fichier de vidage mémoire puisse bien être écrit. Vous devriez - obtenir un fichier /tmp/core ou - /tmp/httpd.core. Si ce n'est pas le cas, essayez de - lancer votre serveur sous un UID autre que root. - Pour des raisons de sécurité, de nombreux - noyaux modernes de permettent pas à un processus de vider sa - mémoire une fois qu'il a accompli un setuid() (à moins - qu'il effectue un exec()) car des informations d'un - niveau privilégié pourraient être transmises en mémoire. Si - nécessaire, vous pouvez exécuter /chemin/vers/httpd -X - manuellement afin de ne pas permettre à Apache de se clôner (fork). -
      3. - -
    3. Analysez le vidage mémoire. Pour cela, exécutez - gdb /path/to/httpd /tmp/httpd.core ou une commande - similaire. Dans GDB, tout ce que vous avez à faire est d'entrer - bt, et voila, vous obtenez la backtrace. Pour les - débogueurs autres que GDB consulter le manuel correspondant. -
      4. -
    - -
    -
    -

    Langues Disponibles:  en  | - fr 

    -
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    -
    - \ No newline at end of file diff --git a/docs/manual/ssl/ssl_faq.html.fr.utf8 b/docs/manual/ssl/ssl_faq.html.fr.utf8 new file mode 100644 index 0000000000..2e5912d557 --- /dev/null +++ b/docs/manual/ssl/ssl_faq.html.fr.utf8 @@ -0,0 +1,1035 @@ + + + + + +Chiffrement SSL/TLS fort: foire aux questions - Serveur HTTP Apache Version 2.5 + + + + + + +
    +

    Modules | Directives | FAQ | Glossaire | Plan du site

    +

    Serveur HTTP Apache Version 2.5

    +
    +
    <-
    +

    Chiffrement SSL/TLS fort: foire aux questions

    +
    +

    Langues Disponibles:  en  | + fr 

    +
    + +
    +

    Le sage n'apporte pas de bonnes réponses, il pose les bonnes questions

    +

    -- Claude Levi-Strauss

    + +
    +
    + +
    top
    +
    +

    Installation

    + + +

    Pourquoi le démarrage d'Apache provoque-t-il des +erreurs de permission en rapport avec SSLMutex ?

    +

    Des erreurs telles que ``mod_ssl: Child could not open + SSLMutex lockfile /opt/apache/logs/ssl_mutex.18332 (avec l'erreur + système qui suit) [...] System: Permission denied (errno: 13)'' + sont souvent provoquées par des permissions trop restrictives sur les + répertoires parents. Assurez-vous que tous les répertoires + parents (ici /opt, /opt/apache et + /opt/apache/logs) ont le bit x positionné au moins pour + l'UID sous lequel les processus enfants d'Apache s'exécutent (voir la + directive User).

    + + +

    Pourquoi mod_ssl s'arrête-t-il avec l'erreur +"Failed to generate temporary 512 bit RSA private key" au démarrage +d'Apache ?

    +

    Pour fonctionner correctement, les logiciels de cryptographie ont + besoin d'une source de données aléatoires. De nombreux systèmes + d'exploitation libres proposent un "périphérique source d'entropie" + qui fournit ce service (il se nomme en général + /dev/random). Sur d'autres systèmes, les applications + doivent amorcer manuellement + le Générateur de Nombres Pseudo-Aléatoires d'OpenSSL + (Pseudo Random Number Generator -PRNG) à l'aide de données appropriées + avant de générer des clés ou d'effectuer un chiffrement à clé + publique. Depuis la version 0.9.5, les fonctions d'OpenSSL qui nécessitent + des données aléatoires provoquent une erreur si le PRNG n'a pas été amorcé + avec une source de données aléatoires d'au moins 128 bits.

    +

    Pour éviter cette erreur, mod_ssl doit fournir + suffisamment d'entropie au PRNG pour lui permettre de fonctionner + correctement. Ce niveau d'entropie est défini par la directive + SSLRandomSeed.

    + +
    top
    +
    +

    Configuration

    + + +

    Peut-on faire cohabiter HTTP et HTTPS sur le même +serveur ?

    +

    Oui. HTTP et HTTPS utilisent des ports différents (HTTP écoute le port + 80 et HTTPS le port 443), si bien qu'il n'y a pas de conflit direct entre + les deux. Vous pouvez soit exécuter deux instances séparées du serveur, + chacune d'entre elles écoutant l'un de ces ports, soit utiliser l'élégante + fonctionnalité d'Apache que constituent les hôtes virtuels pour créer + deux serveurs virtuels gérés par la même instance d'Apache - le + premier serveur répondant en HTTP aux requêtes sur le port 80, + le second répondant en HTTPS aux requêtes sur le port + 443.

    + + +

    Quel port HTTPS utilise-t-il ?

    +

    Vous pouvez associer le protocole HTTPS à n'importe quel port, mais le port +standard est le port 443, que tout navigateur compatible HTTPS va utiliser par +défaut. Vous pouvez forcer votre navigateur à utiliser un port différent en le +précisant dans l'URL. Par exemple, si votre serveur est configuré pour +servir des pages en HTTPS sur le port 8080, vous pourrez y accéder par +l'adresse https://example.com:8080/.

    + + +

    Comment s'exprimer en langage HTTPS à des fins +de test ?

    +

    Alors que vous utilisez simplement

    + +

    $ telnet localhost 80
    + GET / HTTP/1.0

    + +

    pour tester facilement Apache via HTTP, les choses ne sont pas si + simples pour HTTPS à cause du protocole SSL situé entre TCP et HTTP. + La commande OpenSSL s_client vous permet cependant + d'effectuer un test similaire via HTTPS :

    + +

    $ openssl s_client -connect localhost:443 -state -debug
    + GET / HTTP/1.0

    + +

    Avant la véritable réponse HTTP, vous recevrez des informations + détaillées à propos de l'établissement de la connexion SSL. Si vous + recherchez un client en ligne de commande à usage plus général qui comprend + directement HTTP et HTTPS, qui peut effectuer des opérations GET et POST, + peut utiliser un mandataire, supporte les requêtes portant sur une partie + d'un fichier (byte-range), etc..., vous devriez vous tourner vers + l'excellent outil cURL. Grâce à lui, + vous pouvez vérifier si Apache répond correctement aux requêtes via + HTTP et HTTPS comme suit :

    + +

    $ curl http://localhost/
    + $ curl https://localhost/

    + + +

    Pourquoi la communication se bloque-t-elle lorsque je +me connecte à mon serveur Apache configuré pour SSL ?

    +

    Ceci peut arriver si vous vous connectez à un serveur HTTPS (ou à +un serveur virtuel) via HTTP (par exemple, en utilisant +http://example.com/ au lieu de https://example.com). +Cela peut aussi arriver en essayant de vous connecter via HTTPS à un +serveur HTTP (par exemple, en utilisant https://example.com/ +avec un serveur qui ne supporte pas HTTPS, ou le supporte, mais sur un +port non standard). Assurez-vous que vous vous connectez bien à un +serveur (virtuel) qui supporte SSL.

    + + +

    Pourquoi, lorsque je tente d'accéder en HTTPS à mon +serveur Apache+mod_ssl fraîchement installé, l'erreur ``Connection Refused'' +s'affiche-t-elle ?

    +

    Une configuration incorrecte peut provoquer ce type d'erreur. +Assurez-vous que vos directives Listen s'accordent avec vos directives + <VirtualHost>. Si + l'erreur persiste, recommencez depuis le début en restaurant la + configuration par défaut fournie parmod_ssl.

    + + +

    Pourquoi les variables SSL_XXX +ne sont-elles pas disponibles dans mes scripts CGI et SSI ?

    +

    Assurez-vous que la directive ``SSLOptions +StdEnvVars'' est +bien présente dans le contexte de vos requêtes CGI/SSI.

    + + +

    Comment puis-je basculer entre les protocoles HTTP et +HTTPS dans les hyperliens relatifs ?

    + +

    Normalement, pour basculer entre HTTP et HTTPS, vous devez utiliser des +hyperliens pleinement qualifiés (car vous devez modifier le schéma de l'URL). +Cependant, à l'aide du module mod_rewrite, vous pouvez +manipuler des hyperliens relatifs, pour obtenir le même effet.

    + 
    RewriteEngine on
+RewriteRule   "^/(.*)_SSL$"   "https://%{SERVER_NAME}/$1" [R,L]
+RewriteRule   "^/(.*)_NOSSL$" "http://%{SERVER_NAME}/$1"  [R,L]
    + + +

    Ce jeu de règles rewrite vous permet d'utiliser des hyperliens de la + forme <a href="document.html_SSL"> pour passer en HTTPS + dans les liens relatifs. (Remplacez SSL par NOSSL pour passer en HTTP.)

    + +
    top
    +
    +

    Certificats

    + + +

    Qu'est-ce qu'un clé privée RSA, un certificat, +une demande de signature de certificat (CSR) ?

    +

    Un fichier de clé privée RSA est un fichier numérique que vous pouvez +utiliser pour déchiffrer des messages que l'on vous a envoyés. Il a son +pendant à caractère public que vous pouvez distribuer (par le biais de votre +certificat), ce qui permet aux utilisateurs de chiffrer les messages qu'ils +vous envoient.

    +

    Une Demande de Signature de Certificat (CSR) est un fichier numérique + qui contient votre clé publique et votre nom. La CSR doit être envoyée à + une Autorité de Certification (CA), qui va la convertir en vrai certificat + en la signant.

    +

    Un certificat contient votre clé publique RSA, votre nom, le nom + de la CA, et est signé numériquement par cette dernière. Les navigateurs + qui reconnaissent la CA peuvent vérifier la signature du certificat, et + ainsi en extraire votre clé publique RSA. Ceci leur permet de vous envoyer + des messages chiffrés que vous seul pourrez déchiffrer.

    +

    Se référer au chapitre Introduction + pour une description générale du protocole SSL.

    + + +

    Y a-t-il une différence au démarrage entre un serveur +Apache non SSL et un serveur Apache supportant SSL ?

    +

    Oui. En général, avec ou sans mod_ssl intégré, le démarrage +d'Apache ne présente pas de différences. Cependant, si votre fichier de clé +privée SSL possède un mot de passe, vous devrez le taper au démarrage +d'Apache.

    + +

    Devoir entrer manuellement le mot de passe au démarrage du serveur peut + poser quelques problèmes - par exemple, quand le serveur est démarré au + moyen de scripts au lancement du système. Dans ce cas, vous pouvez suivre + les étapes ci-dessous pour supprimer le + mot de passe de votre clé privée. Gardez à l'esprit qu'agir ainsi augmente + les risques de sécurité - agissez avec précaution !

    + + +

    Comment créer un certificat auto-signé SSL à des +fins de test ?

    +
      +
    1. Vérifiez qu'OpenSSL est installé et l'exécutable openssl dans votre + PATH.
      +
      +
      2. +
    2. Exécuter la commande suivante pour créer les fichiers + server.key et server.crt :
      + $ openssl req -new -x509 -nodes -out server.crt + -keyout server.key
      + Ces fichiers seront utilisés comme suit dans votre + httpd.conf : + 
      SSLCertificateFile    /path/to/this/server.crt
+SSLCertificateKeyFile /path/to/this/server.key
      + +
      3. +
    3. Il est important de savoir que le fichier server.key n'a + pas de mot de passe. Pour ajouter un mot de passe à la clé, vous + devez exécuter la commande suivante et confirmer le mot de passe comme + demandé.
      +

      $ openssl rsa -des3 -in server.key -out + server.key.new
      + $ mv server.key.new server.key

      + Sauvegardez le fichier server.key ainsi que son mot de + passe en lieu sûr. +
      4. +
    + + +

    Comment créer un vrai certificat SSL ?

    +

    Voici la marche à suivre pas à pas :

    +
      +
    1. Assurez-vous qu'OpenSSL est bien installé et dans votre PATH. +
      +
      +
      2. +
    2. Créez une clé privée RSA pour votre serveur Apache + (elle sera au format PEM et chiffrée en Triple-DES):
      +
      + $ openssl genrsa -des3 -out server.key 2048
      +
      + Enregistrez le fichier server.key et le mot de passe + éventuellement défini en lieu sûr. + Vous pouvez afficher les détails de cette clé privée RSA à l'aide de la + commande :
      + +
      + $ openssl rsa -noout -text -in server.key
      +
      + Si nécessaire, vous pouvez aussi créer une version PEM non chiffrée + (non recommandé) de clé privée RSA avec :
      +
      + $ openssl rsa -in server.key -out server.key.unsecure
      +
      + +
      3. +
    3. Créez une Demande de signature de Certificat (CSR) à l'aide de la + clé privée précédemment générée (la sortie sera au format PEM):
      +
      + $ openssl req -new -key server.key -out server.csr
      +
      + Vous devez entrer le Nom de Domaine Pleinement Qualifié + ("Fully Qualified Domain Name" ou FQDN) de votre serveur lorsqu'OpenSSL + vous demande le "CommonName", c'est à dire que si vous générez une CSR + pour un site web auquel on accèdera par l'URL + https://www.foo.dom/, le FQDN sera "www.foo.dom". Vous + pouvez afficher les détails de ce CSR avec :
      + +
      + $ openssl req -noout -text -in server.csr
      +
      +
      4. +
    4. Vous devez maintenant envoyer la CSR à une Autorité de Certification + (CA), afin que cette dernière puisse la signer. Une fois la CSR signée, + vous disposerez d'un véritable certificat que vous pourrez utiliser avec + Apache. Vous pouvez faire signer votre CSR par une CA commerciale ou par + votre propre CA.
      + Les CAs commerciales vous demandent en général de leur envoyer la CSR + par l'intermédiaire d'un formulaire web, de régler le montant de la + signature, puis vous envoient un certificat signé que vous pouvez + enregistrer dans un fichier server.crt. + + Pour plus de détails sur la manière de créer sa propre CA, et de + l'utiliser pour signer une CSR, voir ci-dessous.
      + + Une fois la CSR signée, vous pouvez afficher les détails du certificat + comme suit :
      +
      + $ openssl x509 -noout -text -in server.crt
      + +
      5. +
    5. Vous devez maintenant disposer de deux fichiers : + server.key et server.crt. Ils sont précisés dans + votre fichier httpd.conf comme suit : + 
      SSLCertificateFile    /path/to/this/server.crt
+SSLCertificateKeyFile /path/to/this/server.key
      + + Le fichier server.csr n'est plus nécessaire. +
      6. + +
    + + +

    Comment créer et utiliser sa propre Autorité de +certification (CA) ?

    +

    La solution la plus simple consiste à utiliser les scripts + CA.sh ou CA.pl fournis avec OpenSSL. De + préférence, utilisez cette solution, à moins que vous ayez de bonnes + raisons de ne pas le faire. Dans ce dernier cas, vous pouvez créer un + certificat auto-signé comme suit :

    + +
      +
    1. Créez une clé privée RSA pour votre serveur + (elle sera au format PEM et chiffrée en Triple-DES) :
      +
      + $ openssl genrsa -des3 -out server.key 2048
      +
      + Sauvegardez le fichier server.key et le mot de passe + éventuellement défini en lieu sûr. + Vous pouvez afficher les détails de cette clé privée RSA à l'aide de la + commande :
      +
      + $ openssl rsa -noout -text -in server.key
      +
      + Si nécessaire, vous pouvez aussi créer une version PEM non chiffrée + (non recommandé) de cette clé privée RSA avec :
      +
      + $ openssl rsa -in server.key -out server.key.unsecure
      +
      +
      2. +
    2. Créez un certificat auto-signé (structure X509) à l'aide de la clé RSA + que vous venez de générer (la sortie sera au format PEM) :
      +
      + $ openssl req -new -x509 -nodes -sha1 -days 365 + -key server.key -out server.crt -extensions usr_cert
      +
      + Cette commande signe le certificat du serveur et produit un fichier + server.crt. Vous pouvez afficher les détails de ce + certificat avec :
      +
      + $ openssl x509 -noout -text -in server.crt
      +
      +
      3. +
    + + +

    Comment modifier le mot de passe +de ma clé privée ?

    +

    Vous devez simplement lire la clé avec l'ancien mot de passe et la +réécrire en spécifiant le nouveau mot de passe. Pour cela, vous pouvez +utiliser les commandes suivantes :

    + + +

    $ openssl rsa -des3 -in server.key -out server.key.new
    + $ mv server.key.new server.key

    + +

    La première fois qu'il vous est demandé un mot de passe PEM, vous + devez entrer l'ancien mot de passe. Ensuite, on vous demandera d'entrer + encore un mot de passe - cette fois, entrez le nouveau mot de passe. Si on + vous demande de vérifier le mot de passe, vous devrez entrer le nouveau + mot de passe une seconde fois.

    + + +

    Comment démarrer Apache sans avoir à entrer de +mot de passe ?

    +

    L'apparition de ce dialogue au démarrage et à chaque redémarrage provient +du fait que la clé privée RSA contenue dans votre fichier server.key est +enregistrée sous forme chiffrée pour des raisons de sécurité. Le +déchiffrement de ce fichier nécessite un mot de passe, afin de pouvoir être +lu et interprété. Cependant, La suppression du mot de passe diminue le niveau de +sécurité du serveur - agissez avec précautions !

    +
      +
    1. Supprimer le chiffrement de la clé privée RSA (tout en conservant une + copie de sauvegarde du fichier original) :
      +
      + $ cp server.key server.key.org
      + $ openssl rsa -in server.key.org -out server.key
      + +
      +
      2. +
    2. Assurez-vous que le fichier server.key n'est lisible que par root :
      +
      + $ chmod 400 server.key
      +
      +
      3. +
    + +

    Maintenant, server.key contient une copie non chiffrée de + la clé. Si vous utilisez ce fichier pour votre serveur, il ne vous + demandera plus de mot de passe. CEPENDANT, si quelqu'un arrive à obtenir + cette clé, il sera en mesure d'usurper votre identité sur le réseau. + Vous DEVEZ par conséquent vous assurer que seuls root ou le serveur web + peuvent lire ce fichier (de préférence, démarrez le serveur web sous + root et faites le s'exécuter sous un autre utilisateur, en n'autorisant + la lecture de la clé que par root).

    + +

    Une autre alternative consiste à utiliser la directive + ``SSLPassPhraseDialog exec:/chemin/vers/programme''. Gardez + cependant à l'esprit que ce n'est bien entendu ni plus ni moins + sécurisé.

    + + +

    Comment vérifier si une clé privée correspond bien +à son certificat ?

    +

    Une clé privée contient une série de nombres. Deux de ces nombres forment la +"clé publique", les autres appartiennent à la "clé privée". Les bits de la +"clé publique" sont inclus quand vous générez une CSR, et font par +conséquent partie du certificat associé.

    +

    Pour vérifier que la clé publique contenue dans votre certificat + correspond bien à la partie publique de votre clé privée, il vous suffit + de comparer ces nombres. Pour afficher le certificat et la clé, + utilisez cette commande :

    + +

    $ openssl x509 -noout -text -in server.crt
    + $ openssl rsa -noout -text -in server.key

    + +

    Les parties `modulus' et `public exponent' doivent être identiques dans + la clé et le certificat. Comme le `public exponent' est habituellement + 65537, et comme il est difficile de vérifier visuellement que les nombreux + nombres du `modulus' sont identiques, vous pouvez utiliser l'approche + suivante :

    + +

    $ openssl x509 -noout -modulus -in server.crt | openssl md5
    + $ openssl rsa -noout -modulus -in server.key | openssl md5

    + +

    Il ne vous reste ainsi que deux nombres relativement courts à comparer. + Il est possible, en théorie que ces deux nombres soient les mêmes, sans que + les nombres du modulus soient identiques, mais les chances en sont infimes.

    +

    Si vous souhaitez vérifier à quelle clé ou certificat appartient une CSR + particulière, vous pouvez effectuer le même calcul + sur la CSR comme suit :

    + +

    $ openssl req -noout -modulus -in server.csr | openssl md5

    + + +

    Comment convertir un certificat du format PEM +au format DER ?

    +

    Le format des certificats par défaut pour OpenSSL est le format PEM, +qui est tout simplement un format DER codé en Base64, avec des lignes +d'en-têtes et des annotations. Certaines applications, comme +Microsoft Internet Explorer, ont besoin d'un certificat au format DER de base. +Vous pouvez convertir un fichier PEM cert.pem en son équivalent +au format DER cert.der à l'aide de la commande suivante : +$ openssl x509 -in cert.pem -out cert.der +-outform DER

    + + +

    Pourquoi les navigateurs se plaignent-ils de ne pas pouvoir +vérifier mon certificat de serveur ?

    + +

    Ceci peut se produire si votre certificat de serveur est signé + par une autorité de certification intermédiaire. Plusieurs CAs, + comme Verisign ou Thawte, ont commencé à signer les certificats avec + des certificats intermédiaires au lieu de leur certificat racine.

    + +

    Les certificats de CA intermédiaires se situe à un niveau + intermédiaire entre le certificat racine de la CA (qui est installé dans les + navigateurs) et le certificat du serveur (que vous avez installé sur + votre serveur). Pour que le navigateur puisse traverser et vérifier + la chaîne de confiance depuis le certificat du serveur jusqu'au + certificat racine, il faut lui fournir les certificats + intermédiaires. Les CAs devraient pouvoir fournir de tels + paquetages de certificats intermédiaires à installer sur les + serveurs.

    + +

    Vous devez inclure ces certificats intermédiaires via la + directive SSLCertificateChainFile.

    + +
    top
    +
    +

    Le protocole SSL

    + + +

    Pourquoi de nombreuses et aléatoires erreurs de +protocole SSL apparaissent-elles en cas de forte charge du serveur ?

    +

    Ce problème peut avoir plusieurs causes, mais la principale réside dans le +cache de session SSL défini par la directive +SSLSessionCache. Le cache de session +DBM est souvent à la source du problème qui peut être résolu en utilisant le +cache de session SHM (ou en n'utilisant tout simplement pas de cache).

    + + +

    Pourquoi la charge de mon serveur est-elle plus +importante depuis qu'il sert des ressources chiffrées en SSL ?

    +

    SSL utilise un procédé de chiffrement fort qui nécessite la manipulation +d'une quantité très importante de nombres. Lorsque vous effectuez une requête +pour une page web via HTTPS, tout (même les images) est chiffré avant d'être +transmis. C'est pourquoi un accroissement du traffic HTTPS entraîne une +augmentation de la charge.

    + + +

    Pourquoi les connexions en HTTPS à mon serveur +prennent-elles parfois jusqu'à 30 secondes pour s'établir ?

    +

    Ce problème provient en général d'un périphérique /dev/random +qui bloque l'appel système read(2) jusqu'à ce que suffisamment d'entropie +soit disponible pour servir la requête. Pour plus d'information, se référer au +manuel de référence de la directive +SSLRandomSeed.

    + + +

    Quels sont les algorithmes de chiffrement +supportés par mod_ssl ?

    +

    En général, tous les algorithmes de chiffrement supportés par la version +d'OpenSSL installée, le sont aussi par mod_ssl. La liste des +algorithmes disponibles peut dépendre de la manière dont vous avez installé +OpenSSL. Typiquement, au moins les algorithmes suivants sont supportés :

    + +
      +
    1. RC4 avec SHA1
      2. +
    2. AES avec SHA1
      3. +
    3. Triple-DES avec SHA1
      4. +
    + +

    Pour déterminer la liste réelle des algorithmes disponibles, vous + pouvez utiliser la commande suivante :

    +

    $ openssl ciphers -v

    + + +

    Pourquoi une erreur ``no shared cipher'' apparaît-elle +quand j'essaie d'utiliser un algorithme de chiffrement +Diffie-Hellman anonyme (ADH) ?

    +

    Par défaut et pour des raisons de sécurité, OpenSSl ne permet pas +l'utilisation des algorithmes de chiffrements ADH. Veuillez vous informer +sur les effets pervers potentiels si vous choisissez d'activer le support +de ces algorithmes de chiffrements.

    +

    Pour pouvoir utiliser les algorithmes de chiffrements Diffie-Hellman +anonymes (ADH), vous devez compiler OpenSSL avec +``-DSSL_ALLOW_ADH'', puis ajouter ``ADH'' à votre +directive SSLCipherSuite.

    + + +

    Pourquoi une erreur ``no shared cipher'' +apparaît-elle lorsqu'on se connecte à mon serveur +fraîchement installé ?

    +

    Soit vous avez fait une erreur en définissant votre directive +SSLCipherSuite (comparez-la avec +l'exemple préconfiguré dans extra/httpd-ssl.conf), soit vous avez +choisi d'utiliser des algorithmes DSA/DH au lieu de RSA lorsque vous avez +généré votre clé privée, et avez ignoré ou êtes passé outre les +avertissements. Si vous avez choisi DSA/DH, votre serveur est incapable de +communiquer en utilisant des algorithmes de chiffrements SSL basés sur RSA +(du moins tant que vous n'aurez pas configuré une paire clé/certificat RSA +additionnelle). Les navigateurs modernes tels que NS ou IE ne peuvent +communiquer par SSL qu'avec des algorithmes RSA. C'est ce qui provoque l'erreur +"no shared ciphers". Pour la corriger, générez une nouvelle paire +clé/certificat pour le serveur en utilisant un algorithme de chiffrement +RSA.

    + + +

    Pourquoi ne peut-on pas utiliser SSL avec des hôtes +virtuels identifiés par un nom et non par une adresse IP ?

    +

    La raison est très technique, et s'apparente au problème de la primauté de +l'oeuf ou de la poule. La couche du protocole SSL se trouve en dessous de la +couche de protocole HTTP qu'elle encapsule. Lors de l'établissement d'une +connexion SSL (HTTPS), Apache/mod_ssl doit négocier les paramètres du +protocole SSL avec le client. Pour cela, mod_ssl doit consulter la +configuration du serveur virtuel (par exemple, il doit accéder à la suite +d'algorithmes de chiffrement, au certificat du serveur, etc...). Mais afin de +sélectionner le bon serveur virtuel, Apache doit connaître le contenu du champ +d'en-tête HTTP Host. Pour cela, il doit lire l'en-tête de la +requête HTTP. Mais il ne peut le faire tant que la négociation SSL n'est pas +terminée, or, la phase de négociation SSL a besoin du nom d'hôte contenu +dans l'en-tête de la requête. Voir la question suivante pour +contourner ce problème.

    + +

    Notez que si votre certificat comporte un nom de serveur avec + caractères génériques, ou des noms de serveurs multiples dans le + champ subjectAltName, vous pouvez utiliser SSL avec les serveurs + virtuels à base de noms sans avoir à contourner ce problème.

    + + +

    Est-il possible d'utiliser +l'hébergement virtuel basé sur le nom d'hôte +pour différencier plusieurs hôtes virtuels ?

    +

    L'hébergement virtuel basé sur le nom est une méthode très populaire + d'identification des différents hôtes virtuels. Il permet d'utiliser la + même adresse IP et le même numéro de port pour de nombreux sites + différents. Lorsqu'on se tourne vers SSL, il semble tout naturel de penser + que l'on peut appliquer la même méthode pour gérer plusieurs hôtes + virtuels SSL sur le même serveur.

    + +

    C'est possible, mais seulement si on utilise une version 2.2.12 + ou supérieure du serveur web compilée avec OpenSSL + version 0.9.8j ou supérieure. Ceci est du au fait que + l'utilisation de l'hébergement virtuel à base de nom + avec SSL nécessite une fonctionnalité appelée + Indication du Nom de Serveur (Server Name Indication - SNI) que + seules les révisions les plus récentes de la + spécification SSL supportent.

    + +

    Notez que si votre certificat comporte un nom de serveur avec + caractères génériques, ou des noms de serveurs multiples dans le + champ subjectAltName, vous pouvez utiliser SSL avec les serveurs + virtuels à base de noms sans avoir à contourner ce problème.

    + +

    La raison en est que le protocole SSL constitue une couche séparée qui + encapsule le protocole HTTP. Aini, la session SSL nécessite une + transaction séparée qui prend place avant que la session HTTP n'ait débuté. + Le serveur reçoit une requête SSL sur l'adresse IP X et le port Y + (habituellement 443). Comme la requête SSL ne contenait aucun + en-tête Host:, le serveur n'avait aucun moyen de déterminer quel hôte virtuel SSL il + devait utiliser. En général, il utilisait le premier + qu'il trouvait et qui + correspondait à l'adresse IP et au port spécifiés.

    + +

    Par contre, si vous utilisez des versions du serveur web et + d'OpenSSL qui supportent SNI, et si le navigateur du client le + supporte aussi, alors le nom d'hôte sera inclus dans la + requête SSL originale, et le serveur web pourra + sélectionner le bon serveur virtuel SSL.

    + +

    Bien entendu, vous pouvez utiliser l'hébergement virtuel basé sur le nom + pour identifier de nombreux hôtes virtuels non-SSL + (tous sur le port 80 par exemple), et ne gérer qu'un seul hôte virtuel SSL + (sur le port 443). Mais dans ce cas, vous devez définir le numéro de port + non-SSL à l'aide de la directive NameVirtualHost dans ce style :

    + + 
    NameVirtualHost 192.168.1.1:80
    + + +

    il existe d'autres solutions alternatives comme :

    + +

    Utiliser des adresses IP différentes pour chaque hôte SSL. + Utiliser des numéros de port différents pour chaque hôte SSL.

    + + +

    Comment mettre en oeuvre la compression SSL ?

    +

    Bien que la négociation pour la compression SSL ait été définie dans la +spécification de SSLv2 et TLS, ce n'est qu'en mai 2004 que la RFC 3749 a +défini DEFLATE comme une méthode de compression standard négociable. +

    +

    Depuis la version 0.9.8, OpenSSL supporte cette compression par défaut +lorsqu'il est compilé avec l'option zlib. Si le client et le +serveur supportent la compression, elle sera utilisée. Cependant, la +plupart des clients essaient encore de se connecter avec un Hello SSLv2. +Comme SSLv2 ne comportait pas de table des algorithmes de compression préférés +dans sa négociation, la compression ne peut pas être négociée avec ces clients. +Si le client désactive le support SSLv2, un Hello SSLv3 ou TLS peut être +envoyé, selon la bibliothèque SSL utilisée, et la compression peut être mise +en oeuvre. Vous pouvez vérifier si un client utilise la compression SSL en +journalisant la variable %{SSL_COMPRESS_METHOD}x. +

    + + +

    Lorsque j'utilise l'authentification de base sur HTTPS, +l'icône de verrouillage des navigateurs Netscape reste ouverte quand la boîte +de dialogue d'authentification apparaît. Cela signifie-t-il que les utilisateur +et mot de passe sont envoyés en clair ?

    +

    Non, le couple utilisateur/mot de passe est transmis sous forme chiffrée. + L'icône de chiffrement dans les navigateurs Netscape n'est pas vraiment + synchronisé avec la couche SSL/TLS. Il ne passe à l'état verrouillé + qu'au moment où la première partie des données relatives à la page web + proprement dite sont transférées, ce qui peut prêter à confusion. Le + dispositif d'authentification de base appartient à la couche HTTP, qui + est située au dessus de la couche SSL/TLS dans HTTPS. Avant tout + transfert de données HTTP sous HTTPS, la couche SSL/TLS a déjà achevé + sa phase de négociation et basculé dans le mode de communication + chiffrée. Ne vous laissez donc pas abuser par l'état de cet icône.

    + + +

    Pourquoi des erreurs d'entrée/sortie apparaissent-elles +lorsqu'on se connecte via HTTPS à un serveur Apache+mod_ssl avec des +versions anciennes de +Microsoft Internet Explorer (MSIE) ?

    +

    La première raison en est la présence dans l'implémentation SSL de +certaines versions de MSIE de bogues subtils en rapport avec le +dispositif de "maintien en vie" (keep-alive) HTTP, et les alertes de +notification de fermeture de session SSL en cas de coupure de la +connexion au point d'entrée (socket). De plus, l'interaction entre +SSL et les fonctionnalités HTTP/1.1 pose problème avec certaines +versions de MSIE. Vous pouvez contourner ces problèmes en interdisant +à Apache l'utilisation de HTTP/1.1, les connexions avec maintien en vie +ou l'envoi de messages de notification de fermeture de session SSL aux +clients MSIE. Pour cela, vous pouvez utiliser la directive suivante +dans votre section d'hôte virtuel avec support SSL :

    + 
    SetEnvIf User-Agent "MSIE [2-5]" \
+         nokeepalive ssl-unclean-shutdown \
+         downgrade-1.0 force-response-1.0
    + +

    En outre, certaines versions de MSIE ont des problèmes avec des + algorithmes de chiffrement particuliers. Hélas, il n'est pas + possible d'apporter une solution spécifique à MSIE pour ces + problèmes, car les algorithmes de chiffrement sont utilisés dès la + phase de négociation SSL. Ainsi, une directive + SetEnvIf spécifique + à MSIE ne peut être d'aucun secours. Par contre, vous devrez + ajuster les paramètres généraux de manière drastique. Avant de + vous décider, soyez sûr que vos clients rencontrent vraiment des + problèmes. Dans la négative, n'effectuez pas ces ajustements car + ils affecteront tous vos clients, ceux utilisant MSIE, + mais aussi les autres.

    + + + +

    Comment activer TLS-SRP ?

    +

    TLS-SRP (Echange de clés avec mot de passe distant sécurisé, + défini dans la RFC 5054) peut compléter ou même remplacer les + certificats au cours de l'authentification d'une connexion SSL. Pour + utiliser TLS-SRP, affectez à la directive SSLSRPVerifierFile un fichier de + vérification OpenSSL SRP. Pour créer ce fichier de vérification, + utilisez l'outil openssl :

    +

    + openssl srp -srpvfile passwd.srpv -add username +

    +

    Une fois ce fichier créé, spécifiez-le dans la configuration SSL + du serveur :

    +

    + SSLSRPVerifierFile /path/to/passwd.srpv +

    +

    Pour forcer les clients à utiliser des algorithmes de chiffrement + non basés sur les certificats, utilisez la directive suivante :

    +

    + SSLCipherSuite "!DSS:!aRSA:SRP" +

    + + +

    Pourquoi des erreurs de négociation apparaissent +avec les clients basés sur Java lorsqu'on utilise un certificat de plus +de 1024 bits ?

    +

    Depuis la version 2.5.0-dev et à/c du 29/09/2013, + mod_ssl utilise des paramètres DH qui comportent + des nombres premiers de plus de 1024 bits. Cependant, java 7 et ses versions + antérieures ne supportent que les nombres premiers DH d'une longueur + maximale de 1024 bits.

    + +

    Si votre client basé sur Java s'arrête avec une exception telle + que java.lang.RuntimeException: Could not generate DH + keypair et + java.security.InvalidAlgorithmParameterException: Prime size + must be multiple of 64, and can only range from 512 to 1024 + (inclusive), et si httpd enregistre le message tlsv1 + alert internal error (SSL alert number 80) dans son journal + des erreurs (avec un LogLevel + info ou supérieur), vous pouvez soit réarranger la + liste d'algorithmes de mod_ssl via la directive SSLCipherSuite (éventuellement en + conjonction avec la directive SSLHonorCipherOrder), soit utiliser des + paramètres DH personnalisés avec un nombre + premier de 1024 bits, paramètres qui seront toujours prioritaires + par rapport à tout autre paramètre DH par défaut.

    + +

    Pour générer des paramètres DH personnalisés, utilisez la + commande openssl dhparam 1024. Vous pouvez aussi + utiliser les paramètres DH standards issus de la RFC 2409, section 6.2 :

    + 
    -----BEGIN DH PARAMETERS-----
+MIGHAoGBAP//////////yQ/aoiFowjTExmKLgNwc0SkCTgiKZ8x0Agu+pjsTmyJR
+Sgh5jjQE3e+VGbPNOkMbMCsKbfJfFDdP4TVtbVHCReSFtXZiXn7G9ExC6aY37WsL
+/1y29Aa37e44a/taiZ+lrp8kEXxLH+ZJKGZR7OZTgf//////////AgEC
+-----END DH PARAMETERS-----
    +

    Ajoute les paramètres personnalisés incluant les lignes "BEGIN DH + PARAMETERS" et "END DH PARAMETERS" à la fin du premier fichier de + certificat défini via la directive SSLCertificateFile.

    + + + +
    top
    +
    +

    Support de mod_ssl

    + + +

    Quelles sont les sources d'informations +disponibles en cas de problème avec mod_ssl ?

    +

    Voici les sources d'informations disponibles ; vous devez chercher +ici en cas de problème.

    + +
    +
    Vous trouverez des réponses dans la Foire Aux Questions du + manuel utilisateur (ce document)
    +
    + http://httpd.apache.org/docs/trunk/ssl/ssl_faq.html
    + Cherchez tout d'abord dans la foire aux questions + (ce document). Si votre question est courante, on a déjà dû y + répondre de nombreuses fois, et elle fait probablement partie + de ce document. +
    +
    + + +

    Qui peut-on contacter pour un support en cas de +problème avec mod_ssl ?

    +

    Voici toutes les possibilités de support pour mod_ssl, par ordre + de préférence. Merci d'utiliser ces possibilités + dans cet ordre - ne vous précipitez pas sur celle qui vous + paraît la plus alléchante.

    +
      +
    1. Envoyez un rapport de problème à la liste de diffusion de + support des utilisateurs d'Apache httpd
      + + users@httpd.apache.org
      + C'est la deuxième manière de soumettre votre rapport de + problème. Ici aussi, vous devez d'abord vous abonner à la + liste, mais vous pourrez ensuite discuter facilement de votre + problème avec l'ensemble de la communauté d'utilisateurs + d'Apache httpd. +
      2. + +
    2. Ecrire un rapport de problème dans la base de données des + bogues
      + + http://httpd.apache.org/bug_report.html
      + C'est la dernière manière de soumettre votre rapport de + problème. Vous ne devez utiliser cette solution que si vous + avez déjà écrit aux listes de diffusion, et n'avez pas trouvé + de solution. Merci de suivre les instructions de la page + mentionnée ci-dessus avec soin. +
      3. +
    + + +

    Quelles informations dois-je fournir lors +de l'écriture d'un rapport de bogue ?

    +

    Vous devez toujours fournir au moins les informations +suivantes :

    + +
    +
    Les versions d'Apache httpd et OpenSSL installées
    +
    La version d'Apache peut être déterminée en exécutant + httpd -v. La version d'OpenSSL peut être déterminée + en exécutant openssl version. Si Lynx est installé, + vous pouvez aussi exécuter la commandelynx -mime_header + http://localhost/ | grep Server et ainsi obtenir ces + informations en une seule fois. +
    + +
    Les détails de votre installation d'Apache httpd et OpenSSL
    +
    A cet effet, vous pouvez fournir un fichier journal de votre + session de terminal qui montre les étapes de la configuration et + de l'installation. En cas d'impossibilité, vous devez au moins + fournir la ligne de commande configure que + vous avez utilisée. +
    + +
    En cas de vidage mémoire, inclure une trace de ce qui s'est + passé
    +
    Si votre serveur Apache httpd fait un vidage de sa + mémoire, merci de fournir en pièce jointe un fichier contenant + une trace de la zone dédiée à la pile (voir + ci-dessous pour des informations sur la manière + de l'obtenir). Il est nécessaire de disposer de ces informations + afin de pouvoir déterminer la raison de votre vidage mémoire. +
    + +
    Une description détaillée de votre problème
    + +
    Ne riez pas, nous sommes sérieux ! De nombreux rapports + n'incluent pas de description de la véritable nature du problème. + Sans ces informations, il est très difficile pour quiconque de + vous aider. Donc, et c'est votre propre intérêt (vous souhaitez + que le problème soit résolu, n'est-ce pas ?), fournissez, s'il vous + plait, le maximum de détails possible. Bien entendu, vous devez + aussi inclure tout ce qui a été dit précédemment. +
    +
    + + +

    Un vidage mémoire s'est produit, +pouvez-vous m'aider ?

    +

    En général non, du moins tant que vous n'aurez pas fourni plus de +détails à propos de la localisation dans le code où Apache a effectué +son vidage mémoire. Ce dont nous avons en général besoin pour vous +aider est une trace de ce qui s'est passé (voir la question suivante). +Sans cette information, il est pratiquement impossible de déterminer +la nature du problème et de vous aider à le résoudre.

    + + +

    Comment puis-je obtenir une journalisation de +ce qui s'est passé, pour m'aider à trouver la raison de ce vidage +mémoire ?

    +

    Vous trouverez ci-dessous les différentes étapes permettant +d'obtenir une journalisation des évènements (backtrace) :

    +
      +
    1. Assurez-vous que les symboles de débogage sont disponibles, au + moins pour Apache. Pour cela, sur les plates-formes où GCC/GDB est + utilisé, vous devez compiler Apache+mod_ssl avec l'option + ``OPTIM="-g -ggdb3"''. Sur les autres plates-formes, + l'option ``OPTIM="-g"'' est un minimum. +
      2. + +
    2. Démarrez le serveur et essayez de reproduire le vidage mémoire. + A cet effet, vous pouvez utiliser une directive du style + ``CoreDumpDirectory /tmp'' pour être sûr que le + fichier de vidage mémoire puisse bien être écrit. Vous devriez + obtenir un fichier /tmp/core ou + /tmp/httpd.core. Si ce n'est pas le cas, essayez de + lancer votre serveur sous un UID autre que root. + Pour des raisons de sécurité, de nombreux + noyaux modernes de permettent pas à un processus de vider sa + mémoire une fois qu'il a accompli un setuid() (à moins + qu'il effectue un exec()) car des informations d'un + niveau privilégié pourraient être transmises en mémoire. Si + nécessaire, vous pouvez exécuter /chemin/vers/httpd -X + manuellement afin de ne pas permettre à Apache de se clôner (fork). +
      3. + +
    3. Analysez le vidage mémoire. Pour cela, exécutez + gdb /path/to/httpd /tmp/httpd.core ou une commande + similaire. Dans GDB, tout ce que vous avez à faire est d'entrer + bt, et voila, vous obtenez la backtrace. Pour les + débogueurs autres que GDB consulter le manuel correspondant. +
      4. +
    + +
    +
    +

    Langues Disponibles:  en  | + fr 

    +
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    +
    + \ No newline at end of file diff --git a/docs/manual/ssl/ssl_howto.html.en b/docs/manual/ssl/ssl_howto.html.en index 45b653309c..dce6b736f5 100644 --- a/docs/manual/ssl/ssl_howto.html.en +++ b/docs/manual/ssl/ssl_howto.html.en @@ -24,7 +24,7 @@ Apache > HTTP Server > Documentation > Version 2.5 > SSL/TLS

    SSL/TLS Strong Encryption: How-To

    Available Languages:  en  | - fr 

    + fr 

    @@ -472,7 +472,7 @@ plain HTTP access for clients on the Intranet.

    Available Languages:  en  | - fr 

    + fr 

    top

    Comments

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    - - -
    -

    Modules | Directives | FAQ | Glossaire | Plan du site

    -

    Serveur HTTP Apache Version 2.5

    -
    -
    <-
    -

    Chiffrement fort SSL/TLS : Mode d'emploi

    -
    -

    Langues Disponibles:  en  | - fr 

    -
    - - -

    Ce document doit vous permettre de démarrer et de faire fonctionner -une configuration de base. Avant de vous lancer dans l'application de -techniques avancées, il est fortement recommandé de lire le reste -de la documentation SSL afin d'en comprendre le fonctionnement de -manière plus approfondie.

    -
    - -
    top
    -
    -

    Exemple de configuration basique

    - - -

    Votre configuration SSL doit comporter au moins les directives -suivantes :

    - -
    Listen 443
-<VirtualHost *:443>
-    ServerName www.example.com
-    SSLEngine on
-    SSLCertificateFile "/path/to/www.example.com.cert"
-    SSLCertificateKeyFile "/path/to/www.example.com.key"
-</VirtualHost>
    - - -
    top
    -
    -

    Suites d'algorithmes de chiffrement et mise en oeuvre du chiffrement fort

    - - -
    -

    Le "chiffrement fort est et a toujours été une cible mouvante. En outre, la -définition du terme "fort" dépend de l'utilisation que vous allez faire de votre -chiffrement, de vos modèles de menaces, et du niveau de risque que vous -considérez comme acceptable. L'équipe du serveur HTTP Apache ne peut donc pas -définir ce chiffrement fort à votre place.

    -

    Dans ce document dont la dernière mise à jour remonte à la mi-2016, une -"chiffrement fort" fait référence à une implémentation TLS qui fournit, en plus -d'une protection basique de la confidentialité, de l'intégrité et de -l'authenticité que tout utilisateur s'attend à trouver, toutes les -fonctionnalités suivantes :

    -
      -
    • Une confidentialité persistante (Forward Secrecy) parfaite qui garantie que -la découverte de la clé privée d'un serveur ne compromettra pas la -condidentialité des communications TLS passées.
      • -
    • Une protection contre les types d'attaque connus contre les anciennes -implémentations SSL et TLS comme POODLE et BEAST.
      • -
    • Le support des algorithmes de chiffrement les plus efficaces disponibles sur -les navigateurs web modernes (et à jour), ainsi que sur les autres clients HTTP.
      • -
    • Le Rejet des clients qui ne sont pas en mesure de respecter -ces prérequis. En d'autres termes, un "chiffrement fort" implique que les -clients obsolètes ne doivent pas avoir la possibilité de se connecter au serveur -afin de les empêcher de mettre en danger leurs utilisateurs. Vous seul(e) êtes -alors à même de décider si ce comportement est approprié à votre situation.
      • -
    -

    Notez cependant qu'un chiffrement fort ne suffit pas à lui seul pour -assurer un niveau de securité fort (A titre d'exemple, les attaques -oracle sur la compression HTTP comme BREACH -peuvent nécessiter des actions supplémentaires pour être éradiquées).

    -
    - - - - -

    Comment créer un serveur SSL qui n'accepte -que le chiffrement fort ?

    - -

    La configuration suivante active le "chiffrement fort" telle qu'il est - défini ci-dessus, et s'inspire du document de la Fondation Mozilla sur les - prérequis de Server Side - TLS :

    - - 
    # Configuration "moderne" définie en août 2016 par le générateur de
-# configuration SSL de la Fondation Mozilla. Ce dernier est disponible à
-# https://mozilla.github.io/server-side-tls/ssl-config-generator/
-SSLProtocol         all -SSLv3 -TLSv1 -TLSv1.1
-# De nombreux algorithmes de chiffrement définis ici nécessitent une version
-# récente (1.0.1 ou plus) d'OpenSSL. Certains nécessitent même OpenSSL 1.1.0
-# qui, à l'heure où ces lignes sont écrites, était encore en pre-release.
-SSLCipherSuite      ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
-SSLHonorCipherOrder on
-SSLCompression      off
-SSLSessionTickets   off
    - - -
      -
    • SSL 3.0 et TLS 1.0 étant vulnérables à certaines attaques connues contre - le protocole, ils ont été entièrement retirés.
      • -
    • Actuellement (en août 2016), la désactivation de TLS 1.1 est facultative - ; TLS 1.2 fournit des options de chiffrement plus évoluées, mais la version - 1.1 n'est pas encore considérée comme obsolète. La désactivation de TLS 1.1 - peut cependant juguler des attaques contre certaines implémentations - dépassées de TLS.
      • -
    • La directive SSLHonorCipherOrder - permet de s'assurer que ce sont les préférences de chiffrement du serveur - qui seront suivies, et non celles du client.
      • -
    • La désactivation de SSLCompression permet de prévenir les attaques - oracle sur la compression TLS (en autres CRIME).
      • -
    • La désactivation de SSLSessionTickets permet de s'assurer que la - qualité de la confidentialité persistante (Forward Secrecy) ne sera pas - compromise, même si le serveur n'est pas redémarré régulièrement.
      • -
    - -

    C'est votre version d'OpenSSL installée qui détermine la liste des - algorithmes de chiffrement supportés par la directive SSLCipherSuite, et non le serveur. Pour pouvoir - utiliser certains d'entre eux, vous devrez peut-être mettre à jour votre - version d'OpenSSL.

    - - -

    Comment créer un serveur qui accepte de nombreux types de -chiffrement en général, mais exige un chiffrement fort pour pouvoir -accéder à une URL particulière ?

    - -

    Dans ce cas bien évidemment, une directive SSLCipherSuite au niveau du serveur principal - qui restreint le choix des suites de chiffrement aux versions les plus - fortes ne conviendra pas. mod_ssl peut cependant être - reconfiguré au sein de blocs Location qui permettent - d'adapter la configuration générale à un répertoire spécifique ; - mod_ssl peut alors forcer automatiquement une - renégociation des paramètres SSL pour parvenir au but recherché. - Cette configuration peut se présenter comme suit :

    - 
    # soyons très tolérant a priori -- utilisons la suite d'algorithmes de
-# chiffrement "intermédiaire" de Mozilla (des suites plus légères peuvent aussi
-# être utilisées mais ne seront pas documentées ici)
-SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
-
-<Location "/strong/area">
-# sauf pour https://hostname/strong/area/ et ses sous-répertoires qui exigent
-# des chiffrements forts
-SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
-</Location>
    - - -
    top
    -
    -

    Agrafage OCSP

    - - -

    Le protocole de contrôle du statut des certificats en ligne (Online -Certificate Status Protocol - OCSP) est un mécanisme permettant de -déterminer si un certificat a été révoqué ou non, et l'agrafage OCSP en -est une fonctionnalité particulière par laquelle le serveur, par exemple -httpd et mod_ssl, maintient une liste des réponses OCSP actuelles pour -ses certificats et l'envoie aux clients qui communiquent avec lui. La -plupart des certificats contiennent l'adresse d'un répondeur OCSP maintenu -par l'Autorité de Certification (CA) spécifiée, et mod_ssl peut requérir -ce répondeur pour obtenir une réponse signée qui peut être envoyée aux -clients qui communiquent avec le serveur.

    - -

    L'agrafage OCSP est la méthode la plus performante pour obtenir le -statut d'un certificat car il est disponible au niveau du serveur, et le -client n'a donc pas besoin d'ouvrir une nouvelle connexion vers -l'autorité de certification. Autres avantages de l'absence de -communication entre le client et l'autorité de certification : -l'autorité de certification n'a pas accès à l'historique de navigation -du client, et l'obtention du statut du certificat est plus efficace car -elle n'est plus assujettie à une surcharge éventuelle des serveurs de -l'autorité de certification.

    - -

    La charge du serveur est moindre car la réponse qu'il a obtenu du -répondeur OCSP peut être réutilisée par tous les clients qui utilisent -le même certificat dans la limite du temps de validité de la réponse.

    - -

    Une fois le support général SSL correctement configuré, l'activation -de l'agrafage OCSP ne requiert que des modifications mineures -à la configuration de httpd et il suffit en général de l'ajout de ces -deux directives :

    - - 
    SSLUseStapling On
-SSLStaplingCache "shmcb:ssl_stapling(32768)"
    - - -

    Ces directives sont placées de façon à ce qu'elles aient une portée -globale (et particulièrement en dehors de toute section VirtualHost), le -plus souvent où sont placées les autres directives de configuration -globales SSL, comme conf/extra/httpd-ssl.conf pour les -installations de httpd à partir des sources, ou -/etc/apache2/mods-enabled/ssl.conf pour Ubuntu ou Debian, -etc...

    - -

    Cette directive SSLStaplingCache particulière -nécessite le chargement du module mod_socache_shmcb (à -cause du préfixe shmcb de son argument). Ce module est en -général déjà activé pour la directive -SSLSessionCache, ou pour des modules autres que -mod_ssl. Si vous activez un cache de session SSL -utilisant un mécanisme autre que mod_socache_shmcb, -utilisez aussi ce mécanisme alternatif pour la directive -SSLStaplingCache. Par exemple :

    - - 
    SSLSessionCache "dbm:ssl_scache"
-SSLStaplingCache "dbm:ssl_stapling"
    - - -

    Vous pouvez utiliser la commande openssl pour vérifier que votre -serveur envoie bien une réponse OCSP :

    - -
    $ openssl s_client -connect www.example.com:443 -status -servername www.example.com
-...
-OCSP response: 
-======================================
-OCSP Response Data:
-    OCSP Response Status: successful (0x0)
-    Response Type: Basic OCSP Response
-...
-    Cert Status: Good
-...
    - -

    Les sections suivantes explicitent les situations courantes qui -requièrent des modifications supplémentaires de la configuration. Vous -pouvez aussi vous référer au manuel de référence de -mod_ssl.

    - -

    Si l'on utilise plus que quelques certificats SSL pour le serveur

    - -

    Les réponses OCSP sont stockées dans le cache d'agrafage SSL. Alors -que les réponses ont une taille de quelques centaines à quelques -milliers d'octets, mod_ssl supporte des réponses d'une taille jusqu'à -environ 10 ko. Dans notre cas, le nombre de certificats est conséquent -et la taille du cache (32768 octets dans l'exemple ci-dessus) doit être -augmentée. En cas d'erreur lors du stockage d'une réponse, le -message AH01929 sera enregistré dans le journal.

    - - -

    Si le certificat ne spécifie pas de répondeur OCSP, ou si une -adresse différente doit être utilisée

    - -

    Veuillez vous référer à la documentation de la directive SSLStaplingForceURL.

    - -

    Vous pouvez vérifier si un certificat spécifie un répondeur OCSP en -utilisant la commande openssl comme suit :

    - -
    $ openssl x509 -in ./www.example.com.crt -text | grep 'OCSP.*http'
-OCSP - URI:http://ocsp.example.com
    - -

    Si un URI OCSP est fourni et si le serveur web peut communiquer -directement avec lui sans passer par un mandataire, aucune modification -supplémentaire de la configuration n'est requise. Notez que les règles -du pare-feu qui contrôlent les connexions sortantes en provenance du -serveur web devront peut-être subir quelques ajustements.

    - -

    Si aucun URI OCSP n'est fourni, contactez votre autorité de -certification pour savoir s'il en existe une ; si c'est le -cas, utilisez la directive SSLStaplingForceURL pour la spécifier dans -la configuration du serveur virtuel qui utilise le certificat.

    - - -

    Si plusieurs serveurs virtuels sont configurés pour utiliser SSL -et si l'agrafage OCSP doit être désactivé pour certains d'entre eux

    - - -

    Ajoutez la directive SSLUseStapling Off à la -configuration des serveurs virtuels pour lesquels l'agrafage OCSP doit -être désactivé.

    - - -

    Si le répondeur OCSP est lent ou instable

    - -

    De nombreuses directives permettent de gérer les temps de réponse et -les erreurs. Référez-vous à la documentation de SSLStaplingFakeTryLater, SSLStaplingResponderTimeout, et SSLStaplingReturnResponderErrors.

    - - -

    Si mod_ssl enregistre l'erreur AH02217 dans le journal

    - -
    AH02217: ssl_stapling_init_cert: Can't retrieve issuer certificate!
    -

    Afin de pouvoir supporter l'agrafage OCSP lorsqu'un certificat de -serveur particulier est utilisé, une chaîne de certification pour ce -certificat doit être spécifiée. Si cela n'a pas été fait lors de -l'activation de SSL, l'erreur AH02217 sera enregistrée lorsque -l'agrafage OCSP sera activé, et les clients qui utilisent le certificat -considéré ne recevront pas de réponse OCSP.

    - -

    Veuillez vous référer à la documentation des directives SSLCertificateChainFile et SSLCertificateFile pour spécifier une -chaîne de certification.

    - - -
    top
    -
    -

    Authentification du client et contrôle d'accès

    - - - -

    Comment forcer les clients -à s'authentifier à l'aide de certificats ? -

    - - -

    Lorsque vous connaissez tous vos clients (comme c'est en général le cas - au sein d'un intranet d'entreprise), vous pouvez imposer une - authentification basée uniquement sur les certificats. Tout ce dont vous - avez besoin pour y parvenir est de créer des certificats clients signés par - le certificat de votre propre autorité de certification - (ca.crt), et d'authentifier les clients à l'aide de ces - certificats.

    - 
    # exige un certificat client signé par le certificat de votre CA
-# contenu dans ca.crt
-SSLVerifyClient require
-SSLVerifyDepth 1
-SSLCACertificateFile "conf/ssl.crt/ca.crt"
    - - - -

    Comment forcer les clients -à s'authentifier à l'aide de certificats pour une URL particulière, -mais autoriser quand-même tout client anonyme -à accéder au reste du serveur ?

    - - -

    Pour forcer les clients à s'authentifier à l'aide de certificats pour une -URL particulière, vous pouvez utiliser les fonctionnalités de reconfiguration -de mod_ssl en fonction du répertoire :

    - - 
    SSLVerifyClient none
-SSLCACertificateFile "conf/ssl.crt/ca.crt"
-
-<Location "/secure/area">
-SSLVerifyClient require
-SSLVerifyDepth 1
-</Location>
    - - - -

    Comment n'autoriser l'accès à une URL -particulière qu'aux clients qui possèdent des certificats, mais autoriser -l'accès au reste du serveur à tous les clients ?

    - - -

    La clé du problème consiste à vérifier si une partie du certificat - client correspond à ce que vous attendez. Cela signifie en général - consulter tout ou partie du nom distinctif (DN), afin de vérifier s'il - contient une chaîne connue. Il existe deux méthodes pour y parvenir ; - on utilise soit le module mod_auth_basic, soit la - directive SSLRequire.

    - -

    La méthode du module mod_auth_basic est en général - incontournable lorsque les certificats ont un contenu arbitraire, ou - lorsque leur DN ne contient aucun champ connu - (comme l'organisation, etc...). Dans ce cas, vous devez construire une base - de données de mots de passe contenant tous les clients - autorisés, comme suit :

    - - 
    SSLVerifyClient      none
-SSLCACertificateFile "conf/ssl.crt/ca.crt"
-SSLCACertificatePath "conf/ssl.crt"
-
-<Directory "/usr/local/apache2/htdocs/secure/area">
-SSLVerifyClient      require
-    SSLVerifyDepth       5
-    SSLOptions           +FakeBasicAuth
-    SSLRequireSSL
-    AuthName             "Snake Oil Authentication"
-    AuthType             Basic
-    AuthBasicProvider    file
-    AuthUserFile         "/usr/local/apache2/conf/httpd.passwd"
-    Require              valid-user
-</Directory>
    - - - -

    Le mot de passe utilisé dans cet exemple correspond à la chaîne de - caractères "password" chiffrée en DES. Voir la documentation de la - directive SSLOptions pour - plus de détails.

    - -

    httpd.passwd

    /C=DE/L=Munich/O=Snake Oil, Ltd./OU=Staff/CN=Foo:xxj31ZMTZzkVA
-/C=US/L=S.F./O=Snake Oil, Ltd./OU=CA/CN=Bar:xxj31ZMTZzkVA
-/C=US/L=L.A./O=Snake Oil, Ltd./OU=Dev/CN=Quux:xxj31ZMTZzkVA
    - -

    Lorsque vos clients font tous partie d'une même hiérarchie, ce qui - apparaît dans le DN, vous pouvez les authentifier plus facilement en - utilisant la directive SSLRequire, comme suit :

    - - - 
    SSLVerifyClient      none
-SSLCACertificateFile "conf/ssl.crt/ca.crt"
-SSLCACertificatePath "conf/ssl.crt"
-
-<Directory "/usr/local/apache2/htdocs/secure/area">
-  SSLVerifyClient      require
-  SSLVerifyDepth       5
-  SSLOptions           +FakeBasicAuth
-  SSLRequireSSL
-  SSLRequire       %{SSL_CLIENT_S_DN_O}  eq "Snake Oil, Ltd." \
-               and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"}
-</Directory>
    - - - -

    Comment imposer HTTPS avec chiffrements forts, -et soit authentification de base, soit possession de certificats clients, -pour l'accès à une partie de l'Intranet, pour les clients en -provenance de l'Internet ? Je souhaite quand-même autoriser l'accès en HTTP -aux clients de l'intranet.

    - - -

    On suppose dans ces exemples que les clients de l'intranet ont des - adresses IP dans la gamme 192.168.1.0/24, et que la partie de l'intranet - à laquelle vous voulez autoriser l'accès depuis l'Internet est - /usr/local/apache2/htdocs/subarea. Ces lignes de configuration - doivent se trouver en dehors de votre hôte virtuel HTTPS, afin qu'elles - s'appliquent à la fois à HTTP et HTTPS.

    - - 
    SSLCACertificateFile "conf/ssl.crt/company-ca.crt"
-
-<Directory "/usr/local/apache2/htdocs">
-#   En dehors de subarea, seul l'accès depuis l'intranet est
-#   autorisé
-    Require              ip 192.168.1.0/24
-</Directory>
-
-<Directory "/usr/local/apache2/htdocs/subarea">
-#   Dans subarea, tout accès depuis l'intranet est autorisé
-#   mais depuis l'Internet, seul l'accès par HTTPS + chiffrement fort + Mot de passe
-#   ou HTTPS + chiffrement fort + certificat client n'est autorisé.
-
-#   Si HTTPS est utilisé, on s'assure que le niveau de chiffrement est fort.
-#   Autorise en plus les certificats clients comme une alternative à
-#   l'authentification basique.
-    SSLVerifyClient      optional
-    SSLVerifyDepth       1
-    SSLOptions           +FakeBasicAuth +StrictRequire
-    SSLRequire           %{SSL_CIPHER_USEKEYSIZE} >= 128
-    
-    #   ON oblige les clients venant d'Internet à utiliser HTTPS
-    RewriteEngine        on
-    RewriteCond          "%{REMOTE_ADDR}" "!^192\.168\.1\.[0-9]+$"
-    RewriteCond          "%{HTTPS}" "!=on"
-    RewriteRule          "." "-" [F]
-    
-    #   On permet l'accès soit sur les critères réseaux, soit par authentification Basique
-    Satisfy              any
-    
-    #   Contrôle d'accès réseau
-    Require              ip 192.168.1.0/24
-    
-    #   Configuration de l'authentification HTTP Basique
-    AuthType             basic
-    AuthName             "Protected Intranet Area"
-    AuthBasicProvider    file
-    AuthUserFile         "conf/protected.passwd"
-    Require              valid-user
-</Directory>
    - - -
    top
    -
    -

    Journalisation

    - - -

    mod_ssl peut enregistrer des informations de - débogage très verbeuses dans le journal des erreurs, lorsque sa - directive LogLevel est définie - à des niveaux de trace élevés. Par contre, sur un serveur très - sollicité, le niveau info sera probablement déjà trop - élevé. Souvenez-vous que vous pouvez configurer la directive - LogLevel par module afin de - pourvoir à vos besoins.

    -
    -
    -

    Langues Disponibles:  en  | - fr 

    -
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    -
    - \ No newline at end of file diff --git a/docs/manual/ssl/ssl_howto.html.fr.utf8 b/docs/manual/ssl/ssl_howto.html.fr.utf8 new file mode 100644 index 0000000000..4cd3afd24a --- /dev/null +++ b/docs/manual/ssl/ssl_howto.html.fr.utf8 @@ -0,0 +1,540 @@ + + + + + +Chiffrement fort SSL/TLS : Mode d'emploi - Serveur HTTP Apache Version 2.5 + + + + + + +
    +

    Modules | Directives | FAQ | Glossaire | Plan du site

    +

    Serveur HTTP Apache Version 2.5

    +
    +
    <-
    +

    Chiffrement fort SSL/TLS : Mode d'emploi

    +
    +

    Langues Disponibles:  en  | + fr 

    +
    + + +

    Ce document doit vous permettre de démarrer et de faire fonctionner +une configuration de base. Avant de vous lancer dans l'application de +techniques avancées, il est fortement recommandé de lire le reste +de la documentation SSL afin d'en comprendre le fonctionnement de +manière plus approfondie.

    +
    + +
    top
    +
    +

    Exemple de configuration basique

    + + +

    Votre configuration SSL doit comporter au moins les directives +suivantes :

    + +
    Listen 443
+<VirtualHost *:443>
+    ServerName www.example.com
+    SSLEngine on
+    SSLCertificateFile "/path/to/www.example.com.cert"
+    SSLCertificateKeyFile "/path/to/www.example.com.key"
+</VirtualHost>
    + + +
    top
    +
    +

    Suites d'algorithmes de chiffrement et mise en oeuvre du chiffrement fort

    + + +
    +

    Le "chiffrement fort est et a toujours été une cible mouvante. En outre, la +définition du terme "fort" dépend de l'utilisation que vous allez faire de votre +chiffrement, de vos modèles de menaces, et du niveau de risque que vous +considérez comme acceptable. L'équipe du serveur HTTP Apache ne peut donc pas +définir ce chiffrement fort à votre place.

    +

    Dans ce document dont la dernière mise à jour remonte à la mi-2016, une +"chiffrement fort" fait référence à une implémentation TLS qui fournit, en plus +d'une protection basique de la confidentialité, de l'intégrité et de +l'authenticité que tout utilisateur s'attend à trouver, toutes les +fonctionnalités suivantes :

    +
      +
    • Une confidentialité persistante (Forward Secrecy) parfaite qui garantie que +la découverte de la clé privée d'un serveur ne compromettra pas la +condidentialité des communications TLS passées.
      • +
    • Une protection contre les types d'attaque connus contre les anciennes +implémentations SSL et TLS comme POODLE et BEAST.
      • +
    • Le support des algorithmes de chiffrement les plus efficaces disponibles sur +les navigateurs web modernes (et à jour), ainsi que sur les autres clients HTTP.
      • +
    • Le Rejet des clients qui ne sont pas en mesure de respecter +ces prérequis. En d'autres termes, un "chiffrement fort" implique que les +clients obsolètes ne doivent pas avoir la possibilité de se connecter au serveur +afin de les empêcher de mettre en danger leurs utilisateurs. Vous seul(e) êtes +alors à même de décider si ce comportement est approprié à votre situation.
      • +
    +

    Notez cependant qu'un chiffrement fort ne suffit pas à lui seul pour +assurer un niveau de securité fort (A titre d'exemple, les attaques +oracle sur la compression HTTP comme BREACH +peuvent nécessiter des actions supplémentaires pour être éradiquées).

    +
    + + + + +

    Comment créer un serveur SSL qui n'accepte +que le chiffrement fort ?

    + +

    La configuration suivante active le "chiffrement fort" telle qu'il est + défini ci-dessus, et s'inspire du document de la Fondation Mozilla sur les + prérequis de Server Side + TLS :

    + + 
    # Configuration "moderne" définie en août 2016 par le générateur de
+# configuration SSL de la Fondation Mozilla. Ce dernier est disponible à
+# https://mozilla.github.io/server-side-tls/ssl-config-generator/
+SSLProtocol         all -SSLv3 -TLSv1 -TLSv1.1
+# De nombreux algorithmes de chiffrement définis ici nécessitent une version
+# récente (1.0.1 ou plus) d'OpenSSL. Certains nécessitent même OpenSSL 1.1.0
+# qui, à l'heure où ces lignes sont écrites, était encore en pre-release.
+SSLCipherSuite      ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
+SSLHonorCipherOrder on
+SSLCompression      off
+SSLSessionTickets   off
    + + +
      +
    • SSL 3.0 et TLS 1.0 étant vulnérables à certaines attaques connues contre + le protocole, ils ont été entièrement retirés.
      • +
    • Actuellement (en août 2016), la désactivation de TLS 1.1 est facultative + ; TLS 1.2 fournit des options de chiffrement plus évoluées, mais la version + 1.1 n'est pas encore considérée comme obsolète. La désactivation de TLS 1.1 + peut cependant juguler des attaques contre certaines implémentations + dépassées de TLS.
      • +
    • La directive SSLHonorCipherOrder + permet de s'assurer que ce sont les préférences de chiffrement du serveur + qui seront suivies, et non celles du client.
      • +
    • La désactivation de SSLCompression permet de prévenir les attaques + oracle sur la compression TLS (en autres CRIME).
      • +
    • La désactivation de SSLSessionTickets permet de s'assurer que la + qualité de la confidentialité persistante (Forward Secrecy) ne sera pas + compromise, même si le serveur n'est pas redémarré régulièrement.
      • +
    + +

    C'est votre version d'OpenSSL installée qui détermine la liste des + algorithmes de chiffrement supportés par la directive SSLCipherSuite, et non le serveur. Pour pouvoir + utiliser certains d'entre eux, vous devrez peut-être mettre à jour votre + version d'OpenSSL.

    + + +

    Comment créer un serveur qui accepte de nombreux types de +chiffrement en général, mais exige un chiffrement fort pour pouvoir +accéder à une URL particulière ?

    + +

    Dans ce cas bien évidemment, une directive SSLCipherSuite au niveau du serveur principal + qui restreint le choix des suites de chiffrement aux versions les plus + fortes ne conviendra pas. mod_ssl peut cependant être + reconfiguré au sein de blocs Location qui permettent + d'adapter la configuration générale à un répertoire spécifique ; + mod_ssl peut alors forcer automatiquement une + renégociation des paramètres SSL pour parvenir au but recherché. + Cette configuration peut se présenter comme suit :

    + 
    # soyons très tolérant a priori -- utilisons la suite d'algorithmes de
+# chiffrement "intermédiaire" de Mozilla (des suites plus légères peuvent aussi
+# être utilisées mais ne seront pas documentées ici)
+SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
+
+<Location "/strong/area">
+# sauf pour https://hostname/strong/area/ et ses sous-répertoires qui exigent
+# des chiffrements forts
+SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
+</Location>
    + + +
    top
    +
    +

    Agrafage OCSP

    + + +

    Le protocole de contrôle du statut des certificats en ligne (Online +Certificate Status Protocol - OCSP) est un mécanisme permettant de +déterminer si un certificat a été révoqué ou non, et l'agrafage OCSP en +est une fonctionnalité particulière par laquelle le serveur, par exemple +httpd et mod_ssl, maintient une liste des réponses OCSP actuelles pour +ses certificats et l'envoie aux clients qui communiquent avec lui. La +plupart des certificats contiennent l'adresse d'un répondeur OCSP maintenu +par l'Autorité de Certification (CA) spécifiée, et mod_ssl peut requérir +ce répondeur pour obtenir une réponse signée qui peut être envoyée aux +clients qui communiquent avec le serveur.

    + +

    L'agrafage OCSP est la méthode la plus performante pour obtenir le +statut d'un certificat car il est disponible au niveau du serveur, et le +client n'a donc pas besoin d'ouvrir une nouvelle connexion vers +l'autorité de certification. Autres avantages de l'absence de +communication entre le client et l'autorité de certification : +l'autorité de certification n'a pas accès à l'historique de navigation +du client, et l'obtention du statut du certificat est plus efficace car +elle n'est plus assujettie à une surcharge éventuelle des serveurs de +l'autorité de certification.

    + +

    La charge du serveur est moindre car la réponse qu'il a obtenu du +répondeur OCSP peut être réutilisée par tous les clients qui utilisent +le même certificat dans la limite du temps de validité de la réponse.

    + +

    Une fois le support général SSL correctement configuré, l'activation +de l'agrafage OCSP ne requiert que des modifications mineures +à la configuration de httpd et il suffit en général de l'ajout de ces +deux directives :

    + + 
    SSLUseStapling On
+SSLStaplingCache "shmcb:ssl_stapling(32768)"
    + + +

    Ces directives sont placées de façon à ce qu'elles aient une portée +globale (et particulièrement en dehors de toute section VirtualHost), le +plus souvent où sont placées les autres directives de configuration +globales SSL, comme conf/extra/httpd-ssl.conf pour les +installations de httpd à partir des sources, ou +/etc/apache2/mods-enabled/ssl.conf pour Ubuntu ou Debian, +etc...

    + +

    Cette directive SSLStaplingCache particulière +nécessite le chargement du module mod_socache_shmcb (à +cause du préfixe shmcb de son argument). Ce module est en +général déjà activé pour la directive +SSLSessionCache, ou pour des modules autres que +mod_ssl. Si vous activez un cache de session SSL +utilisant un mécanisme autre que mod_socache_shmcb, +utilisez aussi ce mécanisme alternatif pour la directive +SSLStaplingCache. Par exemple :

    + + 
    SSLSessionCache "dbm:ssl_scache"
+SSLStaplingCache "dbm:ssl_stapling"
    + + +

    Vous pouvez utiliser la commande openssl pour vérifier que votre +serveur envoie bien une réponse OCSP :

    + +
    $ openssl s_client -connect www.example.com:443 -status -servername www.example.com
+...
+OCSP response: 
+======================================
+OCSP Response Data:
+    OCSP Response Status: successful (0x0)
+    Response Type: Basic OCSP Response
+...
+    Cert Status: Good
+...
    + +

    Les sections suivantes explicitent les situations courantes qui +requièrent des modifications supplémentaires de la configuration. Vous +pouvez aussi vous référer au manuel de référence de +mod_ssl.

    + +

    Si l'on utilise plus que quelques certificats SSL pour le serveur

    + +

    Les réponses OCSP sont stockées dans le cache d'agrafage SSL. Alors +que les réponses ont une taille de quelques centaines à quelques +milliers d'octets, mod_ssl supporte des réponses d'une taille jusqu'à +environ 10 ko. Dans notre cas, le nombre de certificats est conséquent +et la taille du cache (32768 octets dans l'exemple ci-dessus) doit être +augmentée. En cas d'erreur lors du stockage d'une réponse, le +message AH01929 sera enregistré dans le journal.

    + + +

    Si le certificat ne spécifie pas de répondeur OCSP, ou si une +adresse différente doit être utilisée

    + +

    Veuillez vous référer à la documentation de la directive SSLStaplingForceURL.

    + +

    Vous pouvez vérifier si un certificat spécifie un répondeur OCSP en +utilisant la commande openssl comme suit :

    + +
    $ openssl x509 -in ./www.example.com.crt -text | grep 'OCSP.*http'
+OCSP - URI:http://ocsp.example.com
    + +

    Si un URI OCSP est fourni et si le serveur web peut communiquer +directement avec lui sans passer par un mandataire, aucune modification +supplémentaire de la configuration n'est requise. Notez que les règles +du pare-feu qui contrôlent les connexions sortantes en provenance du +serveur web devront peut-être subir quelques ajustements.

    + +

    Si aucun URI OCSP n'est fourni, contactez votre autorité de +certification pour savoir s'il en existe une ; si c'est le +cas, utilisez la directive SSLStaplingForceURL pour la spécifier dans +la configuration du serveur virtuel qui utilise le certificat.

    + + +

    Si plusieurs serveurs virtuels sont configurés pour utiliser SSL +et si l'agrafage OCSP doit être désactivé pour certains d'entre eux

    + + +

    Ajoutez la directive SSLUseStapling Off à la +configuration des serveurs virtuels pour lesquels l'agrafage OCSP doit +être désactivé.

    + + +

    Si le répondeur OCSP est lent ou instable

    + +

    De nombreuses directives permettent de gérer les temps de réponse et +les erreurs. Référez-vous à la documentation de SSLStaplingFakeTryLater, SSLStaplingResponderTimeout, et SSLStaplingReturnResponderErrors.

    + + +

    Si mod_ssl enregistre l'erreur AH02217 dans le journal

    + +
    AH02217: ssl_stapling_init_cert: Can't retrieve issuer certificate!
    +

    Afin de pouvoir supporter l'agrafage OCSP lorsqu'un certificat de +serveur particulier est utilisé, une chaîne de certification pour ce +certificat doit être spécifiée. Si cela n'a pas été fait lors de +l'activation de SSL, l'erreur AH02217 sera enregistrée lorsque +l'agrafage OCSP sera activé, et les clients qui utilisent le certificat +considéré ne recevront pas de réponse OCSP.

    + +

    Veuillez vous référer à la documentation des directives SSLCertificateChainFile et SSLCertificateFile pour spécifier une +chaîne de certification.

    + + +
    top
    +
    +

    Authentification du client et contrôle d'accès

    + + + +

    Comment forcer les clients +à s'authentifier à l'aide de certificats ? +

    + + +

    Lorsque vous connaissez tous vos clients (comme c'est en général le cas + au sein d'un intranet d'entreprise), vous pouvez imposer une + authentification basée uniquement sur les certificats. Tout ce dont vous + avez besoin pour y parvenir est de créer des certificats clients signés par + le certificat de votre propre autorité de certification + (ca.crt), et d'authentifier les clients à l'aide de ces + certificats.

    + 
    # exige un certificat client signé par le certificat de votre CA
+# contenu dans ca.crt
+SSLVerifyClient require
+SSLVerifyDepth 1
+SSLCACertificateFile "conf/ssl.crt/ca.crt"
    + + + +

    Comment forcer les clients +à s'authentifier à l'aide de certificats pour une URL particulière, +mais autoriser quand-même tout client anonyme +à accéder au reste du serveur ?

    + + +

    Pour forcer les clients à s'authentifier à l'aide de certificats pour une +URL particulière, vous pouvez utiliser les fonctionnalités de reconfiguration +de mod_ssl en fonction du répertoire :

    + + 
    SSLVerifyClient none
+SSLCACertificateFile "conf/ssl.crt/ca.crt"
+
+<Location "/secure/area">
+SSLVerifyClient require
+SSLVerifyDepth 1
+</Location>
    + + + +

    Comment n'autoriser l'accès à une URL +particulière qu'aux clients qui possèdent des certificats, mais autoriser +l'accès au reste du serveur à tous les clients ?

    + + +

    La clé du problème consiste à vérifier si une partie du certificat + client correspond à ce que vous attendez. Cela signifie en général + consulter tout ou partie du nom distinctif (DN), afin de vérifier s'il + contient une chaîne connue. Il existe deux méthodes pour y parvenir ; + on utilise soit le module mod_auth_basic, soit la + directive SSLRequire.

    + +

    La méthode du module mod_auth_basic est en général + incontournable lorsque les certificats ont un contenu arbitraire, ou + lorsque leur DN ne contient aucun champ connu + (comme l'organisation, etc...). Dans ce cas, vous devez construire une base + de données de mots de passe contenant tous les clients + autorisés, comme suit :

    + + 
    SSLVerifyClient      none
+SSLCACertificateFile "conf/ssl.crt/ca.crt"
+SSLCACertificatePath "conf/ssl.crt"
+
+<Directory "/usr/local/apache2/htdocs/secure/area">
+SSLVerifyClient      require
+    SSLVerifyDepth       5
+    SSLOptions           +FakeBasicAuth
+    SSLRequireSSL
+    AuthName             "Snake Oil Authentication"
+    AuthType             Basic
+    AuthBasicProvider    file
+    AuthUserFile         "/usr/local/apache2/conf/httpd.passwd"
+    Require              valid-user
+</Directory>
    + + + +

    Le mot de passe utilisé dans cet exemple correspond à la chaîne de + caractères "password" chiffrée en DES. Voir la documentation de la + directive SSLOptions pour + plus de détails.

    + +

    httpd.passwd

    /C=DE/L=Munich/O=Snake Oil, Ltd./OU=Staff/CN=Foo:xxj31ZMTZzkVA
+/C=US/L=S.F./O=Snake Oil, Ltd./OU=CA/CN=Bar:xxj31ZMTZzkVA
+/C=US/L=L.A./O=Snake Oil, Ltd./OU=Dev/CN=Quux:xxj31ZMTZzkVA
    + +

    Lorsque vos clients font tous partie d'une même hiérarchie, ce qui + apparaît dans le DN, vous pouvez les authentifier plus facilement en + utilisant la directive SSLRequire, comme suit :

    + + + 
    SSLVerifyClient      none
+SSLCACertificateFile "conf/ssl.crt/ca.crt"
+SSLCACertificatePath "conf/ssl.crt"
+
+<Directory "/usr/local/apache2/htdocs/secure/area">
+  SSLVerifyClient      require
+  SSLVerifyDepth       5
+  SSLOptions           +FakeBasicAuth
+  SSLRequireSSL
+  SSLRequire       %{SSL_CLIENT_S_DN_O}  eq "Snake Oil, Ltd." \
+               and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"}
+</Directory>
    + + + +

    Comment imposer HTTPS avec chiffrements forts, +et soit authentification de base, soit possession de certificats clients, +pour l'accès à une partie de l'Intranet, pour les clients en +provenance de l'Internet ? Je souhaite quand-même autoriser l'accès en HTTP +aux clients de l'intranet.

    + + +

    On suppose dans ces exemples que les clients de l'intranet ont des + adresses IP dans la gamme 192.168.1.0/24, et que la partie de l'intranet + à laquelle vous voulez autoriser l'accès depuis l'Internet est + /usr/local/apache2/htdocs/subarea. Ces lignes de configuration + doivent se trouver en dehors de votre hôte virtuel HTTPS, afin qu'elles + s'appliquent à la fois à HTTP et HTTPS.

    + + 
    SSLCACertificateFile "conf/ssl.crt/company-ca.crt"
+
+<Directory "/usr/local/apache2/htdocs">
+#   En dehors de subarea, seul l'accès depuis l'intranet est
+#   autorisé
+    Require              ip 192.168.1.0/24
+</Directory>
+
+<Directory "/usr/local/apache2/htdocs/subarea">
+#   Dans subarea, tout accès depuis l'intranet est autorisé
+#   mais depuis l'Internet, seul l'accès par HTTPS + chiffrement fort + Mot de passe
+#   ou HTTPS + chiffrement fort + certificat client n'est autorisé.
+
+#   Si HTTPS est utilisé, on s'assure que le niveau de chiffrement est fort.
+#   Autorise en plus les certificats clients comme une alternative à
+#   l'authentification basique.
+    SSLVerifyClient      optional
+    SSLVerifyDepth       1
+    SSLOptions           +FakeBasicAuth +StrictRequire
+    SSLRequire           %{SSL_CIPHER_USEKEYSIZE} >= 128
+    
+    #   ON oblige les clients venant d'Internet à utiliser HTTPS
+    RewriteEngine        on
+    RewriteCond          "%{REMOTE_ADDR}" "!^192\.168\.1\.[0-9]+$"
+    RewriteCond          "%{HTTPS}" "!=on"
+    RewriteRule          "." "-" [F]
+    
+    #   On permet l'accès soit sur les critères réseaux, soit par authentification Basique
+    Satisfy              any
+    
+    #   Contrôle d'accès réseau
+    Require              ip 192.168.1.0/24
+    
+    #   Configuration de l'authentification HTTP Basique
+    AuthType             basic
+    AuthName             "Protected Intranet Area"
+    AuthBasicProvider    file
+    AuthUserFile         "conf/protected.passwd"
+    Require              valid-user
+</Directory>
    + + +
    top
    +
    +

    Journalisation

    + + +

    mod_ssl peut enregistrer des informations de + débogage très verbeuses dans le journal des erreurs, lorsque sa + directive LogLevel est définie + à des niveaux de trace élevés. Par contre, sur un serveur très + sollicité, le niveau info sera probablement déjà trop + élevé. Souvenez-vous que vous pouvez configurer la directive + LogLevel par module afin de + pourvoir à vos besoins.

    +
    +
    +

    Langues Disponibles:  en  | + fr 

    +
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    +
    + \ No newline at end of file diff --git a/docs/manual/ssl/ssl_intro.html.en b/docs/manual/ssl/ssl_intro.html.en index cfbf62c68f..732034c9e8 100644 --- a/docs/manual/ssl/ssl_intro.html.en +++ b/docs/manual/ssl/ssl_intro.html.en @@ -24,7 +24,7 @@ Apache > HTTP Server > Documentation > Version 2.5 > SSL/TLS

    SSL/TLS Strong Encryption: An Introduction

    Available Languages:  en  | - fr  | + fr  |  ja 

    @@ -643,7 +643,7 @@ Version 3.0, 1996. See

    Available Languages:  en  | - fr  | + fr  |  ja 

    top

    Comments

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    - - -
    -

    Modules | Directives | FAQ | Glossaire | Plan du site

    -

    Serveur HTTP Apache Version 2.5

    -
    -
    <-
    -

    Chiffrement SSL/TLS fort : Introduction

    -
    -

    Langues Disponibles:  en  | - fr  | - ja 

    -
    - - -

    Ce chapitre en guise d'introduction est destiné aux lecteurs pour lesquels -le Web, HTTP et Apache sont familiers, mais ne sont pas des experts en matière -de sécurité. Il n'a pas la prétention d'être un guide détaillé sur le -protocole SSL, il ne traitera pas non plus des techniques spécifiques de gestion -des certificats dans une organisation, ni des importants problèmes légaux de -brevets ou des restrictions d'importation ou d'exportation. Il se veut plutôt -une base de travail pour les utilisateurs de mod_ssl en -rassemblant différents concepts, définitions et exemples comme point de départ -pour une exploration plus détaillée.

    - -
    - -
    top
    -
    -

    Techniques de chiffrement

    - -

    La maîtrise de SSL nécessite la compréhension des algorithmes de -chiffrement, des fonctions relatives aux empreintes de messages (comme les -fonctions de type hash ou non réversibles), et des signatures numériques. Ces -techniques pourraient faire l'objet d'un ouvrage à elles seules (voir par -exemple [AC96]) et constituent les bases de la -confidentialité, de l'intégrité et de l'authentification.

    - -

    Algorithmes de chiffrement

    - -

    Supposons qu'Alice veuille envoyer un message à sa banque pour - transférer une certaine somme. Alice souhaiterait que le message soit - privé, car il contient des informations comme son numéro de compte et le - montant du transfert. Une solution consisterait à utiliser un algorithme de - chiffrement, technique qui permet de remplacer un message par sa version - chiffrée, illisible jusqu'à ce qu'elle soit déchiffrée. - Sous sa forme chiffrée, - le message ne peut être déchiffré qu'en utilisant une clé secrète. Sans la - clé, le message est inutilisable : les bons algorithmes de chiffrement - rendent si difficile la restitution du texte original par des intrus que - ceux-ci y gaspilleraient leurs efforts.

    - -

    Il existe deux catégories d'algorithmes de chiffrement : conventionnel - ou à clé publique.

    - -
    -
    Chiffrement conventionnel
    -
    aussi connu sous le nom de chiffrement symétrique, il nécessite le - partage d'une clé entre l'expéditeur et le destinataire : une portion - d'information secrète permettant de chiffrer et déchiffrer un message. - Tant que cette clé reste secrète, personne à part l'expéditeur et le - destinataire ne peut lire le message. Si Alice et sa banque partagent une - clé secrète, ils peuvent donc s'envoyer l'un à l'autre des messages privés. - Le fait de partager une clé entre l'expéditeur et le destinataire avant - de communiquer, tout en la maintenant secrète vis à vis des autres, peut - toutefois poser des problèmes.
    - -
    Chiffrement à clé publique
    -
    aussi connu sous le nom de chiffrement asymétrique, il résoud le - problème d'échange de clé en définissant un algorithme qui utilise deux - clés, chacune d'entre elles pouvant être utilisée pour chiffrer un message. - Si une des clés a été utilisée pour chiffrer le message, on doit utiliser - l'autre clé pour le déchiffrer. Il est ainsi possible de recevoir des - messages sécurisés simplement en rendant publique une des clés (la clé - publique), et en gardant l'autre clé secrète (la clé privée).
    -
    - -

    Tout le monde peut chiffrer un message en utilisant la clé publique, - mais seul le propriétaire de la clé privée sera en mesure de le lire. De - cette façon, Alice peut envoyer des messages privés au propriétaire d'une - paire de clés (sa banque), en les chiffrant à l'aide de la clé publique. - Seule la banque sera en mesure de les déchiffrer.

    - - -

    Empreinte d'un message

    - -

    Bien qu'Alice puisse chiffrer son message pour le rendre privé, il - subsiste toujours le risque que quelqu'un puisse modifier le message - original ou le remplacer par un autre, afin d'effectuer le transfert de - fonds à son profit, par exemple. Une solution pour garantir l'intégrité du - message consisterait pour Alice à créer un résumé concentré de son message - qu'elle enverrait à sa banque avec ce dernier. A la réception du message, - la banque crée son propre résumé et le compare avec celui qu'Alice a - envoyé. Si les deux résumés sont identiques, le message reçu n'a pas - été modifié.

    - -

    Un résumé tel que celui-ci est appelé - empreinte numérique de message (message digest), - fonction irréversible (one-way function) ou - fonction de hashage (hash function). Une empreinte de message - constitue une représentation courte et de longueur fixe, d'un message plus - long et de longueur variable. Les algorithmes de création d'empreintes sont - conçus pour produire une empreinte unique pour chaque message. Les - empreintes de messages sont conçues pour que la restitution du message - à partir de l'empreinte soit d'une difficulté insurmontable, et qu'il soit - (en théorie) impossible de trouver deux messages différents qui produisent - la même empreinte -- ce qui élimine la possibilité de remplacer un message - par un autre en conservant la même empreinte.

    - -

    Trouver le moyen d'envoyer l'empreinte de manière sécurisée à la banque - constitue un autre défit auquel Alice doit faire face ; si l'empreinte - n'est pas envoyée de manière sécurisée, son intégrité peut être compromise, - et avec elle, la possibilité pour la banque de vérifier l'intégrité du - message original. L'intégrité du message ne peut être vérifiée que si - l'empreinte qui lui est associée est envoyée de manière sécurisée.

    - -

    Une solution pour envoyer l'empreinte de manière sécurisée consiste à - l'inclure dans une signature numérique.

    - - -

    Signatures numériques

    -

    Quand Alice envoie un message à sa banque, cette dernière doit s'assurer -que le message a bien été envoyé par elle, pour éviter qu'un intrus puisse -effectuer une transaction sur son compte. Une signature numérique, -créée par Alice et incluse dans le message, permet d'atteindre cet -objectif.

    - -

    Les signatures numériques peuvent être créées en chiffrant une empreinte de -message, ainsi que d'autres informations (comme un numéro d'ordre) avec la clé -privée de l'expéditeur. Bien que tout le monde puisse déchiffrer la -signature à l'aide de la clé publique, seul l'expéditeur connait la clé privée. -Ce qui implique que seul l'expéditeur peut avoir signé le message. Inclure -l'empreinte dans la signature entraîne que cette dernière n'est valable que -pour ce message ; ceci assure aussi l'intégrité du message car personne ne -peut modifier l'empreinte et ensuite signer le message.

    -

    Afin de se prémunir contre l'interception et la réutilisation de la -signature par un intrus quelques jours plus tard, la signature contient un -numéro d'ordre unique. Ceci protège la banque contre une plainte frauduleuse -de la part d'Alice alléguant qu'elle n'a pas envoyé le message -- -elle seule peut l'avoir signé (non-répudiation).

    - - -
    top
    -
    -

    Certificats

    - -

    Bien qu'Alice soit parvenue à envoyer un message privé à sa banque, après -l'avoir signé et avoir ainsi assuré l'intégrité du message, elle doit encore vérifier -qu'elle communique réellement avec la banque. C'est à dire qu'elle doit -s'assurer que la clé publique qu'elle utilise appartient bien à la paire de -clés de la banque, et non à celle d'un intrus. -De même, la banque doit vérifier que la -signature du message a bien été construite avec la clé privée d'Alice.

    - -

    Si chaque partie possède un certificat qui valide l'identité de l'autre, -confirme la clé publique, et est signé par un organisme de confiance, alors -les deux protagonistes peuvent être sûrs que la personne avec laquelle ils -communiquent est bien celle avec laquelle ils désirent le faire. Un tel -organisme de confiance s'appelle une Autorité de Certification, et -on utilise les certificats à des fins d'authentification.

    - -

    Contenu d'un certificat

    - -

    Un certificat associe une clé publique avec l'identité réelle d'un - individu, d'un serveur, ou d'une autre entité plus connue sous le nom de - sujet. Comme on le voit dans le Tableau 1, les - information concernant le sujet comprennent des informations - d'identification (le nom distinctif ou distinguished name - dn), ainsi que - la clé publique. Il comporte aussi l'identification et la signature de - l'autorité de certification qui a délivré le certificat, ainsi que la - période de validité de ce dernier. Il peut aussi contenir des informations - supplémentaires (ou extensions) telles que des informations de gestion - destinées à l'autorité de certification, comme un numéro de série.

    - -

    Tableau 1: Information contenues dans un certificat

    - - - - - - - - - - - - - -
    SujetNom distinctif, Clé publique
    FournisseurNom distinctif, Signature
    Période de validitéPas avant, Pas après
    Informations de gestionVersion, Numéro de série
    ExtensionsContraintes de base, Drapeaux Netscape, etc.
    - - -

    Un nom distinctif sert à fournir une identité dans un contexte - spécifique -- par exemple, un individu peut posséder un certificat - personnel, et aussi un certificat en tant qu'employé. Les noms distinctifs - doivent respecter le standard X509 [X509], qui définit - les champs, les noms de champs, et les abréviations utilisées pour faire - référence aux champs (voir Tableau 2).

    - -

    Tableau 2: Informations contenues dans le nom distinctif

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    Champ du DNAbrév.DescriptionExemple
    Nom complet (Common Name)CNNom certifiéCN=Joe Average
    Organisation or EntrepriseONom est associé à cette
    organisation    		O=Snake Oil, Ltd.
    Unité organisationnelle (Organizational Unit)OUNom est associé avec cette
    unité organisationnelle, - par exemple un département    		OU=Research Institute
    Ville/LocalisationLNom est localisé dans cette villeL=Snake City
    Etat/ProvinceSTNom est localisé dans cet état/provinceST=Desert
    PaysCNom est localisé dans ce pays (code ISO)C=XZ
    - - -

    Une autorité de certification peut définir une contrainte spécifiant - quels champs du nom distinctif sont optionnels et lesquels sont - obligatoires. Elle peut aussi imposer des contraintes sur le contenu des - champs, ce que peuvent aussi faire les utilisateurs de certificats. Par - exemple, un navigateur Netscape peut exiger, dans le cas d'un certificat - de serveur, que le nom complet (Common Name) corresponde à un nom générique - contenant le nom de domaine du serveur, comme - *.snakeoil.com.

    - -

    Le format binaire d'un certificat est défini en utilisant la - notation ASN.1 [ASN1] [PKCS]. - Cette notation definit la manière de spécifier les contenus, et les règles - d'encodage définissent la manière dont ces information sont converties au - format binaire. L'encodage binaire du certificat est défini par les Règles - d'Encodage Distinctives (Distinguished Encoding Rules - DER), qui se basent - d'une manière plus générale sur les Règles d'Encodage de Base (Basic - Encoding Rules - BER). Pour les transmissions qui ne supportent pas le - format binaire, ce dernier peut être converti au format ASCII en utilisant - le codage Base64 [MIME]. Lorsqu'il est placé entre des - délimiteurs de début et de fin (comme ci-dessous), on dit que le certificat - est encodé au format PEM ("Privacy Enhanced Mail").

    - -

    Exemple de certificat encodé au format PEM (snakeoil.crt)

    -----BEGIN CERTIFICATE-----
-MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx
-FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG
-A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv
-cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz
-bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL
-MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h
-a2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl
-cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN
-AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
-gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b
-vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa
-lWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV
-HRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB
-gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt
-2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7
-dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ==
------END CERTIFICATE-----
    - - -

    Autorités de certification

    - -

    En vérifiant les informations contenues dans une demande de certificat - avant de l'accorder, l'autorité de certification s'assure de l'identité du - propriétaire de la clé privée issue de sa paire de clés. Par exemple, Si - Alice demande un certificat personnel, l'autorité de certification doit - d'abord s'assurer qu'elle correspond vraiment à la personne à laquelle - la demande de certificat fait référence.

    - -

    Chaînes de certification

    - -

    Une autorité de certification peut aussi émettre un certificat à - destination d'une - autre autorité de certification. Pour vérifier un certificat, Alice - peut être amenée à vérifier le certificat de l'émetteur pour chaque - autorité de certification parente, jusqu'à ce qu'elle en atteigne une - en qui elle a confiance. Elle peut aussi ne faire confiance qu'aux - certificats faisant l'objet d'une chaîne limitée d'émetteurs, afin - de réduire le risque de rencontrer un "mauvais" certificat dans la - chaîne.

    - - -

    Création d'une autorité de certification racine

    - -

    Comme indiqué plus haut, chaque certificat nécessite la validation - de l'identité du sujet par un émetteur de certificats - de niveau supérieur, et ceci en - remontant jusqu'à l'Autorité de Certification (CA) racine. Ceci pose un - problème : qui va se porter garant du certificat de l'autorité racine - qui ne possède pas d'émetteur de certificat ? C'est uniquement dans ce - cas que le certificat est auto-signé, l'émetteur du certificat et son - sujet étant confondus. Les navigateurs sont préconfigurés avec une - liste d'autorités de certification de confiance, mais il est important - d'être extrèmement prudent avant de faire confiance à un certificat - auto-signé. La large publication d'une clé publique par l'autorité - racine réduit cependant les risques encourus - en faisant confiance à cette clé -- - si quelqu'un publiait une clé en se faisant passer pour l'autorité, il - serait vite démasqué.

    - -

    Quelques compagnies, comme Thawte et VeriSign, - se sont proclamées elles-mêmes Autorités de Certification. Ces - compagnies proposent les services suivant :

    - -
      -
    • Vérification des demandes de certificats
      • -
    • Traitement des demandes de certificats
      • -
    • Emission et gestion des certificats
      • -
    - -

    Vous pouvez aussi créer votre propre autorité de certification. Bien - que risqué dans l'environnement de l'Internet, ceci peut s'avérer utile - dans un Intranet, où l'organisme peut vérifier facilement les identités - des individus et des serveurs.

    - - -

    Gestion des certificats

    - -

    Constituer une autorité de certification représente une - responsabilité qui nécessite une solide infrastructure administrative, - technique et gestionnaire. Les autorités de certification ne se - contentent pas d'émettre des certificats, elles doivent aussi les gérer - -- à savoir elles déterminent leur durée de validité, elles les - renouvellent, et elles maintiennent des listes de certificats qui ont - été émis dans le passé mais ne sont plus valides (Listes de révocations - de certificats, ou CRLs).

    - -

    Par exemple, si Alice est titulaire d'un certificat en tant - qu'employée d'une compagnie, mais vient de quitter cette compagnie, - son certificat doit être révoqué. Comme les certificats ne sont émis - qu'après vérification de l'identité du sujet, et peuvent être envoyés - à tous ceux avec lesquels le sujet peut communiquer, il est impossible - de discerner à partir du seul certificat s'il a été révoqué. Pour - vérifier la validité d'un certificat, il est donc nécessaire de - contacter l'autorité de certification qui l'a émis afin de pouvoir - consulter ses listes de révocations de certificats -- ce qui n'est - en général pas une partie automatique du processus.

    - -

    Note

    -

    Si votre autorité de certification ne fait pas partie de la liste - des autorités de confiance de votre navigateur, il faut enregistrer le - certificat de l'autorité de certification dans ce dernier, ce qui lui - permettra de valider les certificats de serveurs signés par cette - autorité de certification. Ceci peut être dangereux, car une fois le - certificat enregistré, le navigateur acceptera tous les certificats - signés par cette autorité de certification.

    -
    - - - -
    top
    -
    -

    Couche Points d'Accès Sécurisés - Secure Sockets Layer (SSL)

    - -

    Le protocole Couche Points d'Accès Sécurisés est une couche protocolaire -qui pourrait s'intercaler entre un protocole d'une couche réseau orientée -connexion (comme TCP/IP) et une couche protocolaire d'application (comme HTTP). -SSL fournit une communication sécurisée entre client et serveur en permettant -l'authentification mutuelle, l'utilisation des signatures numériques pour la -vérification de l'intégrité des données, et le chiffrement pour la -confidentialité.

    - -

    Ce protocole est conçu pour supporter un grand choix d'algorithmes -spécifiques utilisés pour la cryptographie, les empreintes et les signatures. -Ceci permet la sélection d'un algorithme pour des serveurs spécifiques en -respectant la légalité, les règles d'exportation ou autres contraintes, et -permet aussi au protocole de tirer parti des nouveaux algorithmes. Ces choix -font l'objet d'une négociation entre client et serveur lors de -l'établissement de la session protocolaire.

    - -

    Tableau 4: Versions du protocole SSL

    - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    VersionSourceDescription
    SSL v2.0Standard du fournisseur (de Netscape Corp.)Premier protocole SSL pour lequel il existe des implémentations
    SSL v3.0Projet Internet arrivé à expiration (de Netscape Corp.) [SSL3]Comporte des révisions permettant de prévenir certaines attaques de - sécurité spécifiques, ajout de chiffrements non RSA, et support des - chaînes de certification
    TLS v1.0Standard proposé pour l'Internet (de l'IETF) [TLS1]Révision de SSL 3.0 pour mettre à jour la couche MAC vers HMAC, - ajout du bourrage de bloc pour le chiffrement de bloc, standardisation - de l'ordonnancement des messages et plus de messages d'alerte.
    TLS v1.1Standard proposé pour l'Internet (de l'IETF) [TLS11]Mise à jour de TLS 1.0 pour la protection contre les - attaques de type Cipher block chaining (CBC).
    TLS v1.2Standard proposé pour l'Internet (de l'IETF) [TLS12]Mise à jour de TLS 1.1 rendant les condensés MD5 obsolètes, - et introduisant une incompatibilité avec SSL ce qui interdit toute - négociation en vue d'une utilisation de SSLv2.
    - - -

    Il existe plusieurs versions du protocole SSL, comme le montre le -Tableau 4. Comme indiqué dans ce dernier, un des apports -de SSL 3.0 est le support du chargement des chaînes de certification. Cette -fonctionnalité permet à un serveur de passer au navigateur un certificat de -serveur accompagné du certificat de l'émetteur. Le chargement de la -chaîne permet aussi au navigateur de valider le certificat du serveur, même si -les certificats de l'autorité de certification ne sont pas installés pour les -émetteurs intermédiaires, car ils sont inclus dans la chaîne de certification. -SSL 3.0 sert de base au standard du protocole Sécurité de la Couche Transport -ou Transport Layer Security -[TLS], actuellement en développement au sein de -l'Internet Engineering Task Force (IETF).

    - -

    Etablissement d'une session

    - -

    La session SSL est établie en suivant une séquence d'échanges - d'informations entre client et serveur, comme le montre la - Figure 1. Cette séquence peut varier, selon que - le serveur est configuré pour fournir un certificat de serveur ou - réclame un certificat client. Bien que dans certains cas, des étapes - d'échanges d'informations supplémentaires soient nécessaires pour la - gestion des informations de chiffrement, cet article résume un scénario - courant. Se reporter aux spécifications SSL pour avoir la liste de - toutes les possibilités.

    - -

    Note

    -

    Une fois la session SSL établie, elle peut être réutilisée. Ceci - permet d'éviter la perte de performances due à la répétition des nombreuses - étapes nécessaires à l'établissement d'une session. Pour parvenir à ceci, - le serveur assigne un identifiant de session unique à chaque session SSL ; - cet identifiant est mis en cache dans le serveur et le client peut - l'utiliser pour des connexions ultérieures afin de réduire la durée des - échanges d'informations (et ceci jusqu'à ce que l'identifiant de session - arrive à expiration dans le cache du serveur).

    -
    - -

    -
    - Figure 1 : Séquence - simplifiée d'échanges d'informations SSL

    - -

    Les éléments de la séquence d'échanges d'informations, tels qu'ils - sont utilisés par le client et le serveur, sont énumérés ci-après :

    - -
      -
    1. Négociation de la suite de chiffrement à utiliser durant le transfert des données
      2. -
    2. Elaboration et échange d'une clé de session entre le client et le serveur
      3. -
    3. Authentification éventuelle du serveur par le client
      4. -
    4. Authentification éventuelle du client par le serveur
      5. -
    - -

    La première étape, la négociation de la suite de chiffrement, permet au - client et au serveur de choisir une suite de chiffrement qu'ils supportent - tous les deux. La spécification du protocole SSL 3.0 définit 31 suites de - chiffrement. Une suite de chiffrement se compose des éléments - suivants :

    - -
      -
    • Méthode d'échange de la clé
      • -
    • Chiffrement du transfert des données
      • -
    • Empreinte du message servant à créer le code d'authentification du - message (MAC)
      • -
    - -

    Ces trois éléments sont décrits dans les sections suivantes.

    - - -

    Méthode d'échange de la clé

    - -

    La méthode d'échange de la clé définit la manière - dont la clé de chiffrement - symétrique secrète et partagée utilisée pour le transfert des données de - l'application sera acceptée par le client et le serveur. SSL 2.0 utilise - l'échange de clé RSA seulement, tandis que SSL 3.0 supporte tout un choix - d'algorithmes d'échange de clé incluant l'échange de clé RSA (quand les - certificats sont utilisés), et l'échange de clés Diffie-Hellman (pour - échanger des clés sans certificat, ou en l'absence de communication - préalable entre le client et le serveur).

    - -

    Les signatures numériques constituent une variante dans le choix des - méthodes d'échange de clé -- utiliser les signatures ou pas, et dans - l'affirmative, quel genre de signatures utiliser. La signature à l'aide - d'une clé privée fournit une protection contre une attaque - "man-in-the-middle" au cours de laquelle - l'échange d'informations destiné à générer la - clé partagée peut être intercepté [AC96, p516].

    - - -

    Chiffrement du transfert de données

    - -

    Comme décrit plus haut, SSL utilise le chiffrement symétrique - conventionnel pour chiffrer les messages au cours d'une session. Il existe - neuf choix possibles pour le chiffrement, y compris l'option du transfert - non chiffré :

    - -
      -
    • Pas de chiffrement
      • -
    • Chiffrement en continu (Stream Ciphers) -
        -
      • RC4 avec clés de 40 bits
        • -
      • RC4 avec clés de 128 bits
        • -
      • -
    • Chiffrement par blocs CBC (CBC Block Ciphers) -
      • RC2 avec clé de 40 bits
        • -
      • DES avec clé de 40 bits
        • -
      • DES avec clé de 56 bits
        • -
      • Triple-DES avec clé de 168 bits
        • -
      • Idea (clé de 128 bits)
        • -
      • Fortezza (clé de 96 bits)
        • -
      • -
    - -

    "CBC" signifie Cipher Block Chaining (Chaînage de blocs chiffrés), - c'est à dire qu'une portion du bloc de texte chiffré précédent est utilisée - pour le chiffrement du bloc courant. "DES" signifie Data Encryption - Standard (Standard de Chiffrement des Données) - [AC96, ch12], et possède de nombreuses variantes - (telles que DES40 et 3DES_EDE). Parmi les algorithmes disponibles, "Idea" - est actuellement un des meilleurs et des plus puissants sur le plan - cryptographique, et "RC2" est un algorithme propriétaire de RSA DSI - [AC96, ch13].

    - - -

    Fonction de création d'empreinte

    - -

    Le choix d'une fonction de création d'empreinte détermine la manière - dont une empreinte est créée à partir d'une unité de données. SSL supporte - les fonctions suivantes :

    - -
      -
    • Pas d'empreinte (choix Null)
      • -
    • MD5, une empreinte de 128 bits
      • -
    • Algorithme d'Empreinte Sécurisée (Secure Hash Algorithm - SHA-1), une - empreinte de 160 bits
      • -
    - -

    On utilise l'empreinte de message pour créer un Code d'Authentification - de Message (Message Authentication Code - MAC) qui est chiffré avec le - message afin de vérifier son intégrité et de se protéger contre les - attaques de type "rejeu".

    - - -

    Protocole de la séquence d'échanges d'informations

    - -

    La séquence d'échanges d'informations utilise trois protocoles :

    - -
      -
    • Le Protocole d'échanges d'informations SSL pour établir - la session SSl entre le client et le serveur.
      • -
    • Le Protocole de spécification du chiffrement SSL pour - l'agrément effectif de la suite de chiffrement à utiliser - pour la session.
      • -
    • Le Protocole d'alertes SSL pour la transmission de - messages d'erreur SSL entre le client et le serveur.
      • -
    - -

    Ces protocoles, ainsi que les données du protocole de l'application, - sont encapsulés dans le Protocole d'enregistrement SSL - (SSL Record Protocol), comme - le montre la Figure 2. Un protocole encapsulé est - tranféré en tant que données par le protocole de la couche de niveau - inférieur, qui ne se préoccupe pas du contenu des données. Le protocole - encapsulé n'a aucune connaissance du protocole sous-jacent.

    - -

    -
    - Figure 2: - Pile du protocole SSL

    - -

    L'encapsulation des protocoles de contrôle SSL dans le protocole - d'enregistrement signifie que si une session active est renégociée, les - protocoles de contrôle seront transmis de manière sécurisée. S'il n'y - avait pas de session préalable, la suite de chiffrement Null est utilisée, - ce qui signifie que les messages ne seront pas chiffrés et ne possèderont - pas d'empreinte d'intégrité, jusqu'à ce que la session ait été établie.

    - - -

    Transmission des données

    - -

    Le protocole d'enregistrement SSL, comme le montre la - Figure 3, est utilisé pour transmettre les données - de l'application et les données de contrôle SSL entre le client et le - serveur, les données étant nécessairement fragmentées en éléments plus - petits, ou plusieurs messages de données avec protocole de niveau - supérieur pouvant être combinés en un seul élément. Ce protocole peut - joindre des signatures d'empreintes, compresser et chiffrer ces éléments - avant de les transmettre en utilisant le protocole fiable de transport - sous-jacent (Note : actuellement, aucune implémentation majeure de SSL - n'inclut le support de la compression).

    - -

    -
    - Figure 3: - Protocole d'enregistrement SSL

    - - -

    Sécurisation des communications HTTP

    - -

    Une des utilisations courantes de SSL est la sécurisation des - communication HTTP sur le Web entre un navigateur et un serveur web. Ceci - n'exclut pas l'utilisation de HTTP non sécurisé - la version sécurisée - (appelée HTTPS) est identique à du vrai HTTP sur SSL, - mais utilise le préfixe - d'URL https au lieu de http, et un port - de serveur différent (par défaut le port 443). - Ceci constitue pour une large part - ce qu'apporte mod_ssl au serveur web Apache.

    - -
    top
    -
    -

    Références

    - -
    -
    [AC96]
    -
    Bruce Schneier, Applied Cryptography, 2nd Edition, Wiley, -1996. Voir http://www.counterpane.com/ pour diverses autres productions de Bruce -Schneier.
    - -
    [ASN1]
    -
    ITU-T Recommendation X.208, Specification of Abstract Syntax Notation -One (ASN.1), dernière mise à jour en 2008. Voir http://www.itu.int/ITU-T/asn1/. -
    - -
    [X509]
    -
    ITU-T Recommendation X.509, The Directory - Authentication -Framework. A titre de référence, voir http://en.wikipedia.org/wiki/X.509. -
    - -
    [PKCS]
    -
    Public Key Cryptography Standards (PKCS), -RSA Laboratories Technical Notes, Voir http://www.rsasecurity.com/rsalabs/pkcs/.
    - -
    [MIME]
    -
    N. Freed, N. Borenstein, Multipurpose Internet Mail Extensions -(MIME) Part One: Format of Internet Message Bodies, RFC2045. -Voir par exemple http://tools.ietf.org/html/rfc2045.
    - -
    [SSL3]
    -
    Alan O. Freier, Philip Karlton, Paul C. Kocher, The SSL Protocol -Version 3.0, 1996. Voir http://www.netscape.com/eng/ssl3/draft302.txt.
    - -
    [TLS1]
    -
    Tim Dierks, Christopher Allen, The TLS Protocol Version 1.0, -1999. Voir http://ietf.org/rfc/rfc2246.txt.
    - -
    [TLS11]
    -
    Le protocole TLS Version 1.1, -2006. Voir http://tools.ietf.org/html/rfc4346.
    - -
    [TLS12]
    -
    Le protocole TLS Version 1.2, -2008. Voir http://tools.ietf.org/html/rfc5246.
    -
    -
    -
    -

    Langues Disponibles:  en  | - fr  | - ja 

    -
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    -
    - \ No newline at end of file diff --git a/docs/manual/ssl/ssl_intro.html.fr.utf8 b/docs/manual/ssl/ssl_intro.html.fr.utf8 new file mode 100644 index 0000000000..63a1fa9434 --- /dev/null +++ b/docs/manual/ssl/ssl_intro.html.fr.utf8 @@ -0,0 +1,727 @@ + + + + + +Chiffrement SSL/TLS fort : Introduction - Serveur HTTP Apache Version 2.5 + + + + + + +
    +

    Modules | Directives | FAQ | Glossaire | Plan du site

    +

    Serveur HTTP Apache Version 2.5

    +
    +
    <-
    +

    Chiffrement SSL/TLS fort : Introduction

    +
    +

    Langues Disponibles:  en  | + fr  | + ja 

    +
    + + +

    Ce chapitre en guise d'introduction est destiné aux lecteurs pour lesquels +le Web, HTTP et Apache sont familiers, mais ne sont pas des experts en matière +de sécurité. Il n'a pas la prétention d'être un guide détaillé sur le +protocole SSL, il ne traitera pas non plus des techniques spécifiques de gestion +des certificats dans une organisation, ni des importants problèmes légaux de +brevets ou des restrictions d'importation ou d'exportation. Il se veut plutôt +une base de travail pour les utilisateurs de mod_ssl en +rassemblant différents concepts, définitions et exemples comme point de départ +pour une exploration plus détaillée.

    + +
    + +
    top
    +
    +

    Techniques de chiffrement

    + +

    La maîtrise de SSL nécessite la compréhension des algorithmes de +chiffrement, des fonctions relatives aux empreintes de messages (comme les +fonctions de type hash ou non réversibles), et des signatures numériques. Ces +techniques pourraient faire l'objet d'un ouvrage à elles seules (voir par +exemple [AC96]) et constituent les bases de la +confidentialité, de l'intégrité et de l'authentification.

    + +

    Algorithmes de chiffrement

    + +

    Supposons qu'Alice veuille envoyer un message à sa banque pour + transférer une certaine somme. Alice souhaiterait que le message soit + privé, car il contient des informations comme son numéro de compte et le + montant du transfert. Une solution consisterait à utiliser un algorithme de + chiffrement, technique qui permet de remplacer un message par sa version + chiffrée, illisible jusqu'à ce qu'elle soit déchiffrée. + Sous sa forme chiffrée, + le message ne peut être déchiffré qu'en utilisant une clé secrète. Sans la + clé, le message est inutilisable : les bons algorithmes de chiffrement + rendent si difficile la restitution du texte original par des intrus que + ceux-ci y gaspilleraient leurs efforts.

    + +

    Il existe deux catégories d'algorithmes de chiffrement : conventionnel + ou à clé publique.

    + +
    +
    Chiffrement conventionnel
    +
    aussi connu sous le nom de chiffrement symétrique, il nécessite le + partage d'une clé entre l'expéditeur et le destinataire : une portion + d'information secrète permettant de chiffrer et déchiffrer un message. + Tant que cette clé reste secrète, personne à part l'expéditeur et le + destinataire ne peut lire le message. Si Alice et sa banque partagent une + clé secrète, ils peuvent donc s'envoyer l'un à l'autre des messages privés. + Le fait de partager une clé entre l'expéditeur et le destinataire avant + de communiquer, tout en la maintenant secrète vis à vis des autres, peut + toutefois poser des problèmes.
    + +
    Chiffrement à clé publique
    +
    aussi connu sous le nom de chiffrement asymétrique, il résoud le + problème d'échange de clé en définissant un algorithme qui utilise deux + clés, chacune d'entre elles pouvant être utilisée pour chiffrer un message. + Si une des clés a été utilisée pour chiffrer le message, on doit utiliser + l'autre clé pour le déchiffrer. Il est ainsi possible de recevoir des + messages sécurisés simplement en rendant publique une des clés (la clé + publique), et en gardant l'autre clé secrète (la clé privée).
    +
    + +

    Tout le monde peut chiffrer un message en utilisant la clé publique, + mais seul le propriétaire de la clé privée sera en mesure de le lire. De + cette façon, Alice peut envoyer des messages privés au propriétaire d'une + paire de clés (sa banque), en les chiffrant à l'aide de la clé publique. + Seule la banque sera en mesure de les déchiffrer.

    + + +

    Empreinte d'un message

    + +

    Bien qu'Alice puisse chiffrer son message pour le rendre privé, il + subsiste toujours le risque que quelqu'un puisse modifier le message + original ou le remplacer par un autre, afin d'effectuer le transfert de + fonds à son profit, par exemple. Une solution pour garantir l'intégrité du + message consisterait pour Alice à créer un résumé concentré de son message + qu'elle enverrait à sa banque avec ce dernier. A la réception du message, + la banque crée son propre résumé et le compare avec celui qu'Alice a + envoyé. Si les deux résumés sont identiques, le message reçu n'a pas + été modifié.

    + +

    Un résumé tel que celui-ci est appelé + empreinte numérique de message (message digest), + fonction irréversible (one-way function) ou + fonction de hashage (hash function). Une empreinte de message + constitue une représentation courte et de longueur fixe, d'un message plus + long et de longueur variable. Les algorithmes de création d'empreintes sont + conçus pour produire une empreinte unique pour chaque message. Les + empreintes de messages sont conçues pour que la restitution du message + à partir de l'empreinte soit d'une difficulté insurmontable, et qu'il soit + (en théorie) impossible de trouver deux messages différents qui produisent + la même empreinte -- ce qui élimine la possibilité de remplacer un message + par un autre en conservant la même empreinte.

    + +

    Trouver le moyen d'envoyer l'empreinte de manière sécurisée à la banque + constitue un autre défit auquel Alice doit faire face ; si l'empreinte + n'est pas envoyée de manière sécurisée, son intégrité peut être compromise, + et avec elle, la possibilité pour la banque de vérifier l'intégrité du + message original. L'intégrité du message ne peut être vérifiée que si + l'empreinte qui lui est associée est envoyée de manière sécurisée.

    + +

    Une solution pour envoyer l'empreinte de manière sécurisée consiste à + l'inclure dans une signature numérique.

    + + +

    Signatures numériques

    +

    Quand Alice envoie un message à sa banque, cette dernière doit s'assurer +que le message a bien été envoyé par elle, pour éviter qu'un intrus puisse +effectuer une transaction sur son compte. Une signature numérique, +créée par Alice et incluse dans le message, permet d'atteindre cet +objectif.

    + +

    Les signatures numériques peuvent être créées en chiffrant une empreinte de +message, ainsi que d'autres informations (comme un numéro d'ordre) avec la clé +privée de l'expéditeur. Bien que tout le monde puisse déchiffrer la +signature à l'aide de la clé publique, seul l'expéditeur connait la clé privée. +Ce qui implique que seul l'expéditeur peut avoir signé le message. Inclure +l'empreinte dans la signature entraîne que cette dernière n'est valable que +pour ce message ; ceci assure aussi l'intégrité du message car personne ne +peut modifier l'empreinte et ensuite signer le message.

    +

    Afin de se prémunir contre l'interception et la réutilisation de la +signature par un intrus quelques jours plus tard, la signature contient un +numéro d'ordre unique. Ceci protège la banque contre une plainte frauduleuse +de la part d'Alice alléguant qu'elle n'a pas envoyé le message -- +elle seule peut l'avoir signé (non-répudiation).

    + + +
    top
    +
    +

    Certificats

    + +

    Bien qu'Alice soit parvenue à envoyer un message privé à sa banque, après +l'avoir signé et avoir ainsi assuré l'intégrité du message, elle doit encore vérifier +qu'elle communique réellement avec la banque. C'est à dire qu'elle doit +s'assurer que la clé publique qu'elle utilise appartient bien à la paire de +clés de la banque, et non à celle d'un intrus. +De même, la banque doit vérifier que la +signature du message a bien été construite avec la clé privée d'Alice.

    + +

    Si chaque partie possède un certificat qui valide l'identité de l'autre, +confirme la clé publique, et est signé par un organisme de confiance, alors +les deux protagonistes peuvent être sûrs que la personne avec laquelle ils +communiquent est bien celle avec laquelle ils désirent le faire. Un tel +organisme de confiance s'appelle une Autorité de Certification, et +on utilise les certificats à des fins d'authentification.

    + +

    Contenu d'un certificat

    + +

    Un certificat associe une clé publique avec l'identité réelle d'un + individu, d'un serveur, ou d'une autre entité plus connue sous le nom de + sujet. Comme on le voit dans le Tableau 1, les + information concernant le sujet comprennent des informations + d'identification (le nom distinctif ou distinguished name - dn), ainsi que + la clé publique. Il comporte aussi l'identification et la signature de + l'autorité de certification qui a délivré le certificat, ainsi que la + période de validité de ce dernier. Il peut aussi contenir des informations + supplémentaires (ou extensions) telles que des informations de gestion + destinées à l'autorité de certification, comme un numéro de série.

    + +

    Tableau 1: Information contenues dans un certificat

    + + + + + + + + + + + + + +
    SujetNom distinctif, Clé publique
    FournisseurNom distinctif, Signature
    Période de validitéPas avant, Pas après
    Informations de gestionVersion, Numéro de série
    ExtensionsContraintes de base, Drapeaux Netscape, etc.
    + + +

    Un nom distinctif sert à fournir une identité dans un contexte + spécifique -- par exemple, un individu peut posséder un certificat + personnel, et aussi un certificat en tant qu'employé. Les noms distinctifs + doivent respecter le standard X509 [X509], qui définit + les champs, les noms de champs, et les abréviations utilisées pour faire + référence aux champs (voir Tableau 2).

    + +

    Tableau 2: Informations contenues dans le nom distinctif

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Champ du DNAbrév.DescriptionExemple
    Nom complet (Common Name)CNNom certifiéCN=Joe Average
    Organisation or EntrepriseONom est associé à cette
    organisation    		O=Snake Oil, Ltd.
    Unité organisationnelle (Organizational Unit)OUNom est associé avec cette
    unité organisationnelle, + par exemple un département    		OU=Research Institute
    Ville/LocalisationLNom est localisé dans cette villeL=Snake City
    Etat/ProvinceSTNom est localisé dans cet état/provinceST=Desert
    PaysCNom est localisé dans ce pays (code ISO)C=XZ
    + + +

    Une autorité de certification peut définir une contrainte spécifiant + quels champs du nom distinctif sont optionnels et lesquels sont + obligatoires. Elle peut aussi imposer des contraintes sur le contenu des + champs, ce que peuvent aussi faire les utilisateurs de certificats. Par + exemple, un navigateur Netscape peut exiger, dans le cas d'un certificat + de serveur, que le nom complet (Common Name) corresponde à un nom générique + contenant le nom de domaine du serveur, comme + *.snakeoil.com.

    + +

    Le format binaire d'un certificat est défini en utilisant la + notation ASN.1 [ASN1] [PKCS]. + Cette notation definit la manière de spécifier les contenus, et les règles + d'encodage définissent la manière dont ces information sont converties au + format binaire. L'encodage binaire du certificat est défini par les Règles + d'Encodage Distinctives (Distinguished Encoding Rules - DER), qui se basent + d'une manière plus générale sur les Règles d'Encodage de Base (Basic + Encoding Rules - BER). Pour les transmissions qui ne supportent pas le + format binaire, ce dernier peut être converti au format ASCII en utilisant + le codage Base64 [MIME]. Lorsqu'il est placé entre des + délimiteurs de début et de fin (comme ci-dessous), on dit que le certificat + est encodé au format PEM ("Privacy Enhanced Mail").

    + +

    Exemple de certificat encodé au format PEM (snakeoil.crt)

    -----BEGIN CERTIFICATE-----
+MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx
+FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG
+A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv
+cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz
+bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL
+MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h
+a2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl
+cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN
+AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
+gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b
+vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa
+lWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV
+HRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB
+gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt
+2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7
+dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ==
+-----END CERTIFICATE-----
    + + +

    Autorités de certification

    + +

    En vérifiant les informations contenues dans une demande de certificat + avant de l'accorder, l'autorité de certification s'assure de l'identité du + propriétaire de la clé privée issue de sa paire de clés. Par exemple, Si + Alice demande un certificat personnel, l'autorité de certification doit + d'abord s'assurer qu'elle correspond vraiment à la personne à laquelle + la demande de certificat fait référence.

    + +

    Chaînes de certification

    + +

    Une autorité de certification peut aussi émettre un certificat à + destination d'une + autre autorité de certification. Pour vérifier un certificat, Alice + peut être amenée à vérifier le certificat de l'émetteur pour chaque + autorité de certification parente, jusqu'à ce qu'elle en atteigne une + en qui elle a confiance. Elle peut aussi ne faire confiance qu'aux + certificats faisant l'objet d'une chaîne limitée d'émetteurs, afin + de réduire le risque de rencontrer un "mauvais" certificat dans la + chaîne.

    + + +

    Création d'une autorité de certification racine

    + +

    Comme indiqué plus haut, chaque certificat nécessite la validation + de l'identité du sujet par un émetteur de certificats + de niveau supérieur, et ceci en + remontant jusqu'à l'Autorité de Certification (CA) racine. Ceci pose un + problème : qui va se porter garant du certificat de l'autorité racine + qui ne possède pas d'émetteur de certificat ? C'est uniquement dans ce + cas que le certificat est auto-signé, l'émetteur du certificat et son + sujet étant confondus. Les navigateurs sont préconfigurés avec une + liste d'autorités de certification de confiance, mais il est important + d'être extrèmement prudent avant de faire confiance à un certificat + auto-signé. La large publication d'une clé publique par l'autorité + racine réduit cependant les risques encourus + en faisant confiance à cette clé -- + si quelqu'un publiait une clé en se faisant passer pour l'autorité, il + serait vite démasqué.

    + +

    Quelques compagnies, comme Thawte et VeriSign, + se sont proclamées elles-mêmes Autorités de Certification. Ces + compagnies proposent les services suivant :

    + +
      +
    • Vérification des demandes de certificats
      • +
    • Traitement des demandes de certificats
      • +
    • Emission et gestion des certificats
      • +
    + +

    Vous pouvez aussi créer votre propre autorité de certification. Bien + que risqué dans l'environnement de l'Internet, ceci peut s'avérer utile + dans un Intranet, où l'organisme peut vérifier facilement les identités + des individus et des serveurs.

    + + +

    Gestion des certificats

    + +

    Constituer une autorité de certification représente une + responsabilité qui nécessite une solide infrastructure administrative, + technique et gestionnaire. Les autorités de certification ne se + contentent pas d'émettre des certificats, elles doivent aussi les gérer + -- à savoir elles déterminent leur durée de validité, elles les + renouvellent, et elles maintiennent des listes de certificats qui ont + été émis dans le passé mais ne sont plus valides (Listes de révocations + de certificats, ou CRLs).

    + +

    Par exemple, si Alice est titulaire d'un certificat en tant + qu'employée d'une compagnie, mais vient de quitter cette compagnie, + son certificat doit être révoqué. Comme les certificats ne sont émis + qu'après vérification de l'identité du sujet, et peuvent être envoyés + à tous ceux avec lesquels le sujet peut communiquer, il est impossible + de discerner à partir du seul certificat s'il a été révoqué. Pour + vérifier la validité d'un certificat, il est donc nécessaire de + contacter l'autorité de certification qui l'a émis afin de pouvoir + consulter ses listes de révocations de certificats -- ce qui n'est + en général pas une partie automatique du processus.

    + +

    Note

    +

    Si votre autorité de certification ne fait pas partie de la liste + des autorités de confiance de votre navigateur, il faut enregistrer le + certificat de l'autorité de certification dans ce dernier, ce qui lui + permettra de valider les certificats de serveurs signés par cette + autorité de certification. Ceci peut être dangereux, car une fois le + certificat enregistré, le navigateur acceptera tous les certificats + signés par cette autorité de certification.

    +
    + + + +
    top
    +
    +

    Couche Points d'Accès Sécurisés - Secure Sockets Layer (SSL)

    + +

    Le protocole Couche Points d'Accès Sécurisés est une couche protocolaire +qui pourrait s'intercaler entre un protocole d'une couche réseau orientée +connexion (comme TCP/IP) et une couche protocolaire d'application (comme HTTP). +SSL fournit une communication sécurisée entre client et serveur en permettant +l'authentification mutuelle, l'utilisation des signatures numériques pour la +vérification de l'intégrité des données, et le chiffrement pour la +confidentialité.

    + +

    Ce protocole est conçu pour supporter un grand choix d'algorithmes +spécifiques utilisés pour la cryptographie, les empreintes et les signatures. +Ceci permet la sélection d'un algorithme pour des serveurs spécifiques en +respectant la légalité, les règles d'exportation ou autres contraintes, et +permet aussi au protocole de tirer parti des nouveaux algorithmes. Ces choix +font l'objet d'une négociation entre client et serveur lors de +l'établissement de la session protocolaire.

    + +

    Tableau 4: Versions du protocole SSL

    + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    VersionSourceDescription
    SSL v2.0Standard du fournisseur (de Netscape Corp.)Premier protocole SSL pour lequel il existe des implémentations
    SSL v3.0Projet Internet arrivé à expiration (de Netscape Corp.) [SSL3]Comporte des révisions permettant de prévenir certaines attaques de + sécurité spécifiques, ajout de chiffrements non RSA, et support des + chaînes de certification
    TLS v1.0Standard proposé pour l'Internet (de l'IETF) [TLS1]Révision de SSL 3.0 pour mettre à jour la couche MAC vers HMAC, + ajout du bourrage de bloc pour le chiffrement de bloc, standardisation + de l'ordonnancement des messages et plus de messages d'alerte.
    TLS v1.1Standard proposé pour l'Internet (de l'IETF) [TLS11]Mise à jour de TLS 1.0 pour la protection contre les + attaques de type Cipher block chaining (CBC).
    TLS v1.2Standard proposé pour l'Internet (de l'IETF) [TLS12]Mise à jour de TLS 1.1 rendant les condensés MD5 obsolètes, + et introduisant une incompatibilité avec SSL ce qui interdit toute + négociation en vue d'une utilisation de SSLv2.
    + + +

    Il existe plusieurs versions du protocole SSL, comme le montre le +Tableau 4. Comme indiqué dans ce dernier, un des apports +de SSL 3.0 est le support du chargement des chaînes de certification. Cette +fonctionnalité permet à un serveur de passer au navigateur un certificat de +serveur accompagné du certificat de l'émetteur. Le chargement de la +chaîne permet aussi au navigateur de valider le certificat du serveur, même si +les certificats de l'autorité de certification ne sont pas installés pour les +émetteurs intermédiaires, car ils sont inclus dans la chaîne de certification. +SSL 3.0 sert de base au standard du protocole Sécurité de la Couche Transport +ou Transport Layer Security +[TLS], actuellement en développement au sein de +l'Internet Engineering Task Force (IETF).

    + +

    Etablissement d'une session

    + +

    La session SSL est établie en suivant une séquence d'échanges + d'informations entre client et serveur, comme le montre la + Figure 1. Cette séquence peut varier, selon que + le serveur est configuré pour fournir un certificat de serveur ou + réclame un certificat client. Bien que dans certains cas, des étapes + d'échanges d'informations supplémentaires soient nécessaires pour la + gestion des informations de chiffrement, cet article résume un scénario + courant. Se reporter aux spécifications SSL pour avoir la liste de + toutes les possibilités.

    + +

    Note

    +

    Une fois la session SSL établie, elle peut être réutilisée. Ceci + permet d'éviter la perte de performances due à la répétition des nombreuses + étapes nécessaires à l'établissement d'une session. Pour parvenir à ceci, + le serveur assigne un identifiant de session unique à chaque session SSL ; + cet identifiant est mis en cache dans le serveur et le client peut + l'utiliser pour des connexions ultérieures afin de réduire la durée des + échanges d'informations (et ceci jusqu'à ce que l'identifiant de session + arrive à expiration dans le cache du serveur).

    +
    + +

    +
    + Figure 1 : Séquence + simplifiée d'échanges d'informations SSL

    + +

    Les éléments de la séquence d'échanges d'informations, tels qu'ils + sont utilisés par le client et le serveur, sont énumérés ci-après :

    + +
      +
    1. Négociation de la suite de chiffrement à utiliser durant le transfert des données
      2. +
    2. Elaboration et échange d'une clé de session entre le client et le serveur
      3. +
    3. Authentification éventuelle du serveur par le client
      4. +
    4. Authentification éventuelle du client par le serveur
      5. +
    + +

    La première étape, la négociation de la suite de chiffrement, permet au + client et au serveur de choisir une suite de chiffrement qu'ils supportent + tous les deux. La spécification du protocole SSL 3.0 définit 31 suites de + chiffrement. Une suite de chiffrement se compose des éléments + suivants :

    + +
      +
    • Méthode d'échange de la clé
      • +
    • Chiffrement du transfert des données
      • +
    • Empreinte du message servant à créer le code d'authentification du + message (MAC)
      • +
    + +

    Ces trois éléments sont décrits dans les sections suivantes.

    + + +

    Méthode d'échange de la clé

    + +

    La méthode d'échange de la clé définit la manière + dont la clé de chiffrement + symétrique secrète et partagée utilisée pour le transfert des données de + l'application sera acceptée par le client et le serveur. SSL 2.0 utilise + l'échange de clé RSA seulement, tandis que SSL 3.0 supporte tout un choix + d'algorithmes d'échange de clé incluant l'échange de clé RSA (quand les + certificats sont utilisés), et l'échange de clés Diffie-Hellman (pour + échanger des clés sans certificat, ou en l'absence de communication + préalable entre le client et le serveur).

    + +

    Les signatures numériques constituent une variante dans le choix des + méthodes d'échange de clé -- utiliser les signatures ou pas, et dans + l'affirmative, quel genre de signatures utiliser. La signature à l'aide + d'une clé privée fournit une protection contre une attaque + "man-in-the-middle" au cours de laquelle + l'échange d'informations destiné à générer la + clé partagée peut être intercepté [AC96, p516].

    + + +

    Chiffrement du transfert de données

    + +

    Comme décrit plus haut, SSL utilise le chiffrement symétrique + conventionnel pour chiffrer les messages au cours d'une session. Il existe + neuf choix possibles pour le chiffrement, y compris l'option du transfert + non chiffré :

    + +
      +
    • Pas de chiffrement
      • +
    • Chiffrement en continu (Stream Ciphers) +
        +
      • RC4 avec clés de 40 bits
        • +
      • RC4 avec clés de 128 bits
        • +
      • +
    • Chiffrement par blocs CBC (CBC Block Ciphers) +
      • RC2 avec clé de 40 bits
        • +
      • DES avec clé de 40 bits
        • +
      • DES avec clé de 56 bits
        • +
      • Triple-DES avec clé de 168 bits
        • +
      • Idea (clé de 128 bits)
        • +
      • Fortezza (clé de 96 bits)
        • +
      • +
    + +

    "CBC" signifie Cipher Block Chaining (Chaînage de blocs chiffrés), + c'est à dire qu'une portion du bloc de texte chiffré précédent est utilisée + pour le chiffrement du bloc courant. "DES" signifie Data Encryption + Standard (Standard de Chiffrement des Données) + [AC96, ch12], et possède de nombreuses variantes + (telles que DES40 et 3DES_EDE). Parmi les algorithmes disponibles, "Idea" + est actuellement un des meilleurs et des plus puissants sur le plan + cryptographique, et "RC2" est un algorithme propriétaire de RSA DSI + [AC96, ch13].

    + + +

    Fonction de création d'empreinte

    + +

    Le choix d'une fonction de création d'empreinte détermine la manière + dont une empreinte est créée à partir d'une unité de données. SSL supporte + les fonctions suivantes :

    + +
      +
    • Pas d'empreinte (choix Null)
      • +
    • MD5, une empreinte de 128 bits
      • +
    • Algorithme d'Empreinte Sécurisée (Secure Hash Algorithm - SHA-1), une + empreinte de 160 bits
      • +
    + +

    On utilise l'empreinte de message pour créer un Code d'Authentification + de Message (Message Authentication Code - MAC) qui est chiffré avec le + message afin de vérifier son intégrité et de se protéger contre les + attaques de type "rejeu".

    + + +

    Protocole de la séquence d'échanges d'informations

    + +

    La séquence d'échanges d'informations utilise trois protocoles :

    + +
      +
    • Le Protocole d'échanges d'informations SSL pour établir + la session SSl entre le client et le serveur.
      • +
    • Le Protocole de spécification du chiffrement SSL pour + l'agrément effectif de la suite de chiffrement à utiliser + pour la session.
      • +
    • Le Protocole d'alertes SSL pour la transmission de + messages d'erreur SSL entre le client et le serveur.
      • +
    + +

    Ces protocoles, ainsi que les données du protocole de l'application, + sont encapsulés dans le Protocole d'enregistrement SSL + (SSL Record Protocol), comme + le montre la Figure 2. Un protocole encapsulé est + tranféré en tant que données par le protocole de la couche de niveau + inférieur, qui ne se préoccupe pas du contenu des données. Le protocole + encapsulé n'a aucune connaissance du protocole sous-jacent.

    + +

    +
    + Figure 2: + Pile du protocole SSL

    + +

    L'encapsulation des protocoles de contrôle SSL dans le protocole + d'enregistrement signifie que si une session active est renégociée, les + protocoles de contrôle seront transmis de manière sécurisée. S'il n'y + avait pas de session préalable, la suite de chiffrement Null est utilisée, + ce qui signifie que les messages ne seront pas chiffrés et ne possèderont + pas d'empreinte d'intégrité, jusqu'à ce que la session ait été établie.

    + + +

    Transmission des données

    + +

    Le protocole d'enregistrement SSL, comme le montre la + Figure 3, est utilisé pour transmettre les données + de l'application et les données de contrôle SSL entre le client et le + serveur, les données étant nécessairement fragmentées en éléments plus + petits, ou plusieurs messages de données avec protocole de niveau + supérieur pouvant être combinés en un seul élément. Ce protocole peut + joindre des signatures d'empreintes, compresser et chiffrer ces éléments + avant de les transmettre en utilisant le protocole fiable de transport + sous-jacent (Note : actuellement, aucune implémentation majeure de SSL + n'inclut le support de la compression).

    + +

    +
    + Figure 3: + Protocole d'enregistrement SSL

    + + +

    Sécurisation des communications HTTP

    + +

    Une des utilisations courantes de SSL est la sécurisation des + communication HTTP sur le Web entre un navigateur et un serveur web. Ceci + n'exclut pas l'utilisation de HTTP non sécurisé - la version sécurisée + (appelée HTTPS) est identique à du vrai HTTP sur SSL, + mais utilise le préfixe + d'URL https au lieu de http, et un port + de serveur différent (par défaut le port 443). + Ceci constitue pour une large part + ce qu'apporte mod_ssl au serveur web Apache.

    + +
    top
    +
    +

    Références

    + +
    +
    [AC96]
    +
    Bruce Schneier, Applied Cryptography, 2nd Edition, Wiley, +1996. Voir http://www.counterpane.com/ pour diverses autres productions de Bruce +Schneier.
    + +
    [ASN1]
    +
    ITU-T Recommendation X.208, Specification of Abstract Syntax Notation +One (ASN.1), dernière mise à jour en 2008. Voir http://www.itu.int/ITU-T/asn1/. +
    + +
    [X509]
    +
    ITU-T Recommendation X.509, The Directory - Authentication +Framework. A titre de référence, voir http://en.wikipedia.org/wiki/X.509. +
    + +
    [PKCS]
    +
    Public Key Cryptography Standards (PKCS), +RSA Laboratories Technical Notes, Voir http://www.rsasecurity.com/rsalabs/pkcs/.
    + +
    [MIME]
    +
    N. Freed, N. Borenstein, Multipurpose Internet Mail Extensions +(MIME) Part One: Format of Internet Message Bodies, RFC2045. +Voir par exemple http://tools.ietf.org/html/rfc2045.
    + +
    [SSL3]
    +
    Alan O. Freier, Philip Karlton, Paul C. Kocher, The SSL Protocol +Version 3.0, 1996. Voir http://www.netscape.com/eng/ssl3/draft302.txt.
    + +
    [TLS1]
    +
    Tim Dierks, Christopher Allen, The TLS Protocol Version 1.0, +1999. Voir http://ietf.org/rfc/rfc2246.txt.
    + +
    [TLS11]
    +
    Le protocole TLS Version 1.1, +2006. Voir http://tools.ietf.org/html/rfc4346.
    + +
    [TLS12]
    +
    Le protocole TLS Version 1.2, +2008. Voir http://tools.ietf.org/html/rfc5246.
    +
    +
    +
    +

    Langues Disponibles:  en  | + fr  | + ja 

    +
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    +
    + \ No newline at end of file diff --git a/docs/manual/stopping.html b/docs/manual/stopping.html index 4ed4cacd6f..479cd9d672 100644 --- a/docs/manual/stopping.html +++ b/docs/manual/stopping.html @@ -10,7 +10,7 @@ Content-type: text/html; charset=ISO-8859-1 URI: stopping.html.es Content-Language: es -Content-type: text/html; charset=ISO-8859-1 +Content-type: text/html; charset=UTF-8 URI: stopping.html.fr Content-Language: fr diff --git a/docs/manual/stopping.html.en b/docs/manual/stopping.html.en index 075546b9a7..34a92d24e3 100644 --- a/docs/manual/stopping.html.en +++ b/docs/manual/stopping.html.en @@ -25,11 +25,11 @@

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

    + tr 

    This document covers stopping and restarting Apache HTTP Server on @@ -232,11 +232,11 @@ syntax error(s).

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

    + tr 

    top

    Comments

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    - - -
    -

    Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

    -

    Versin 2.5 del Servidor HTTP Apache

    -
    -
    <-
    -

    Iniciar y Parar el servidor Apache

    -
    -

    Idiomas disponibles:  de  | - en  | - es  | - fr  | - ja  | - ko  | - tr 

    -
    - -

    Este documento explica como iniciar y parar el servidor Apache - en sistemas tipo Unix. Los usuarios de Windows NT, 2000 y XP - deben consultar la seccin Ejecutar Apache como un - servicio y los usuario de Windows 9x y ME deben consultar Ejecutar Apache como una - Aplicacin de Consola para obtener informacin - sobre como controlar Apache en esas plataformas.

    -
    - -
    top
    -
    -

    Introduccin

    - -

    Para parar y reiniciar Apache, hay que enviar la seal - apropiada al proceso padre httpd que se est - ejecutando. Hay dos maneras de enviar estas seales. En - primer lugar, puede usar el comando de Unix kill que - enva seales directamente a los procesos. Puede que - tenga varios procesos httpd ejecutndose en su - sistema, pero las seales deben enviarse solamente al proceso - padre, cuyo PID est especificado en la directiva PidFile. Esto quiere decir que no - debe necesitar enviar seales a ningn proceso excepto - al proceso padre. Hay tres seales que puede enviar al - proceso padre: - TERM, - USR1 - HUP, y - WINCH, - que van a ser descritas a continuacin.

    - -

    Para enviar una seal al proceso padre debe escribir un - comando como el que se muestra en el ejemplo:

    - -

    kill -TERM `cat /usr/local/apache2/logs/httpd.pid`

    - -

    La segunda manera de enviar seales a los procesos - httpd es usando las opciones de lnea de - comandos -k: stop, restart, - y graceful y graceful-stop, como se - muestra ms abajo. Estas opciones se le pueden pasar al binario - httpd, pero se recomienda que se pasen al - script de control apachectl, que a su vez los - pasar a httpd.

    - -

    Despus de haber enviado las seales que desee a - httpd, puede ver como progresa el proceso - escribiendo:

    - -

    tail -f /usr/local/apache2/logs/error_log

    - -

    Modifique estos ejemplos para que coincidan con la - configuracin que tenga especificada en las directivas - ServerRoot y PidFile en su fichero principal de - configuracin.

    -
    top
    -
    -

    Parar Ahora Apache

    - -
    Seal: TERM
    -
    apachectl -k stop
    -
    - -

    Enviar las seales TERM o stop - al proceso padre hace que se intenten eliminar todos los procesos - hijos inmediatamente. Esto puede tardar algunos segundos. Una vez que hayan - terminado todos los procesos hijos, terminar el proceso padre. - Cualquier peticin en proceso terminar inmediatamente, y - ninguna peticin posterior ser - atendida.

    -
    top
    -
    -

    Reinicio "Graceful" o elegante

    - -
    Seal: USR1
    -
    apachectl -k graceful
    -
    - -

    Las seales USR1 o graceful - hacen que el proceso padre indique a sus hijos que - terminen despus de servir la peticin que estn - atendiendo en ese momento (o de inmediato si no estn - sirviendo ninguna peticin). El proceso padre lee de nuevo - sus ficheros de configuracin y vuelve a abrir sus ficheros - log. Conforme cada hijo va terminando, el proceso padre lo va - sustituyendo con un hijo de una nueva generacin con - la nueva configuracin, que empiezan a servir peticiones - inmediatamente.

    - -
    En algunas plataformas que no permiten usar - USR1 para reinicios graceful, puede usarse una - seal alternativa (como WINCH). Tambin puede - usar apachectl graceful y el script de control - enviar la seal adecuada para su plataforma.
    - -

    Apache est diseado para respetar en todo momento la - directiva de control de procesos de los MPM, as como para - que el nmero de procesos e hilos disponibles para servir a - los clientes se mantenga en los valores adecuados durante el - proceso de reinicio. An ms, est diseado - para respetar la directiva StartServers de la siguiente - manera: si despus de al menos un segundo el nuevo hijo de la - directiva StartServers - no ha sido creado, entonces crea los suficientes para que se atienda - el trabajo que queda por hacer. As, se intenta mantener - tanto el nmero de hijos adecuado para el trabajo que el - servidor tenga en ese momento, como respetar la configuracin - determinada por los parmetros de la directiva - StartServers.

    - -

    Los usuarios del mdulo mod_status - notarn que las estadsticas del servidor - no se ponen a cero cuando se usa la seal - USR1. Apache fue escrito tanto para minimizar el - tiempo en el que el servidor no puede servir nuevas peticiones - (que se pondrn en cola por el sistema operativo, de modo que - se no se pierda ningn evento), como para respetar sus - parmetros de ajuste. Para hacer esto, tiene que guardar el - scoreboard usado para llevar el registro de los procesos - hijo a travs de las distintas generaciones.

    - -

    El mod_status tambin usa una G para indicar - que esos hijos estn todava sirviendo peticiones - previas al reinicio graceful.

    - -

    Actualmente no existe ninguna manera de que un script con un - log de rotacin usando USR1 sepa con seguridad - que todos los hijos que se registraron en el log con anterioridad - al reinicio han terminado. Se aconseja que se use un retardo - adecuado despus de enviar la seal USR1 - antes de hacer nada con el log antiguo. Por ejemplo, si la mayor - parte las visitas que recibe de usuarios que tienen conexiones de - baja velocidad tardan menos de 10 minutos en completarse, entonces - espere 15 minutos antes de hacer nada con el log antiguo.

    - -
    Si su fichero de configuracin tiene errores cuando - haga el reinicio, entonces el proceso padre no se reiniciar - y terminar con un error. En caso de un reinicio graceful, - tambin dejar a los procesos hijo ejecutndose mientras - existan. (Estos son los hijos de los que se est saliendo de - forma graceful y que estn sirviendo sus ltimas - peticiones.) Esto provocar problemas si intenta reiniciar el - servidor no ser posible conectarse a la lista de puertos - de escucha. Antes de reiniciar, puede comprobar que la sintaxis de - sus ficheros de configuracin es correcta con la opcin de - lnea de comandos -t (consulte httpd). - No obstante, esto no - garantiza que el servidor se reinicie correctamente. Para - comprobar que no hay errores en los ficheros de - configuracin, puede intentar iniciar httpd con - un usuario diferente a root. Si no hay errores, intentar - abrir sus sockets y logs y fallar porque el usuario no es - root (o porque el httpd que se est ejecutando - en ese momento ya est conectado a esos puertos). Si falla - por cualquier otra razn, entonces casi seguro que hay - algn error en alguno de los ficheros de configuracin y - debe corregir ese o esos errores antes de hacer un reinicio - graceful.
    -
    top
    -
    -

    Reiniciar Apache

    - -
    Seal: HUP
    -
    apachectl -k restart
    -
    - -

    El envo de las seales HUP o - restart al proceso padre hace que los procesos hijo - terminen como si le enviramos la seal - TERM, para eliminar el proceso padre. La diferencia - est en que estas seales vuelven a leer los archivos de - configuracin y vuelven a abrir los ficheros log. Se genera - un nuevo conjunto de hijos y se contina sirviendo - peticiones.

    - -

    Los usuarios del mdulo mod_status - notarn que las estadsticas del servidor se ponen a - cero cuando se enva la seal HUP.

    - -
    Si su fichero de configuracin contiene errores, cuando -intente reiniciar, el proceso padre del servidor no se -reiniciar, sino que terminar con un error. Consulte -ms arriba cmo puede solucionar este problema.
    -
    top
    -
    -

    Apndice: seales y race conditions

    - -

    Con anterioridad a la versin de Apache 1.2b9 haba - varias race conditions implicadas en las seales - para parar y reiniciar procesos (una descripcin sencilla de - una race condition es: un problema relacionado con el momento en - que suceden las cosas, como si algo sucediera en momento en que no - debe, y entonces el resultado esperado no se corresponde con el - obtenido). Para aquellas arquitecturas que tienen el conjunto de - caractersticas "adecuadas", se han eliminado tantas race - conditions como ha sido posible. Pero hay que tener en cuenta que - todava existen race conditions en algunas arquitecturas.

    - -

    En las arquitecturas que usan un ScoreBoardFile en disco, existe la - posibilidad de que se corrompan los scoreboards. Esto puede hacer - que se produzca el error "bind: Address already in use" - (despus de usarHUP) o el error "long lost child - came home!" (despus de usar USR1). En el - primer caso se trata de un error irrecuperable, mientras que en el - segundo, solo ocurre que el servidor pierde un slot del - scoreboard. Por lo tanto, sera aconsejable usar reinicios - graceful, y solo hacer reinicios normales de forma - ocasional. Estos problemas son bastante complicados de solucionar, - pero afortunadamente casi ninguna arquitectura necesita un fichero - scoreboard. Consulte la documentacin de la directiva - ScoreBoardFile para ver - las arquitecturas que la usan.

    - -

    Todas las arquitecturas tienen una pequea race condition - en cada proceso hijo implicada en la segunda y subsiguientes - peticiones en una conexin HTTP persistente - (KeepAlive). Puede ser que el servidor termine despus de - leer la lnea de peticin pero antes de leer cualquiera - de las cabeceras de peticin. Hay una solucin que fue - descubierta demasiado tarde para la incluirla en versin - 1.2. En teora esto no debe suponer ningn problema porque el - cliente KeepAlive ha de esperar que estas cosas pasen debido a los - retardos de red y a los timeouts que a veces dan los - servidores. En la practica, parece que no afecta a nada ms - en una sesin de pruebas, un servidor se reinici - veinte veces por segundo y los clientes pudieron navegar sin - problemas por el sitio web sin encontrar problemas ni para - descargar una sola imagen ni encontrar un solo enlace roto.

    -
    -
    -

    Idiomas disponibles:  de  | - en  | - es  | - fr  | - ja  | - ko  | - tr 

    -
    top

    Comentarios

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    -
    - \ No newline at end of file diff --git a/docs/manual/stopping.html.es.utf8 b/docs/manual/stopping.html.es.utf8 new file mode 100644 index 0000000000..af6cc41f41 --- /dev/null +++ b/docs/manual/stopping.html.es.utf8 @@ -0,0 +1,299 @@ + + + + + +Iniciar y Parar el servidor Apache - Servidor HTTP Apache Versin 2.5 + + + + + + +
    +

    Mdulos | Directivas | Preguntas Frecuentes | Glosario | Mapa del sitio web

    +

    Versin 2.5 del Servidor HTTP Apache

    +
    +
    <-
    +

    Iniciar y Parar el servidor Apache

    +
    +

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

    +
    + +

    Este documento explica como iniciar y parar el servidor Apache + en sistemas tipo Unix. Los usuarios de Windows NT, 2000 y XP + deben consultar la seccin Ejecutar Apache como un + servicio y los usuario de Windows 9x y ME deben consultar Ejecutar Apache como una + Aplicacin de Consola para obtener informacin + sobre como controlar Apache en esas plataformas.

    +
    + +
    top
    +
    +

    Introduccin

    + +

    Para parar y reiniciar Apache, hay que enviar la seal + apropiada al proceso padre httpd que se est + ejecutando. Hay dos maneras de enviar estas seales. En + primer lugar, puede usar el comando de Unix kill que + enva seales directamente a los procesos. Puede que + tenga varios procesos httpd ejecutndose en su + sistema, pero las seales deben enviarse solamente al proceso + padre, cuyo PID est especificado en la directiva PidFile. Esto quiere decir que no + debe necesitar enviar seales a ningn proceso excepto + al proceso padre. Hay tres seales que puede enviar al + proceso padre: + TERM, + USR1 + HUP, y + WINCH, + que van a ser descritas a continuacin.

    + +

    Para enviar una seal al proceso padre debe escribir un + comando como el que se muestra en el ejemplo:

    + +

    kill -TERM `cat /usr/local/apache2/logs/httpd.pid`

    + +

    La segunda manera de enviar seales a los procesos + httpd es usando las opciones de lnea de + comandos -k: stop, restart, + y graceful y graceful-stop, como se + muestra ms abajo. Estas opciones se le pueden pasar al binario + httpd, pero se recomienda que se pasen al + script de control apachectl, que a su vez los + pasar a httpd.

    + +

    Despus de haber enviado las seales que desee a + httpd, puede ver como progresa el proceso + escribiendo:

    + +

    tail -f /usr/local/apache2/logs/error_log

    + +

    Modifique estos ejemplos para que coincidan con la + configuracin que tenga especificada en las directivas + ServerRoot y PidFile en su fichero principal de + configuracin.

    +
    top
    +
    +

    Parar Ahora Apache

    + +
    Seal: TERM
    +
    apachectl -k stop
    +
    + +

    Enviar las seales TERM o stop + al proceso padre hace que se intenten eliminar todos los procesos + hijos inmediatamente. Esto puede tardar algunos segundos. Una vez que hayan + terminado todos los procesos hijos, terminar el proceso padre. + Cualquier peticin en proceso terminar inmediatamente, y + ninguna peticin posterior ser + atendida.

    +
    top
    +
    +

    Reinicio "Graceful" o elegante

    + +
    Seal: USR1
    +
    apachectl -k graceful
    +
    + +

    Las seales USR1 o graceful + hacen que el proceso padre indique a sus hijos que + terminen despus de servir la peticin que estn + atendiendo en ese momento (o de inmediato si no estn + sirviendo ninguna peticin). El proceso padre lee de nuevo + sus ficheros de configuracin y vuelve a abrir sus ficheros + log. Conforme cada hijo va terminando, el proceso padre lo va + sustituyendo con un hijo de una nueva generacin con + la nueva configuracin, que empiezan a servir peticiones + inmediatamente.

    + +
    En algunas plataformas que no permiten usar + USR1 para reinicios graceful, puede usarse una + seal alternativa (como WINCH). Tambin puede + usar apachectl graceful y el script de control + enviar la seal adecuada para su plataforma.
    + +

    Apache est diseado para respetar en todo momento la + directiva de control de procesos de los MPM, as como para + que el nmero de procesos e hilos disponibles para servir a + los clientes se mantenga en los valores adecuados durante el + proceso de reinicio. An ms, est diseado + para respetar la directiva StartServers de la siguiente + manera: si despus de al menos un segundo el nuevo hijo de la + directiva StartServers + no ha sido creado, entonces crea los suficientes para que se atienda + el trabajo que queda por hacer. As, se intenta mantener + tanto el nmero de hijos adecuado para el trabajo que el + servidor tenga en ese momento, como respetar la configuracin + determinada por los parmetros de la directiva + StartServers.

    + +

    Los usuarios del mdulo mod_status + notarn que las estadsticas del servidor + no se ponen a cero cuando se usa la seal + USR1. Apache fue escrito tanto para minimizar el + tiempo en el que el servidor no puede servir nuevas peticiones + (que se pondrn en cola por el sistema operativo, de modo que + se no se pierda ningn evento), como para respetar sus + parmetros de ajuste. Para hacer esto, tiene que guardar el + scoreboard usado para llevar el registro de los procesos + hijo a travs de las distintas generaciones.

    + +

    El mod_status tambin usa una G para indicar + que esos hijos estn todava sirviendo peticiones + previas al reinicio graceful.

    + +

    Actualmente no existe ninguna manera de que un script con un + log de rotacin usando USR1 sepa con seguridad + que todos los hijos que se registraron en el log con anterioridad + al reinicio han terminado. Se aconseja que se use un retardo + adecuado despus de enviar la seal USR1 + antes de hacer nada con el log antiguo. Por ejemplo, si la mayor + parte las visitas que recibe de usuarios que tienen conexiones de + baja velocidad tardan menos de 10 minutos en completarse, entonces + espere 15 minutos antes de hacer nada con el log antiguo.

    + +
    Si su fichero de configuracin tiene errores cuando + haga el reinicio, entonces el proceso padre no se reiniciar + y terminar con un error. En caso de un reinicio graceful, + tambin dejar a los procesos hijo ejecutndose mientras + existan. (Estos son los hijos de los que se est saliendo de + forma graceful y que estn sirviendo sus ltimas + peticiones.) Esto provocar problemas si intenta reiniciar el + servidor no ser posible conectarse a la lista de puertos + de escucha. Antes de reiniciar, puede comprobar que la sintaxis de + sus ficheros de configuracin es correcta con la opcin de + lnea de comandos -t (consulte httpd). + No obstante, esto no + garantiza que el servidor se reinicie correctamente. Para + comprobar que no hay errores en los ficheros de + configuracin, puede intentar iniciar httpd con + un usuario diferente a root. Si no hay errores, intentar + abrir sus sockets y logs y fallar porque el usuario no es + root (o porque el httpd que se est ejecutando + en ese momento ya est conectado a esos puertos). Si falla + por cualquier otra razn, entonces casi seguro que hay + algn error en alguno de los ficheros de configuracin y + debe corregir ese o esos errores antes de hacer un reinicio + graceful.
    +
    top
    +
    +

    Reiniciar Apache

    + +
    Seal: HUP
    +
    apachectl -k restart
    +
    + +

    El envo de las seales HUP o + restart al proceso padre hace que los procesos hijo + terminen como si le enviramos la seal + TERM, para eliminar el proceso padre. La diferencia + est en que estas seales vuelven a leer los archivos de + configuracin y vuelven a abrir los ficheros log. Se genera + un nuevo conjunto de hijos y se contina sirviendo + peticiones.

    + +

    Los usuarios del mdulo mod_status + notarn que las estadsticas del servidor se ponen a + cero cuando se enva la seal HUP.

    + +
    Si su fichero de configuracin contiene errores, cuando +intente reiniciar, el proceso padre del servidor no se +reiniciar, sino que terminar con un error. Consulte +ms arriba cmo puede solucionar este problema.
    +
    top
    +
    +

    Apndice: seales y race conditions

    + +

    Con anterioridad a la versin de Apache 1.2b9 haba + varias race conditions implicadas en las seales + para parar y reiniciar procesos (una descripcin sencilla de + una race condition es: un problema relacionado con el momento en + que suceden las cosas, como si algo sucediera en momento en que no + debe, y entonces el resultado esperado no se corresponde con el + obtenido). Para aquellas arquitecturas que tienen el conjunto de + caractersticas "adecuadas", se han eliminado tantas race + conditions como ha sido posible. Pero hay que tener en cuenta que + todava existen race conditions en algunas arquitecturas.

    + +

    En las arquitecturas que usan un ScoreBoardFile en disco, existe la + posibilidad de que se corrompan los scoreboards. Esto puede hacer + que se produzca el error "bind: Address already in use" + (despus de usarHUP) o el error "long lost child + came home!" (despus de usar USR1). En el + primer caso se trata de un error irrecuperable, mientras que en el + segundo, solo ocurre que el servidor pierde un slot del + scoreboard. Por lo tanto, sera aconsejable usar reinicios + graceful, y solo hacer reinicios normales de forma + ocasional. Estos problemas son bastante complicados de solucionar, + pero afortunadamente casi ninguna arquitectura necesita un fichero + scoreboard. Consulte la documentacin de la directiva + ScoreBoardFile para ver + las arquitecturas que la usan.

    + +

    Todas las arquitecturas tienen una pequea race condition + en cada proceso hijo implicada en la segunda y subsiguientes + peticiones en una conexin HTTP persistente + (KeepAlive). Puede ser que el servidor termine despus de + leer la lnea de peticin pero antes de leer cualquiera + de las cabeceras de peticin. Hay una solucin que fue + descubierta demasiado tarde para la incluirla en versin + 1.2. En teora esto no debe suponer ningn problema porque el + cliente KeepAlive ha de esperar que estas cosas pasen debido a los + retardos de red y a los timeouts que a veces dan los + servidores. En la practica, parece que no afecta a nada ms + en una sesin de pruebas, un servidor se reinici + veinte veces por segundo y los clientes pudieron navegar sin + problemas por el sitio web sin encontrar problemas ni para + descargar una sola imagen ni encontrar un solo enlace roto.

    +
    +
    +

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

    +
    top

    Comentarios

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    +
    + \ No newline at end of file diff --git a/docs/manual/stopping.html.fr b/docs/manual/stopping.html.fr deleted file mode 100644 index cd2ace817c..0000000000 --- a/docs/manual/stopping.html.fr +++ /dev/null @@ -1,305 +0,0 @@ - - - - - -Arrêt et redémarrage du serveur HTTP Apache - Serveur HTTP Apache Version 2.5 - - - - - - -
    -

    Modules | Directives | FAQ | Glossaire | Plan du site

    -

    Serveur HTTP Apache Version 2.5

    -
    -
    <-
    -

    Arrêt et redémarrage du serveur HTTP Apache

    -
    -

    Langues Disponibles:  de  | - en  | - es  | - fr  | - ja  | - ko  | - tr 

    -
    - -

    Ce document couvre l'arrêt et le redémarrage du - serveur HTTP Apache sur - les systèmes Unix et similaires. Les utilisateurs de Windows NT, 2000 - and XP doivent consulter - Exécuter httpd en tant que - service et les utilisateurs de Windows 9x et ME doivent consulter - Exécuter httpd comme une - application de type console pour plus d'informations sur le contrôle - de httpd à partir de ces plateformes.

    -
    - -
    top
    -
    -

    Introduction

    - -

    Afin d'arrêter ou redémarrer le serveur HTTP Apache, vous devez envoyer un signal aux - processus httpd en cours d'exécution. Les signaux - peuvent être envoyés de deux manières. La - première méthode consiste à - utiliser la commande unix kill - pour envoyer directement des signaux aux processus. Vous pouvez remarquer - que plusieurs processus httpd s'exécutent sur votre - système, mais il vous suffit d'envoyer les signaux au processus parent, - dont le PID est enregistré dans le fichier précisé par la directive - PidFile. Autrement dit, vous - n'aurez jamais besoin d'envoyer des signaux à aucun des - processus enfants, mais seulement au processus parent. Quatre types - de signaux peuvent être envoyés au processus parent : - TERM, - USR1, - HUP, et - WINCH, qui - seront décrit plus loin.

    - -

    Pour envoyer un signal au processus parent, vous devez entrer une commande - du style :

    - -

    kill -TERM `cat /usr/local/apache2/logs/httpd.pid`

    - -

    La seconde méthode permettant d'envoyer des signaux aux processus - httpd - consiste à utiliser les options stop, - restart, graceful et - graceful-stop du commutateur -k de la ligne - de commande comme décrit ci-dessous. Ce sont des arguments du binaire - httpd, mais il est recommandé de les utiliser - avec le script de contrôle apachectl, qui se - chargera de les passer à httpd.

    - -

    Après avoir envoyé un signal à httpd, vous pouvez - suivre le cours de son action en entrant :

    - -

    tail -f /usr/local/apache2/logs/error_log

    - -

    Adaptez ces exemples en fonction de la définition de vos directives - ServerRoot et - PidFile.

    -
    top
    -
    -

    Arrêter immédiatement

    - -
    Signal: TERM
    -
    apachectl -k stop
    -
    - -

    A la réception du signal TERM ou stop, - le processus parent tente immédiatement - de tuer tous ses processus enfants. Cela peut durer plusieurs secondes. - Après cela, le processus parent lui-même se termine. Toutes les requêtes - en cours sont terminées, et plus aucune autre n'est traitée.

    -
    top
    -
    -

    Redémarrage en douceur

    - -
    Signal: USR1
    -
    apachectl -k graceful
    -
    - -

    A la réception du signal USR1 ou - graceful, le - processus parent envoie aux processus enfants - l'ordre de se terminer une fois leur requête courante - traitée (ou de se terminer immédiatement s'ils n'ont plus rien à traiter). - Le processus parent relit ses fichiers de configuration et - réouvre ses fichiers de log. Chaque fois qu'un enfant s'éteint, le - processus parent le remplace par un processus - enfant de la nouvelle génération de la - configuration, et celui-ci commence immédiatement à traiter les - nouvelles requêtes.

    - -

    Ce code est conçu pour toujours respecter la directive de contrôle - de processus des modules MPMs, afin que les nombres de processus et de - threads - disponibles pour traiter les demandes des clients soient maintenus à - des valeurs appropriées tout au long du processus de démarrage. - En outre, il respecte la directive - StartServers de la manière - suivante : si après une seconde au moins StartServers nouveaux processus - enfants n'ont pas été créés, un nombre suffisant de processus - supplémentaires est créé pour combler le manque. Ainsi le code - tente de maintenir à la fois le nombre approprié de processus enfants - en fonction de la charge du serveur, et le nombre de processus défini par la - directive StartServers.

    - -

    Les utilisateurs du module mod_status - noteront que les statistiques du serveur ne sont pas - remises à zéro quand un signal USR1 est envoyé. Le code - a été conçu à la fois pour minimiser la durée durant laquelle le - serveur ne peut pas traiter de nouvelles requêtes (elle sont mises en - file d'attente par le système d'exploitation, et ne sont ainsi jamais - perdues) et pour respecter vos paramètres de personnalisation. - Pour y parvenir, il doit conserver le - tableau utilisé pour garder la trace de tous les processus - enfants au cours des différentes générations.

    - -

    Dans son état des processus, - le module status utilise aussi un caractère G afin d'indiquer - quels processus enfants ont encore des traitements de requêtes en cours - débutés avant que l'ordre graceful restart ne soit donné.

    - -

    Pour l'instant, il est impossible pour un script de rotation - des logs utilisant - USR1 de savoir de manière certaine si tous les processus - enfants inscrivant des traces de pré-redémarrage sont terminés. - Nous vous suggérons d'attendre un délai suffisant après l'envoi du - signal USR1 - avant de faire quoi que ce soit avec les anciens logs. Par exemple, - si la plupart de vos traitements durent moins de 10 minutes pour des - utilisateurs empruntant des liaisons à faible bande passante, alors vous - devriez attendre 15 minutes avant de faire quoi que ce soit - avec les anciens logs.

    - -
    -

    Lorsque vous initiez un redémarrage, une vérification de - la syntaxe est tout d'abord effectuée, afin de s'assurer qu'il n'y a - pas d'erreurs dans les fichiers de configuration. Si votre fichier de - configuration comporte des erreurs de syntaxe, vous recevrez un message - d'erreur les concernant, et le serveur refusera de redémarrer. Ceci - permet d'éviter la situation où un serveur a - été arrêté et ne peut plus redémarrer, - et où vous vous retrouvez avec un serveur hors-service.

    - -

    Ceci ne garantit pas encore que le serveur va redémarrer - correctement. Pour vérifier la sémantique des fichiers de configuration - en plus de leur syntaxe, vous pouvez essayer de démarrer - httpd sous un utilisateur non root. - S'il n'y a pas d'erreur, il tentera d'ouvrir ses sockets et ses fichiers - de log et échouera car il n'a pas les privilèges root (ou parce que - l'instance actuelle de - httpd est déjà associée à ces ports). S'il échoue - pour toute autre raison, il y a probablement une erreur dans le - fichier de configuration et celle-ci doit être corrigée avant de lancer - le redémarrage en douceur.

    -
    top
    -
    -

    Redémarrer immédiatement

    - -
    Signal: HUP
    -
    apachectl -k restart
    -
    - -

    A la réception du signal HUP ou - restart, le - processus parent tue ses processus enfants comme pour le signal - TERM, mais le processus parent ne se termine pas. - Il relit ses fichiers de configuration, et réouvre ses fichiers de log. - Puis il donne naissance à un nouveau jeu de processus enfants - et continue de traiter les requêtes.

    - -

    Les utilisateurs du module mod_status - noteront que les statistiques du serveur sont remises à zéro quand un - signal HUP est envoyé.

    - -
    Comme dans le cas d'un redémarrage "graceful", une -vérification de la syntaxe est effectuée avant que le -redémarrage ne soit tenté. Si votre fichier de configuration comporte -des erreurs de syntaxe, le redémarrage ne sera pas effectué, et -vous recevrez un message concernant ces erreurs.
    -
    top
    -
    -

    Arrêt en douceur

    - -
    Signal : WINCH
    -
    apachectl -k graceful-stop
    -
    - -

    A la réception du signal WINCH ou - graceful-stop, le - processus parent ordonne à ses processus enfants - de s'arrêter après le traitement de leur requête en cours - (ou de s'arrêter immédiatement s'ils n'ont plus de requête à traiter). - Le processus parent va alors supprimer son fichier - PidFile et cesser l'écoute - de tous ses ports. Le processus parent va continuer à s'exécuter, - et va surveiller les processus enfants - qui ont encore des requêtes à traiter. Lorsque tous les processus enfants - ont terminé leurs traitements et se sont arrêtés ou lorsque le délai - spécifié par la directive GracefulShutdownTimeout a été atteint, - le processus parent s'arrêtera à son tour. Si ce délai est atteint, - tout processus enfant encore en cours d'exécution se verra envoyer - le signal TERM - afin de le forcer à s'arrêter.

    - -

    L'envoi du signal TERM va arrêter immédiatement - les processus parent et enfants en état "graceful". Cependant, - comme le fichier PidFile - aura été supprimé, vous ne pourrez pas utiliser - apachectl ou httpd pour envoyer ce signal.

    - -

    Le signal graceful-stop vous permet d'exécuter - simultanément plusieurs instances de httpd - avec des configurations identiques. Ceci s'avère une fonctionnalité - puissante quand vous effectuez des mises à jour "en douceur" - de httpd ; cependant, cela peut aussi causer des blocages fatals et des - situations de compétition (race conditions) - avec certaines configurations.

    - -

    On a pris soin de s'assurer que les fichiers sur disque - comme les fichiers verrou (Mutex) et les fichiers socket Unix - (ScriptSock) contiennent le PID - du serveur, et coexistent sans problème. Cependant, si une directive de - configuration, un module tiers ou une CGI résidente utilise un autre - verrou ou fichier d'état sur disque, il faut prendre soin de s'assurer - que chaque instance de httpd qui s'exécute - n'écrase pas les fichiers des autres instances.

    - -

    Vous devez aussi prendre garde aux autres situations de compétition, - comme l'enregistrement des logs avec un transfert de ceux-ci - via un pipe vers le programme rotatelogs. Plusieurs instances - du programme rotatelogs qui tentent d'effectuer - une rotation des mêmes fichiers de log en même temps peuvent détruire - mutuellement leurs propres fichiers de log.

    -
    -
    -

    Langues Disponibles:  de  | - en  | - es  | - fr  | - ja  | - ko  | - tr 

    -
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    -
    - \ No newline at end of file diff --git a/docs/manual/stopping.html.fr.utf8 b/docs/manual/stopping.html.fr.utf8 new file mode 100644 index 0000000000..cd2ace817c --- /dev/null +++ b/docs/manual/stopping.html.fr.utf8 @@ -0,0 +1,305 @@ + + + + + +Arrêt et redémarrage du serveur HTTP Apache - Serveur HTTP Apache Version 2.5 + + + + + + +
    +

    Modules | Directives | FAQ | Glossaire | Plan du site

    +

    Serveur HTTP Apache Version 2.5

    +
    +
    <-
    +

    Arrêt et redémarrage du serveur HTTP Apache

    +
    +

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

    +
    + +

    Ce document couvre l'arrêt et le redémarrage du + serveur HTTP Apache sur + les systèmes Unix et similaires. Les utilisateurs de Windows NT, 2000 + and XP doivent consulter + Exécuter httpd en tant que + service et les utilisateurs de Windows 9x et ME doivent consulter + Exécuter httpd comme une + application de type console pour plus d'informations sur le contrôle + de httpd à partir de ces plateformes.

    +
    + +
    top
    +
    +

    Introduction

    + +

    Afin d'arrêter ou redémarrer le serveur HTTP Apache, vous devez envoyer un signal aux + processus httpd en cours d'exécution. Les signaux + peuvent être envoyés de deux manières. La + première méthode consiste à + utiliser la commande unix kill + pour envoyer directement des signaux aux processus. Vous pouvez remarquer + que plusieurs processus httpd s'exécutent sur votre + système, mais il vous suffit d'envoyer les signaux au processus parent, + dont le PID est enregistré dans le fichier précisé par la directive + PidFile. Autrement dit, vous + n'aurez jamais besoin d'envoyer des signaux à aucun des + processus enfants, mais seulement au processus parent. Quatre types + de signaux peuvent être envoyés au processus parent : + TERM, + USR1, + HUP, et + WINCH, qui + seront décrit plus loin.

    + +

    Pour envoyer un signal au processus parent, vous devez entrer une commande + du style :

    + +

    kill -TERM `cat /usr/local/apache2/logs/httpd.pid`

    + +

    La seconde méthode permettant d'envoyer des signaux aux processus + httpd + consiste à utiliser les options stop, + restart, graceful et + graceful-stop du commutateur -k de la ligne + de commande comme décrit ci-dessous. Ce sont des arguments du binaire + httpd, mais il est recommandé de les utiliser + avec le script de contrôle apachectl, qui se + chargera de les passer à httpd.

    + +

    Après avoir envoyé un signal à httpd, vous pouvez + suivre le cours de son action en entrant :

    + +

    tail -f /usr/local/apache2/logs/error_log

    + +

    Adaptez ces exemples en fonction de la définition de vos directives + ServerRoot et + PidFile.

    +
    top
    +
    +

    Arrêter immédiatement

    + +
    Signal: TERM
    +
    apachectl -k stop
    +
    + +

    A la réception du signal TERM ou stop, + le processus parent tente immédiatement + de tuer tous ses processus enfants. Cela peut durer plusieurs secondes. + Après cela, le processus parent lui-même se termine. Toutes les requêtes + en cours sont terminées, et plus aucune autre n'est traitée.

    +
    top
    +
    +

    Redémarrage en douceur

    + +
    Signal: USR1
    +
    apachectl -k graceful
    +
    + +

    A la réception du signal USR1 ou + graceful, le + processus parent envoie aux processus enfants + l'ordre de se terminer une fois leur requête courante + traitée (ou de se terminer immédiatement s'ils n'ont plus rien à traiter). + Le processus parent relit ses fichiers de configuration et + réouvre ses fichiers de log. Chaque fois qu'un enfant s'éteint, le + processus parent le remplace par un processus + enfant de la nouvelle génération de la + configuration, et celui-ci commence immédiatement à traiter les + nouvelles requêtes.

    + +

    Ce code est conçu pour toujours respecter la directive de contrôle + de processus des modules MPMs, afin que les nombres de processus et de + threads + disponibles pour traiter les demandes des clients soient maintenus à + des valeurs appropriées tout au long du processus de démarrage. + En outre, il respecte la directive + StartServers de la manière + suivante : si après une seconde au moins StartServers nouveaux processus + enfants n'ont pas été créés, un nombre suffisant de processus + supplémentaires est créé pour combler le manque. Ainsi le code + tente de maintenir à la fois le nombre approprié de processus enfants + en fonction de la charge du serveur, et le nombre de processus défini par la + directive StartServers.

    + +

    Les utilisateurs du module mod_status + noteront que les statistiques du serveur ne sont pas + remises à zéro quand un signal USR1 est envoyé. Le code + a été conçu à la fois pour minimiser la durée durant laquelle le + serveur ne peut pas traiter de nouvelles requêtes (elle sont mises en + file d'attente par le système d'exploitation, et ne sont ainsi jamais + perdues) et pour respecter vos paramètres de personnalisation. + Pour y parvenir, il doit conserver le + tableau utilisé pour garder la trace de tous les processus + enfants au cours des différentes générations.

    + +

    Dans son état des processus, + le module status utilise aussi un caractère G afin d'indiquer + quels processus enfants ont encore des traitements de requêtes en cours + débutés avant que l'ordre graceful restart ne soit donné.

    + +

    Pour l'instant, il est impossible pour un script de rotation + des logs utilisant + USR1 de savoir de manière certaine si tous les processus + enfants inscrivant des traces de pré-redémarrage sont terminés. + Nous vous suggérons d'attendre un délai suffisant après l'envoi du + signal USR1 + avant de faire quoi que ce soit avec les anciens logs. Par exemple, + si la plupart de vos traitements durent moins de 10 minutes pour des + utilisateurs empruntant des liaisons à faible bande passante, alors vous + devriez attendre 15 minutes avant de faire quoi que ce soit + avec les anciens logs.

    + +
    +

    Lorsque vous initiez un redémarrage, une vérification de + la syntaxe est tout d'abord effectuée, afin de s'assurer qu'il n'y a + pas d'erreurs dans les fichiers de configuration. Si votre fichier de + configuration comporte des erreurs de syntaxe, vous recevrez un message + d'erreur les concernant, et le serveur refusera de redémarrer. Ceci + permet d'éviter la situation où un serveur a + été arrêté et ne peut plus redémarrer, + et où vous vous retrouvez avec un serveur hors-service.

    + +

    Ceci ne garantit pas encore que le serveur va redémarrer + correctement. Pour vérifier la sémantique des fichiers de configuration + en plus de leur syntaxe, vous pouvez essayer de démarrer + httpd sous un utilisateur non root. + S'il n'y a pas d'erreur, il tentera d'ouvrir ses sockets et ses fichiers + de log et échouera car il n'a pas les privilèges root (ou parce que + l'instance actuelle de + httpd est déjà associée à ces ports). S'il échoue + pour toute autre raison, il y a probablement une erreur dans le + fichier de configuration et celle-ci doit être corrigée avant de lancer + le redémarrage en douceur.

    +
    top
    +
    +

    Redémarrer immédiatement

    + +
    Signal: HUP
    +
    apachectl -k restart
    +
    + +

    A la réception du signal HUP ou + restart, le + processus parent tue ses processus enfants comme pour le signal + TERM, mais le processus parent ne se termine pas. + Il relit ses fichiers de configuration, et réouvre ses fichiers de log. + Puis il donne naissance à un nouveau jeu de processus enfants + et continue de traiter les requêtes.

    + +

    Les utilisateurs du module mod_status + noteront que les statistiques du serveur sont remises à zéro quand un + signal HUP est envoyé.

    + +
    Comme dans le cas d'un redémarrage "graceful", une +vérification de la syntaxe est effectuée avant que le +redémarrage ne soit tenté. Si votre fichier de configuration comporte +des erreurs de syntaxe, le redémarrage ne sera pas effectué, et +vous recevrez un message concernant ces erreurs.
    +
    top
    +
    +

    Arrêt en douceur

    + +
    Signal : WINCH
    +
    apachectl -k graceful-stop
    +
    + +

    A la réception du signal WINCH ou + graceful-stop, le + processus parent ordonne à ses processus enfants + de s'arrêter après le traitement de leur requête en cours + (ou de s'arrêter immédiatement s'ils n'ont plus de requête à traiter). + Le processus parent va alors supprimer son fichier + PidFile et cesser l'écoute + de tous ses ports. Le processus parent va continuer à s'exécuter, + et va surveiller les processus enfants + qui ont encore des requêtes à traiter. Lorsque tous les processus enfants + ont terminé leurs traitements et se sont arrêtés ou lorsque le délai + spécifié par la directive GracefulShutdownTimeout a été atteint, + le processus parent s'arrêtera à son tour. Si ce délai est atteint, + tout processus enfant encore en cours d'exécution se verra envoyer + le signal TERM + afin de le forcer à s'arrêter.

    + +

    L'envoi du signal TERM va arrêter immédiatement + les processus parent et enfants en état "graceful". Cependant, + comme le fichier PidFile + aura été supprimé, vous ne pourrez pas utiliser + apachectl ou httpd pour envoyer ce signal.

    + +

    Le signal graceful-stop vous permet d'exécuter + simultanément plusieurs instances de httpd + avec des configurations identiques. Ceci s'avère une fonctionnalité + puissante quand vous effectuez des mises à jour "en douceur" + de httpd ; cependant, cela peut aussi causer des blocages fatals et des + situations de compétition (race conditions) + avec certaines configurations.

    + +

    On a pris soin de s'assurer que les fichiers sur disque + comme les fichiers verrou (Mutex) et les fichiers socket Unix + (ScriptSock) contiennent le PID + du serveur, et coexistent sans problème. Cependant, si une directive de + configuration, un module tiers ou une CGI résidente utilise un autre + verrou ou fichier d'état sur disque, il faut prendre soin de s'assurer + que chaque instance de httpd qui s'exécute + n'écrase pas les fichiers des autres instances.

    + +

    Vous devez aussi prendre garde aux autres situations de compétition, + comme l'enregistrement des logs avec un transfert de ceux-ci + via un pipe vers le programme rotatelogs. Plusieurs instances + du programme rotatelogs qui tentent d'effectuer + une rotation des mêmes fichiers de log en même temps peuvent détruire + mutuellement leurs propres fichiers de log.

    +
    +
    +

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

    +
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    +
    + \ No newline at end of file diff --git a/docs/manual/style/lang/es.xml b/docs/manual/style/lang/es.xml index a23790ce29..27cf0274bc 100644 --- a/docs/manual/style/lang/es.xml +++ b/docs/manual/style/lang/es.xml @@ -23,7 +23,7 @@ Spanish UTF-8 .xml.es - .html.es + .html.es.utf8 0xC0A Spanish (International) diff --git a/docs/manual/style/lang/fr.xml b/docs/manual/style/lang/fr.xml index 5b4ef4a781..0a39a86777 100644 --- a/docs/manual/style/lang/fr.xml +++ b/docs/manual/style/lang/fr.xml @@ -23,7 +23,7 @@ French UTF-8 .xml.fr - .html.fr + .html.fr.utf8 0x40c French (France) diff --git a/docs/manual/suexec.html.en b/docs/manual/suexec.html.en index 56e659d5f4..96160a115c 100644 --- a/docs/manual/suexec.html.en +++ b/docs/manual/suexec.html.en @@ -24,10 +24,10 @@ Apache > HTTP Server > Documentation > Version 2.5

    suEXEC Support

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

    + tr 

    The suEXEC feature provides users of the Apache @@ -636,10 +636,10 @@ Group webgroup

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

    + tr 

    top

    Comments

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    - - -
    -

    Modules | Directives | FAQ | Glossaire | Plan du site

    -

    Serveur HTTP Apache Version 2.5

    -
    -
    <-
    -

    Support suEXEC

    -
    -

    Langues Disponibles:  en  | - fr  | - ja  | - ko  | - tr 

    -
    - -

    La fonctionnalité suEXEC permet - l'exécution des programmes CGI et - SSI sous un utilisateur autre que celui sous - lequel s'exécute le serveur web qui appelle ces programmes. - Normalement, lorsqu'un programme CGI ou SSI est lancé, il - s'exécute sous le même utilisateur que celui du serveur web qui - l'appelle.

    - -

    Utilisée de manière appropriée, cette fonctionnalité peut - réduire considérablement les risques de sécurité encourus - lorsqu'on autorise les utilisateurs à développer et faire - s'exécuter des programmes CGI ou SSI de leur cru. Cependant, mal - configuré, suEXEC peut causer de nombreux problèmes et même créer - de nouvelles failles dans la sécurité de votre ordinateur. Si - vous n'êtes pas familier avec la gestion des programmes - setuid root et les risques de sécurité qu'ils comportent, - nous vous recommandons vivement de ne pas tenter - d'utiliser suEXEC.

    -
    - -
    top
    -
    -

    Avant de commencer

    - -

    Avant de foncer tête baissée dans la lecture de ce document, - vous devez tenir compte de certaines hypothèses concernant vous-même - et l'environnement dans lequel vous allez utiliser suexec.

    - -

    Premièrement, vous devez utiliser un système d'exploitation - UNIX ou dérivé, capable d'effectuer des opérations - setuid et setgid. Tous les - exemples de commande sont donnés en conséquence. D'autres - plates-formes, même si elles supportent suEXEC, peuvent - avoir une configuration différente.

    - -

    Deuxièmement, vous devez être familier avec les concepts de base - relatifs à la sécurité de votre ordinateur et son administration. - Ceci implique la compréhension des opérations - setuid/setgid et des différents effets qu'elles - peuvent produire sur votre système et son niveau de sécurité.

    - -

    Troisièmement, vous devez utiliser une version - non modifiée du code de suEXEC. L'ensemble du - code de suEXEC a été scruté et testé avec soin par les développeurs - et de nombreux bêta testeurs. Toutes les précautions ont été prises - pour s'assurer d'une base sûre de code non seulement simple, mais - aussi solide. La modification de ce code peut causer des problèmes - inattendus et de nouveaux risques de sécurité. Il est - vivement recommandé de ne pas modifier le code de - suEXEC, à moins que vous ne soyez un programmeur spécialiste des - particularités liées à la sécurité, et souhaitez partager votre - travail avec l'équipe de développement du serveur HTTP Apache afin - de pouvoir en discuter.

    - -

    Quatrièmement et dernièrement, l'équipe de développement du - serveur HTTP Apache a décidé de ne - PAS inclure suEXEC dans l'installation par défaut - d'Apache httpd. Pour pouvoir mettre en oeuvre suEXEC, l'administrateur - doit porter la plus grande attention aux détails. Après avoir bien - réfléchi aux différents points de la configuration de suEXEC, - l'administrateur peut l'installer selon les méthodes classiques. - Les valeurs des paramètres de configuration doivent être - déterminées et spécifiées avec soin par l'administrateur, afin de - maintenir la sécurité du système de manière appropriée lors de - l'utilisation de la fonctionnalité suEXEC. C'est par le biais de - ce processus minutieux que nous espérons réserver - l'installation de suEXEC aux administrateurs prudents et - suffisamment déterminés à vouloir l'utiliser.

    - -

    Vous êtes encore avec nous ? Oui ? Bien. - Alors nous pouvons continuer !

    -
    top
    -
    -

    Modèle de sécurité de suEXEC

    - -

    Avant d'installer et configurer suEXEC, nous allons tout d'abord - décrire le modèle de sécurité que vous êtes sur le point - d'implémenter. Vous devriez ainsi mieux comprendre ce qui se passe - vraiment à l'intérieur de suEXEC et quelles précautions ont été - prises pour préserver la sécurité de votre système.

    - -

    suEXEC est basé sur un programme "conteneur" - (wrapper) setuid qui est appelé par le serveur HTTP Apache principal. - Ce conteneur est appelé quand une requête HTTP concerne - un programme CGI ou SSI que l'administrateur - a décidé de faire s'exécuter - sous un utilisateur autre que celui du serveur principal. - Lorsqu'il reçoit une telle requête, Apache httpd fournit au conteneur - suEXEC le nom du programme, ainsi que les identifiants utilisateur - et groupe sous lesquels le programme doit s'exécuter.

    - -

    Le conteneur effectue ensuite les vérifications suivantes afin - de déterminer la réussite ou l'échec du processus -- si une seule - de ces conditions n'est pas vérifiée, le programme journalise - l'erreur et se termine en retournant un code d'erreur, sinon il - continue :

    - -
      -
    1. - L'utilisateur qui exécute le conteneur est-il un - utilisateur valide de ce système ? - -

      - Ceci permet de s'assurer que l'utilisateur qui exécute le - conteneur est vraiment un utilisateur appartenant au système. -

      -
      2. - -
    2. - Le conteneur a-t-il été appelé avec un nombre - d'arguments correct ? - -

      - Le conteneur ne s'exécutera que si on lui fournit un nombre - d'arguments correct. Le serveur HTTP apache sait quel est le - bon format des arguments. Si le conteneur ne reçoit pas un - nombre d'arguments correct, soit il a été modifié, - soit quelque chose ne va pas dans la portion suEXEC de - votre binaire Apache httpd. -

      -
      3. - -
    3. - Cet utilisateur valide est-il autorisé à exécuter le - conteneur ? - -

      - Cet utilisateur est-il celui autorisé à exécuter le - conteneur ? Un seul utilisateur (celui d'Apache) est - autorisé à exécuter ce programme. -

      -
      4. - -
    4. - Le chemin du programme CGI ou SSI cible est-il - non sûr ? - -

      - Le chemin du programme CGI ou SSI cible débute-t-il par un - '/' ou contient-il une référence arrière '..' ? Ceci est - interdit ; le programme CGI ou SSI cible doit se trouver dans - la hiérarchie de la racine des documents de suEXEC (voir - --with-suexec-docroot=DIR ci-dessous). -

      -
      5. - -
    5. - Le nom utilisateur cible est-il valide ? - -

      - L'utilisateur cible existe-t-il ? -

      -
      6. - -
    6. - Le nom du groupe cible est-il valide ? - -

      - Le groupe cible existe-t-il ? -

      -
      7. - -
    7. - L'utilisateur cible n'est-il PAS - superutilisateur ? - - -

      - suEXEc ne permet pas à - root d'exécuter des programmes CGI/SSI. -

      -
      8. - -
    8. - Le numéro de l'identifiant de l'utilisateur cible - est-il SUPERIEUR au numéro d'identifiant - minimum ? - -

      - Le numéro d'identifiant utilisateur minimum est défini à - l'exécution du script configure. Ceci vous permet de définir - le numéro d'identifiant utilisateur le plus bas qui sera - autorisé à éxécuter des programmes CGI/SSI. En particulier, - cela permet d'écarter les comptes système. -

      -
      9. - -
    9. - Le groupe cible n'est-il PAS le groupe - superutilisateur ? - -

      - Actuellement, suEXEC ne permet pas au groupe - root d'exécuter des programmes CGI/SSI. -

      -
      10. - -
    10. - Le numéro d'identifiant du groupe cible est-il - SUPERIEUR au numéro d'identifiant minimum ? - -

      - Le numéro d'identifiant de groupe minimum est spécifié lors - de l'exécution du script configure. Ceci vous permet de - définir l'identifiant de groupe le plus bas possible qui sera - autorisé à exécuter des programmes CGI/SSI, et est - particulièrement utile pour écarter les groupes "système". -

      -
      11. - -
    11. - Le conteneur peut-il obtenir avec succès l'identité - des utilisateur et groupe cibles ? - -

      - C'est ici que le programme obtient l'identité des utilisateur - et groupe cibles via des appels à setuid et setgid. De même, - la liste des accès groupe est initialisée avec tous les - groupes auxquels l'utilisateur cible appartient. -

      -
      12. - -
    12. - Peut-on se positionner dans le répertoire dans dequel - sont situés les programmes CGI/SSI ? - -

      - S'il n'existe pas, il ne peut pas contenir de fichier. Et si - l'on ne peut pas s'y positionner, il n'existe probablement - pas. -

      -
      13. - -
    13. - Le répertoire est-il dans l'espace web - de httpd ? - -

      - Si la requête concerne une portion de la racine du serveur, - le répertoire demandé est-il dans la hiérarchie de la racine - des documents de suEXEC ? Si la requête concerne un - UserDir, le répertoire demandé est-il dans - la hiérarchie du répertoire défini comme le répertoire - utilisateur de suEXEC (voir les - options de configuration de suEXEC) ? -

      -
      14. - -
    14. - L'écriture dans le répertoire est-elle interdite pour - un utilisateur autre que le propriétaire - -

      - Le répertoire ne doit pas être ouvert aux autres - utilisateurs ; seul l'utilisateur propriétaire doit pouvoir - modifier le contenu du répertoire. -

      -
      15. - -
    15. - Le programme CGI/SSI cible existe-t-il ? - -

      - S'il n'existe pas, il ne peut pas être exécuté. -

      -
      16. - -
    16. - Les utilisateurs autres que le propriétaire n'ont-ils - PAS de droits en écriture sur le programme - CGI/SSI ? - -

      - Les utilisateurs autres que le propriétaire ne doivent pas - pouvoir modifier le programme CGI/SSI. -

      -
      17. - -
    17. - Le programme CGI/SSI n'est-il PAS setuid ou - setgid ? - -

      - Les programmes cibles ne doivent pas pouvoir modifier à - nouveau les identifiants utilisateur/groupe. -

      -
      18. - -
    18. - Le couple utilisateur/groupe cible est-il le même que - celui du programme ? - -

      - L'utilisateur est-il le propriétaire du fichier ? -

      -
      19. - -
    19. - Peut-on nettoyer avec succès l'environnement des - processus afin de garantir la sûreté des opérations ? - -

      - suExec nettoie l'environnement des processus en établissant - un chemin d'exécution sûr (défini lors de la configuration), - et en ne passant que les variables dont les noms font partie - de la liste de l'environnement sûr (créée de même lors de la - configuration). -

      -
      20. - -
    20. - Le conteneur peut-il avec succès se substituer au - programme CGI/SSI cible et s'exécuter ? - -

      - C'est là où l'exécution de suEXEC s'arrête et où commence - celle du programme CGI/ssi cible. -

      -
      21. -
    - -

    Ce sont les opérations standards effectuées par le modèle de - sécurité du conteneur suEXEC. Il peut paraître strict et est - susceptible d'imposer de nouvelles limitations et orientations - dans la conception des programmes CGI/SSI, mais il a été développé - avec le plus grand soin, étape par étape, en se focalisant sur - la sécurité.

    - -

    Pour plus d'informations sur la mesure dans laquelle ce modèle - de sécurité peut limiter vos possibilités au regard de la - configuration du serveur, ainsi que les risques de sécurité qui - peuvent être évités grâce à une configuration appropriée de suEXEC, - se référer à la section "Avis à la population !" de ce document.

    -
    top
    -
    -

    Configurer et installer suEXEC

    - -

    C'est ici que nous entrons dans le vif du sujet.

    - -

    Options de configuration de suEXEC
    -

    - -
    -
    --enable-suexec
    - -
    Cette option active la fonctionnalité suEXEC qui n'est - jamais installée ou activée par défaut. Au moins une option - --with-suexec-xxxxx doit accompagner l'option - --enable-suexec pour qu'APACI (l'utilitaire de - configuration de la compilation d'Apache) accepte votre demande - d'utilisation de la fonctionnalité suEXEC.
    - -
    --enable-suexec-capabilities
    - -
    Spécifique à Linux : Normalement, le binaire - suexec est installé en mode "setuid/setgid root", ce - qui lui permet de s'exécuter avec la totalité des privilèges de - l'utilisateur root. Avec cette option, le binaire - suexec sera installé avec seulement les bits - setuid/setgid "capability" définis, ce qui constitue un - sous-ensemble des privilèges de root pour les opérations de - suexec. Notez que dans ce mode, le binaire suexec ne - sera pas en mesure d'écrire dans un fichier journal ; il est donc - recommandé dans ce mode d'utiliser les options - --with-suexec-syslog --without-suexec-logfile, afin - d'utiliser la jounalisation syslog.
    - -
    --with-suexec-bin=PATH
    - -
    Le chemin du binaire suexec doit être codé en - dur dans le serveur pour des raisons de sécurité. Cette option - vous permet de modifier le chemin par défaut. - Par exemple - --with-suexec-bin=/usr/sbin/suexec
    - -
    --with-suexec-caller=UID
    - -
    L'utilisateur sous - lequel httpd s'exécute habituellement. C'est le seul utilisateur - autorisé à exécuter le wrapper suEXEC.
    - -
    --with-suexec-userdir=DIR
    - -
    Cette option définit le sous-répertoire de la hiérarchie des - répertoires utilisateurs dans lequel l'utilisation - de suEXEC sera autorisée. Tous les exécutables situés dans ce - répertoire seront exécutables par suEXEC sous l'utilisateur - cible ; ces programmes doivent donc être sûrs. Si vous utilisez - une directive UserDir - "simple" (c'est à dire ne contenant pas de - "*"), l'option --with-suexec-userdir - devra contenir la même valeur. SuEXEC ne fonctionnera pas - correctement si la directive UserDir contient une valeur - différente du répertoire home de l'utilisateur tel qu'il est - défini dans le fichier passwd. la valeur par défaut - est "public_html".
    - Si vous avez plusieurs hôtes virtuels avec une directive - UserDir différente - pour chacun d'entre eux, vous devrez faire en sorte que chaque - UserDir possède un répertoire parent commun ; donnez alors à - l'option --with-suexec-userdir le nom - de ce répertoire commun. Si tout ceci n'est pas défini - correctement, les requêtes CGI "~userdir" ne fonctionneront - pas !
    - -
    --with-suexec-docroot=DIR
    - -
    Cette option fonctionne comme la directive DocumentRoot pour - httpd. Il s'agit de la seule hiérarchie (en dehors des directives - UserDir) dans laquelle la fonctionnalité suEXEC - pourra être utilisée. La valeur par défaut est la valeur de - --datadir accompagnée du suffixe - "/htdocs" ; - Par exemple, si vous exécutez configure avec - "--datadir=/home/apache", la valeur - "/home/apache/htdocs" sera utilisée par défaut comme - racine des documents pour le conteneur suEXEC.
    - -
    --with-suexec-uidmin=UID
    - -
    Cette option définit l'identifiant utilisateur le plus bas - avec lequel un utilisateur pourra être la cible de - suEXEC. 500 ou 100 sont des valeurs courantes sur la plupart des - systèmes. la valeur par défaut est 100.
    - -
    --with-suexec-gidmin=GID
    - -
    Cette option définit l'identifiant de groupe le plus bas - avec lequel un utilisateur pourra être la cible de - suEXEC. 100 est une valeur courante sur la plupart des - systèmes et est par conséquent la valeur par défaut.
    - -
    --with-suexec-logfile=FILE
    - -
    Cette option permet de définir le fichier dans lequel - toutes les transactions et erreurs de suEXEC seront journalisées - (à des fins d'analyse ou de débogage). Par défaut, le fichier - journal se nomme "suexec_log" et se trouve dans votre - répertoire standard des fichiers journaux défini par - --logfiledir
    - -
    --with-suexec-syslog
    - -
    Avec cette option, suexec enregistrera les messages d'erreurs - et d'informations dans le journal syslog. Cette option doit être - utilisée conjointement avec l'option - --without-suexec-logfile.
    - -
    --with-suexec-safepath=PATH
    - -
    Cette option permet de définir une variable d'environnement - PATH sûre à passer aux exécutables CGI. La valeur par défaut - est "/usr/local/bin:/usr/bin:/bin".
    -
    - -

    Compilation et installation du conteneur suEXEC

    - - -

    Si vous avez activé la fonctionnalité suEXEC à l'aide de - l'option --enable-suexec, le binaire - suexec sera automatiquement construit (en même temps - que httpd) lorsque vous exécuterez la commande - make.

    - -

    Lorsque tous les composants auront été construits, vous pourrez - exécuter la commande make install afin de les - installer. Le binaire suexec sera installé dans le - répertoire défini à l'aide de l'option --sbindir. La - localisation par défaut est "/usr/local/apache2/bin/suexec".

    -

    Veuillez noter que vous aurez besoin des - privilèges root pour passer l'étape de - l'installation. Pour que le conteneur puisse changer - l'identifiant utilisateur, il doit avoir comme propriétaire - root, et les droits du fichier doivent - inclure le bit d'exécution setuserid.

    - - -

    >Mise en place de permissions pour - paranoïaque

    - -

    Bien que le conteneur suEXEC vérifie que l'utilisateur qui - l'appelle correspond bien à l'utilisateur spécifié à l'aide de - l'option --with-suexec-caller du programme - configure, il subsiste toujours le risque qu'un - appel système ou une bibliothèque fasse appel à suEXEC avant que - cette vérification ne soit exploitable sur votre système. Pour - tenir compte de ceci, et parce que c'est en général la meilleure - pratique, vous devez utiliser les permissions du système de - fichiers afin de vous assurer que seul le groupe sous lequel - s'exécute httpd puisse faire appel à suEXEC.

    - -

    Si, par exemple, votre serveur web est configuré pour - s'exécuter en tant que :

    - -
    User www
-Group webgroup
    - - -

    et suexec se trouve à - "/usr/local/apache2/bin/suexec", vous devez exécuter les - commandes

    - -

    - chgrp webgroup /usr/local/apache2/bin/suexec
    - chmod 4750 /usr/local/apache2/bin/suexec
    -

    - -

    Ceci permet de s'assurer que seul le groupe sous lequel httpd - s'exécute (ici webgroup) puisse faire appel au conteneur - suEXEC.

    - -
    top
    -
    -

    Activation et désactivation -de suEXEC

    - -

    Au démarrage, httpd vérifie la présence du fichier - suexec dans le répertoire défini par - l'option --sbindir du script configure (le - répertoire par défaut est "/usr/local/apache/sbin/suexec"). Si - httpd trouve un conteneur suEXEC correctement configuré, il - enregistrera le message suivant dans le journal des erreurs :

    - -

    - [notice] suEXEC mechanism enabled (wrapper: /path/to/suexec) -

    - -

    Si ce message n'est pas généré au démarrage du serveur, ce - dernier ne trouve probablement pas le programme conteneur à - l'endroit où il est sensé être, ou l'exécutable suexec n'est pas - installé en setuid root.

    - -

    Si le serveur HTTP Apache est déjà en cours d'exécution, et si - vous activez le mécanisme suEXEC pour la première fois, vous - devez arrêter et redémarrer httpd. Un redémarrage - à l'aide d'un simple signal HUP ou USR1 suffira.

    -

    Pour désactiver suEXEC, vous devez supprimer le fichier - suexec, puis arrêter et redémarrer - httpd.

    -
    top
    -
    -

    Utilisation de suEXEC

    - -

    Les requêtes pour des programmes CGI ne feront appel au - conteneur suEXEC que si elles concernent un hôte virtuel - contenant une directive SuexecUserGroup, ou si elles sont - traitées par mod_userdir.

    - -

    Hôtes virtuels :
    Une des méthodes - d'utilisation du conteneur suEXEC consiste à insérer une - directive SuexecUserGroup dans une section - VirtualHost. En définissant - des valeurs différentes de celles du serveur principal, toutes les - requêtes pour des ressources CGI seront exécutées sous - les User et Group définis pour cette section - <VirtualHost>. Si cette - directive est absente de la section <VirtualHost>, l'utilisateur du - serveur principal sera pris par défaut

    - -

    Répertoires des utilisateurs :
    Avec - cette méthode, les - requêtes traitées par mod_userdir appelleront le - conteneur suEXEC pour exécuter le programme CGI sous l'identifiant - utilisateur du répertoire utilisateur concerné. Seuls prérequis - pour pouvoir accéder à cette fonctionnalité : l'exécution des CGI - doit être activée pour l'utilisateur concerné, et le script doit - passer avec succès le test des vérifications de - sécurité décrit plus haut. Voir aussi l' - option de compilation - --with-suexec-userdir.

    top
    -
    -

    Débogage de suEXEC

    - -

    Le conteneur suEXEC va écrire ses informations de journalisation - dans le fichier défini par l'option de compilation - --with-suexec-logfile comme indiqué plus haut, - ou vers syslog si l'option --with-suexec-syslog est - utilisée. Si vous - pensez avoir configuré et installé correctement le conteneur, - consultez ce journal, ainsi que le journal des erreurs du serveur - afin de déterminer l'endroit où vous avez fait fausse - route. Si vous utilisez une distribution binaire, la commande - "suexec -V" vous permet de déterminer quelles options - ont été utilisées pour compiler suexec.

    - -
    top
    -
    -

    Avis à la population ! - Avertissements et exemples

    - -

    NOTE ! Cette section est peut-être incomplète. - Pour en consulter la dernière révision, voir la version de la Documentation en ligne.

    - -

    Quelques points importants du conteneur peuvent - imposer des contraintes du point de vue de la configuration du - serveur. Veuillez en prendre connaissance avant de soumettre un - rapport de bogue à propos de suEXEC.

    - -
      -
    • Points importants de suEXEC
      • - -
    • - Limitations concernant la hiérarchie. - -

      - Pour des raisons de sécurité et d'efficacité, toutes les - requêtes suEXEC ne doivent concerner que des ressources - situées dans la racine des documents définie pour les - requêtes concernant un hôte virtuel, ou des ressources - situées dans la racine des documents définies pour les - requêtes concernant un répertoire utilisateur. Par exemple, - si vous avez configuré quatre hôtes virtuels, vous devrez - définir la structure des racines de documents de vos hôtes - virtuels en dehors d'une hiérarchie de documents principale - de httpd, afin de tirer parti de suEXEC dans le contexte des - hôtes virtuels (Exemple à venir). -

      -
      • - -
    • - La variable d'environnement PATH de suEXEC - -

      - Modifier cette variable peut s'avérer dangereux. Assurez-vous - que tout chemin que vous ajoutez à cette variable est un - répertoire de confiance. Vous n'avez - probablement pas l'intention d'ouvrir votre serveur de façon - à ce que l'on puisse y exécuter un cheval de Troie. -

      -
      • - -
    • - Modification de suEXEC - -

      - Encore une fois, ceci peut vous causer de - graves ennuis si vous vous y essayez sans - savoir ce que vous faites. Evitez de vous y risquer dans la - mesure du possible. -

      -
      • -
    - -
    -
    -

    Langues Disponibles:  en  | - fr  | - ja  | - ko  | - tr 

    -
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    -
    - \ No newline at end of file diff --git a/docs/manual/suexec.html.fr.utf8 b/docs/manual/suexec.html.fr.utf8 new file mode 100644 index 0000000000..049dfa172f --- /dev/null +++ b/docs/manual/suexec.html.fr.utf8 @@ -0,0 +1,716 @@ + + + + + +Support suEXEC - Serveur HTTP Apache Version 2.5 + + + + + + +
    +

    Modules | Directives | FAQ | Glossaire | Plan du site

    +

    Serveur HTTP Apache Version 2.5

    +
    +
    <-
    +

    Support suEXEC

    +
    +

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

    +
    + +

    La fonctionnalité suEXEC permet + l'exécution des programmes CGI et + SSI sous un utilisateur autre que celui sous + lequel s'exécute le serveur web qui appelle ces programmes. + Normalement, lorsqu'un programme CGI ou SSI est lancé, il + s'exécute sous le même utilisateur que celui du serveur web qui + l'appelle.

    + +

    Utilisée de manière appropriée, cette fonctionnalité peut + réduire considérablement les risques de sécurité encourus + lorsqu'on autorise les utilisateurs à développer et faire + s'exécuter des programmes CGI ou SSI de leur cru. Cependant, mal + configuré, suEXEC peut causer de nombreux problèmes et même créer + de nouvelles failles dans la sécurité de votre ordinateur. Si + vous n'êtes pas familier avec la gestion des programmes + setuid root et les risques de sécurité qu'ils comportent, + nous vous recommandons vivement de ne pas tenter + d'utiliser suEXEC.

    +
    + +
    top
    +
    +

    Avant de commencer

    + +

    Avant de foncer tête baissée dans la lecture de ce document, + vous devez tenir compte de certaines hypothèses concernant vous-même + et l'environnement dans lequel vous allez utiliser suexec.

    + +

    Premièrement, vous devez utiliser un système d'exploitation + UNIX ou dérivé, capable d'effectuer des opérations + setuid et setgid. Tous les + exemples de commande sont donnés en conséquence. D'autres + plates-formes, même si elles supportent suEXEC, peuvent + avoir une configuration différente.

    + +

    Deuxièmement, vous devez être familier avec les concepts de base + relatifs à la sécurité de votre ordinateur et son administration. + Ceci implique la compréhension des opérations + setuid/setgid et des différents effets qu'elles + peuvent produire sur votre système et son niveau de sécurité.

    + +

    Troisièmement, vous devez utiliser une version + non modifiée du code de suEXEC. L'ensemble du + code de suEXEC a été scruté et testé avec soin par les développeurs + et de nombreux bêta testeurs. Toutes les précautions ont été prises + pour s'assurer d'une base sûre de code non seulement simple, mais + aussi solide. La modification de ce code peut causer des problèmes + inattendus et de nouveaux risques de sécurité. Il est + vivement recommandé de ne pas modifier le code de + suEXEC, à moins que vous ne soyez un programmeur spécialiste des + particularités liées à la sécurité, et souhaitez partager votre + travail avec l'équipe de développement du serveur HTTP Apache afin + de pouvoir en discuter.

    + +

    Quatrièmement et dernièrement, l'équipe de développement du + serveur HTTP Apache a décidé de ne + PAS inclure suEXEC dans l'installation par défaut + d'Apache httpd. Pour pouvoir mettre en oeuvre suEXEC, l'administrateur + doit porter la plus grande attention aux détails. Après avoir bien + réfléchi aux différents points de la configuration de suEXEC, + l'administrateur peut l'installer selon les méthodes classiques. + Les valeurs des paramètres de configuration doivent être + déterminées et spécifiées avec soin par l'administrateur, afin de + maintenir la sécurité du système de manière appropriée lors de + l'utilisation de la fonctionnalité suEXEC. C'est par le biais de + ce processus minutieux que nous espérons réserver + l'installation de suEXEC aux administrateurs prudents et + suffisamment déterminés à vouloir l'utiliser.

    + +

    Vous êtes encore avec nous ? Oui ? Bien. + Alors nous pouvons continuer !

    +
    top
    +
    +

    Modèle de sécurité de suEXEC

    + +

    Avant d'installer et configurer suEXEC, nous allons tout d'abord + décrire le modèle de sécurité que vous êtes sur le point + d'implémenter. Vous devriez ainsi mieux comprendre ce qui se passe + vraiment à l'intérieur de suEXEC et quelles précautions ont été + prises pour préserver la sécurité de votre système.

    + +

    suEXEC est basé sur un programme "conteneur" + (wrapper) setuid qui est appelé par le serveur HTTP Apache principal. + Ce conteneur est appelé quand une requête HTTP concerne + un programme CGI ou SSI que l'administrateur + a décidé de faire s'exécuter + sous un utilisateur autre que celui du serveur principal. + Lorsqu'il reçoit une telle requête, Apache httpd fournit au conteneur + suEXEC le nom du programme, ainsi que les identifiants utilisateur + et groupe sous lesquels le programme doit s'exécuter.

    + +

    Le conteneur effectue ensuite les vérifications suivantes afin + de déterminer la réussite ou l'échec du processus -- si une seule + de ces conditions n'est pas vérifiée, le programme journalise + l'erreur et se termine en retournant un code d'erreur, sinon il + continue :

    + +
      +
    1. + L'utilisateur qui exécute le conteneur est-il un + utilisateur valide de ce système ? + +

      + Ceci permet de s'assurer que l'utilisateur qui exécute le + conteneur est vraiment un utilisateur appartenant au système. +

      +
      2. + +
    2. + Le conteneur a-t-il été appelé avec un nombre + d'arguments correct ? + +

      + Le conteneur ne s'exécutera que si on lui fournit un nombre + d'arguments correct. Le serveur HTTP apache sait quel est le + bon format des arguments. Si le conteneur ne reçoit pas un + nombre d'arguments correct, soit il a été modifié, + soit quelque chose ne va pas dans la portion suEXEC de + votre binaire Apache httpd. +

      +
      3. + +
    3. + Cet utilisateur valide est-il autorisé à exécuter le + conteneur ? + +

      + Cet utilisateur est-il celui autorisé à exécuter le + conteneur ? Un seul utilisateur (celui d'Apache) est + autorisé à exécuter ce programme. +

      +
      4. + +
    4. + Le chemin du programme CGI ou SSI cible est-il + non sûr ? + +

      + Le chemin du programme CGI ou SSI cible débute-t-il par un + '/' ou contient-il une référence arrière '..' ? Ceci est + interdit ; le programme CGI ou SSI cible doit se trouver dans + la hiérarchie de la racine des documents de suEXEC (voir + --with-suexec-docroot=DIR ci-dessous). +

      +
      5. + +
    5. + Le nom utilisateur cible est-il valide ? + +

      + L'utilisateur cible existe-t-il ? +

      +
      6. + +
    6. + Le nom du groupe cible est-il valide ? + +

      + Le groupe cible existe-t-il ? +

      +
      7. + +
    7. + L'utilisateur cible n'est-il PAS + superutilisateur ? + + +

      + suEXEc ne permet pas à + root d'exécuter des programmes CGI/SSI. +

      +
      8. + +
    8. + Le numéro de l'identifiant de l'utilisateur cible + est-il SUPERIEUR au numéro d'identifiant + minimum ? + +

      + Le numéro d'identifiant utilisateur minimum est défini à + l'exécution du script configure. Ceci vous permet de définir + le numéro d'identifiant utilisateur le plus bas qui sera + autorisé à éxécuter des programmes CGI/SSI. En particulier, + cela permet d'écarter les comptes système. +

      +
      9. + +
    9. + Le groupe cible n'est-il PAS le groupe + superutilisateur ? + +

      + Actuellement, suEXEC ne permet pas au groupe + root d'exécuter des programmes CGI/SSI. +

      +
      10. + +
    10. + Le numéro d'identifiant du groupe cible est-il + SUPERIEUR au numéro d'identifiant minimum ? + +

      + Le numéro d'identifiant de groupe minimum est spécifié lors + de l'exécution du script configure. Ceci vous permet de + définir l'identifiant de groupe le plus bas possible qui sera + autorisé à exécuter des programmes CGI/SSI, et est + particulièrement utile pour écarter les groupes "système". +

      +
      11. + +
    11. + Le conteneur peut-il obtenir avec succès l'identité + des utilisateur et groupe cibles ? + +

      + C'est ici que le programme obtient l'identité des utilisateur + et groupe cibles via des appels à setuid et setgid. De même, + la liste des accès groupe est initialisée avec tous les + groupes auxquels l'utilisateur cible appartient. +

      +
      12. + +
    12. + Peut-on se positionner dans le répertoire dans dequel + sont situés les programmes CGI/SSI ? + +

      + S'il n'existe pas, il ne peut pas contenir de fichier. Et si + l'on ne peut pas s'y positionner, il n'existe probablement + pas. +

      +
      13. + +
    13. + Le répertoire est-il dans l'espace web + de httpd ? + +

      + Si la requête concerne une portion de la racine du serveur, + le répertoire demandé est-il dans la hiérarchie de la racine + des documents de suEXEC ? Si la requête concerne un + UserDir, le répertoire demandé est-il dans + la hiérarchie du répertoire défini comme le répertoire + utilisateur de suEXEC (voir les + options de configuration de suEXEC) ? +

      +
      14. + +
    14. + L'écriture dans le répertoire est-elle interdite pour + un utilisateur autre que le propriétaire + +

      + Le répertoire ne doit pas être ouvert aux autres + utilisateurs ; seul l'utilisateur propriétaire doit pouvoir + modifier le contenu du répertoire. +

      +
      15. + +
    15. + Le programme CGI/SSI cible existe-t-il ? + +

      + S'il n'existe pas, il ne peut pas être exécuté. +

      +
      16. + +
    16. + Les utilisateurs autres que le propriétaire n'ont-ils + PAS de droits en écriture sur le programme + CGI/SSI ? + +

      + Les utilisateurs autres que le propriétaire ne doivent pas + pouvoir modifier le programme CGI/SSI. +

      +
      17. + +
    17. + Le programme CGI/SSI n'est-il PAS setuid ou + setgid ? + +

      + Les programmes cibles ne doivent pas pouvoir modifier à + nouveau les identifiants utilisateur/groupe. +

      +
      18. + +
    18. + Le couple utilisateur/groupe cible est-il le même que + celui du programme ? + +

      + L'utilisateur est-il le propriétaire du fichier ? +

      +
      19. + +
    19. + Peut-on nettoyer avec succès l'environnement des + processus afin de garantir la sûreté des opérations ? + +

      + suExec nettoie l'environnement des processus en établissant + un chemin d'exécution sûr (défini lors de la configuration), + et en ne passant que les variables dont les noms font partie + de la liste de l'environnement sûr (créée de même lors de la + configuration). +

      +
      20. + +
    20. + Le conteneur peut-il avec succès se substituer au + programme CGI/SSI cible et s'exécuter ? + +

      + C'est là où l'exécution de suEXEC s'arrête et où commence + celle du programme CGI/ssi cible. +

      +
      21. +
    + +

    Ce sont les opérations standards effectuées par le modèle de + sécurité du conteneur suEXEC. Il peut paraître strict et est + susceptible d'imposer de nouvelles limitations et orientations + dans la conception des programmes CGI/SSI, mais il a été développé + avec le plus grand soin, étape par étape, en se focalisant sur + la sécurité.

    + +

    Pour plus d'informations sur la mesure dans laquelle ce modèle + de sécurité peut limiter vos possibilités au regard de la + configuration du serveur, ainsi que les risques de sécurité qui + peuvent être évités grâce à une configuration appropriée de suEXEC, + se référer à la section "Avis à la population !" de ce document.

    +
    top
    +
    +

    Configurer et installer suEXEC

    + +

    C'est ici que nous entrons dans le vif du sujet.

    + +

    Options de configuration de suEXEC
    +

    + +
    +
    --enable-suexec
    + +
    Cette option active la fonctionnalité suEXEC qui n'est + jamais installée ou activée par défaut. Au moins une option + --with-suexec-xxxxx doit accompagner l'option + --enable-suexec pour qu'APACI (l'utilitaire de + configuration de la compilation d'Apache) accepte votre demande + d'utilisation de la fonctionnalité suEXEC.
    + +
    --enable-suexec-capabilities
    + +
    Spécifique à Linux : Normalement, le binaire + suexec est installé en mode "setuid/setgid root", ce + qui lui permet de s'exécuter avec la totalité des privilèges de + l'utilisateur root. Avec cette option, le binaire + suexec sera installé avec seulement les bits + setuid/setgid "capability" définis, ce qui constitue un + sous-ensemble des privilèges de root pour les opérations de + suexec. Notez que dans ce mode, le binaire suexec ne + sera pas en mesure d'écrire dans un fichier journal ; il est donc + recommandé dans ce mode d'utiliser les options + --with-suexec-syslog --without-suexec-logfile, afin + d'utiliser la jounalisation syslog.
    + +
    --with-suexec-bin=PATH
    + +
    Le chemin du binaire suexec doit être codé en + dur dans le serveur pour des raisons de sécurité. Cette option + vous permet de modifier le chemin par défaut. + Par exemple + --with-suexec-bin=/usr/sbin/suexec
    + +
    --with-suexec-caller=UID
    + +
    L'utilisateur sous + lequel httpd s'exécute habituellement. C'est le seul utilisateur + autorisé à exécuter le wrapper suEXEC.
    + +
    --with-suexec-userdir=DIR
    + +
    Cette option définit le sous-répertoire de la hiérarchie des + répertoires utilisateurs dans lequel l'utilisation + de suEXEC sera autorisée. Tous les exécutables situés dans ce + répertoire seront exécutables par suEXEC sous l'utilisateur + cible ; ces programmes doivent donc être sûrs. Si vous utilisez + une directive UserDir + "simple" (c'est à dire ne contenant pas de + "*"), l'option --with-suexec-userdir + devra contenir la même valeur. SuEXEC ne fonctionnera pas + correctement si la directive UserDir contient une valeur + différente du répertoire home de l'utilisateur tel qu'il est + défini dans le fichier passwd. la valeur par défaut + est "public_html".
    + Si vous avez plusieurs hôtes virtuels avec une directive + UserDir différente + pour chacun d'entre eux, vous devrez faire en sorte que chaque + UserDir possède un répertoire parent commun ; donnez alors à + l'option --with-suexec-userdir le nom + de ce répertoire commun. Si tout ceci n'est pas défini + correctement, les requêtes CGI "~userdir" ne fonctionneront + pas !
    + +
    --with-suexec-docroot=DIR
    + +
    Cette option fonctionne comme la directive DocumentRoot pour + httpd. Il s'agit de la seule hiérarchie (en dehors des directives + UserDir) dans laquelle la fonctionnalité suEXEC + pourra être utilisée. La valeur par défaut est la valeur de + --datadir accompagnée du suffixe + "/htdocs" ; + Par exemple, si vous exécutez configure avec + "--datadir=/home/apache", la valeur + "/home/apache/htdocs" sera utilisée par défaut comme + racine des documents pour le conteneur suEXEC.
    + +
    --with-suexec-uidmin=UID
    + +
    Cette option définit l'identifiant utilisateur le plus bas + avec lequel un utilisateur pourra être la cible de + suEXEC. 500 ou 100 sont des valeurs courantes sur la plupart des + systèmes. la valeur par défaut est 100.
    + +
    --with-suexec-gidmin=GID
    + +
    Cette option définit l'identifiant de groupe le plus bas + avec lequel un utilisateur pourra être la cible de + suEXEC. 100 est une valeur courante sur la plupart des + systèmes et est par conséquent la valeur par défaut.
    + +
    --with-suexec-logfile=FILE
    + +
    Cette option permet de définir le fichier dans lequel + toutes les transactions et erreurs de suEXEC seront journalisées + (à des fins d'analyse ou de débogage). Par défaut, le fichier + journal se nomme "suexec_log" et se trouve dans votre + répertoire standard des fichiers journaux défini par + --logfiledir
    + +
    --with-suexec-syslog
    + +
    Avec cette option, suexec enregistrera les messages d'erreurs + et d'informations dans le journal syslog. Cette option doit être + utilisée conjointement avec l'option + --without-suexec-logfile.
    + +
    --with-suexec-safepath=PATH
    + +
    Cette option permet de définir une variable d'environnement + PATH sûre à passer aux exécutables CGI. La valeur par défaut + est "/usr/local/bin:/usr/bin:/bin".
    +
    + +

    Compilation et installation du conteneur suEXEC

    + + +

    Si vous avez activé la fonctionnalité suEXEC à l'aide de + l'option --enable-suexec, le binaire + suexec sera automatiquement construit (en même temps + que httpd) lorsque vous exécuterez la commande + make.

    + +

    Lorsque tous les composants auront été construits, vous pourrez + exécuter la commande make install afin de les + installer. Le binaire suexec sera installé dans le + répertoire défini à l'aide de l'option --sbindir. La + localisation par défaut est "/usr/local/apache2/bin/suexec".

    +

    Veuillez noter que vous aurez besoin des + privilèges root pour passer l'étape de + l'installation. Pour que le conteneur puisse changer + l'identifiant utilisateur, il doit avoir comme propriétaire + root, et les droits du fichier doivent + inclure le bit d'exécution setuserid.

    + + +

    >Mise en place de permissions pour + paranoïaque

    + +

    Bien que le conteneur suEXEC vérifie que l'utilisateur qui + l'appelle correspond bien à l'utilisateur spécifié à l'aide de + l'option --with-suexec-caller du programme + configure, il subsiste toujours le risque qu'un + appel système ou une bibliothèque fasse appel à suEXEC avant que + cette vérification ne soit exploitable sur votre système. Pour + tenir compte de ceci, et parce que c'est en général la meilleure + pratique, vous devez utiliser les permissions du système de + fichiers afin de vous assurer que seul le groupe sous lequel + s'exécute httpd puisse faire appel à suEXEC.

    + +

    Si, par exemple, votre serveur web est configuré pour + s'exécuter en tant que :

    + +
    User www
+Group webgroup
    + + +

    et suexec se trouve à + "/usr/local/apache2/bin/suexec", vous devez exécuter les + commandes

    + +

    + chgrp webgroup /usr/local/apache2/bin/suexec
    + chmod 4750 /usr/local/apache2/bin/suexec
    +

    + +

    Ceci permet de s'assurer que seul le groupe sous lequel httpd + s'exécute (ici webgroup) puisse faire appel au conteneur + suEXEC.

    + +
    top
    +
    +

    Activation et désactivation +de suEXEC

    + +

    Au démarrage, httpd vérifie la présence du fichier + suexec dans le répertoire défini par + l'option --sbindir du script configure (le + répertoire par défaut est "/usr/local/apache/sbin/suexec"). Si + httpd trouve un conteneur suEXEC correctement configuré, il + enregistrera le message suivant dans le journal des erreurs :

    + +

    + [notice] suEXEC mechanism enabled (wrapper: /path/to/suexec) +

    + +

    Si ce message n'est pas généré au démarrage du serveur, ce + dernier ne trouve probablement pas le programme conteneur à + l'endroit où il est sensé être, ou l'exécutable suexec n'est pas + installé en setuid root.

    + +

    Si le serveur HTTP Apache est déjà en cours d'exécution, et si + vous activez le mécanisme suEXEC pour la première fois, vous + devez arrêter et redémarrer httpd. Un redémarrage + à l'aide d'un simple signal HUP ou USR1 suffira.

    +

    Pour désactiver suEXEC, vous devez supprimer le fichier + suexec, puis arrêter et redémarrer + httpd.

    +
    top
    +
    +

    Utilisation de suEXEC

    + +

    Les requêtes pour des programmes CGI ne feront appel au + conteneur suEXEC que si elles concernent un hôte virtuel + contenant une directive SuexecUserGroup, ou si elles sont + traitées par mod_userdir.

    + +

    Hôtes virtuels :
    Une des méthodes + d'utilisation du conteneur suEXEC consiste à insérer une + directive SuexecUserGroup dans une section + VirtualHost. En définissant + des valeurs différentes de celles du serveur principal, toutes les + requêtes pour des ressources CGI seront exécutées sous + les User et Group définis pour cette section + <VirtualHost>. Si cette + directive est absente de la section <VirtualHost>, l'utilisateur du + serveur principal sera pris par défaut

    + +

    Répertoires des utilisateurs :
    Avec + cette méthode, les + requêtes traitées par mod_userdir appelleront le + conteneur suEXEC pour exécuter le programme CGI sous l'identifiant + utilisateur du répertoire utilisateur concerné. Seuls prérequis + pour pouvoir accéder à cette fonctionnalité : l'exécution des CGI + doit être activée pour l'utilisateur concerné, et le script doit + passer avec succès le test des vérifications de + sécurité décrit plus haut. Voir aussi l' + option de compilation + --with-suexec-userdir.

    top
    +
    +

    Débogage de suEXEC

    + +

    Le conteneur suEXEC va écrire ses informations de journalisation + dans le fichier défini par l'option de compilation + --with-suexec-logfile comme indiqué plus haut, + ou vers syslog si l'option --with-suexec-syslog est + utilisée. Si vous + pensez avoir configuré et installé correctement le conteneur, + consultez ce journal, ainsi que le journal des erreurs du serveur + afin de déterminer l'endroit où vous avez fait fausse + route. Si vous utilisez une distribution binaire, la commande + "suexec -V" vous permet de déterminer quelles options + ont été utilisées pour compiler suexec.

    + +
    top
    +
    +

    Avis à la population ! + Avertissements et exemples

    + +

    NOTE ! Cette section est peut-être incomplète. + Pour en consulter la dernière révision, voir la version de la Documentation en ligne.

    + +

    Quelques points importants du conteneur peuvent + imposer des contraintes du point de vue de la configuration du + serveur. Veuillez en prendre connaissance avant de soumettre un + rapport de bogue à propos de suEXEC.

    + +
      +
    • Points importants de suEXEC
      • + +
    • + Limitations concernant la hiérarchie. + +

      + Pour des raisons de sécurité et d'efficacité, toutes les + requêtes suEXEC ne doivent concerner que des ressources + situées dans la racine des documents définie pour les + requêtes concernant un hôte virtuel, ou des ressources + situées dans la racine des documents définies pour les + requêtes concernant un répertoire utilisateur. Par exemple, + si vous avez configuré quatre hôtes virtuels, vous devrez + définir la structure des racines de documents de vos hôtes + virtuels en dehors d'une hiérarchie de documents principale + de httpd, afin de tirer parti de suEXEC dans le contexte des + hôtes virtuels (Exemple à venir). +

      +
      • + +
    • + La variable d'environnement PATH de suEXEC + +

      + Modifier cette variable peut s'avérer dangereux. Assurez-vous + que tout chemin que vous ajoutez à cette variable est un + répertoire de confiance. Vous n'avez + probablement pas l'intention d'ouvrir votre serveur de façon + à ce que l'on puisse y exécuter un cheval de Troie. +

      +
      • + +
    • + Modification de suEXEC + +

      + Encore une fois, ceci peut vous causer de + graves ennuis si vous vous y essayez sans + savoir ce que vous faites. Evitez de vous y risquer dans la + mesure du possible. +

      +
      • +
    + +
    +
    +

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

    +
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    +
    + \ No newline at end of file diff --git a/docs/manual/upgrading.html.en b/docs/manual/upgrading.html.en index 3acc9e3fc9..12f7c96178 100644 --- a/docs/manual/upgrading.html.en +++ b/docs/manual/upgrading.html.en @@ -24,7 +24,7 @@ Apache > HTTP Server > Documentation > Version 2.5

    Upgrading to 2.4 from 2.2

    Available Languages:  en  | - fr 

    + fr 

    In order to assist folks upgrading, we maintain a document @@ -507,7 +507,7 @@ Require ip 127.0.0.1

    Available Languages:  en  | - fr 

    + fr 

    top

    Comments

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    - - -
    -

    Modules | Directives | FAQ | Glossaire | Plan du site

    -

    Serveur HTTP Apache Version 2.5

    -
    -
    <-
    -

    Mise à jour de la version 2.2 vers la version 2.4

    -
    -

    Langues Disponibles:  en  | - fr 

    -
    - -

    Afin d'assister les utilisateurs lors de leurs opérations de mise à - jour, nous maintenons un document - qui comporte des informations critiques à l'attention des personnes qui - utilisent déjà le serveur HTTP Apache. Ces informations - ne sont que de brèves notes, et vous - trouverez plus d'informations dans le document Nouvelles fonctionnalités, ou dans - le fichier src/CHANGES. Les développeurs d'applications - et de modules trouveront un résumé des modifications de l'API dans la - vue d'ensemble Mises à jour de - l'API.

    - -

    Ce document présente les changements de comportement du serveur qui - peuvent nécessiter une modification de la configuration, et la manière - d'utiliser la version 2.4 du serveur en parallèle avec la - version 2.2. Pour tirer parti des nouvelles fonctionnalités de la - version 2.4, reportez-vous au document "Nouvelles fonctionnalités".

    - -

    Ce document ne décrit que les modifications intervenues entre les versions - 2.2 et 2.4. Si vous effectuez une mise à jour depuis la version 2.0, vous - devez aussi consulter le - document de mise - à jour de 2.0 vers 2.2.

    - -
    - -
    top
    -
    -

    Modifications des paramètres de compilation

    - -

    Le processus de compilation est très similaire à celui de la - version 2.2. Dans la plupart des cas, vous pourrez utiliser votre - ancienne ligne de commande configure (telle qu'elle - est enregistrée dans le fichier build/config.nice - situé dans le répertoire de compilation du serveur). Voici certains - changements intervenus dans la configuration par défaut :

    - -
      -
    • Les modules suivants ont été supprimés : mod_authn_default, - mod_authz_default et mod_mem_cache. Si vous utilisiez - mod_mem_cache sous la version 2.2, vous devez maintenant utiliser - mod_cache_disk dans la version 2.4.
      • - -
    • Toutes les implémentations de répartition de charge ont été - déplacées vers des sous-modules spécifiques de mod_proxy, comme - mod_lbmethod_bybusyness. Vous devrez compiler et - chargés tous les modules correspondants que votre configuration - utilise.
      • - -
    • Le support de BeOS, TPF, et des anciennes plates-formes telles - que A/UX, Next, et Tandem a été supprimé, car - elles ne sont plus considérées comme maintenues.
      • - -
    • configure: les modules dynamiques (DSO) sont compilés par - défaut
      • - -
    • configure: par défaut, seul un jeu de modules de base est - chargé. Les autres directives LoadModule - sont mises en commentaires dans le fichier de configuration.
      • - -
    • configure: le jeu de modules "most" est compilé par défaut
      • - -
    • configure: le jeu de modules "reallyall" ajoute les modules de - développeur au jeu "all".
      • -
    - -
    top
    -
    -

    Modifications de la configuration à l'exécution

    - -

    Des changements significatifs dans la configuration de -l'autorisation, ainsi que quelques changements mineurs, peuvent -nécessiter une mise à jour des fichiers de configuration de la version -2.2 avant de les utiliser sous la version 2.4.

    - -

    Autorisation

    - - -

    Tout fichier de configuration qui gère des autorisations devra - probablement être mis à jour.

    - -

    Vous devez vous reporter au document Authentification, autorisation et contrôle - d'accès, et plus particulièrement à la section Plus loin qu'une simple - autorisation qui explique les nouveaux mécanismes permettant de - contrôler l'ordre dans lequel les directives d'autorisation sont - appliquées.

    - -

    Les directives qui contrôlent la manière dont les modules - d'autorisation réagissent lorsqu'ils ne reconnaissent pas - l'utilisateur authentifié ont été supprimées : elles comprennent les - directives AuthzLDAPAuthoritative, AuthzDBDAuthoritative, - AuthzDBMAuthoritative, AuthzGroupFileAuthoritative, - AuthzUserAuthoritative et AuthzOwnerAuthoritative. Ces directives - ont été remplacées par les directives plus explicites RequireAny, RequireNone, et RequireAll.

    - -

    Si vous utilisez mod_authz_dbm, vous devez - mettre à jour votre configuration en remplaçant les directives du - style Require group ... par des directives du style - Require dbm-group ....

    - -

    Contrôle d'accès

    - - -

    Dans la version 2.2, le contrôle d'accès basé sur le nom d'hôte - du client, son adresse IP, ou d'autres caractéristiques de la - requête était assuré via les directives Order, Allow, Deny, et Satisfy.

    - -

    Dans la version 2.4, ce contrôle d'accès est assuré, comme tout - contrôle d'autorisation, par le nouveau module - mod_authz_host. Bien que le module - mod_access_compat assure la - compatibilité avec les anciennes configurations, les anciennes - directives de contrôle d'accès devront être remplacées par les - nouveaux mécanismes d'authentification.

    - -

    Mélanger anciennes et nouvelles directives

    -

    Mélanger d'anciennes directives comme Order, Allow ou Deny avec des nouvelles comme - Require est techniquement - possible mais déconseillé. En effet, mod_access_compat a - été conçu pour supporter des configurations ne contenant que des anciennes - directives afin de faciliter le passage à la version 2.4. Les - exemples ci-dessous vous permettront de vous faire une meilleure idée des - problèmes qui peuvent survenir. -

    -
    - -

    Voici quelques exemples de contrôle d'accès avec l'ancienne et - la nouvelle méthode :

    - -

    Dans cet exemple, il n'y a pas d'authentification et toutes les - requêtes sont rejetées :

    -

    version 2.2 :

    Order deny,allow
-Deny from all
    -
    -

    version 2.4 :

    Require all denied
    -
    - -

    Dans cet exemple, il n'y a pas d'authentification et toutes les - requêtes sont acceptées :

    -

    version 2.2 :

    Order allow,deny
-Allow from all
    -
    -

    version 2.4 :

    Require all granted
    -
    - -

    Dans l'exemple suivant, il n'y a pas d'authentification et tous les - hôtes du domaine example.org - ont l'autorisation d'accès, tous les autres étant rejetés :

    - -

    version 2.2 :

    Order Deny,Allow
-Deny from all
-Allow from example.org
    -
    -

    version 2.4 :

    Require host example.org
    -
    - -

    Dans l'exemple suivant, le mélange d'anciennes et de nouvelles - directives produit des résultats inattendus.

    - -

    Mélange d'anciennes et de nouvelles directives : RESULTAT - INATTENDU

    DocumentRoot "/var/www/html"
-
-<Directory "/">
-    AllowOverride None
-    Order deny,allow
-    Deny from all
-</Directory>
-
-<Location "/server-status">
-    SetHandler server-status
-    Require local
-</Location>
-
-access.log - GET /server-status 403 127.0.0.1
-error.log - AH01797: client denied by server configuration: /var/www/html/server-status
    -
    -

    Pourquoi httpd interdit l'accès à server-status alors que la - configuration semble l'autoriser ? Parce que dans ce scénario de fusion de configuration, les - directives de mod_access_compat sont prioritaires par - rapport à celles de mod_authz_host.

    - -

    L'exemple suivant quant à lui produit un résultat conforme :

    - -

    Mélange d'anciennes et de nouvelles directives : RESULTAT - CONFORME

    DocumentRoot "/var/www/html"
-
-<Directory "/">
-    AllowOverride None
-    Require all denied
-</Directory>
-
-<Location "/server-status">
-    SetHandler server-status
-    Order deny,allow
-    Deny from all
-    Allow From 127.0.0.1
-</Location>
-
-access.log - GET /server-status 200 127.0.0.1
    -
    -

    En conclusion, même si une configuration hybride peut fonctionner, - essayez de l'éviter lors de la mise à jour : soit conservez les anciennes - directives, puis migrez-les vers les nouvelles ultérieurement, soit - effectuez une migration immédiate de toutes les anciennes directives vers - les nouvelles. -

    - - - -

    Dans de nombreuses configurations avec authentification où la directive - Satisfy était définie à sa valeur par défaut - ALL, les lignes de configuration qui désactivent le contrôle - d'accès basé sur l'hôte sont maintenant omises :

    - -

    Version 2.2 :

    # configuration en version 2.2 qui désactive le contrôle d'accès basé sur le nom
-# d'hôte pour n'utiliser que l'authentification
-Order Deny,Allow
-Allow from all
-AuthType Basic
-AuthBasicProvider file
-AuthUserFile /example.com/conf/users.passwd
-AuthName secure
-Require valid-user
    -
    -

    Version 2.4 :

    # Pas besoin de remplacer les directives Order et deny pour les désactiver
-AuthType Basic
-AuthBasicProvider file
-AuthUserFile /example.com/conf/users.passwd
-AuthName secure
-Require valid-user
    -
    - -

    Dans les configurations où l'authentification et le contrôle d'accès se - combinaient dans un but précis, les directives de contrôle d'accès doivent - être migrées. Dans l'exemple suivant, les requêtes qui correspondent aux - deux critères sont acceptées :

    -

    Version 2.2 :

    Order allow,deny
-Deny from all
-# ALL est la valeur par défaut de Satisfy
-Satisfy ALL
-Allow from 127.0.0.1
-AuthType Basic
-AuthBasicProvider file
-AuthUserFile /example.com/conf/users.passwd
-AuthName secure
-Require valid-user
    -
    -

    Version 2.4 :

    AuthType Basic
-AuthBasicProvider file
-AuthUserFile /example.com/conf/users.passwd
-AuthName secure
-<RequireAll>
-  Require valid-user
-  Require ip 127.0.0.1
-</RequireAll>
    -
    - -

    Dans les configurations où l'authentification et le contrôle d'accès se - combinaient dans un but précis, les directives de contrôle d'accès doivent - être migrées. Dans l'exemple suivant, les requêtes qui correspondent à - au moins un critère sont acceptées :

    -

    Version 2.2 :

    Order allow,deny
-Deny from all
-Satisfy any
-Allow from 127.0.0.1
-AuthType Basic
-AuthBasicProvider file
-AuthUserFile /example.com/conf/users.passwd
-AuthName secure
-Require valid-user
    -
    -

    Version 2.4 :

    AuthType Basic
-AuthBasicProvider file
-AuthUserFile /example.com/conf/users.passwd
-AuthName secure
-# Implicite : <RequireAny>
-Require valid-user
-Require ip 127.0.0.1
    -
    - - - -

    Autres changements dans la configuration

    - - -

    D'autres ajustements mineurs peuvent s'avérer nécessaires pour - certaines configurations particulières, comme décrit ci-dessous.

    - -
      -
    • MaxRequestsPerChild a été renommée en - MaxConnectionsPerChild; - ce nouveau nom reflète mieux l'usage de cette directive. - L'ancien nom est encore supporté.
      • - -
    • La directive MaxClients a - été renommée en MaxRequestWorkers; ce nouveau - nom reflète mieux l'usage de cette directive. Pour les - modules multiprocessus asynchrones, comme event, le nombre - maximal de clients n'est pas équivalent au nombre de threads du - worker. L'ancien nom est encore supporté.
      • - -
    • La directive DefaultType ne produit plus aucun - effet, si ce n'est d'émettre un avertissement si elle est - définie à une valeur autre que none. D'autres - directives de configuration la remplacent dans la version 2.4. -
      • - -
    • La valeur par défaut de la directive AllowOverride est maintenant - None.
      • - -
    • La valeur par défaut de la directive EnableSendfile est maintenant Off.
      • - -
    • La valeur par défaut de la directive FileETag est maintenant "MTime Size" - (sans INode).
      • - -
    • mod_dav_fs: le format du fichier DavLockDB a changé pour les systèmes - avec inodes. L'ancien fichier DavLockDB doit être supprimé dans le - cadre de la mise à jour. -
      • - -
    • La directive KeepAlive - n'accepte que les valeurs On ou Off. - Avant, toute valeur autre que "Off" ou "0" était traitée comme - "On".
      • - -
    • Les directives AcceptMutex, LockFile, RewriteLock, SSLMutex, - SSLStaplingMutex et WatchdogMutexPath ont été remplacées par la - directive unique Mutex. - Vous devez évaluer l'impact de ces directives obsolètes dans - votre configuration version 2.2 afin de déterminer si elles - peuvent être simplement supprimées, ou si elles doivent être - remplacées par la directive Mutex.
      • - -
    • mod_cache: la directive CacheIgnoreURLSessionIdentifiers - effectue maintenant une correspondance exacte dans la chaîne de - paramètres au lieu d'une correspondance partielle. Si votre - configuration mettait en jeu des sous-chaînes comme - sessionid pour correspondre à - /une-application/image.gif;jsessionid=123456789, - vous devez maintenant utiliser la chaîne de correspondance - complète jsessionid. -
      • - -
    • mod_cache: le second paramètre de la - directive CacheEnable - ne concerne les contenus en mandat direct que s'ils débutent par - le protocole approprié. Dans les versions 2.2 et antérieures, un - paramètre tel que '/' concernait tous les contenus.
      • - -
    • mod_ldap: la directive LDAPTrustedClientCert s'utilise - maintenant exclusivement au sein d'une configuration de niveau - répertoire. Si vous utilisez cette directive, passez en revue - votre configuration pour vous assurer qu'elle est bien présente - dans tous les contextes de répertoire nécessaires.
      • - -
    • mod_filter: la syntaxe de la directive - FilterProvider utilise - maintenant une expression booléenne pour déterminer si un filtre - s'applique. -
      • - -
    • mod_include: -
        -
      • L'élément #if expr utilise maintenant le - nouvel interpréteur d'expressions. - L'ancienne syntaxe peut être réactivée via la directive - SSILegacyExprParser. -
        • -
      • Dans la portée du répertoire, une directive de - configuration SSI* ne provoque plus la réinitialisation à - leur valeur par défaut de toutes les directives SSI* de - niveau répertoire.
        • -
      -
      • - -
    • mod_charset_lite : l'option - DebugLevel a été supprimée en faveur d'une - configuration de la directive LogLevel au niveau répertoire. -
      • - -
    • mod_ext_filter : l'option - DebugLevel a été supprimée en faveur d'une - configuration de la directive LogLevel au niveau répertoire. -
      • - -
    • mod_proxy_scgi: certaines applications web - ne fonctionneront plus correctement avec la nouvelle - configuration de PATH_INFO qui est différente de - celle de la version 2.2. La configuration - précédente peut être - restaurée en définissant la variable - proxy-scgi-pathinfo.
      • - -
    • mod_ssl: le contrôle de révocation des - certificats basé sur les CRL doit être maintenant explicitement - configuré via la directive SSLCARevocationCheck. -
      • - -
    • mod_substitute: la taille maximale d'une - ligne est maintenant 1Mo. -
      • - -
    • mod_reqtimeout: si ce module est chargé, il - définit maintenant certains temps d'attente par défaut.
      • - -
    • mod_dumpio: la directive - DumpIOLogLevel n'est plus supportée. Les - données sont toujours enregistrées au niveau trace7 - de LogLevel
      • - -
    • Jusqu'à la version 2.2, sur les plateformes de style Unix, - les commandes de redirection des logs définies via ErrorLog ou CustomLog étaient invoquées - en utilisant /bin/sh -c. A - partir de la version 2.4, les commandes de redirection des logs - sont exécutées directement. Pour retrouver l'ancien - comportement, voir la documentation - sur la redirection des logs
      • - -
    - -
    top
    -
    -

    Changements divers

    - - -
      -
    • mod_auto_index: extrait maintenant les titres - et affiche la description pour les fichiers .xhtml qui étaient - jusqu'alors ignorés.
      • - -
    • mod_ssl : le format par défaut des variables - *_DN a changé. Il est cependant encore possible - d'utiliser l'ancien format via la nouvelle option - LegacyDNStringFormat de la directive SSLOptions. Le protocole SSLv2 n'est - plus supporté. Les directives SSLProxyCheckPeerCN et - SSLProxyCheckPeerExpire - sont maintenant définies par défaut à On, et les requêtes mandatées - vers des serveurs HTTPS possèdant des certificats non conformes ou - périmés échoueront donc avec un code d'erreur 502 (Bad gateway).
      • - -
    • htpasswd utilise maintenant par défaut les - condensés MD5 sur toutes les plates-formes.
      • - -
    • La directive NameVirtualHost n'a plus aucun effet, si - ce n'est l'émission d'un avertissement. Toute combinaison - adresse/port apparaissant dans plusieurs serveurs virtuels est - traitée implicitement comme un serveur virtuel basé sur le nom. -
      • - -
    • mod_deflate n'effectue plus de compression - s'il s'aperçoit que la quantité de données ajoutée par la - compression est supérieure à la quantité de données à compresser. -
      • - -
    • Les pages d'erreur multilingues de la version 2.2.x ne - fonctionneront qu'après avoir été corrigées pour - respecter la nouvelle syntaxe de l'élément #if expr= - du module mod_include, ou si la directive - SSILegacyExprParser a - été activée pour le répertoire contenant les pages d'erreur. -
      • - -
    • La fonctionnalité fournie par mod_authn_alias - dans les précédentes versions (en fait la directive - AuthnProviderAlias) - est maintenant fournie par mod_authn_core. -
      • - -
    • mod_cgid utilise la valeur de la directive - Timeout du serveur pour - limiter le temps d'attente entre les sorties d'un programme CGI. - La valeur de ce temps d'attente peut maintenant être modifiée via - la directive CGIDScriptTImeout. -
      • - -
    - -
    top
    -
    -

    Modules tiers

    - - -

    Tous les modules tiers doivent être recompilés pour la - version 2.4 avant d'être chargés.

    - -

    De nombreux modules tiers conçus pour la version 2.2 - fonctionneront sans changement avec le serveur HTTP Apache - version 2.4. Certains nécessiteront cependant des modifications ; se - reporter à la vue d'ensemble Mise à jour de l'API.

    -
    top
    -
    -

    Problèmes de mise à jour courants

    - -
    • Erreurs au démarrage : -
        -
      • Invalid command 'User', perhaps misspelled or defined by - a module not included in the server configuration - chargez - le module mod_unixd
        • - -
      • Invalid command 'Require', perhaps misspelled or defined - by a module not included in the server configuration, ou - Invalid command 'Order', perhaps misspelled or defined by a - module not included in the server configuration - chargez - le module mod_access_compat, ou mettez à jour - vers la version 2.4 les directives d'autorisation.
        • - -
      • Ignoring deprecated use of DefaultType in line NN of - /path/to/httpd.conf - supprimez la directive DefaultType et remplacez-la par les - directives de configuration appropriées.
        • - -
      • Invalid command 'AddOutputFilterByType', perhaps misspelled - or defined by a module not included in the server configuration - - la directive AddOutputFilterByType qui était - jusqu'alors implémentée par le module core, l'est maintenant par - le module mod_filter, qui doit donc être chargé.
        • - -
      • -
    • Erreurs de traitement des requêtes : -
        -
      • configuration error: couldn't check user: /path - - chargez le module mod_authn_core.
        • -
      • Les fichiers .htaccess ne sont pas traités - - Vérifiez la présence d'une directive AllowOverride appropriée ; sa valeur par - défaut est maintenant None.
        • -
      -
      • -
    - -
    -
    -

    Langues Disponibles:  en  | - fr 

    -
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    -
    - \ No newline at end of file diff --git a/docs/manual/upgrading.html.fr.utf8 b/docs/manual/upgrading.html.fr.utf8 new file mode 100644 index 0000000000..20c7947db8 --- /dev/null +++ b/docs/manual/upgrading.html.fr.utf8 @@ -0,0 +1,591 @@ + + + + + +Mise à jour de la version 2.2 vers la version 2.4 - Serveur HTTP Apache Version 2.5 + + + + + + +
    +

    Modules | Directives | FAQ | Glossaire | Plan du site

    +

    Serveur HTTP Apache Version 2.5

    +
    +
    <-
    +

    Mise à jour de la version 2.2 vers la version 2.4

    +
    +

    Langues Disponibles:  en  | + fr 

    +
    + +

    Afin d'assister les utilisateurs lors de leurs opérations de mise à + jour, nous maintenons un document + qui comporte des informations critiques à l'attention des personnes qui + utilisent déjà le serveur HTTP Apache. Ces informations + ne sont que de brèves notes, et vous + trouverez plus d'informations dans le document Nouvelles fonctionnalités, ou dans + le fichier src/CHANGES. Les développeurs d'applications + et de modules trouveront un résumé des modifications de l'API dans la + vue d'ensemble Mises à jour de + l'API.

    + +

    Ce document présente les changements de comportement du serveur qui + peuvent nécessiter une modification de la configuration, et la manière + d'utiliser la version 2.4 du serveur en parallèle avec la + version 2.2. Pour tirer parti des nouvelles fonctionnalités de la + version 2.4, reportez-vous au document "Nouvelles fonctionnalités".

    + +

    Ce document ne décrit que les modifications intervenues entre les versions + 2.2 et 2.4. Si vous effectuez une mise à jour depuis la version 2.0, vous + devez aussi consulter le + document de mise + à jour de 2.0 vers 2.2.

    + +
    + +
    top
    +
    +

    Modifications des paramètres de compilation

    + +

    Le processus de compilation est très similaire à celui de la + version 2.2. Dans la plupart des cas, vous pourrez utiliser votre + ancienne ligne de commande configure (telle qu'elle + est enregistrée dans le fichier build/config.nice + situé dans le répertoire de compilation du serveur). Voici certains + changements intervenus dans la configuration par défaut :

    + +
      +
    • Les modules suivants ont été supprimés : mod_authn_default, + mod_authz_default et mod_mem_cache. Si vous utilisiez + mod_mem_cache sous la version 2.2, vous devez maintenant utiliser + mod_cache_disk dans la version 2.4.
      • + +
    • Toutes les implémentations de répartition de charge ont été + déplacées vers des sous-modules spécifiques de mod_proxy, comme + mod_lbmethod_bybusyness. Vous devrez compiler et + chargés tous les modules correspondants que votre configuration + utilise.
      • + +
    • Le support de BeOS, TPF, et des anciennes plates-formes telles + que A/UX, Next, et Tandem a été supprimé, car + elles ne sont plus considérées comme maintenues.
      • + +
    • configure: les modules dynamiques (DSO) sont compilés par + défaut
      • + +
    • configure: par défaut, seul un jeu de modules de base est + chargé. Les autres directives LoadModule + sont mises en commentaires dans le fichier de configuration.
      • + +
    • configure: le jeu de modules "most" est compilé par défaut
      • + +
    • configure: le jeu de modules "reallyall" ajoute les modules de + développeur au jeu "all".
      • +
    + +
    top
    +
    +

    Modifications de la configuration à l'exécution

    + +

    Des changements significatifs dans la configuration de +l'autorisation, ainsi que quelques changements mineurs, peuvent +nécessiter une mise à jour des fichiers de configuration de la version +2.2 avant de les utiliser sous la version 2.4.

    + +

    Autorisation

    + + +

    Tout fichier de configuration qui gère des autorisations devra + probablement être mis à jour.

    + +

    Vous devez vous reporter au document Authentification, autorisation et contrôle + d'accès, et plus particulièrement à la section Plus loin qu'une simple + autorisation qui explique les nouveaux mécanismes permettant de + contrôler l'ordre dans lequel les directives d'autorisation sont + appliquées.

    + +

    Les directives qui contrôlent la manière dont les modules + d'autorisation réagissent lorsqu'ils ne reconnaissent pas + l'utilisateur authentifié ont été supprimées : elles comprennent les + directives AuthzLDAPAuthoritative, AuthzDBDAuthoritative, + AuthzDBMAuthoritative, AuthzGroupFileAuthoritative, + AuthzUserAuthoritative et AuthzOwnerAuthoritative. Ces directives + ont été remplacées par les directives plus explicites RequireAny, RequireNone, et RequireAll.

    + +

    Si vous utilisez mod_authz_dbm, vous devez + mettre à jour votre configuration en remplaçant les directives du + style Require group ... par des directives du style + Require dbm-group ....

    + +

    Contrôle d'accès

    + + +

    Dans la version 2.2, le contrôle d'accès basé sur le nom d'hôte + du client, son adresse IP, ou d'autres caractéristiques de la + requête était assuré via les directives Order, Allow, Deny, et Satisfy.

    + +

    Dans la version 2.4, ce contrôle d'accès est assuré, comme tout + contrôle d'autorisation, par le nouveau module + mod_authz_host. Bien que le module + mod_access_compat assure la + compatibilité avec les anciennes configurations, les anciennes + directives de contrôle d'accès devront être remplacées par les + nouveaux mécanismes d'authentification.

    + +

    Mélanger anciennes et nouvelles directives

    +

    Mélanger d'anciennes directives comme Order, Allow ou Deny avec des nouvelles comme + Require est techniquement + possible mais déconseillé. En effet, mod_access_compat a + été conçu pour supporter des configurations ne contenant que des anciennes + directives afin de faciliter le passage à la version 2.4. Les + exemples ci-dessous vous permettront de vous faire une meilleure idée des + problèmes qui peuvent survenir. +

    +
    + +

    Voici quelques exemples de contrôle d'accès avec l'ancienne et + la nouvelle méthode :

    + +

    Dans cet exemple, il n'y a pas d'authentification et toutes les + requêtes sont rejetées :

    +

    version 2.2 :

    Order deny,allow
+Deny from all
    +
    +

    version 2.4 :

    Require all denied
    +
    + +

    Dans cet exemple, il n'y a pas d'authentification et toutes les + requêtes sont acceptées :

    +

    version 2.2 :

    Order allow,deny
+Allow from all
    +
    +

    version 2.4 :

    Require all granted
    +
    + +

    Dans l'exemple suivant, il n'y a pas d'authentification et tous les + hôtes du domaine example.org + ont l'autorisation d'accès, tous les autres étant rejetés :

    + +

    version 2.2 :

    Order Deny,Allow
+Deny from all
+Allow from example.org
    +
    +

    version 2.4 :

    Require host example.org
    +
    + +

    Dans l'exemple suivant, le mélange d'anciennes et de nouvelles + directives produit des résultats inattendus.

    + +

    Mélange d'anciennes et de nouvelles directives : RESULTAT + INATTENDU

    DocumentRoot "/var/www/html"
+
+<Directory "/">
+    AllowOverride None
+    Order deny,allow
+    Deny from all
+</Directory>
+
+<Location "/server-status">
+    SetHandler server-status
+    Require local
+</Location>
+
+access.log - GET /server-status 403 127.0.0.1
+error.log - AH01797: client denied by server configuration: /var/www/html/server-status
    +
    +

    Pourquoi httpd interdit l'accès à server-status alors que la + configuration semble l'autoriser ? Parce que dans ce scénario de fusion de configuration, les + directives de mod_access_compat sont prioritaires par + rapport à celles de mod_authz_host.

    + +

    L'exemple suivant quant à lui produit un résultat conforme :

    + +

    Mélange d'anciennes et de nouvelles directives : RESULTAT + CONFORME

    DocumentRoot "/var/www/html"
+
+<Directory "/">
+    AllowOverride None
+    Require all denied
+</Directory>
+
+<Location "/server-status">
+    SetHandler server-status
+    Order deny,allow
+    Deny from all
+    Allow From 127.0.0.1
+</Location>
+
+access.log - GET /server-status 200 127.0.0.1
    +
    +

    En conclusion, même si une configuration hybride peut fonctionner, + essayez de l'éviter lors de la mise à jour : soit conservez les anciennes + directives, puis migrez-les vers les nouvelles ultérieurement, soit + effectuez une migration immédiate de toutes les anciennes directives vers + les nouvelles. +

    + + + +

    Dans de nombreuses configurations avec authentification où la directive + Satisfy était définie à sa valeur par défaut + ALL, les lignes de configuration qui désactivent le contrôle + d'accès basé sur l'hôte sont maintenant omises :

    + +

    Version 2.2 :

    # configuration en version 2.2 qui désactive le contrôle d'accès basé sur le nom
+# d'hôte pour n'utiliser que l'authentification
+Order Deny,Allow
+Allow from all
+AuthType Basic
+AuthBasicProvider file
+AuthUserFile /example.com/conf/users.passwd
+AuthName secure
+Require valid-user
    +
    +

    Version 2.4 :

    # Pas besoin de remplacer les directives Order et deny pour les désactiver
+AuthType Basic
+AuthBasicProvider file
+AuthUserFile /example.com/conf/users.passwd
+AuthName secure
+Require valid-user
    +
    + +

    Dans les configurations où l'authentification et le contrôle d'accès se + combinaient dans un but précis, les directives de contrôle d'accès doivent + être migrées. Dans l'exemple suivant, les requêtes qui correspondent aux + deux critères sont acceptées :

    +

    Version 2.2 :

    Order allow,deny
+Deny from all
+# ALL est la valeur par défaut de Satisfy
+Satisfy ALL
+Allow from 127.0.0.1
+AuthType Basic
+AuthBasicProvider file
+AuthUserFile /example.com/conf/users.passwd
+AuthName secure
+Require valid-user
    +
    +

    Version 2.4 :

    AuthType Basic
+AuthBasicProvider file
+AuthUserFile /example.com/conf/users.passwd
+AuthName secure
+<RequireAll>
+  Require valid-user
+  Require ip 127.0.0.1
+</RequireAll>
    +
    + +

    Dans les configurations où l'authentification et le contrôle d'accès se + combinaient dans un but précis, les directives de contrôle d'accès doivent + être migrées. Dans l'exemple suivant, les requêtes qui correspondent à + au moins un critère sont acceptées :

    +

    Version 2.2 :

    Order allow,deny
+Deny from all
+Satisfy any
+Allow from 127.0.0.1
+AuthType Basic
+AuthBasicProvider file
+AuthUserFile /example.com/conf/users.passwd
+AuthName secure
+Require valid-user
    +
    +

    Version 2.4 :

    AuthType Basic
+AuthBasicProvider file
+AuthUserFile /example.com/conf/users.passwd
+AuthName secure
+# Implicite : <RequireAny>
+Require valid-user
+Require ip 127.0.0.1
    +
    + + + +

    Autres changements dans la configuration

    + + +

    D'autres ajustements mineurs peuvent s'avérer nécessaires pour + certaines configurations particulières, comme décrit ci-dessous.

    + +
      +
    • MaxRequestsPerChild a été renommée en + MaxConnectionsPerChild; + ce nouveau nom reflète mieux l'usage de cette directive. + L'ancien nom est encore supporté.
      • + +
    • La directive MaxClients a + été renommée en MaxRequestWorkers; ce nouveau + nom reflète mieux l'usage de cette directive. Pour les + modules multiprocessus asynchrones, comme event, le nombre + maximal de clients n'est pas équivalent au nombre de threads du + worker. L'ancien nom est encore supporté.
      • + +
    • La directive DefaultType ne produit plus aucun + effet, si ce n'est d'émettre un avertissement si elle est + définie à une valeur autre que none. D'autres + directives de configuration la remplacent dans la version 2.4. +
      • + +
    • La valeur par défaut de la directive AllowOverride est maintenant + None.
      • + +
    • La valeur par défaut de la directive EnableSendfile est maintenant Off.
      • + +
    • La valeur par défaut de la directive FileETag est maintenant "MTime Size" + (sans INode).
      • + +
    • mod_dav_fs: le format du fichier DavLockDB a changé pour les systèmes + avec inodes. L'ancien fichier DavLockDB doit être supprimé dans le + cadre de la mise à jour. +
      • + +
    • La directive KeepAlive + n'accepte que les valeurs On ou Off. + Avant, toute valeur autre que "Off" ou "0" était traitée comme + "On".
      • + +
    • Les directives AcceptMutex, LockFile, RewriteLock, SSLMutex, + SSLStaplingMutex et WatchdogMutexPath ont été remplacées par la + directive unique Mutex. + Vous devez évaluer l'impact de ces directives obsolètes dans + votre configuration version 2.2 afin de déterminer si elles + peuvent être simplement supprimées, ou si elles doivent être + remplacées par la directive Mutex.
      • + +
    • mod_cache: la directive CacheIgnoreURLSessionIdentifiers + effectue maintenant une correspondance exacte dans la chaîne de + paramètres au lieu d'une correspondance partielle. Si votre + configuration mettait en jeu des sous-chaînes comme + sessionid pour correspondre à + /une-application/image.gif;jsessionid=123456789, + vous devez maintenant utiliser la chaîne de correspondance + complète jsessionid. +
      • + +
    • mod_cache: le second paramètre de la + directive CacheEnable + ne concerne les contenus en mandat direct que s'ils débutent par + le protocole approprié. Dans les versions 2.2 et antérieures, un + paramètre tel que '/' concernait tous les contenus.
      • + +
    • mod_ldap: la directive LDAPTrustedClientCert s'utilise + maintenant exclusivement au sein d'une configuration de niveau + répertoire. Si vous utilisez cette directive, passez en revue + votre configuration pour vous assurer qu'elle est bien présente + dans tous les contextes de répertoire nécessaires.
      • + +
    • mod_filter: la syntaxe de la directive + FilterProvider utilise + maintenant une expression booléenne pour déterminer si un filtre + s'applique. +
      • + +
    • mod_include: +
        +
      • L'élément #if expr utilise maintenant le + nouvel interpréteur d'expressions. + L'ancienne syntaxe peut être réactivée via la directive + SSILegacyExprParser. +
        • +
      • Dans la portée du répertoire, une directive de + configuration SSI* ne provoque plus la réinitialisation à + leur valeur par défaut de toutes les directives SSI* de + niveau répertoire.
        • +
      +
      • + +
    • mod_charset_lite : l'option + DebugLevel a été supprimée en faveur d'une + configuration de la directive LogLevel au niveau répertoire. +
      • + +
    • mod_ext_filter : l'option + DebugLevel a été supprimée en faveur d'une + configuration de la directive LogLevel au niveau répertoire. +
      • + +
    • mod_proxy_scgi: certaines applications web + ne fonctionneront plus correctement avec la nouvelle + configuration de PATH_INFO qui est différente de + celle de la version 2.2. La configuration + précédente peut être + restaurée en définissant la variable + proxy-scgi-pathinfo.
      • + +
    • mod_ssl: le contrôle de révocation des + certificats basé sur les CRL doit être maintenant explicitement + configuré via la directive SSLCARevocationCheck. +
      • + +
    • mod_substitute: la taille maximale d'une + ligne est maintenant 1Mo. +
      • + +
    • mod_reqtimeout: si ce module est chargé, il + définit maintenant certains temps d'attente par défaut.
      • + +
    • mod_dumpio: la directive + DumpIOLogLevel n'est plus supportée. Les + données sont toujours enregistrées au niveau trace7 + de LogLevel
      • + +
    • Jusqu'à la version 2.2, sur les plateformes de style Unix, + les commandes de redirection des logs définies via ErrorLog ou CustomLog étaient invoquées + en utilisant /bin/sh -c. A + partir de la version 2.4, les commandes de redirection des logs + sont exécutées directement. Pour retrouver l'ancien + comportement, voir la documentation + sur la redirection des logs
      • + +
    + +
    top
    +
    +

    Changements divers

    + + +
      +
    • mod_auto_index: extrait maintenant les titres + et affiche la description pour les fichiers .xhtml qui étaient + jusqu'alors ignorés.
      • + +
    • mod_ssl : le format par défaut des variables + *_DN a changé. Il est cependant encore possible + d'utiliser l'ancien format via la nouvelle option + LegacyDNStringFormat de la directive SSLOptions. Le protocole SSLv2 n'est + plus supporté. Les directives SSLProxyCheckPeerCN et + SSLProxyCheckPeerExpire + sont maintenant définies par défaut à On, et les requêtes mandatées + vers des serveurs HTTPS possèdant des certificats non conformes ou + périmés échoueront donc avec un code d'erreur 502 (Bad gateway).
      • + +
    • htpasswd utilise maintenant par défaut les + condensés MD5 sur toutes les plates-formes.
      • + +
    • La directive NameVirtualHost n'a plus aucun effet, si + ce n'est l'émission d'un avertissement. Toute combinaison + adresse/port apparaissant dans plusieurs serveurs virtuels est + traitée implicitement comme un serveur virtuel basé sur le nom. +
      • + +
    • mod_deflate n'effectue plus de compression + s'il s'aperçoit que la quantité de données ajoutée par la + compression est supérieure à la quantité de données à compresser. +
      • + +
    • Les pages d'erreur multilingues de la version 2.2.x ne + fonctionneront qu'après avoir été corrigées pour + respecter la nouvelle syntaxe de l'élément #if expr= + du module mod_include, ou si la directive + SSILegacyExprParser a + été activée pour le répertoire contenant les pages d'erreur. +
      • + +
    • La fonctionnalité fournie par mod_authn_alias + dans les précédentes versions (en fait la directive + AuthnProviderAlias) + est maintenant fournie par mod_authn_core. +
      • + +
    • mod_cgid utilise la valeur de la directive + Timeout du serveur pour + limiter le temps d'attente entre les sorties d'un programme CGI. + La valeur de ce temps d'attente peut maintenant être modifiée via + la directive CGIDScriptTImeout. +
      • + +
    + +
    top
    +
    +

    Modules tiers

    + + +

    Tous les modules tiers doivent être recompilés pour la + version 2.4 avant d'être chargés.

    + +

    De nombreux modules tiers conçus pour la version 2.2 + fonctionneront sans changement avec le serveur HTTP Apache + version 2.4. Certains nécessiteront cependant des modifications ; se + reporter à la vue d'ensemble Mise à jour de l'API.

    +
    top
    +
    +

    Problèmes de mise à jour courants

    + +
    • Erreurs au démarrage : +
        +
      • Invalid command 'User', perhaps misspelled or defined by + a module not included in the server configuration - chargez + le module mod_unixd
        • + +
      • Invalid command 'Require', perhaps misspelled or defined + by a module not included in the server configuration, ou + Invalid command 'Order', perhaps misspelled or defined by a + module not included in the server configuration - chargez + le module mod_access_compat, ou mettez à jour + vers la version 2.4 les directives d'autorisation.
        • + +
      • Ignoring deprecated use of DefaultType in line NN of + /path/to/httpd.conf - supprimez la directive DefaultType et remplacez-la par les + directives de configuration appropriées.
        • + +
      • Invalid command 'AddOutputFilterByType', perhaps misspelled + or defined by a module not included in the server configuration + - la directive AddOutputFilterByType qui était + jusqu'alors implémentée par le module core, l'est maintenant par + le module mod_filter, qui doit donc être chargé.
        • + +
      • +
    • Erreurs de traitement des requêtes : +
        +
      • configuration error: couldn't check user: /path - + chargez le module mod_authn_core.
        • +
      • Les fichiers .htaccess ne sont pas traités - + Vérifiez la présence d'une directive AllowOverride appropriée ; sa valeur par + défaut est maintenant None.
        • +
      +
      • +
    + +
    +
    +

    Langues Disponibles:  en  | + fr 

    +
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    +
    + \ No newline at end of file diff --git a/docs/manual/urlmapping.html.en b/docs/manual/urlmapping.html.en index 9970310cf5..91944eec54 100644 --- a/docs/manual/urlmapping.html.en +++ b/docs/manual/urlmapping.html.en @@ -24,10 +24,10 @@ Apache > HTTP Server > Documentation > Version 2.5

    Mapping URLs to Filesystem Locations

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

    + tr 

    This document explains how the Apache HTTP Server uses the URL of a request @@ -348,10 +348,10 @@ proxying scenarios can be handled.

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

    + tr 

    top

    Comments

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    - - -
    -

    Modules | Directives | FAQ | Glossaire | Plan du site

    -

    Serveur HTTP Apache Version 2.5

    -
    -
    <-
    -

    Mise en correspondance des URLs avec le système de fichiers

    -
    -

    Langues Disponibles:  en  | - fr  | - ja  | - ko  | - tr 

    -
    - -

    Ce document explique comment le serveur HTTP Apache utilise l'URL contenue dans une - requête pour déterminer le noeud du système de fichier à partir duquel le - fichier devra être servi.

    -
    - -
    top
    -
    -

    Modules et directives concernés

    - -
    Modules ApparentésDirectives Apparentées
    -
    top
    -
    -

    Racine des documents (DocumentRoot)

    - -

    La méthode par défaut de httpd pour déterminer quel fichier servir pour - une requête donnée, consiste à extraire le chemin du fichier de la requête - (la partie de l'URL qui suit le nom d'hôte et le port), puis de l'ajouter - à la fin de la valeur de la directive - DocumentRoot définie dans vos fichiers - de configuration. - Ainsi, les fichiers et répertoires - situés en dessous de DocumentRoot - constituent l'arborescence de base des documents qui seront visibles - depuis le web.

    - -

    Par exemple, si la directive - DocumentRoot contient - /var/www/html, une requête pour - http://www.example.com/fish/guppies.html retournera le - fichier /var/www/html/fish/guppies.html au client.

    - -

    Si la requête concerne un répertoire (autrement dit un chemin se - terminant par un slash /), le nom du fichier qui sera - recherché et servi depuis ce répertoire est défini via la directive - DirectoryIndex. Par exemple, - supposons que DocumentRoot ait été définie comme - précédemment, et que vous ayez défini DirectoryIndex - comme suit :

    - -

    DirectoryIndex index.html index.php

    - -

    Si httpd reçoit alors une requête pour - http://www.example.com/fish/, il tentera de servir le - fichier /var/www/html/fish/index.html. Si ce fichier - n'existe pas, il tentera de servir le fichier - /var/www/html/fish/index.php.

    - -

    Si aucun de ces fichiers existe, httpd tentera de générer et - d'afficher un index du répertoire, à condition que - mod_autoindex ait été chargé et configuré pour le - permettre.

    - -

    httpd supporte aussi les Hôtes virtuels, - ce qui lui permet de traiter des requêtes pour plusieurs hôtes. - Dans ce cas, un DocumentRoot - différent peut être défini pour chaque hôte virtuel; - les directives fournies par le module - mod_vhost_alias peuvent aussi être utilisées afin de - déterminer dynamiquement le noeud approprié du système de fichiers - à partir duquel servir un contenu en fonction de l'adresse IP - ou du nom d'hôte.

    - -

    La directive DocumentRoot est - définie dans le fichier de configuration de votre serveur principal - (httpd.conf), mais peut aussi être redéfinie pour chaque - Hôte virtuel supplémentaire que vous avez créé.

    -
    top
    -
    -

    Fichiers situés en dehors de -l'arborescence DocumentRoot

    - -

    Il existe de nombreuses circonstances pour lesquelles il est nécessaire - d'autoriser l'accès web à des portions du système de fichiers qui ne se - trouvent pas dans l'arborescence DocumentRoot. httpd propose de nombreuses - solutions pour réaliser cela. Sur les systèmes Unix, les liens - symboliques permettent de rattacher d'autres portions du système de - fichiers au DocumentRoot. Pour des raisons de sécurité, - httpd ne suivra les liens symboliques que si les Options pour le répertoire concerné contiennent - FollowSymLinks ou SymLinksIfOwnerMatch.

    - -

    Une autre méthode consiste à utiliser la directive Alias pour rattacher toute portion - du système de fichiers à l'arborescence du site web. Par exemple, avec

    - -
    Alias "/docs" "/var/web"
    - - -

    l'URL http://www.example.com/docs/dir/file.html - correspondra au fichier /var/web/dir/file.html. La - directive - ScriptAlias - fonctionne de la même manière, excepté que tout contenu localisé dans le - chemin cible sera traité comme un script CGI.

    - -

    Pour les situations qui nécessitent plus de flexibilité, vous disposez - des directives AliasMatch - et ScriptAliasMatch - qui permettent des substitutions et comparaisons puissantes basées - sur les expressions rationnelles. - Par exemple,

    - -
    ScriptAliasMatch "^/~([a-zA-Z0-9]+)/cgi-bin/(.+)" "/home/$1/cgi-bin/$2"
    - - -

    fera correspondre une requête du style - http://example.com/~user/cgi-bin/script.cgi au chemin - /home/user/cgi-bin/script.cgi, et traitera le fichier résultant - comme un script CGI.

    -
    top
    -
    -

    Répertoires des utilisateurs

    - -

    Sur les systèmes Unix, on peut traditionnellement faire référence - au répertoire personnel d'un utilisateur particulier à l'aide de - l'expression ~user/. - Le module mod_userdir - étend cette idée au web en autorisant l'accès aux fichiers situés dans les - répertoires home des utilisateurs à l'aide d'URLs - comme dans ce qui suit :

    - -

    http://www.example.com/~user/file.html

    - -

    Pour des raisons de sécurité, il est déconseillé de permettre un accès - direct à un répertoire home d'utilisateur depuis le web. A cet effet, la - directive UserDir - spécifie un répertoire où sont situés les fichiers accessibles depuis le web - dans le répertoire home de l'utilisateur. - Avec la configuration par défaut - Userdir public_html, l'URL ci-dessus correspondra à un fichier - dont le chemin sera du style - /home/user/public_html/file.html où - /home/user/ est le répertoire home de l'utilisateur tel qu'il - est défini dans /etc/passwd.

    - -

    La directive Userdir met à votre disposition de nombreuses - formes différentes pour les systèmes où /etc/passwd ne - spécifie pas la localisation du répertoire home.

    - -

    Certains jugent le symbole "~" (dont le code sur le web est souvent - %7e) inapproprié et préfèrent utiliser une chaîne de - caractères différente pour représenter les répertoires utilisateurs. - mod_userdir ne supporte pas cette fonctionnalité. Cependant, si les - répertoires home des utilisateurs sont structurés de manière rationnelle, - il est possible d'utiliser la directive - AliasMatch - pour obtenir l'effet désiré. Par exemple, pour faire correspondre - http://www.example.com/upages/user/file.html à - /home/user/public_html/file.html, utilisez la directive - AliasMatch suivante :

    - -
    AliasMatch "^/upages/([a-zA-Z0-9]+)(/(.*))?$" "/home/$1/public_html/$3"
    - -
    top
    -
    -

    Redirection d'URL

    - -

    Les directives de configuration décrites dans les sections précédentes - demandent à httpd d'extraire un contenu depuis un emplacement spécifique - du système de fichiers - et de la retourner au client. Il est cependant parfois - souhaitable d'informer le - client que le contenu demandé est localisé à une URL différente, et de - demander au client d'élaborer une nouvelle requête avec la nouvelle URL. - Ce processus se nomme redirection et est implémenté par la - directive Redirect. - Par exemple, si le contenu du répertoire /foo/ sous - DocumentRoot est déplacé vers le - nouveau répertoire /bar/, vous pouvez demander aux clients - de le requérir à sa nouvelle localisation comme suit :

    - -
    Redirect permanent "/foo/"   "http://www.example.com/bar/"
    - - -

    Ceci aura pour effet de rediriger tout chemin d'URL commençant par - /foo/ vers le même chemin d'URL sur le serveur - www.example.com en remplaçant /foo/ par - /bar/. Vous pouvez rediriger les clients non seulement sur le - serveur d'origine, mais aussi vers n'importe quel autre serveur.

    - -

    httpd propose aussi la directive RedirectMatch pour traiter les problèmes - de réécriture d'une plus grande complexité. Par exemple, afin de rediriger - les requêtes pour la page d'accueil du site vers un site différent, mais - laisser toutes les autres requêtes inchangées, utilisez la - configuration suivante :

    - -
    RedirectMatch permanent "^/$" "http://www.example.com/startpage.html"
    - - -

    De même, pour rediriger temporairement toutes les pages d'un site - vers une page particulière d'un autre site, utilisez ce qui suit :

    - -
    RedirectMatch temp ".*" "http://othersite.example.com/startpage.html"
    - -
    top
    -
    -

    Mandataire inverse (Reverse Proxy)

    - -

    httpd vous permet aussi de rapatrier des documents distants -dans l'espace des URL du serveur local. -Cette technique est appelée mandataire inverse ou reverse -proxying car le serveur web agit comme un serveur mandataire en -rapatriant les documents depuis un serveur distant puis les renvoyant -au client. Ceci diffère d'un service de mandataire usuel (direct) car, pour le client, -les documents semblent appartenir au serveur mandataire inverse.

    - -

    Dans l'exemple suivant, quand les clients demandent des documents situés -dans le répertoire -/foo/, le serveur rapatrie ces documents depuis le répertoire -/bar/ sur internal.example.com -et les renvoie au client comme s'ils appartenaient au serveur local.

    - -
    ProxyPass        "/foo/" "http://internal.example.com/bar/"
-ProxyPassReverse "/foo/" "http://internal.example.com/bar/"
-ProxyPassReverseCookieDomain internal.example.com public.example.com
-ProxyPassReverseCookiePath "/foo/" "/bar/"
    - - -

    La directive ProxyPass configure -le serveur pour rapatrier les documents appropriés, alors que la directive -ProxyPassReverse -réécrit les redirections provenant de -internal.example.com de telle manière qu'elles ciblent le -répertoire approprié sur le serveur local. De manière similaire, les directives -ProxyPassReverseCookieDomain -et ProxyPassReverseCookiePath -réécrivent les cookies élaborés par le serveur d'arrière-plan.

    -

    Il est important de noter cependant, que les liens situés dans les documents -ne seront pas réécrits. Ainsi, tout lien absolu sur -internal.example.com fera décrocher le client -du serveur mandataire et effectuer sa requête directement sur -internal.example.com. Vous pouvez modifier ces liens (et -d'utres contenus) situés dans la page au moment où elle est envoyée au -client en utilisant le module mod_substitute.

    - -
    Substitute s/internal\.example\.com/www.example.com/i
    - - -

    Le module mod_proxy_html rend possible une réécriture plus -élaborée des liens en HTML et XHTML. Il permet de créer des listes -d'URLs et de leurs réécritures, de façon à pouvoir gérer des scénarios -de réécriture complexes.

    -
    top
    -
    -

    Moteur de réécriture

    - -

    Le moteur de réécriture mod_rewrite peut s'avérer - utile lorsqu'une substitution plus puissante est nécessaire. - Les directives fournies par ce module peuvent utiliser des caractéristiques de la - requête comme le type de navigateur ou l'adresse IP source afin de décider - depuis où servir le contenu. En outre, mod_rewrite peut utiliser des - fichiers ou programmes de bases de données externes pour déterminer comment - traiter une requête. Le moteur de réécriture peut effectuer les trois types - de mise en correspondance discutés plus haut : - redirections internes (aliases), redirections externes, et services mandataires. - De nombreux exemples pratiques utilisant mod_rewrite sont discutés dans la - documentation détaillée de mod_rewrite.

    -
    top
    -
    -

    Fichier non trouvé (File Not Found)

    - -

    Inévitablement, apparaîtront des URLs qui ne correspondront à aucun - fichier du système de fichiers. - Ceci peut arriver pour de nombreuses raisons. - Il peut s'agir du déplacement de documents d'une - localisation vers une autre. Dans ce cas, le mieux est d'utiliser la - redirection d'URL pour informer les clients de la - nouvelle localisation de la ressource. De cette façon, vous êtes sur que - les anciens signets et liens continueront de fonctionner, même si la - ressource est déplacée.

    - -

    Une autre cause fréquente d'erreurs "File Not Found" est l'erreur de - frappe accidentelle dans les URLs, soit directement dans le navigateur, - soit dans les liens HTML. httpd propose le module - mod_speling (sic) pour tenter de résoudre ce problème. - Lorsque ce module est activé, il intercepte les erreurs - "File Not Found" et recherche une ressource possédant un nom de fichier - similaire. Si un tel fichier est trouvé, mod_speling va envoyer une - redirection HTTP au client pour lui communiquer l'URL correcte. - Si plusieurs fichiers proches sont trouvés, une liste des alternatives - possibles sera présentée au client.

    - -

    mod_speling possède une fonctionnalité particulièrement utile : - il compare les noms de fichiers sans tenir compte de la casse. - Ceci peut aider les systèmes où les utilisateurs ne connaissent pas la - sensibilité des URLs à la casse et bien sûr les systèmes de fichiers unix. - Mais l'utilisation de mod_speling pour toute autre chose que la correction - occasionnelle d'URLs peut augmenter la charge du serveur, car chaque - requête "incorrecte" entraîne une redirection d'URL et une nouvelle requête - de la part du client.

    - -

    mod_dir fournit la directive FallbackResource qui permet d'associer - des URIs virtuels à une ressource réelle qui peut ainsi les servir. - Cette directive remplace avantageusement - mod_rewrite lors de l'implémentation d'un - "contrôleur frontal".

    - -

    Si toutes les tentatives pour localiser le contenu - échouent, httpd - retourne une page d'erreur avec le code de statut HTTP 404 - (file not found). L'apparence de cette page est contrôlée à l'aide de la - directive ErrorDocument - et peut être personnalisée de manière très flexible comme discuté dans le - document - Réponses personnalisées aux erreurs.

    -
    top
    -
    -

    Autres modules de mise en correspondance des -URLs

    - - - -

    Les autres modules disponibles pour la mise en correspondance des - URLs sont :

    -
      -
    • mod_actions - Met une URL en correspondance - avec un script CGI en fonction de la méthode de la requête, ou du - type MIME de la ressource.
      • -
    • mod_dir - Permet une mise en correspondance - basique d'un slash terminal dans un fichier index comme - index.html.
      • -
    • mod_imagemap - Met en correspondance une - requête avec une URL en fonction de la zone d'une image intégrée à - un document HTML dans laquelle un utilisateur clique.
      • -
    • mod_negotiation - Sélectionne le document - approprié en fonction de préférences du client telles que la langue - ou la compression du contenu.
      • -
    - -
    -
    -

    Langues Disponibles:  en  | - fr  | - ja  | - ko  | - tr 

    -
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    -
    - \ No newline at end of file diff --git a/docs/manual/urlmapping.html.fr.utf8 b/docs/manual/urlmapping.html.fr.utf8 new file mode 100644 index 0000000000..eb417e89d2 --- /dev/null +++ b/docs/manual/urlmapping.html.fr.utf8 @@ -0,0 +1,402 @@ + + + + + + Mise en correspondance des URLs avec le système de fichiers - Serveur HTTP Apache Version 2.5 + + + + + + +
    +

    Modules | Directives | FAQ | Glossaire | Plan du site

    +

    Serveur HTTP Apache Version 2.5

    +
    +
    <-
    +

    Mise en correspondance des URLs avec le système de fichiers

    +
    +

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

    +
    + +

    Ce document explique comment le serveur HTTP Apache utilise l'URL contenue dans une + requête pour déterminer le noeud du système de fichier à partir duquel le + fichier devra être servi.

    +
    + +
    top
    +
    +

    Modules et directives concernés

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

    Racine des documents (DocumentRoot)

    + +

    La méthode par défaut de httpd pour déterminer quel fichier servir pour + une requête donnée, consiste à extraire le chemin du fichier de la requête + (la partie de l'URL qui suit le nom d'hôte et le port), puis de l'ajouter + à la fin de la valeur de la directive + DocumentRoot définie dans vos fichiers + de configuration. + Ainsi, les fichiers et répertoires + situés en dessous de DocumentRoot + constituent l'arborescence de base des documents qui seront visibles + depuis le web.

    + +

    Par exemple, si la directive + DocumentRoot contient + /var/www/html, une requête pour + http://www.example.com/fish/guppies.html retournera le + fichier /var/www/html/fish/guppies.html au client.

    + +

    Si la requête concerne un répertoire (autrement dit un chemin se + terminant par un slash /), le nom du fichier qui sera + recherché et servi depuis ce répertoire est défini via la directive + DirectoryIndex. Par exemple, + supposons que DocumentRoot ait été définie comme + précédemment, et que vous ayez défini DirectoryIndex + comme suit :

    + +

    DirectoryIndex index.html index.php

    + +

    Si httpd reçoit alors une requête pour + http://www.example.com/fish/, il tentera de servir le + fichier /var/www/html/fish/index.html. Si ce fichier + n'existe pas, il tentera de servir le fichier + /var/www/html/fish/index.php.

    + +

    Si aucun de ces fichiers existe, httpd tentera de générer et + d'afficher un index du répertoire, à condition que + mod_autoindex ait été chargé et configuré pour le + permettre.

    + +

    httpd supporte aussi les Hôtes virtuels, + ce qui lui permet de traiter des requêtes pour plusieurs hôtes. + Dans ce cas, un DocumentRoot + différent peut être défini pour chaque hôte virtuel; + les directives fournies par le module + mod_vhost_alias peuvent aussi être utilisées afin de + déterminer dynamiquement le noeud approprié du système de fichiers + à partir duquel servir un contenu en fonction de l'adresse IP + ou du nom d'hôte.

    + +

    La directive DocumentRoot est + définie dans le fichier de configuration de votre serveur principal + (httpd.conf), mais peut aussi être redéfinie pour chaque + Hôte virtuel supplémentaire que vous avez créé.

    +
    top
    +
    +

    Fichiers situés en dehors de +l'arborescence DocumentRoot

    + +

    Il existe de nombreuses circonstances pour lesquelles il est nécessaire + d'autoriser l'accès web à des portions du système de fichiers qui ne se + trouvent pas dans l'arborescence DocumentRoot. httpd propose de nombreuses + solutions pour réaliser cela. Sur les systèmes Unix, les liens + symboliques permettent de rattacher d'autres portions du système de + fichiers au DocumentRoot. Pour des raisons de sécurité, + httpd ne suivra les liens symboliques que si les Options pour le répertoire concerné contiennent + FollowSymLinks ou SymLinksIfOwnerMatch.

    + +

    Une autre méthode consiste à utiliser la directive Alias pour rattacher toute portion + du système de fichiers à l'arborescence du site web. Par exemple, avec

    + +
    Alias "/docs" "/var/web"
    + + +

    l'URL http://www.example.com/docs/dir/file.html + correspondra au fichier /var/web/dir/file.html. La + directive + ScriptAlias + fonctionne de la même manière, excepté que tout contenu localisé dans le + chemin cible sera traité comme un script CGI.

    + +

    Pour les situations qui nécessitent plus de flexibilité, vous disposez + des directives AliasMatch + et ScriptAliasMatch + qui permettent des substitutions et comparaisons puissantes basées + sur les expressions rationnelles. + Par exemple,

    + +
    ScriptAliasMatch "^/~([a-zA-Z0-9]+)/cgi-bin/(.+)" "/home/$1/cgi-bin/$2"
    + + +

    fera correspondre une requête du style + http://example.com/~user/cgi-bin/script.cgi au chemin + /home/user/cgi-bin/script.cgi, et traitera le fichier résultant + comme un script CGI.

    +
    top
    +
    +

    Répertoires des utilisateurs

    + +

    Sur les systèmes Unix, on peut traditionnellement faire référence + au répertoire personnel d'un utilisateur particulier à l'aide de + l'expression ~user/. + Le module mod_userdir + étend cette idée au web en autorisant l'accès aux fichiers situés dans les + répertoires home des utilisateurs à l'aide d'URLs + comme dans ce qui suit :

    + +

    http://www.example.com/~user/file.html

    + +

    Pour des raisons de sécurité, il est déconseillé de permettre un accès + direct à un répertoire home d'utilisateur depuis le web. A cet effet, la + directive UserDir + spécifie un répertoire où sont situés les fichiers accessibles depuis le web + dans le répertoire home de l'utilisateur. + Avec la configuration par défaut + Userdir public_html, l'URL ci-dessus correspondra à un fichier + dont le chemin sera du style + /home/user/public_html/file.html où + /home/user/ est le répertoire home de l'utilisateur tel qu'il + est défini dans /etc/passwd.

    + +

    La directive Userdir met à votre disposition de nombreuses + formes différentes pour les systèmes où /etc/passwd ne + spécifie pas la localisation du répertoire home.

    + +

    Certains jugent le symbole "~" (dont le code sur le web est souvent + %7e) inapproprié et préfèrent utiliser une chaîne de + caractères différente pour représenter les répertoires utilisateurs. + mod_userdir ne supporte pas cette fonctionnalité. Cependant, si les + répertoires home des utilisateurs sont structurés de manière rationnelle, + il est possible d'utiliser la directive + AliasMatch + pour obtenir l'effet désiré. Par exemple, pour faire correspondre + http://www.example.com/upages/user/file.html à + /home/user/public_html/file.html, utilisez la directive + AliasMatch suivante :

    + +
    AliasMatch "^/upages/([a-zA-Z0-9]+)(/(.*))?$" "/home/$1/public_html/$3"
    + +
    top
    +
    +

    Redirection d'URL

    + +

    Les directives de configuration décrites dans les sections précédentes + demandent à httpd d'extraire un contenu depuis un emplacement spécifique + du système de fichiers + et de la retourner au client. Il est cependant parfois + souhaitable d'informer le + client que le contenu demandé est localisé à une URL différente, et de + demander au client d'élaborer une nouvelle requête avec la nouvelle URL. + Ce processus se nomme redirection et est implémenté par la + directive Redirect. + Par exemple, si le contenu du répertoire /foo/ sous + DocumentRoot est déplacé vers le + nouveau répertoire /bar/, vous pouvez demander aux clients + de le requérir à sa nouvelle localisation comme suit :

    + +
    Redirect permanent "/foo/"   "http://www.example.com/bar/"
    + + +

    Ceci aura pour effet de rediriger tout chemin d'URL commençant par + /foo/ vers le même chemin d'URL sur le serveur + www.example.com en remplaçant /foo/ par + /bar/. Vous pouvez rediriger les clients non seulement sur le + serveur d'origine, mais aussi vers n'importe quel autre serveur.

    + +

    httpd propose aussi la directive RedirectMatch pour traiter les problèmes + de réécriture d'une plus grande complexité. Par exemple, afin de rediriger + les requêtes pour la page d'accueil du site vers un site différent, mais + laisser toutes les autres requêtes inchangées, utilisez la + configuration suivante :

    + +
    RedirectMatch permanent "^/$" "http://www.example.com/startpage.html"
    + + +

    De même, pour rediriger temporairement toutes les pages d'un site + vers une page particulière d'un autre site, utilisez ce qui suit :

    + +
    RedirectMatch temp ".*" "http://othersite.example.com/startpage.html"
    + +
    top
    +
    +

    Mandataire inverse (Reverse Proxy)

    + +

    httpd vous permet aussi de rapatrier des documents distants +dans l'espace des URL du serveur local. +Cette technique est appelée mandataire inverse ou reverse +proxying car le serveur web agit comme un serveur mandataire en +rapatriant les documents depuis un serveur distant puis les renvoyant +au client. Ceci diffère d'un service de mandataire usuel (direct) car, pour le client, +les documents semblent appartenir au serveur mandataire inverse.

    + +

    Dans l'exemple suivant, quand les clients demandent des documents situés +dans le répertoire +/foo/, le serveur rapatrie ces documents depuis le répertoire +/bar/ sur internal.example.com +et les renvoie au client comme s'ils appartenaient au serveur local.

    + +
    ProxyPass        "/foo/" "http://internal.example.com/bar/"
+ProxyPassReverse "/foo/" "http://internal.example.com/bar/"
+ProxyPassReverseCookieDomain internal.example.com public.example.com
+ProxyPassReverseCookiePath "/foo/" "/bar/"
    + + +

    La directive ProxyPass configure +le serveur pour rapatrier les documents appropriés, alors que la directive +ProxyPassReverse +réécrit les redirections provenant de +internal.example.com de telle manière qu'elles ciblent le +répertoire approprié sur le serveur local. De manière similaire, les directives +ProxyPassReverseCookieDomain +et ProxyPassReverseCookiePath +réécrivent les cookies élaborés par le serveur d'arrière-plan.

    +

    Il est important de noter cependant, que les liens situés dans les documents +ne seront pas réécrits. Ainsi, tout lien absolu sur +internal.example.com fera décrocher le client +du serveur mandataire et effectuer sa requête directement sur +internal.example.com. Vous pouvez modifier ces liens (et +d'utres contenus) situés dans la page au moment où elle est envoyée au +client en utilisant le module mod_substitute.

    + +
    Substitute s/internal\.example\.com/www.example.com/i
    + + +

    Le module mod_proxy_html rend possible une réécriture plus +élaborée des liens en HTML et XHTML. Il permet de créer des listes +d'URLs et de leurs réécritures, de façon à pouvoir gérer des scénarios +de réécriture complexes.

    +
    top
    +
    +

    Moteur de réécriture

    + +

    Le moteur de réécriture mod_rewrite peut s'avérer + utile lorsqu'une substitution plus puissante est nécessaire. + Les directives fournies par ce module peuvent utiliser des caractéristiques de la + requête comme le type de navigateur ou l'adresse IP source afin de décider + depuis où servir le contenu. En outre, mod_rewrite peut utiliser des + fichiers ou programmes de bases de données externes pour déterminer comment + traiter une requête. Le moteur de réécriture peut effectuer les trois types + de mise en correspondance discutés plus haut : + redirections internes (aliases), redirections externes, et services mandataires. + De nombreux exemples pratiques utilisant mod_rewrite sont discutés dans la + documentation détaillée de mod_rewrite.

    +
    top
    +
    +

    Fichier non trouvé (File Not Found)

    + +

    Inévitablement, apparaîtront des URLs qui ne correspondront à aucun + fichier du système de fichiers. + Ceci peut arriver pour de nombreuses raisons. + Il peut s'agir du déplacement de documents d'une + localisation vers une autre. Dans ce cas, le mieux est d'utiliser la + redirection d'URL pour informer les clients de la + nouvelle localisation de la ressource. De cette façon, vous êtes sur que + les anciens signets et liens continueront de fonctionner, même si la + ressource est déplacée.

    + +

    Une autre cause fréquente d'erreurs "File Not Found" est l'erreur de + frappe accidentelle dans les URLs, soit directement dans le navigateur, + soit dans les liens HTML. httpd propose le module + mod_speling (sic) pour tenter de résoudre ce problème. + Lorsque ce module est activé, il intercepte les erreurs + "File Not Found" et recherche une ressource possédant un nom de fichier + similaire. Si un tel fichier est trouvé, mod_speling va envoyer une + redirection HTTP au client pour lui communiquer l'URL correcte. + Si plusieurs fichiers proches sont trouvés, une liste des alternatives + possibles sera présentée au client.

    + +

    mod_speling possède une fonctionnalité particulièrement utile : + il compare les noms de fichiers sans tenir compte de la casse. + Ceci peut aider les systèmes où les utilisateurs ne connaissent pas la + sensibilité des URLs à la casse et bien sûr les systèmes de fichiers unix. + Mais l'utilisation de mod_speling pour toute autre chose que la correction + occasionnelle d'URLs peut augmenter la charge du serveur, car chaque + requête "incorrecte" entraîne une redirection d'URL et une nouvelle requête + de la part du client.

    + +

    mod_dir fournit la directive FallbackResource qui permet d'associer + des URIs virtuels à une ressource réelle qui peut ainsi les servir. + Cette directive remplace avantageusement + mod_rewrite lors de l'implémentation d'un + "contrôleur frontal".

    + +

    Si toutes les tentatives pour localiser le contenu + échouent, httpd + retourne une page d'erreur avec le code de statut HTTP 404 + (file not found). L'apparence de cette page est contrôlée à l'aide de la + directive ErrorDocument + et peut être personnalisée de manière très flexible comme discuté dans le + document + Réponses personnalisées aux erreurs.

    +
    top
    +
    +

    Autres modules de mise en correspondance des +URLs

    + + + +

    Les autres modules disponibles pour la mise en correspondance des + URLs sont :

    +
      +
    • mod_actions - Met une URL en correspondance + avec un script CGI en fonction de la méthode de la requête, ou du + type MIME de la ressource.
      • +
    • mod_dir - Permet une mise en correspondance + basique d'un slash terminal dans un fichier index comme + index.html.
      • +
    • mod_imagemap - Met en correspondance une + requête avec une URL en fonction de la zone d'une image intégrée à + un document HTML dans laquelle un utilisateur clique.
      • +
    • mod_negotiation - Sélectionne le document + approprié en fonction de préférences du client telles que la langue + ou la compression du contenu.
      • +
    + +
    +
    +

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

    +
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    +
    + \ No newline at end of file diff --git a/docs/manual/vhosts/details.html.en b/docs/manual/vhosts/details.html.en index d31db5235e..2824e2a1f7 100644 --- a/docs/manual/vhosts/details.html.en +++ b/docs/manual/vhosts/details.html.en @@ -24,9 +24,9 @@ Apache > HTTP Server > Documentation > Version 2.5 > Virtual Hosts

    An In-Depth Discussion of Virtual Host Matching

    Available Languages:  en  | - fr  | + fr  |  ko  | - tr 

    + tr 

    @@ -318,9 +318,9 @@

    Available Languages:  en  | - fr  | + fr  |  ko  | - tr 

    + tr 

    top

    Comments

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    - - -
    -

    Modules | Directives | FAQ | Glossaire | Plan du site

    -

    Serveur HTTP Apache Version 2.5

    -
    -
    <-
    -

    Détails sur le fonctionnement des serveurs virtuels

    -
    -

    Langues Disponibles:  en  | - fr  | - ko  | - tr 

    -
    - - -

    Ce document vise à expliquer dans le détail comment le serveur - HTTP Apache procède lors du choix de l'utilisation - d'un serveur virtuel en fonction d'une requête reçue.

    - -

    Il est recommandé de lire la documentation - Serveurs virtuels à base de nom et serveurs virtuels à base - d'adresse IP pour déterminer quel type de serveur virtuel nous - convient le mieux, puis de lire les documentations serveurs virtuels à base de nom ou serveurs virtuels à base d'adresse IP, et enfin - d'étudier quelques exemples.

    - -

    Si vous voulez entrer dans les détails, vous pouvez revenir vers - cette page.

    - -
    - -
    top
    -
    -

    Fichier de configuration

    - -

    Un serveur principal (main_server) contient toutes - les définitions qui apparaissent en dehors des sections - <VirtualHost>.

    - -

    Les serveurs virtuels, aussi - appelés vhosts (pour virtual hosts), sont définis par les - sections <VirtualHost>.

    - -

    Chaque directive VirtualHost comporte une ou - plusieurs adresses et des ports optionnels.

    - -

    Il est possible d'utiliser des noms d'hôtes dans la définition - d'un serveur virtuel, mais ils seront résolus en adresses IP au - démarrage du serveur, et si une résolution de nom échoue, cette - définition de serveur virtuel sera ignorée. Cette méthode est par - conséquent déconseillée.

    - -

    L'adresse peut - être spécifiée sous la forme *, ce qui conviendra à la - requête si aucun autre serveur virtuel ne possède l'adresse IP - explicite correspondant à celle de la requête.

    - -

    L'adresse qui apparaît dans la directive VirtualHost - peut être associée à un port optionnel. Si aucun port n'est - spécifié, il s'agit d'un port générique qui peut aussi être spécifié - comme *. Le port générique correspond à toutes les - valeurs de port.

    - -

    (Il ne faut pas confondre les numéros de port sur lesquels Apache - est en écoute avec les numéros de port spécifiés dans la directive - VirtualHost ; ces derniers ne servent qu'à définir le - serveur virtuel qui sera sélectionné pour traiter la - requête. Pour définir les ports sur lesquels Apache est en écoute, - utilisez la directive Listen). -

    - -

    L'ensemble des adresses (y compris les résultats multiples - A issus des requêtes DNS) est appelé jeu - d'adresses du serveur virtuel.

    - -

    Apache fait automatiquement sa sélection à partir de l'en-tête - HTTP Host fourni par le client, lorsque la - correspondance la plus exacte du point de vue adresse IP/port a lieu - pour plusieurs serveurs virtuels.

    - -

    La directive ServerName peut - apparaître en quelque endroit de la définition d'un serveur. - Cependant, chaque occurrence écrase la précédente (pour ce serveur). - Si aucune directive ServerName n'est spécifiée, le - serveur tente de déterminer le nom du serveur à partir de l'adresse - IP.

    - -

    Le premier serveur virtuel à base de nom apparaissant dans le - fichier de configuration pour une paire IP:port donnée est - significatif car c'est lui qui sera utilisé pour toutes les requêtes - reçues sur cette adresse IP/port et pour laquelle aucun autre - serveur virtuel ne possède un ServerName ou un ServerAlias - correspondant. Il sera aussi utilisé pour toutes les connexions SSL - si le serveur ne supporte pas l'Indication du nom du serveur.

    - -

    Tous les noms spécifiés au sein d'une section - VirtualHost sont traités comme un - ServerAlias (sans caractères génériques), mais ne sont - écrasés par aucune directive ServerAlias.

    - -

    Pour chaque serveur virtuel, diverses valeurs sont initialisées - par défaut. En particulier :

    - -
      -
    1. Dans le cas où un serveur virtuel ne contient pas de directives - ServerAdmin, - Timeout, - KeepAliveTimeout, - KeepAlive, - MaxKeepAliveRequests, - ReceiveBufferSize, - ou SendBufferSize, - alors la valeur de chacun de ces paramètres est héritée de celle du - serveur principal. (C'est à dire, héritée de la valeur finale après - lecture de la configuration du serveur principal.)
      2. - -
    2. Les permissions par défaut sur les répertoires de chaque - serveur virtuel sont assemblées avec celles du serveur principal. - Elles concernent également toutes les informations de configuration - par répertoire pour tous les modules.
      3. - -
    3. Les configurations par serveur pour chaque module sont assemblées - à partir de celles du serveur principal.
      4. -
    - -

    L'essentiel des valeurs de configuration des serveurs virtuels - provient de valeurs par défaut issues du serveur principal. - Mais la position dans le fichier de configuration des directives - du serveur principal n'a pas d'importance -- l'ensemble de la - configuration du serveur principal est lu avant que ces valeurs par - défaut soient appliquées aux serveur virtuels. Ainsi, même si la - définition d'une valeur apparaît après celle d'un serveur virtuel, - cette valeur peut affecter la definition du serveur virtuel.

    - -

    Dans le cas où le serveur principal n'a pas de ServerName - à ce stade, le nom de la machine sur laquelle tourne le programme - httpd est utilisé à sa place. Nous appellerons - jeu d'adresses du serveur principal les adresses IP - renvoyées par une résolution DNS sur le ServerName - du serveur principal.

    - -

    Pour tous les champs ServerName non définis, dans - le cas d'une configuration en serveur virtuel par nom, la valeur - adoptée par défaut est la première adresse donnée dans la section - VirtualHost qui définit le serveur virtuel.

    - -

    Si un serveur virtuel contient la valeur magique - _default_, il fonctionne sur le même ServerName - que le serveur principal.

    - -
    top
    -
    -

    Choix du serveur virtuel

    - -

    À la réception d'une requête, le serveur procède comme suit pour - déterminer quel serveur virtuel utiliser :

    - -

    Recherche de l'adresse IP

    - -

    Lors d'une première connexion sur une adresse/port, le serveur - recherche toutes les directives VirtualHost qui - possèdent la même adresse IP/port.

    - -

    S'il n'y a aucune correspondance exacte pour cette adresse/port, - la recherche s'effectue sur la valeur générique (*).

    - -

    Si aucune correspondance n'est enfin trouvée, la requête sera - servie par le serveur principal.

    - -

    S'il existe des définitions VirtualHost pour - l'adresse IP, l'étape suivante consiste à déterminer si nous avons à - faire à un serveur virtuel à base de nom ou d'adresse IP.

    - - - -

    Serveur virtuel par IP

    - -

    Si une seule section VirtualHost présente la - meilleure correspondance avec la paire adresse IP/port, aucune - action n'est entreprise et la requête est - traitée par le serveur virtuel qui correspond.

    - - - -

    Serveur virtuel par nom

    - -

    Si plusieurs sections VirtualHost présentent la - meilleure correspondance avec la paire adresse IP/port, le terme - "liste" dans les étapes suivantes fait référence à la liste des - serveurs virtuels qui correspondent, selon l'ordre dans lequel ils - apparaissent dans le fichier de configuration.

    - -

    Si la connexion utilise SSL, si le serveur supporte l'Indication de nom de serveur, - et si la négociation du client SSL inclut l'extension TLS dans le - nom d'hôte requis, alors ce nom d'hôte sera utilisé par la suite, tout - comme un en-tête Host: aurait été utilisé dans le cas - d'une connexion non-SSL. Si ces conditions ne sont pas réunies, le - premier serveur virtuel à base de nom dont l'adresse correspond sera - utilisé pour les connexions SSL. Ceci est important car c'est le - serveur virtuel qui détermine quel certificat le serveur va utiliser - pour la connexion.

    - -

    Si la requête contient un en-tête Host:, on - recherche dans la liste le premier serveur virtuel dont le - ServerName ou le ServerAlias correspond, - et c'est celui-ci qui va traiter la requête. Un en-tête - Host: peut comporter un numéro de port mais Apache - l'ignore systématiquement et utilise toujours le - port sur lequel il a effectivement reçu la requête.

    - -

    Le premier serveur virtuel du fichier de configuration qui - possède l'adresse spécifiée est prioritaire et intercepte toutes les - requêtes à destination d'un nom de serveur inconnu, ou toute requête - sans en-tête Host: (comme les requêtes HTTP/1.0).

    - - - -

    Connexions persistantes

    - -

    La recherche par adresse IP décrite ci-avant n'est faite - qu'une fois pour chaque session TCP/IP, alors que la - recherche par nom est réalisée pour chaque requête au - cours d'une connexion persistante (KeepAlive). En d'autres termes, - il est possible pour un client de faire des requêtes sur - différents serveurs virtuels par nom, au cours d'une unique - connexion persistante.

    - - - -

    URI absolu

    - -

    Au cas où l'URI de la requête est absolu, et que son nom de - serveur et son port correspondent au serveur principal (ou l'un - des serveurs virtuels configurés), et qu'ils correspondent - à l'adresse et au port de la requête, alors l'URI est amputé - de son préfixe protocole/nom de serveur/port et traité par le - serveur correspondant (principal ou virtuel). Si cette correspondance - n'existe pas, l'URI reste inchangé et la requête est considérée - comme une requête d'un serveur mandataire (proxy).

    - - -

    Observations

    - -
      -
    • La sélection d'un serveur virtuel en fonction de son nom est - un processus qui intervient après la sélection par le serveur du - serveur virtuel qui correspond le mieux du point de vue adresse - IP/port.
      • - -
    • Si vous ne tenez pas compte de l'adresse IP à laquelle le - client s'est connecté, indiquez un caractère "*" comme adresse - pour tous les serveurs virtuels, et la sélection du serveur - virtuel en fonction du nom s'appliquera alors à tous les serveurs - virtuels définis.
      • - -
    • Les vérifications sur ServerName et - ServerAlias ne sont jamais - réalisées pour les serveurs virtuels par IP.
      • - -
    • Seul l'ordre des serveurs virtuels par nom - pour une adresse donnée a une importance. Le serveur virtuel - par nom qui est présent en premier dans la configuration se - voit attribué la priorité la plus haute pour les requêtes - arrivant sur son jeu d'adresses IP.
      • - -
    • Le numéro de port contenu dans l'en-tête Host: n'est jamais utilisé - pour les tests de correspondances. Apache ne prend en compte - que le numéro de port sur lequel le client a envoyé la requête.
      • - -
    • Si deux serveurs virtuels partagent la même adresse, la - sélection se fera implicitement sur le nom. Il s'agit d'une - nouvelle fonctionnalité de la version 2.3.11.
      • - -
    • Le serveur principal ne sert les requêtes que - lorsque l'adresse IP et le port demandés par le client ne - correspondent à aucun serveur virtuel (y compris un serveur - virtuel *). En d'autres termes, le serveur - principal n'est utile que pour les combinaisons adresse/port - non spécifiées (sauf quand un serveur virtuel _default_ - correspond au port).
      • - -
    • Il ne faut jamais employer de noms DNS dans des directives - VirtualHost, car cela oblige le serveur a s'appuyer - sur le DNS au moment du démarrage. De plus, vous vous exposez - à des problèmes de sécurité si vous n'avez pas la maîtrise du - DNS pour la totalité de vos domaines. Voir la documentation - disponible ici, ainsi que - les deux points précisés ci-après.
      • - -
    • Un nom de serveur ServerName devrait toujours - être indiqué pour chaque serveur virtuel. Sans cela, une - résolution DNS est nécessaire pour chaque serveur virtuel.
      • -
    - - -
    top
    -
    -

    Trucs et astuces

    - -

    En plus des points évoqués sur la page des - problèmes liés au DNS, - voici quelques points intéressants :

    - -
      -
    • Toujours positionner les définitions relatives au serveur - principal avant toute définition VirtualHost. - (Ceci améliore grandement la lisibilité de la configuration - -- la manière dont la configuration est interprétée après la - lecture des fichiers ne met pas en évidence le fait que les - définitions positionnées avant et surtout après les serveurs - virtuels peuvent impacter le fonctionnement de tous les - serveurs virtuels.)
      • - -
    - -
    -
    -

    Langues Disponibles:  en  | - fr  | - ko  | - tr 

    -
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    -
    - \ No newline at end of file diff --git a/docs/manual/vhosts/details.html.fr.utf8 b/docs/manual/vhosts/details.html.fr.utf8 new file mode 100644 index 0000000000..fdf206fdf1 --- /dev/null +++ b/docs/manual/vhosts/details.html.fr.utf8 @@ -0,0 +1,369 @@ + + + + + +Détails sur le fonctionnement des serveurs virtuels - Serveur HTTP Apache Version 2.5 + + + + + + +
    +

    Modules | Directives | FAQ | Glossaire | Plan du site

    +

    Serveur HTTP Apache Version 2.5

    +
    +
    <-
    +

    Détails sur le fonctionnement des serveurs virtuels

    +
    +

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

    +
    + + +

    Ce document vise à expliquer dans le détail comment le serveur + HTTP Apache procède lors du choix de l'utilisation + d'un serveur virtuel en fonction d'une requête reçue.

    + +

    Il est recommandé de lire la documentation + Serveurs virtuels à base de nom et serveurs virtuels à base + d'adresse IP pour déterminer quel type de serveur virtuel nous + convient le mieux, puis de lire les documentations serveurs virtuels à base de nom ou serveurs virtuels à base d'adresse IP, et enfin + d'étudier quelques exemples.

    + +

    Si vous voulez entrer dans les détails, vous pouvez revenir vers + cette page.

    + +
    + +
    top
    +
    +

    Fichier de configuration

    + +

    Un serveur principal (main_server) contient toutes + les définitions qui apparaissent en dehors des sections + <VirtualHost>.

    + +

    Les serveurs virtuels, aussi + appelés vhosts (pour virtual hosts), sont définis par les + sections <VirtualHost>.

    + +

    Chaque directive VirtualHost comporte une ou + plusieurs adresses et des ports optionnels.

    + +

    Il est possible d'utiliser des noms d'hôtes dans la définition + d'un serveur virtuel, mais ils seront résolus en adresses IP au + démarrage du serveur, et si une résolution de nom échoue, cette + définition de serveur virtuel sera ignorée. Cette méthode est par + conséquent déconseillée.

    + +

    L'adresse peut + être spécifiée sous la forme *, ce qui conviendra à la + requête si aucun autre serveur virtuel ne possède l'adresse IP + explicite correspondant à celle de la requête.

    + +

    L'adresse qui apparaît dans la directive VirtualHost + peut être associée à un port optionnel. Si aucun port n'est + spécifié, il s'agit d'un port générique qui peut aussi être spécifié + comme *. Le port générique correspond à toutes les + valeurs de port.

    + +

    (Il ne faut pas confondre les numéros de port sur lesquels Apache + est en écoute avec les numéros de port spécifiés dans la directive + VirtualHost ; ces derniers ne servent qu'à définir le + serveur virtuel qui sera sélectionné pour traiter la + requête. Pour définir les ports sur lesquels Apache est en écoute, + utilisez la directive Listen). +

    + +

    L'ensemble des adresses (y compris les résultats multiples + A issus des requêtes DNS) est appelé jeu + d'adresses du serveur virtuel.

    + +

    Apache fait automatiquement sa sélection à partir de l'en-tête + HTTP Host fourni par le client, lorsque la + correspondance la plus exacte du point de vue adresse IP/port a lieu + pour plusieurs serveurs virtuels.

    + +

    La directive ServerName peut + apparaître en quelque endroit de la définition d'un serveur. + Cependant, chaque occurrence écrase la précédente (pour ce serveur). + Si aucune directive ServerName n'est spécifiée, le + serveur tente de déterminer le nom du serveur à partir de l'adresse + IP.

    + +

    Le premier serveur virtuel à base de nom apparaissant dans le + fichier de configuration pour une paire IP:port donnée est + significatif car c'est lui qui sera utilisé pour toutes les requêtes + reçues sur cette adresse IP/port et pour laquelle aucun autre + serveur virtuel ne possède un ServerName ou un ServerAlias + correspondant. Il sera aussi utilisé pour toutes les connexions SSL + si le serveur ne supporte pas l'Indication du nom du serveur.

    + +

    Tous les noms spécifiés au sein d'une section + VirtualHost sont traités comme un + ServerAlias (sans caractères génériques), mais ne sont + écrasés par aucune directive ServerAlias.

    + +

    Pour chaque serveur virtuel, diverses valeurs sont initialisées + par défaut. En particulier :

    + +
      +
    1. Dans le cas où un serveur virtuel ne contient pas de directives + ServerAdmin, + Timeout, + KeepAliveTimeout, + KeepAlive, + MaxKeepAliveRequests, + ReceiveBufferSize, + ou SendBufferSize, + alors la valeur de chacun de ces paramètres est héritée de celle du + serveur principal. (C'est à dire, héritée de la valeur finale après + lecture de la configuration du serveur principal.)
      2. + +
    2. Les permissions par défaut sur les répertoires de chaque + serveur virtuel sont assemblées avec celles du serveur principal. + Elles concernent également toutes les informations de configuration + par répertoire pour tous les modules.
      3. + +
    3. Les configurations par serveur pour chaque module sont assemblées + à partir de celles du serveur principal.
      4. +
    + +

    L'essentiel des valeurs de configuration des serveurs virtuels + provient de valeurs par défaut issues du serveur principal. + Mais la position dans le fichier de configuration des directives + du serveur principal n'a pas d'importance -- l'ensemble de la + configuration du serveur principal est lu avant que ces valeurs par + défaut soient appliquées aux serveur virtuels. Ainsi, même si la + définition d'une valeur apparaît après celle d'un serveur virtuel, + cette valeur peut affecter la definition du serveur virtuel.

    + +

    Dans le cas où le serveur principal n'a pas de ServerName + à ce stade, le nom de la machine sur laquelle tourne le programme + httpd est utilisé à sa place. Nous appellerons + jeu d'adresses du serveur principal les adresses IP + renvoyées par une résolution DNS sur le ServerName + du serveur principal.

    + +

    Pour tous les champs ServerName non définis, dans + le cas d'une configuration en serveur virtuel par nom, la valeur + adoptée par défaut est la première adresse donnée dans la section + VirtualHost qui définit le serveur virtuel.

    + +

    Si un serveur virtuel contient la valeur magique + _default_, il fonctionne sur le même ServerName + que le serveur principal.

    + +
    top
    +
    +

    Choix du serveur virtuel

    + +

    À la réception d'une requête, le serveur procède comme suit pour + déterminer quel serveur virtuel utiliser :

    + +

    Recherche de l'adresse IP

    + +

    Lors d'une première connexion sur une adresse/port, le serveur + recherche toutes les directives VirtualHost qui + possèdent la même adresse IP/port.

    + +

    S'il n'y a aucune correspondance exacte pour cette adresse/port, + la recherche s'effectue sur la valeur générique (*).

    + +

    Si aucune correspondance n'est enfin trouvée, la requête sera + servie par le serveur principal.

    + +

    S'il existe des définitions VirtualHost pour + l'adresse IP, l'étape suivante consiste à déterminer si nous avons à + faire à un serveur virtuel à base de nom ou d'adresse IP.

    + + + +

    Serveur virtuel par IP

    + +

    Si une seule section VirtualHost présente la + meilleure correspondance avec la paire adresse IP/port, aucune + action n'est entreprise et la requête est + traitée par le serveur virtuel qui correspond.

    + + + +

    Serveur virtuel par nom

    + +

    Si plusieurs sections VirtualHost présentent la + meilleure correspondance avec la paire adresse IP/port, le terme + "liste" dans les étapes suivantes fait référence à la liste des + serveurs virtuels qui correspondent, selon l'ordre dans lequel ils + apparaissent dans le fichier de configuration.

    + +

    Si la connexion utilise SSL, si le serveur supporte l'Indication de nom de serveur, + et si la négociation du client SSL inclut l'extension TLS dans le + nom d'hôte requis, alors ce nom d'hôte sera utilisé par la suite, tout + comme un en-tête Host: aurait été utilisé dans le cas + d'une connexion non-SSL. Si ces conditions ne sont pas réunies, le + premier serveur virtuel à base de nom dont l'adresse correspond sera + utilisé pour les connexions SSL. Ceci est important car c'est le + serveur virtuel qui détermine quel certificat le serveur va utiliser + pour la connexion.

    + +

    Si la requête contient un en-tête Host:, on + recherche dans la liste le premier serveur virtuel dont le + ServerName ou le ServerAlias correspond, + et c'est celui-ci qui va traiter la requête. Un en-tête + Host: peut comporter un numéro de port mais Apache + l'ignore systématiquement et utilise toujours le + port sur lequel il a effectivement reçu la requête.

    + +

    Le premier serveur virtuel du fichier de configuration qui + possède l'adresse spécifiée est prioritaire et intercepte toutes les + requêtes à destination d'un nom de serveur inconnu, ou toute requête + sans en-tête Host: (comme les requêtes HTTP/1.0).

    + + + +

    Connexions persistantes

    + +

    La recherche par adresse IP décrite ci-avant n'est faite + qu'une fois pour chaque session TCP/IP, alors que la + recherche par nom est réalisée pour chaque requête au + cours d'une connexion persistante (KeepAlive). En d'autres termes, + il est possible pour un client de faire des requêtes sur + différents serveurs virtuels par nom, au cours d'une unique + connexion persistante.

    + + + +

    URI absolu

    + +

    Au cas où l'URI de la requête est absolu, et que son nom de + serveur et son port correspondent au serveur principal (ou l'un + des serveurs virtuels configurés), et qu'ils correspondent + à l'adresse et au port de la requête, alors l'URI est amputé + de son préfixe protocole/nom de serveur/port et traité par le + serveur correspondant (principal ou virtuel). Si cette correspondance + n'existe pas, l'URI reste inchangé et la requête est considérée + comme une requête d'un serveur mandataire (proxy).

    + + +

    Observations

    + +
      +
    • La sélection d'un serveur virtuel en fonction de son nom est + un processus qui intervient après la sélection par le serveur du + serveur virtuel qui correspond le mieux du point de vue adresse + IP/port.
      • + +
    • Si vous ne tenez pas compte de l'adresse IP à laquelle le + client s'est connecté, indiquez un caractère "*" comme adresse + pour tous les serveurs virtuels, et la sélection du serveur + virtuel en fonction du nom s'appliquera alors à tous les serveurs + virtuels définis.
      • + +
    • Les vérifications sur ServerName et + ServerAlias ne sont jamais + réalisées pour les serveurs virtuels par IP.
      • + +
    • Seul l'ordre des serveurs virtuels par nom + pour une adresse donnée a une importance. Le serveur virtuel + par nom qui est présent en premier dans la configuration se + voit attribué la priorité la plus haute pour les requêtes + arrivant sur son jeu d'adresses IP.
      • + +
    • Le numéro de port contenu dans l'en-tête Host: n'est jamais utilisé + pour les tests de correspondances. Apache ne prend en compte + que le numéro de port sur lequel le client a envoyé la requête.
      • + +
    • Si deux serveurs virtuels partagent la même adresse, la + sélection se fera implicitement sur le nom. Il s'agit d'une + nouvelle fonctionnalité de la version 2.3.11.
      • + +
    • Le serveur principal ne sert les requêtes que + lorsque l'adresse IP et le port demandés par le client ne + correspondent à aucun serveur virtuel (y compris un serveur + virtuel *). En d'autres termes, le serveur + principal n'est utile que pour les combinaisons adresse/port + non spécifiées (sauf quand un serveur virtuel _default_ + correspond au port).
      • + +
    • Il ne faut jamais employer de noms DNS dans des directives + VirtualHost, car cela oblige le serveur a s'appuyer + sur le DNS au moment du démarrage. De plus, vous vous exposez + à des problèmes de sécurité si vous n'avez pas la maîtrise du + DNS pour la totalité de vos domaines. Voir la documentation + disponible ici, ainsi que + les deux points précisés ci-après.
      • + +
    • Un nom de serveur ServerName devrait toujours + être indiqué pour chaque serveur virtuel. Sans cela, une + résolution DNS est nécessaire pour chaque serveur virtuel.
      • +
    + + +
    top
    +
    +

    Trucs et astuces

    + +

    En plus des points évoqués sur la page des + problèmes liés au DNS, + voici quelques points intéressants :

    + +
      +
    • Toujours positionner les définitions relatives au serveur + principal avant toute définition VirtualHost. + (Ceci améliore grandement la lisibilité de la configuration + -- la manière dont la configuration est interprétée après la + lecture des fichiers ne met pas en évidence le fait que les + définitions positionnées avant et surtout après les serveurs + virtuels peuvent impacter le fonctionnement de tous les + serveurs virtuels.)
      • + +
    + +
    +
    +

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

    +
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    +
    + \ No newline at end of file diff --git a/docs/manual/vhosts/examples.html.en b/docs/manual/vhosts/examples.html.en index 7ac24b5712..4f1cef2c72 100644 --- a/docs/manual/vhosts/examples.html.en +++ b/docs/manual/vhosts/examples.html.en @@ -24,10 +24,10 @@ Apache > HTTP Server > Documentation > Version 2.5 > Virtual Hosts

    VirtualHost Examples

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

    + tr 

    @@ -546,10 +546,10 @@ DocumentRoot "/www/example1"

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

    + tr 

    top

    Comments

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    - - -
    -

    Modules | Directives | FAQ | Glossaire | Plan du site

    -

    Serveur HTTP Apache Version 2.5

    -
    -
    <-
    -

    Exemples d'utilisations de VirtualHost

    -
    -

    Langues Disponibles:  en  | - fr  | - ja  | - ko  | - tr 

    -
    - - -

    Le but de ce document est d'essayer de répondre aux questions - les plus fréquentes sur la configuration des serveurs virtuels. - Les scénarios présentés ici se rencontrent quand plusieurs - serveurs web doivent tourner sur une seule et même machine au - moyen de serveurs virtuels par nom - ou par IP.

    - -

    Note à propos du contexte de configuration

    Les serveurs virtuels - doivent être spécifiés au niveau de la configuration globale du serveur. - Certaines distributions tierces du serveur peuvent cependant utiliser un fichier de - configuration initial alternatif ou des fichiers de configuration multiples - qui acceptent tous des directives à portée globale. Elles peuvent aussi - proposer une convention de spécification des serveurs virtuels au sein de - ces fichiers multiples qui seront eux-mêmes inclus dans le fichier de - configuration global via la directive Include. Vous pourrez trouver plus de détails dans - le README de la distribution tierce, tel que - /usr/share/doc/apache2/README.Debian.gz pour les distributions basées sur - Debian et Ubuntu.

    -
    - -
    - -
    top
    -
    -

    Fonctionnement de plusieurs serveurs - virtuels par nom sur une seule adresse IP.

    - -

    Votre serveur possède plusieurs noms d'hôte qui correspondent à - une seule adresse IP, ce qui lui permet de répondre différemment si - une requête est envoyée à www.example.com ou - www.example.org.

    - -

    Note :

    La configuration de serveurs virtuels - sous Apache ne provoque pas leur apparition magique dans la - configuration du DNS. Il faut que leurs noms soient - définis dans le DNS, et qu'ils y soient résolus sur l'adresse IP - du serveur, faute de quoi personne ne pourra visiter votre site Web. - Il est possible d'ajouter des entrées dans le fichier - hosts pour tests locaux, mais qui ne fonctionneront - que sur la machine possédant ces entrées.

    -
    - - 
    # Apache doit écouter sur le port 80
-Listen 80
-<VirtualHost *:80>
-    DocumentRoot "/www/example1"
-    ServerName www.example.com
-  
-    # Autres directives ici
-</VirtualHost>
-
-<VirtualHost *:80>
-    DocumentRoot "/www/example2"
-    ServerName www.example.org
-
-    # Autres directives ici
-</VirtualHost>
    - - - -

    Les astérisques correspondent à toutes les adresses, si bien que - le serveur principal ne répondra jamais à aucune requête. Comme le - serveur virtuel - ServerName www.example.com se trouve en premier dans le fichier - de configuration, il a la plus grande priorité et peut être vu - comme serveur par défaut ou primaire ; - ce qui signifie que toute requête reçue ne correspondant à aucune - des directives ServerName sera servie par ce premier - <VirtualHost>.

    - -

    La configuration ci-dessus correspond à ce que l'on souhaite pour - la plupart des serveurs virtuels à base de nom. Il faudra cependant - utiliser une configuration différente si vous souhaitez servir un - contenu différent en fonction de l'adresse IP ou du port.

    - -
    -

    Note :

    - -

    Vous pouvez remplacer * - par une adresse IP du système. Le serveur virtuel concerné - ne sera alors sélectionné que pour les requêtes HTTP vers - cette adresse IP.

    - -

    En général, il est commode d'utiliser * sur - les systèmes dont l'adresse IP n'est pas constante - par - exemple, pour des serveurs dont l'adresse IP est attribuée - dynamiquement par le FAI, et où le DNS est géré au moyen - d'un DNS dynamique quelconque. Comme * signifie - n'importe quelle adresse, cette configuration - fonctionne sans devoir être modifiée quand l'adresse IP du - système est modifiée.

    -
    - -
    top
    -
    -

    Serveurs virtuels par nom sur plus - d'une seule adresse IP.

    - -
    -

    Note :

    Toutes les techniques présentées ici - peuvent être étendues à un plus grand nombre d'adresses IP.

    -
    - -

    Le serveur a deux adresses IP. Sur l'une - (172.20.30.40), le serveur "principal" - server.example.com doit répondre, et sur l'autre - (172.20.30.50), deux serveurs virtuels (ou plus) - répondront.

    - - 
    Listen 80
-
-# Serveur "principal" sur 172.20.30.40
-ServerName server.example.com
-DocumentRoot "/www/mainserver"
-
-<VirtualHost 172.20.30.50>
-    DocumentRoot "/www/example1"
-    ServerName www.example.com
-    
-    # D'autres directives ici ...
-</VirtualHost>
-
-<VirtualHost 172.20.30.50>
-    DocumentRoot "/www/example2"
-    ServerName www.example.org
-    
-    # D'autres directives ici ...
-</VirtualHost>
    - - -

    Toute requête arrivant sur une autre adresse que - 172.20.30.50 sera servie par le serveur principal. - Les requêtes vers 172.20.30.50 avec un nom de serveur - inconnu, ou sans en-tête Host:, seront servies par - www.example.com.

    - -
    top
    -
    -

    Servir le même contenu sur des - adresses IP différentes (telle qu'une adresse interne et une - externe).

    - -

    La machine serveur dispose de deux adresses IP - (192.168.1.1 et 172.20.30.40). Cette - machine est placée à la fois sur le réseau interne (l'Intranet) - et le réseau externe (Internet). Sur Internet, le nom - server.example.com pointe vers l'adresse externe - (172.20.30.40), mais sur le réseau interne, ce même - nom pointe vers l'adresse interne (192.168.1.1).

    - -

    Le serveur peut être configuré pour répondre de la même manière - aux requêtes internes et externes, au moyen d'une seule section - <VirtualHost>.

    - - 
    <VirtualHost 192.168.1.1 172.20.30.40>
-    DocumentRoot "/www/server1"
-    ServerName server.example.com
-    ServerAlias server
-</VirtualHost>
    - - -

    Ainsi, les requêtes en provenance de chacun des deux réseaux - seront servies par le même <VirtualHost>.

    - -
    -

    Note :

    Sur le réseau interne, il est possible - d'utiliser le nom raccourci server au lieu du nom - complet server.example.com.

    - -

    Notez également que dans l'exemple précédent, vous pouvez - remplacer la liste des adresses IP par des * afin - que le serveur réponde de la même manière sur toutes ses - adresses.

    -
    - -
    top
    -
    -

    Servir différents sites sur différents - ports.

    - -

    Vous disposez de plusieurs domaines pointant sur la même adresse - IP et vous voulez également servir de multiples ports. L'exemple - suivant montre que la sélection en fonction du nom intervient après - la sélection de la meilleure correspondance du point de vue adresse - IP/port.

    - - 
    Listen 80
-Listen 8080
-
-<VirtualHost 172.20.30.40:80>
-    ServerName www.example.com
-    DocumentRoot "/www/domain-80"
-</VirtualHost>
-
-<VirtualHost 172.20.30.40:8080>
-    ServerName www.example.com
-    DocumentRoot "/www/domain-8080"
-</VirtualHost>
-
-<VirtualHost 172.20.30.40:80>
-    ServerName www.example.org
-    DocumentRoot "/www/otherdomain-80"
-</VirtualHost>
-
-<VirtualHost 172.20.30.40:8080>
-    ServerName www.example.org
-    DocumentRoot "/www/otherdomain-8080"
-</VirtualHost>
    - - -
    top
    -
    -

    Hébergement virtuel basé sur IP

    - -

    Le serveur dispose de deux adresses IP (172.20.30.40 - et 172.20.30.50) correspondant respectivement aux noms - www.example.com et www.example.org.

    - - 
    Listen 80
-
-<VirtualHost 172.20.30.40>
-    DocumentRoot "/www/example1"
-    ServerName www.example.com
-</VirtualHost>
-
-<VirtualHost 172.20.30.50>
-    DocumentRoot "/www/example2"
-    ServerName www.example.org
-</VirtualHost>
    - - -

    Les requêtes provenant d'adresses non spécifiées dans l'une des - directives <VirtualHost> (comme pour - localhost par exemple) seront dirigées vers le serveur - principal, s'il en existe un.

    - -
    top
    -
    -

    Hébergements virtuels mixtes basés sur - les ports et sur les IP

    - -

    Le serveur dispose de deux adresses IP (172.20.30.40 - et 172.20.30.50) correspondant respectivement aux noms - www.example.com et www.example.org. - Pour chacun d'eux, nous voulons un hébergement sur les ports 80 - et 8080.

    - - 
    Listen 172.20.30.40:80
-Listen 172.20.30.40:8080
-Listen 172.20.30.50:80
-Listen 172.20.30.50:8080
-
-<VirtualHost 172.20.30.40:80>
-    DocumentRoot "/www/example1-80"
-    ServerName www.example.com
-</VirtualHost>
-
-<VirtualHost 172.20.30.40:8080>
-    DocumentRoot "/www/example1-8080"
-    ServerName www.example.com
-</VirtualHost>
-
-<VirtualHost 172.20.30.50:80>
-    DocumentRoot "/www/example2-80"
-    ServerName www.example.org
-</VirtualHost>
-
-<VirtualHost 172.20.30.50:8080>
-    DocumentRoot "/www/example2-8080"
-    ServerName www.example.org
-</VirtualHost>
    - - -
    top
    -
    -

    Hébergements virtuels mixtes basé sur - les noms et sur IP

    - -

    Toute adresse indiquée comme argument d'une section VirtualHost - et n'apparaissant dans aucun autre serveur virtuel, fait de cette - section un serveur virtuel sélectionnable uniquement en fonction de - son adresse IP.

    - - 
    Listen 80
-<VirtualHost 172.20.30.40>
-    DocumentRoot "/www/example1"
-    ServerName www.example.com
-</VirtualHost>
-
-<VirtualHost 172.20.30.40>
-    DocumentRoot "/www/example2"
-    ServerName www.example.org
-</VirtualHost>
-
-<VirtualHost 172.20.30.40>
-    DocumentRoot "/www/example3"
-    ServerName www.example.net
-</VirtualHost>
-
-# IP-based
-<VirtualHost 172.20.30.50>
-    DocumentRoot "/www/example4"
-    ServerName www.example.edu
-</VirtualHost>
-
-<VirtualHost 172.20.30.60>
-    DocumentRoot "/www/example5"
-    ServerName www.example.gov
-</VirtualHost>
    - - -
    top
    -
    -

    Utilisation simultanée de - Virtual_host et de mod_proxy

    - -

    L'exemple suivant montre comment une machine peut mandater - un serveur virtuel fonctionnant sur le serveur d'une autre machine. - Dans cet exemple, un serveur virtuel de même nom est configuré sur - une machine à l'adresse 192.168.111.2. La directive - ProxyPreserveHost On est - employée pour permette au nom de domaine d'être préservé lors du - transfert, au cas où plusieurs noms de domaines cohabitent sur - une même machine.

    - - 
    <VirtualHost *:*>
-    ProxyPreserveHost On
-    ProxyPass "/" "http://192.168.111.2/"
-    ProxyPassReverse "/" "http://192.168.111.2/"
-    ServerName hostname.example.com
-</VirtualHost>
    - - -
    top
    -
    -

    Utilisation de serveurs virtuels - _default_

    - -

    Serveurs virtuels - _default_ pour tous les ports

    - -

    Exemple de capture de toutes les requêtes émanant - d'adresses IP ou de ports non connus, c'est-à-dire, d'un - couple adresse/port non traité par aucun autre serveur virtuel.

    - - 
    <VirtualHost _default_:*>
-    DocumentRoot "/www/default"
-</VirtualHost>
    - - -

    L'utilisation d'un tel serveur virtuel avec un joker pour le - port empêche de manière efficace qu'une requête n'atteigne le - serveur principal.

    - -

    Un serveur virtuel par défaut ne servira jamais une requête - qui est envoyée vers un couple adresse/port utilisée par un - serveur virtuel par nom. Si la requête contient un en-tête - Host: inconnu, ou si celui-ci est absent, elle - sera toujours servie par le serveur virtuel primaire par nom - (celui correspondant à ce couple adresse/port trouvé en premier - dans le fichier de configuration).

    - -

    Vous pouvez utiliser une directive - AliasMatch ou - RewriteRule afin de - réécrire une requête pour une unique page d'information (ou pour - un script).

    - - -

    Serveurs virtuels - _default_ pour des ports différents

    - -

    La configuration est similaire à l'exemple précédent, mais - le serveur écoute sur plusieurs ports et un second serveur virtuel - _default_ pour le port 80 est ajouté.

    - - 
    <VirtualHost _default_:80>
-    DocumentRoot "/www/default80"
-    # ...
-</VirtualHost>
-
-<VirtualHost _default_:*>
-    DocumentRoot "/www/default"
-    # ...
-</VirtualHost>
    - - -

    Le serveur virtuel par défaut défini pour le port 80 (il doit - impérativement être placé avant un autre serveur virtuel par - défaut traitant tous les ports grâce au joker *) capture toutes - les requêtes envoyées sur une adresse IP non spécifiée. Le - serveur principal n'est jamais utilisé pour servir une requête.

    - - -

    Serveurs virtuels - _default_ pour un seul port

    - -

    Nous voulons créer un serveur virtuel par défaut seulement - pour le port 80.

    - - 
    <VirtualHost _default_:80>
-DocumentRoot "/www/default"
-...
-</VirtualHost>
    - - -

    Une requête vers une adresse non spécifiée sur le port 80 - sera servie par le serveur virtuel par défaut, et toute autre - requête vers une adresse et un port non spécifiés sera servie - par le serveur principal.

    - -

    L'utilisation du caractère générique * dans la - déclaration d'un serveur virtuel l'emporte sur - _default_.

    - - -
    top
    -
    -

    Migration d'un serveur virtuel - par nom en un serveur virtuel par IP

    - -

    Le serveur virtuel par nom avec le nom de domaine - www.example.org (de notre exemple - par nom) devrait obtenir sa propre adresse IP. Pendant la - phase de migration, il est possible d'éviter les problèmes avec - les noms de serveurs et autres serveurs mandataires qui mémorisent - les vielles adresses IP pour les serveurs virtuels par nom.
    - La solution est simple, car il suffit d'ajouter la nouvelle - adresse IP (172.20.30.50) dans la directive - VirtualHost.

    - - 
    Listen 80
-ServerName www.example.com
-DocumentRoot "/www/example1"
-
-<VirtualHost 172.20.30.40 172.20.30.50>
-    DocumentRoot "/www/example2"
-    ServerName www.example.org
-    # ...
-</VirtualHost>
-
-<VirtualHost 172.20.30.40>
-    DocumentRoot "/www/example3"
-    ServerName www.example.net
-    ServerAlias *.example.net
-    # ...
-</VirtualHost>
    - - -

    Le serveur virtuel peut maintenant être joint par la nouvelle - adresse (comme un serveur virtuel par IP) et par l'ancienne - adresse (comme un serveur virtuel par nom).

    - -
    top
    -
    -

    Utilisation de la directive - ServerPath

    - -

    Dans le cas où vous disposez de deux serveurs virtuels par nom, - le client doit transmettre un en-tête Host: correct - pour déterminer le serveur concerné. Les vieux clients HTTP/1.0 - n'envoient pas un tel en-tête et Apache n'a aucun indice pour - connaître le serveur virtuel devant être joint (il sert la - requête à partir d'un serveur virtuel primaire). Dans un soucis - de préserver la compatibilité descendante, il suffit de créer - un serveur virtuel primaire chargé de retourner une page contenant - des liens dont les URLs auront un préfixe identifiant les serveurs - virtuels par nom.

    - - 
    <VirtualHost 172.20.30.40>
-    # serveur virtuel primaire
-    DocumentRoot "/www/subdomain"
-    RewriteEngine On
-    RewriteRule "." "/www/subdomain/index.html"
-    # ...
-</VirtualHost>
-
-<VirtualHost 172.20.30.40>
-DocumentRoot "/www/subdomain/sub1"
-    ServerName www.sub1.domain.tld
-    ServerPath /sub1/
-    RewriteEngine On
-    RewriteRule "^(/sub1/.*)" "/www/subdomain$1"
-    # ...
-</VirtualHost>
-
-<VirtualHost 172.20.30.40>
-    DocumentRoot "/www/subdomain/sub2"
-    ServerName www.sub2.domain.tld
-    ServerPath /sub2/
-    RewriteEngine On
-    RewriteRule "^(/sub2/.*)" "/www/subdomain$1"
-    # ...
-</VirtualHost>
    - - -

    À cause de la directive - ServerPath, une requête sur - une URL http://www.sub1.domain.tld/sub1/ est - toujours servie par le serveur sub1-vhost.
    - Une requête sur une URL http://www.sub1.domain.tld/ n'est - servie par le serveur sub1-vhost que si le client envoie un en-tête - Host: correct. Si aucun en-tête Host: - n'est transmis, le serveur primaire sera utilisé.

    -

    Notez qu'il y a une singularité : une requête sur - http://www.sub2.domain.tld/sub1/ est également servie - par le serveur sub1-vhost si le client n'envoie pas d'en-tête - Host:.

    -

    Les directives RewriteRule - sont employées pour s'assurer que le client qui envoie un en-tête - Host: correct puisse utiliser d'autres variantes d'URLs, - c'est-à-dire avec ou sans préfixe d'URL.

    - -
    -
    -

    Langues Disponibles:  en  | - fr  | - ja  | - ko  | - tr 

    -
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    -
    - \ No newline at end of file diff --git a/docs/manual/vhosts/examples.html.fr.utf8 b/docs/manual/vhosts/examples.html.fr.utf8 new file mode 100644 index 0000000000..1627c9c679 --- /dev/null +++ b/docs/manual/vhosts/examples.html.fr.utf8 @@ -0,0 +1,600 @@ + + + + + +Exemples d'utilisations de VirtualHost - Serveur HTTP Apache Version 2.5 + + + + + + +
    +

    Modules | Directives | FAQ | Glossaire | Plan du site

    +

    Serveur HTTP Apache Version 2.5

    +
    +
    <-
    +

    Exemples d'utilisations de VirtualHost

    +
    +

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

    +
    + + +

    Le but de ce document est d'essayer de répondre aux questions + les plus fréquentes sur la configuration des serveurs virtuels. + Les scénarios présentés ici se rencontrent quand plusieurs + serveurs web doivent tourner sur une seule et même machine au + moyen de serveurs virtuels par nom + ou par IP.

    + +

    Note à propos du contexte de configuration

    Les serveurs virtuels + doivent être spécifiés au niveau de la configuration globale du serveur. + Certaines distributions tierces du serveur peuvent cependant utiliser un fichier de + configuration initial alternatif ou des fichiers de configuration multiples + qui acceptent tous des directives à portée globale. Elles peuvent aussi + proposer une convention de spécification des serveurs virtuels au sein de + ces fichiers multiples qui seront eux-mêmes inclus dans le fichier de + configuration global via la directive Include. Vous pourrez trouver plus de détails dans + le README de la distribution tierce, tel que + /usr/share/doc/apache2/README.Debian.gz pour les distributions basées sur + Debian et Ubuntu.

    +
    + +
    + +
    top
    +
    +

    Fonctionnement de plusieurs serveurs + virtuels par nom sur une seule adresse IP.

    + +

    Votre serveur possède plusieurs noms d'hôte qui correspondent à + une seule adresse IP, ce qui lui permet de répondre différemment si + une requête est envoyée à www.example.com ou + www.example.org.

    + +

    Note :

    La configuration de serveurs virtuels + sous Apache ne provoque pas leur apparition magique dans la + configuration du DNS. Il faut que leurs noms soient + définis dans le DNS, et qu'ils y soient résolus sur l'adresse IP + du serveur, faute de quoi personne ne pourra visiter votre site Web. + Il est possible d'ajouter des entrées dans le fichier + hosts pour tests locaux, mais qui ne fonctionneront + que sur la machine possédant ces entrées.

    +
    + + 
    # Apache doit écouter sur le port 80
+Listen 80
+<VirtualHost *:80>
+    DocumentRoot "/www/example1"
+    ServerName www.example.com
+  
+    # Autres directives ici
+</VirtualHost>
+
+<VirtualHost *:80>
+    DocumentRoot "/www/example2"
+    ServerName www.example.org
+
+    # Autres directives ici
+</VirtualHost>
    + + + +

    Les astérisques correspondent à toutes les adresses, si bien que + le serveur principal ne répondra jamais à aucune requête. Comme le + serveur virtuel + ServerName www.example.com se trouve en premier dans le fichier + de configuration, il a la plus grande priorité et peut être vu + comme serveur par défaut ou primaire ; + ce qui signifie que toute requête reçue ne correspondant à aucune + des directives ServerName sera servie par ce premier + <VirtualHost>.

    + +

    La configuration ci-dessus correspond à ce que l'on souhaite pour + la plupart des serveurs virtuels à base de nom. Il faudra cependant + utiliser une configuration différente si vous souhaitez servir un + contenu différent en fonction de l'adresse IP ou du port.

    + +
    +

    Note :

    + +

    Vous pouvez remplacer * + par une adresse IP du système. Le serveur virtuel concerné + ne sera alors sélectionné que pour les requêtes HTTP vers + cette adresse IP.

    + +

    En général, il est commode d'utiliser * sur + les systèmes dont l'adresse IP n'est pas constante - par + exemple, pour des serveurs dont l'adresse IP est attribuée + dynamiquement par le FAI, et où le DNS est géré au moyen + d'un DNS dynamique quelconque. Comme * signifie + n'importe quelle adresse, cette configuration + fonctionne sans devoir être modifiée quand l'adresse IP du + système est modifiée.

    +
    + +
    top
    +
    +

    Serveurs virtuels par nom sur plus + d'une seule adresse IP.

    + +
    +

    Note :

    Toutes les techniques présentées ici + peuvent être étendues à un plus grand nombre d'adresses IP.

    +
    + +

    Le serveur a deux adresses IP. Sur l'une + (172.20.30.40), le serveur "principal" + server.example.com doit répondre, et sur l'autre + (172.20.30.50), deux serveurs virtuels (ou plus) + répondront.

    + + 
    Listen 80
+
+# Serveur "principal" sur 172.20.30.40
+ServerName server.example.com
+DocumentRoot "/www/mainserver"
+
+<VirtualHost 172.20.30.50>
+    DocumentRoot "/www/example1"
+    ServerName www.example.com
+    
+    # D'autres directives ici ...
+</VirtualHost>
+
+<VirtualHost 172.20.30.50>
+    DocumentRoot "/www/example2"
+    ServerName www.example.org
+    
+    # D'autres directives ici ...
+</VirtualHost>
    + + +

    Toute requête arrivant sur une autre adresse que + 172.20.30.50 sera servie par le serveur principal. + Les requêtes vers 172.20.30.50 avec un nom de serveur + inconnu, ou sans en-tête Host:, seront servies par + www.example.com.

    + +
    top
    +
    +

    Servir le même contenu sur des + adresses IP différentes (telle qu'une adresse interne et une + externe).

    + +

    La machine serveur dispose de deux adresses IP + (192.168.1.1 et 172.20.30.40). Cette + machine est placée à la fois sur le réseau interne (l'Intranet) + et le réseau externe (Internet). Sur Internet, le nom + server.example.com pointe vers l'adresse externe + (172.20.30.40), mais sur le réseau interne, ce même + nom pointe vers l'adresse interne (192.168.1.1).

    + +

    Le serveur peut être configuré pour répondre de la même manière + aux requêtes internes et externes, au moyen d'une seule section + <VirtualHost>.

    + + 
    <VirtualHost 192.168.1.1 172.20.30.40>
+    DocumentRoot "/www/server1"
+    ServerName server.example.com
+    ServerAlias server
+</VirtualHost>
    + + +

    Ainsi, les requêtes en provenance de chacun des deux réseaux + seront servies par le même <VirtualHost>.

    + +
    +

    Note :

    Sur le réseau interne, il est possible + d'utiliser le nom raccourci server au lieu du nom + complet server.example.com.

    + +

    Notez également que dans l'exemple précédent, vous pouvez + remplacer la liste des adresses IP par des * afin + que le serveur réponde de la même manière sur toutes ses + adresses.

    +
    + +
    top
    +
    +

    Servir différents sites sur différents + ports.

    + +

    Vous disposez de plusieurs domaines pointant sur la même adresse + IP et vous voulez également servir de multiples ports. L'exemple + suivant montre que la sélection en fonction du nom intervient après + la sélection de la meilleure correspondance du point de vue adresse + IP/port.

    + + 
    Listen 80
+Listen 8080
+
+<VirtualHost 172.20.30.40:80>
+    ServerName www.example.com
+    DocumentRoot "/www/domain-80"
+</VirtualHost>
+
+<VirtualHost 172.20.30.40:8080>
+    ServerName www.example.com
+    DocumentRoot "/www/domain-8080"
+</VirtualHost>
+
+<VirtualHost 172.20.30.40:80>
+    ServerName www.example.org
+    DocumentRoot "/www/otherdomain-80"
+</VirtualHost>
+
+<VirtualHost 172.20.30.40:8080>
+    ServerName www.example.org
+    DocumentRoot "/www/otherdomain-8080"
+</VirtualHost>
    + + +
    top
    +
    +

    Hébergement virtuel basé sur IP

    + +

    Le serveur dispose de deux adresses IP (172.20.30.40 + et 172.20.30.50) correspondant respectivement aux noms + www.example.com et www.example.org.

    + + 
    Listen 80
+
+<VirtualHost 172.20.30.40>
+    DocumentRoot "/www/example1"
+    ServerName www.example.com
+</VirtualHost>
+
+<VirtualHost 172.20.30.50>
+    DocumentRoot "/www/example2"
+    ServerName www.example.org
+</VirtualHost>
    + + +

    Les requêtes provenant d'adresses non spécifiées dans l'une des + directives <VirtualHost> (comme pour + localhost par exemple) seront dirigées vers le serveur + principal, s'il en existe un.

    + +
    top
    +
    +

    Hébergements virtuels mixtes basés sur + les ports et sur les IP

    + +

    Le serveur dispose de deux adresses IP (172.20.30.40 + et 172.20.30.50) correspondant respectivement aux noms + www.example.com et www.example.org. + Pour chacun d'eux, nous voulons un hébergement sur les ports 80 + et 8080.

    + + 
    Listen 172.20.30.40:80
+Listen 172.20.30.40:8080
+Listen 172.20.30.50:80
+Listen 172.20.30.50:8080
+
+<VirtualHost 172.20.30.40:80>
+    DocumentRoot "/www/example1-80"
+    ServerName www.example.com
+</VirtualHost>
+
+<VirtualHost 172.20.30.40:8080>
+    DocumentRoot "/www/example1-8080"
+    ServerName www.example.com
+</VirtualHost>
+
+<VirtualHost 172.20.30.50:80>
+    DocumentRoot "/www/example2-80"
+    ServerName www.example.org
+</VirtualHost>
+
+<VirtualHost 172.20.30.50:8080>
+    DocumentRoot "/www/example2-8080"
+    ServerName www.example.org
+</VirtualHost>
    + + +
    top
    +
    +

    Hébergements virtuels mixtes basé sur + les noms et sur IP

    + +

    Toute adresse indiquée comme argument d'une section VirtualHost + et n'apparaissant dans aucun autre serveur virtuel, fait de cette + section un serveur virtuel sélectionnable uniquement en fonction de + son adresse IP.

    + + 
    Listen 80
+<VirtualHost 172.20.30.40>
+    DocumentRoot "/www/example1"
+    ServerName www.example.com
+</VirtualHost>
+
+<VirtualHost 172.20.30.40>
+    DocumentRoot "/www/example2"
+    ServerName www.example.org
+</VirtualHost>
+
+<VirtualHost 172.20.30.40>
+    DocumentRoot "/www/example3"
+    ServerName www.example.net
+</VirtualHost>
+
+# IP-based
+<VirtualHost 172.20.30.50>
+    DocumentRoot "/www/example4"
+    ServerName www.example.edu
+</VirtualHost>
+
+<VirtualHost 172.20.30.60>
+    DocumentRoot "/www/example5"
+    ServerName www.example.gov
+</VirtualHost>
    + + +
    top
    +
    +

    Utilisation simultanée de + Virtual_host et de mod_proxy

    + +

    L'exemple suivant montre comment une machine peut mandater + un serveur virtuel fonctionnant sur le serveur d'une autre machine. + Dans cet exemple, un serveur virtuel de même nom est configuré sur + une machine à l'adresse 192.168.111.2. La directive + ProxyPreserveHost On est + employée pour permette au nom de domaine d'être préservé lors du + transfert, au cas où plusieurs noms de domaines cohabitent sur + une même machine.

    + + 
    <VirtualHost *:*>
+    ProxyPreserveHost On
+    ProxyPass "/" "http://192.168.111.2/"
+    ProxyPassReverse "/" "http://192.168.111.2/"
+    ServerName hostname.example.com
+</VirtualHost>
    + + +
    top
    +
    +

    Utilisation de serveurs virtuels + _default_

    + +

    Serveurs virtuels + _default_ pour tous les ports

    + +

    Exemple de capture de toutes les requêtes émanant + d'adresses IP ou de ports non connus, c'est-à-dire, d'un + couple adresse/port non traité par aucun autre serveur virtuel.

    + + 
    <VirtualHost _default_:*>
+    DocumentRoot "/www/default"
+</VirtualHost>
    + + +

    L'utilisation d'un tel serveur virtuel avec un joker pour le + port empêche de manière efficace qu'une requête n'atteigne le + serveur principal.

    + +

    Un serveur virtuel par défaut ne servira jamais une requête + qui est envoyée vers un couple adresse/port utilisée par un + serveur virtuel par nom. Si la requête contient un en-tête + Host: inconnu, ou si celui-ci est absent, elle + sera toujours servie par le serveur virtuel primaire par nom + (celui correspondant à ce couple adresse/port trouvé en premier + dans le fichier de configuration).

    + +

    Vous pouvez utiliser une directive + AliasMatch ou + RewriteRule afin de + réécrire une requête pour une unique page d'information (ou pour + un script).

    + + +

    Serveurs virtuels + _default_ pour des ports différents

    + +

    La configuration est similaire à l'exemple précédent, mais + le serveur écoute sur plusieurs ports et un second serveur virtuel + _default_ pour le port 80 est ajouté.

    + + 
    <VirtualHost _default_:80>
+    DocumentRoot "/www/default80"
+    # ...
+</VirtualHost>
+
+<VirtualHost _default_:*>
+    DocumentRoot "/www/default"
+    # ...
+</VirtualHost>
    + + +

    Le serveur virtuel par défaut défini pour le port 80 (il doit + impérativement être placé avant un autre serveur virtuel par + défaut traitant tous les ports grâce au joker *) capture toutes + les requêtes envoyées sur une adresse IP non spécifiée. Le + serveur principal n'est jamais utilisé pour servir une requête.

    + + +

    Serveurs virtuels + _default_ pour un seul port

    + +

    Nous voulons créer un serveur virtuel par défaut seulement + pour le port 80.

    + + 
    <VirtualHost _default_:80>
+DocumentRoot "/www/default"
+...
+</VirtualHost>
    + + +

    Une requête vers une adresse non spécifiée sur le port 80 + sera servie par le serveur virtuel par défaut, et toute autre + requête vers une adresse et un port non spécifiés sera servie + par le serveur principal.

    + +

    L'utilisation du caractère générique * dans la + déclaration d'un serveur virtuel l'emporte sur + _default_.

    + + +
    top
    +
    +

    Migration d'un serveur virtuel + par nom en un serveur virtuel par IP

    + +

    Le serveur virtuel par nom avec le nom de domaine + www.example.org (de notre exemple + par nom) devrait obtenir sa propre adresse IP. Pendant la + phase de migration, il est possible d'éviter les problèmes avec + les noms de serveurs et autres serveurs mandataires qui mémorisent + les vielles adresses IP pour les serveurs virtuels par nom.
    + La solution est simple, car il suffit d'ajouter la nouvelle + adresse IP (172.20.30.50) dans la directive + VirtualHost.

    + + 
    Listen 80
+ServerName www.example.com
+DocumentRoot "/www/example1"
+
+<VirtualHost 172.20.30.40 172.20.30.50>
+    DocumentRoot "/www/example2"
+    ServerName www.example.org
+    # ...
+</VirtualHost>
+
+<VirtualHost 172.20.30.40>
+    DocumentRoot "/www/example3"
+    ServerName www.example.net
+    ServerAlias *.example.net
+    # ...
+</VirtualHost>
    + + +

    Le serveur virtuel peut maintenant être joint par la nouvelle + adresse (comme un serveur virtuel par IP) et par l'ancienne + adresse (comme un serveur virtuel par nom).

    + +
    top
    +
    +

    Utilisation de la directive + ServerPath

    + +

    Dans le cas où vous disposez de deux serveurs virtuels par nom, + le client doit transmettre un en-tête Host: correct + pour déterminer le serveur concerné. Les vieux clients HTTP/1.0 + n'envoient pas un tel en-tête et Apache n'a aucun indice pour + connaître le serveur virtuel devant être joint (il sert la + requête à partir d'un serveur virtuel primaire). Dans un soucis + de préserver la compatibilité descendante, il suffit de créer + un serveur virtuel primaire chargé de retourner une page contenant + des liens dont les URLs auront un préfixe identifiant les serveurs + virtuels par nom.

    + + 
    <VirtualHost 172.20.30.40>
+    # serveur virtuel primaire
+    DocumentRoot "/www/subdomain"
+    RewriteEngine On
+    RewriteRule "." "/www/subdomain/index.html"
+    # ...
+</VirtualHost>
+
+<VirtualHost 172.20.30.40>
+DocumentRoot "/www/subdomain/sub1"
+    ServerName www.sub1.domain.tld
+    ServerPath /sub1/
+    RewriteEngine On
+    RewriteRule "^(/sub1/.*)" "/www/subdomain$1"
+    # ...
+</VirtualHost>
+
+<VirtualHost 172.20.30.40>
+    DocumentRoot "/www/subdomain/sub2"
+    ServerName www.sub2.domain.tld
+    ServerPath /sub2/
+    RewriteEngine On
+    RewriteRule "^(/sub2/.*)" "/www/subdomain$1"
+    # ...
+</VirtualHost>
    + + +

    À cause de la directive + ServerPath, une requête sur + une URL http://www.sub1.domain.tld/sub1/ est + toujours servie par le serveur sub1-vhost.
    + Une requête sur une URL http://www.sub1.domain.tld/ n'est + servie par le serveur sub1-vhost que si le client envoie un en-tête + Host: correct. Si aucun en-tête Host: + n'est transmis, le serveur primaire sera utilisé.

    +

    Notez qu'il y a une singularité : une requête sur + http://www.sub2.domain.tld/sub1/ est également servie + par le serveur sub1-vhost si le client n'envoie pas d'en-tête + Host:.

    +

    Les directives RewriteRule + sont employées pour s'assurer que le client qui envoie un en-tête + Host: correct puisse utiliser d'autres variantes d'URLs, + c'est-à-dire avec ou sans préfixe d'URL.

    + +
    +
    +

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

    +
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    +
    + \ No newline at end of file diff --git a/docs/manual/vhosts/fd-limits.html.en b/docs/manual/vhosts/fd-limits.html.en index 69779afce5..5780e71b7e 100644 --- a/docs/manual/vhosts/fd-limits.html.en +++ b/docs/manual/vhosts/fd-limits.html.en @@ -24,10 +24,10 @@ Apache > HTTP Server > Documentation > Version 2.5 > Virtual Hosts

    File Descriptor Limits

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

    + tr 

    @@ -124,10 +124,10 @@ Each file will be called hostname.log.

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

    + tr 

    top

    Comments

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    - - -
    -

    Modules | Directives | FAQ | Glossaire | Plan du site

    -

    Serveur HTTP Apache Version 2.5

    -
    -
    <-
    -

    Limites des descripteurs de fichiers

    -
    -

    Langues Disponibles:  en  | - fr  | - ja  | - ko  | - tr 

    -
    - - -

    Quand de nombreux serveurs virtuels sont créés, Apache peut - dépasser les limites en descripteurs de fichiers ('file descriptors', - également appelés gestionnaires de fichiers) si chacun - des serveurs virtuels utilise ses propres fichiers journaux. Le - nombre total de descripteurs de fichiers utilisés par Apache est - d'un par fichier journal, un pour chacune des autres directives - de fichiers journaux, plus un nombre constant compris entre 10 et 20 - pour son fonctionnement interne. Les systèmes d'exploitation Unix - limitent le nombre de descripteurs de fichiers utilisables par - processus ; une valeur courante pour cette limite est de 64, et - cette valeur peut le plus souvent être augmentée.

    - -

    Apache tente d'accroître cette valeur limite si nécessaire, mais - sans y parvenir dans les cas suivants :

    - -
      -
    1. Le système d'exploitation ne permet pas l'utilisation d'appels - systèmes setrlimit().
      2. - -
    2. L'appel setrlimit(RLIMIT_NOFILE) ne fonctionne pas - sur votre système d'exploitation (c'est le cas sous Solaris 2.3).
      3. - -
    3. Le nombre de descripteurs de fichiers nécessaires à Apache - dépasse la limite physique du matériel.
      4. - -
    4. Le système impose d'autres limites sur l'utilisation des - descripteurs de fichiers, comme par exemple une limite sur les - flux stdio, utilisables uniquement sur les descripteurs de - fichiers inférieurs à 256. (sous Solaris 2).
      5. -
    - -

    En cas de problème, Vous pouvez :

    - -
      -
    • Réduire le nombre de fichiers journaux, en ne spécifiant - aucun fichier journal dans les sections - <VirtualHost>, - en donc en envoyant les informations aux fichiers journaux du - serveur principal (Voir Éclatement des - fichiers journaux ci-dessous pour plus d'informations sur - cette possibilité).
      • - -
    • - Dans les cas 1 ou 2 (évoqués ci-dessus), augmentez la limite sur - les descripteurs de fichiers avant le démarrage d'Apache, au - moyen d'un script comme - -

      - #!/bin/sh
      - ulimit -S -n 100
      - exec httpd       -

      -
      • -
    - - - -
    -
    top
    -
    -

    Éclatement des fichiers journaux

    - -

    Lorsque vous choisissez d'enregistrer les informations émanant de -plusieurs serveurs virtuels dans un même fichier journal, vous voudrez -ensuite pouvoir scinder ces informations à des fins de statistiques, par -exemple, sur les différents serveurs virtuels. Il est possible de procéder -de la manière suivante :

    - -

    Tout d'abord, vous devez ajouter le nom du serveur virtuel à chaque -entrée du journal. Ceci se paramètre au moyen de la directive - LogFormat et de la -variable %v. Ajoutez cette variable au début de la chaîne -de définition du format de journalisations :

    - -
    LogFormat "%v %h %l %u %t \"%r\" %>s %b" vhost
-CustomLog "logs/multiple_vhost_log" vhost
    - - -

    Cette configuration va provoquer la création d'un fichier de -journalisation au format standard (CLF : 'Common Log Format'), mais dont -chaque ligne débutera par le nom canonique du serveur virtuel (spécifié -par la directive ServerName). -(Voir mod_log_config pour d'autres informations sur la -personnalisation des fichiers journaux.)

    - -

    Au moment de séparer les informations du fichier journal en un fichier -par serveur virtuel, le programme -split-logfile peut être -utilisé. Ce programme peut être trouvé dans le répertoire -support de la distribution d'Apache.

    - -

    Exécutez ce programme au moyen de la commande :

    - -

    -split-logfile < /logs/multiple_vhost_log -

    - -

    Une fois exécuté avec le nom du fichier contenant tous les journaux, -ce programme va générer un fichier pour chacun des serveurs virtuels -qui apparaît dans le fichier d'entrée. Chaque fichier en sortie est -nommé nomduserveur.log.

    - -
    -
    -

    Langues Disponibles:  en  | - fr  | - ja  | - ko  | - tr 

    -
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    -
    - \ No newline at end of file diff --git a/docs/manual/vhosts/fd-limits.html.fr.utf8 b/docs/manual/vhosts/fd-limits.html.fr.utf8 new file mode 100644 index 0000000000..c0f1538f59 --- /dev/null +++ b/docs/manual/vhosts/fd-limits.html.fr.utf8 @@ -0,0 +1,167 @@ + + + + + +Limites des descripteurs de fichiers - Serveur HTTP Apache Version 2.5 + + + + + + +
    +

    Modules | Directives | FAQ | Glossaire | Plan du site

    +

    Serveur HTTP Apache Version 2.5

    +
    +
    <-
    +

    Limites des descripteurs de fichiers

    +
    +

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

    +
    + + +

    Quand de nombreux serveurs virtuels sont créés, Apache peut + dépasser les limites en descripteurs de fichiers ('file descriptors', + également appelés gestionnaires de fichiers) si chacun + des serveurs virtuels utilise ses propres fichiers journaux. Le + nombre total de descripteurs de fichiers utilisés par Apache est + d'un par fichier journal, un pour chacune des autres directives + de fichiers journaux, plus un nombre constant compris entre 10 et 20 + pour son fonctionnement interne. Les systèmes d'exploitation Unix + limitent le nombre de descripteurs de fichiers utilisables par + processus ; une valeur courante pour cette limite est de 64, et + cette valeur peut le plus souvent être augmentée.

    + +

    Apache tente d'accroître cette valeur limite si nécessaire, mais + sans y parvenir dans les cas suivants :

    + +
      +
    1. Le système d'exploitation ne permet pas l'utilisation d'appels + systèmes setrlimit().
      2. + +
    2. L'appel setrlimit(RLIMIT_NOFILE) ne fonctionne pas + sur votre système d'exploitation (c'est le cas sous Solaris 2.3).
      3. + +
    3. Le nombre de descripteurs de fichiers nécessaires à Apache + dépasse la limite physique du matériel.
      4. + +
    4. Le système impose d'autres limites sur l'utilisation des + descripteurs de fichiers, comme par exemple une limite sur les + flux stdio, utilisables uniquement sur les descripteurs de + fichiers inférieurs à 256. (sous Solaris 2).
      5. +
    + +

    En cas de problème, Vous pouvez :

    + +
      +
    • Réduire le nombre de fichiers journaux, en ne spécifiant + aucun fichier journal dans les sections + <VirtualHost>, + en donc en envoyant les informations aux fichiers journaux du + serveur principal (Voir Éclatement des + fichiers journaux ci-dessous pour plus d'informations sur + cette possibilité).
      • + +
    • + Dans les cas 1 ou 2 (évoqués ci-dessus), augmentez la limite sur + les descripteurs de fichiers avant le démarrage d'Apache, au + moyen d'un script comme + +

      + #!/bin/sh
      + ulimit -S -n 100
      + exec httpd       +

      +
      • +
    + + + +
    +
    top
    +
    +

    Éclatement des fichiers journaux

    + +

    Lorsque vous choisissez d'enregistrer les informations émanant de +plusieurs serveurs virtuels dans un même fichier journal, vous voudrez +ensuite pouvoir scinder ces informations à des fins de statistiques, par +exemple, sur les différents serveurs virtuels. Il est possible de procéder +de la manière suivante :

    + +

    Tout d'abord, vous devez ajouter le nom du serveur virtuel à chaque +entrée du journal. Ceci se paramètre au moyen de la directive + LogFormat et de la +variable %v. Ajoutez cette variable au début de la chaîne +de définition du format de journalisations :

    + +
    LogFormat "%v %h %l %u %t \"%r\" %>s %b" vhost
+CustomLog "logs/multiple_vhost_log" vhost
    + + +

    Cette configuration va provoquer la création d'un fichier de +journalisation au format standard (CLF : 'Common Log Format'), mais dont +chaque ligne débutera par le nom canonique du serveur virtuel (spécifié +par la directive ServerName). +(Voir mod_log_config pour d'autres informations sur la +personnalisation des fichiers journaux.)

    + +

    Au moment de séparer les informations du fichier journal en un fichier +par serveur virtuel, le programme +split-logfile peut être +utilisé. Ce programme peut être trouvé dans le répertoire +support de la distribution d'Apache.

    + +

    Exécutez ce programme au moyen de la commande :

    + +

    +split-logfile < /logs/multiple_vhost_log +

    + +

    Une fois exécuté avec le nom du fichier contenant tous les journaux, +ce programme va générer un fichier pour chacun des serveurs virtuels +qui apparaît dans le fichier d'entrée. Chaque fichier en sortie est +nommé nomduserveur.log.

    + +
    +
    +

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

    +
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    +
    + \ No newline at end of file diff --git a/docs/manual/vhosts/index.html.en b/docs/manual/vhosts/index.html.en index f0b16534e5..3b53b9c1d9 100644 --- a/docs/manual/vhosts/index.html.en +++ b/docs/manual/vhosts/index.html.en @@ -25,10 +25,10 @@

    Available Languages:  de  |  en  | - fr  | + fr  |  ja  |  ko  | - tr  | + tr  |  zh-cn 

    @@ -111,10 +111,10 @@ hosts
  • IP-based virtual hosts

  • Available Languages:  de  |  en  | - fr  | + fr  |  ja  |  ko  | - tr  | + tr  |  zh-cn 

    • Apache IP-based Virtual Host Support

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

    + tr 

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

    + tr 

    top

    Comments

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    - - -
    -

    Modules | Directives | FAQ | Glossaire | Plan du site

    -

    Serveur HTTP Apache Version 2.5

    -
    -
    <-
    -

    Support Apache des serveurs virtuels par IP

    -
    -

    Langues Disponibles:  en  | - fr  | - ja  | - ko  | - tr 

    -
    -
    - -
    top
    -
    -

    Système requis

    - -

    Comme l'indique le terme par IP, le serveur - doit disposer de différentes paires adresses IP/port pour chaque - serveur virtuel par IP. La machine peut posséder - plusieurs connexions physiques au réseau, ou utiliser des - interfaces virtuelles qui sont supportées par la plupart des - systèmes d'exploitation modernes (Consultez la documentation des - systèmes d'exploitation pour plus de détails, notamment les "alias - IP" et la commande "ifconfig" pour les activer), et/ou utiliser - plusieurs numéros de port.

    - -

    Selon la terminologie du serveur HTTP Apache, l'utilisation d'une - seule adresse IP avec plusieurs ports TCP s'apparente aussi à de - l'hébergement virtuel basé sur IP.

    -
    top
    -
    -

    Comment configurer Apache

    - -

    Il y a deux manières de configurer Apache pour le support de - multiples serveurs virtuels. Il suffit soit de faire tourner un - processus résident httpd pour chaque nom de - domaine, soit de faire tourner un unique processus résident qui - gère tous les serveurs virtuels.

    - -

    Utilisez des processus résidents multiples lorsque :

    - -
      -
    • il y a des problèmes de répartition de sécurité, tels - qu'une entreprise1 ne souhaite que personne d'une entreprise2 - ne puisse lire ses données excepté via le Web. Dans ce cas, - vous aurez besoin de deux processus résidents, chacun fonctionnant - avec des paramètres User, - Group, - Listen, et - ServerRoot différents.
      • - -
    • vous disposez suffisamment de mémoire et de - descripteurs de fichiers - pour l'écoute de chaque alias IP de la machine. Il est seulement - possible d'appliquer la directive - Listen, soit sur toutes - les adresses avec le joker "*", soit uniquement sur des adresses - spécifiques. Donc, si vous avez besoin d'écouter une adresse - en particulier, vous devrez le faire pour l'ensemble des - autres adresses (Bien qu'il soit plus simple de lancer un - processus httpd pour écouter N-1 adresses, - et un autre pour l'adresse restante).
      • -
    - -

    Utilisez un unique processus résident lorsque :

    - -
      -
    • le partage de la configuration httpd entre les serveurs - virtuels est acceptable.
      • - -
    • la machine assume déjà une grande quantité de requêtes, et - que l'ajout de processus résidents supplémentaires en affecterait - les performances.
      • -
    - -
    top
    -
    -

    Configuration de processus multiples

    - -

    Créez une installation indépendante du programme - httpd pour chaque serveur virtuel. Pour - chacune d'elle, utilisez la directive - Listen dans le fichier - de configuration pour définir l'adresse IP (ou serveur virtuel) - que le processus résident doit gérer. Par exemple :

    - - 
    Listen 192.0.2.100:80
    - - -

    Il est recommandé d'utiliser une adresse IP plutôt qu'un nom - de domaine (consultez Problèmes DNS - avec Apache).

    - -
    top
    -
    -

    Configuration d'un unique processus -résident pour des serveurs virtuels

    - -

    Dans ce cas, un unique processus httpd va gérer les requêtes - pour le serveur principal et tous les serveurs virtuels. Dans le - fichier de configuration, la directive - VirtualHost va servir à - définir les autres directives - ServerAdmin, - ServerName, - DocumentRoot, - ErrorLog et - TransferLog ou - CustomLog avec des - valeurs différentes pour chaque serveur virtuel. Par exemple :

    - - 
    <VirtualHost 172.20.30.40:80>
-    ServerAdmin webmaster@www1.example.com
-    DocumentRoot "/www/vhosts/www1"
-    ServerName www1.example.com
-    ErrorLog "/www/logs/www1/error_log"
-    CustomLog "/www/logs/www1/access_log" combined
-</VirtualHost>
-
-<VirtualHost 172.20.30.50:80>
-    ServerAdmin "webmaster@www2.example.org"
-    DocumentRoot "/www/vhosts/www2"
-    ServerName www2.example.org
-    ErrorLog "/www/logs/www2/error_log"
-    CustomLog "/www/logs/www2/access_log" combined
-</VirtualHost>
    - - -

    Il est recommandé d'utiliser une adresse IP plutôt qu'un nom - de domaine comme argument à la directive <VirtualHost> - (consultez Problèmes DNS - avec Apache).

    - -

    Presque toutes les directives de configuration - peuvent être employées dans une directive VirtualHost, à l'exception - des directives qui contrôlent la création du processus et de - quelques autres. Pour connaître celles utilisables dans une - directive VirtualHost, vérifiez leur - Contexte en utilisant - l'directive index.

    - - -

    SuexecUserGroup peut être - utilisées à l'intérieur d'une directive VirtualHost si l'exécution se fait - sous suEXEC. (Voir suEXEC).

    - -

    SÉCURITÉ : lorsque vous spécifiez où écrire les - fichiers journaux, soyez attentif aux risques si quelqu'un d'autre - que celui qui a démarré Apache dispose des droits d'écriture - sur l'emplacement de ces fichiers. Consultez les - Conseils sur la sécurité - pour plus de détails.

    - -
    -
    -

    Langues Disponibles:  en  | - fr  | - ja  | - ko  | - tr 

    -
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    -
    - \ No newline at end of file diff --git a/docs/manual/vhosts/ip-based.html.fr.utf8 b/docs/manual/vhosts/ip-based.html.fr.utf8 new file mode 100644 index 0000000000..e5bd6b7819 --- /dev/null +++ b/docs/manual/vhosts/ip-based.html.fr.utf8 @@ -0,0 +1,213 @@ + + + + + +Support Apache des serveurs virtuels par IP - Serveur HTTP Apache Version 2.5 + + + + + + +
    +

    Modules | Directives | FAQ | Glossaire | Plan du site

    +

    Serveur HTTP Apache Version 2.5

    +
    +
    <-
    +

    Support Apache des serveurs virtuels par IP

    +
    +

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

    +
    +
    + +
    top
    +
    +

    Système requis

    + +

    Comme l'indique le terme par IP, le serveur + doit disposer de différentes paires adresses IP/port pour chaque + serveur virtuel par IP. La machine peut posséder + plusieurs connexions physiques au réseau, ou utiliser des + interfaces virtuelles qui sont supportées par la plupart des + systèmes d'exploitation modernes (Consultez la documentation des + systèmes d'exploitation pour plus de détails, notamment les "alias + IP" et la commande "ifconfig" pour les activer), et/ou utiliser + plusieurs numéros de port.

    + +

    Selon la terminologie du serveur HTTP Apache, l'utilisation d'une + seule adresse IP avec plusieurs ports TCP s'apparente aussi à de + l'hébergement virtuel basé sur IP.

    +
    top
    +
    +

    Comment configurer Apache

    + +

    Il y a deux manières de configurer Apache pour le support de + multiples serveurs virtuels. Il suffit soit de faire tourner un + processus résident httpd pour chaque nom de + domaine, soit de faire tourner un unique processus résident qui + gère tous les serveurs virtuels.

    + +

    Utilisez des processus résidents multiples lorsque :

    + +
      +
    • il y a des problèmes de répartition de sécurité, tels + qu'une entreprise1 ne souhaite que personne d'une entreprise2 + ne puisse lire ses données excepté via le Web. Dans ce cas, + vous aurez besoin de deux processus résidents, chacun fonctionnant + avec des paramètres User, + Group, + Listen, et + ServerRoot différents.
      • + +
    • vous disposez suffisamment de mémoire et de + descripteurs de fichiers + pour l'écoute de chaque alias IP de la machine. Il est seulement + possible d'appliquer la directive + Listen, soit sur toutes + les adresses avec le joker "*", soit uniquement sur des adresses + spécifiques. Donc, si vous avez besoin d'écouter une adresse + en particulier, vous devrez le faire pour l'ensemble des + autres adresses (Bien qu'il soit plus simple de lancer un + processus httpd pour écouter N-1 adresses, + et un autre pour l'adresse restante).
      • +
    + +

    Utilisez un unique processus résident lorsque :

    + +
      +
    • le partage de la configuration httpd entre les serveurs + virtuels est acceptable.
      • + +
    • la machine assume déjà une grande quantité de requêtes, et + que l'ajout de processus résidents supplémentaires en affecterait + les performances.
      • +
    + +
    top
    +
    +

    Configuration de processus multiples

    + +

    Créez une installation indépendante du programme + httpd pour chaque serveur virtuel. Pour + chacune d'elle, utilisez la directive + Listen dans le fichier + de configuration pour définir l'adresse IP (ou serveur virtuel) + que le processus résident doit gérer. Par exemple :

    + + 
    Listen 192.0.2.100:80
    + + +

    Il est recommandé d'utiliser une adresse IP plutôt qu'un nom + de domaine (consultez Problèmes DNS + avec Apache).

    + +
    top
    +
    +

    Configuration d'un unique processus +résident pour des serveurs virtuels

    + +

    Dans ce cas, un unique processus httpd va gérer les requêtes + pour le serveur principal et tous les serveurs virtuels. Dans le + fichier de configuration, la directive + VirtualHost va servir à + définir les autres directives + ServerAdmin, + ServerName, + DocumentRoot, + ErrorLog et + TransferLog ou + CustomLog avec des + valeurs différentes pour chaque serveur virtuel. Par exemple :

    + + 
    <VirtualHost 172.20.30.40:80>
+    ServerAdmin webmaster@www1.example.com
+    DocumentRoot "/www/vhosts/www1"
+    ServerName www1.example.com
+    ErrorLog "/www/logs/www1/error_log"
+    CustomLog "/www/logs/www1/access_log" combined
+</VirtualHost>
+
+<VirtualHost 172.20.30.50:80>
+    ServerAdmin "webmaster@www2.example.org"
+    DocumentRoot "/www/vhosts/www2"
+    ServerName www2.example.org
+    ErrorLog "/www/logs/www2/error_log"
+    CustomLog "/www/logs/www2/access_log" combined
+</VirtualHost>
    + + +

    Il est recommandé d'utiliser une adresse IP plutôt qu'un nom + de domaine comme argument à la directive <VirtualHost> + (consultez Problèmes DNS + avec Apache).

    + +

    Presque toutes les directives de configuration + peuvent être employées dans une directive VirtualHost, à l'exception + des directives qui contrôlent la création du processus et de + quelques autres. Pour connaître celles utilisables dans une + directive VirtualHost, vérifiez leur + Contexte en utilisant + l'directive index.

    + + +

    SuexecUserGroup peut être + utilisées à l'intérieur d'une directive VirtualHost si l'exécution se fait + sous suEXEC. (Voir suEXEC).

    + +

    SÉCURITÉ : lorsque vous spécifiez où écrire les + fichiers journaux, soyez attentif aux risques si quelqu'un d'autre + que celui qui a démarré Apache dispose des droits d'écriture + sur l'emplacement de ces fichiers. Consultez les + Conseils sur la sécurité + pour plus de détails.

    + +
    +
    +

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

    +
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    +
    + \ No newline at end of file diff --git a/docs/manual/vhosts/mass.html.en b/docs/manual/vhosts/mass.html.en index a820e7a206..21736ea7e6 100644 --- a/docs/manual/vhosts/mass.html.en +++ b/docs/manual/vhosts/mass.html.en @@ -24,9 +24,9 @@ Apache > HTTP Server > Documentation > Version 2.5 > Virtual Hosts

    Dynamically Configured Mass Virtual Hosting

    Available Languages:  en  | - fr  | + fr  |  ko  | - tr 

    + tr 

    @@ -318,9 +318,9 @@ documentation.

    Available Languages:  en  | - fr  | + fr  |  ko  | - tr 

    + tr 

    top

    Comments

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    - - -
    -

    Modules | Directives | FAQ | Glossaire | Plan du site

    -

    Serveur HTTP Apache Version 2.5

    -
    -
    <-
    -

    Hébergement virtuel de masse configuré dynamiquement

    -
    -

    Langues Disponibles:  en  | - fr  | - ko  | - tr 

    -
    - - -

    Ce document propose une méthode performante pour servir un nombre - quelconque d'hôtes virtuels avec le serveur HTTP Apache. Un document séparé décrit comment - utiliser mod_rewrite pour gérer l'hébergement - virtuel de masse dynamique. -

    - -
    - -
    top
    -
    -

    A qui ce document est-il destiné ?

    - -

    Les techniques décrites ici vous concernent si votre - httpd.conf contient de nombreuses sections - <VirtualHost> très semblables, - dans le style :

    - -
    <VirtualHost 111.22.33.44>
-    ServerName                 customer-1.example.com
-    DocumentRoot        "/www/hosts/customer-1.example.com/docs"
-    ScriptAlias  "/cgi-bin/"
-    "/www/hosts/customer-1.example.com/cgi-bin"
-</VirtualHost>
-
-<VirtualHost 111.22.33.44>
-    ServerName                 customer-2.example.com
-    DocumentRoot        "/www/hosts/customer-2.example.com/docs"
-    ScriptAlias  "/cgi-bin/" "/www/hosts/customer-2.example.com/cgi-bin"
-</VirtualHost>
-
-<VirtualHost 111.22.33.44>
-    ServerName                 customer-N.example.com
-    DocumentRoot        "/www/hosts/customer-N.example.com/docs"
-    ScriptAlias  "/cgi-bin/" "/www/hosts/customer-N.example.com/cgi-bin"
-</VirtualHost>
    - - -

    Nous voulons remplacer toutes les configurations - <VirtualHost> par un mécanisme qui les génère - dynamiquement. Ceci présente certains avantages :

    - -
      -
    1. Votre fichier de configuration est plus petit, ainsi Apache - démarre plus rapidement et consomme moins de mémoire. Et ce qui - est peut-être le plus important, le fichier de configuration plus - petit est plus facile à maintenir, et le risque d'erreurs en est - diminué d'autant. -
      2. - -
    2. Pour ajouter des serveurs virtuels, il suffit de créer les - répertoires appropriés dans le système de fichiers et les entrées - dans le DNS - il n'est plus nécessaire de reconfigurer ou de - redémarrer Apache.
      3. -
    - -

    Le principal désavantage réside dans le fait que vous ne pouvez - pas définir un fichier journal différent pour chaque serveur - virtuel. De toute façon, ce serait une mauvaise idée si vous avez de - nombreux serveurs virtuels, car cela nécessiterait un nombre important de descripteurs de - fichier. Il est préférable de rediriger les journaux via un pipe ou - une file fifo vers un - programme, et faire en sorte que ce dernier éclate les journaux - en un journal par serveur virtuel. L'utilitaire split-logfile - constitue un exemple de ce traitement.

    - -
    top
    -
    -

    Vue d'ensemble

    - -

    Un serveur virtuel peut être défini par deux informations : son - adresse IP, et le contenu de l'en-tête Host: de la - requête HTTP. La technique d'hébergement virtuel dynamique de masse - utilisée ici consiste à insérer automatiquement ces informations - dans le chemin du fichier à utiliser pour répondre à la requête. On - peut y parvenir assez facilement en utilisant - mod_vhost_alias avec Apache httpd, mais on peut aussi - utiliser mod_rewrite.

    -

    Par défaut, ces deux modules - sont désactivés ; vous devez activer l'un d'eux lors de la - compilation et de la configuration d'Apache httpd si vous voulez utiliser - cette technique.

    - -

    Certains paramètres doivent être extraits de la requête pour que le serveur - dynamique se présente comme un serveur dynamique normal. Le plus - important est le nom du serveur, que le serveur utilise pour générer des - URLs d'auto-référencement, etc... Il est défini via la directive - ServerName, et les CGIs peuvent s'y référer via la - variable d'environnement SERVER_NAME. Sa véritable - valeur utilisée à l'exécution est contrôlée par la définition de la - directive - UseCanonicalName. Avec - UseCanonicalName Off, le nom du serveur correspond au - contenu de l'en-tête Host: de la requête. Avec - UseCanonicalName DNS, il est extrait d'une recherche - DNS inverse sur l'adresse IP du serveur virtuel. La première - configuration est utilisée pour l'hébergement virtuel dynamique par - nom, et la deuxième pour l'hébergement virtuel dynamique par IP. Si - httpd ne peut pas déterminer le nom du serveur, soit parce qu'il - n'y a pas d'en-tête Host:, soit parce que la recherche - DNS a échoué, il prend en compte la valeur définie par la directive - ServerName.

    - -

    L'autre paramètre à extraire est la racine des documents (définie - via la directive DocumentRoot et disponible pour les - scripts CGI via la variable d'environnement DOCUMENT_ROOT). - Dans une configuration classique, il est utilisé par le module core - pour faire correspondre les URIs aux noms de fichiers, mais lorsque - la configuration du serveur comporte des serveurs virtuels, ce - traitement doit être pris en charge par un autre module (soit - mod_vhost_alias, soit mod_rewrite), qui - utilise un méthode de correspondance différente. Aucun de ces - modules ne se chargeant de définir la variable d'environnement - DOCUMENT_ROOT, si des CGIs ou des documents SSI - doivent en faire usage, ils obtiendront une valeur erronée.

    - -
    top
    -
    -

    Hébergement virtuel -dynamique avec mod_vhost_alias

    - -

    Cet extrait de fichier httpd.conf implémente - l'hébergement virtuel décrit dans la section À qui ce document est-il destiné ? ci-dessus - en utilisant mod_vhost_alias.

    - -
    # extrait le nom du serveur de l'en-tête Host:
-UseCanonicalName Off
-
-# ce format de journal peut être éclaté en journaux par serveur virtuel
-# à l'aide du premier champ via l'utilitaire split-logfile
-LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon
-CustomLog "logs/access_log" vcommon
-
-# inclut le nom du serveur dans les noms de fichiers ressources
-# nécessaires aux traitements des requêtes
-VirtualDocumentRoot "/www/hosts/%0/docs"
-VirtualScriptAlias  "/www/hosts/%0/cgi-bin"
    - - -

    Pour changer cette configuration en solution de serveur virtuel - par IP, il suffit de remplacer UseCanonicalName - Off par UseCanonicalName DNS. Le nom du serveur - inséré dans le nom de fichier sera alors déduit de l'adresse IP du - serveur virtuel. La variable %0 fait référence au nom - de serveur de la requête, tel qu'il est indiqué dans l'en-tête - Host:.

    - -

    Voir la documentation du module mod_vhost_alias - pour d'avantages d'exemples d'utilisation.

    - -
    top
    -
    -

    Système de serveurs virtuels dynamiques -simplifié

    - -

    Il s'agit d'une adaptation du système ci-dessus, ajusté pour un - serveur d'hébergement web de FAI. Grâce à la variable - %2, on peut extraire des sous-chaînes de caractères du - nom du serveur pour les utiliser dans le nom de fichier afin, par - exemple, de définir /home/user/www comme emplacement des - documents pour www.user.example.com. Un seul répertoire - cgi-bin suffit pour l'ensemble des - serveurs virtuels.

    - -
    UseCanonicalName Off
-
-LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon
-CustomLog "logs/access_log" vcommon
-
-# insertion d'une partie du nom du serveur dans les noms de fichiers
-VirtualDocumentRoot "/home/%2/www"
-
-# répertoire cgi-bin unique
-ScriptAlias  "/cgi-bin/"  "/www/std-cgi/"
    - - -

    Vous trouverez des exemples plus élaborés d'utilisation de la - directive VirtualDocumentRoot dans la documentation du - module mod_vhost_alias.

    - -
    top
    -
    -

    Utiliser plusieurs systèmes -d'hébergement virtuel sur le même serveur

    - -

    Moyennant une configuration un peu plus compliquée, vous pouvez - contrôler la portée des différentes configurations d'hébergement - virtuel à l'aide des directives <VirtualHost> - normales de httpd. Par exemple, on peut associer une adresse IP pour - les pages d'accueil des clients en général, et une autre pour les - clients commerciaux avec la configuration suivante. Cette - configuration peut être combinée avec les sections - <VirtualHost> conventionnelles, comme indiqué - plus loin.

    - -
    UseCanonicalName Off
-
-LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon
-
-<Directory "/www/commercial">
-    Options FollowSymLinks
-    AllowOverride All
-</Directory>
-
-<Directory "/www/homepages">
-    Options FollowSymLinks
-    AllowOverride None
-</Directory>
-
-<VirtualHost 111.22.33.44>
-    ServerName www.commercial.example.com
-    
-    CustomLog "logs/access_log.commercial" vcommon
-    
-    VirtualDocumentRoot "/www/commercial/%0/docs"
-    VirtualScriptAlias  "/www/commercial/%0/cgi-bin"
-</VirtualHost>
-
-<VirtualHost 111.22.33.45>
-    ServerName www.homepages.example.com
-    
-    CustomLog "logs/access_log.homepages" vcommon
-    
-    VirtualDocumentRoot "/www/homepages/%0/docs"
-    ScriptAlias         "/cgi-bin/" "/www/std-cgi/"
-</VirtualHost>
    - - -
    -

    Note

    -

    Si le premier bloc VirtualHost ne comporte pas de - directive ServerName, c'est - le nom issu d'une recherche DNS inverse à partir de l'adresse IP - du serveur virtuel qui sera utilisé. Si ce nom ne correspond pas - à celui que vous voulez utiliser, vous pouvez ajouter une entrée - de remplacement (par exemple ServerName - none.example.com) pour éviter ce comportement.

    -
    - -
    top
    -
    -

    Pour un hébergement virtuel par IP plus -efficace

    - -

    Les changements de configuration suggérés pour transformer le premier exemple en hébergement virtuel par IP - conduisent à une configuration peu efficace. Chaque requête - nécessite une nouvelle recherche DNS. Pour éviter cette surcharge de - travail, le système de fichiers peut être organisé pour correspondre - aux adresses IP, plutôt qu'aux noms de serveurs, supprimant par - la-même la nécessité d'une recherche DNS. La journalisation doit - aussi être adaptée pour fonctionner sur un tel système.

    - -
    # obtention du nom du serveur par recherche DNS inverse
-# sur l'adresse IP
-UseCanonicalName DNS
-
-# insertion de l'adresse IP dans les journaux afin de pouvoir les
-# éclater
-LogFormat "%A %h %l %u %t \"%r\" %s %b" vcommon
-CustomLog "logs/access_log" vcommon
-
-# insertion de l'adresse IP dans les noms de fichiers
-VirtualDocumentRootIP "/www/hosts/%0/docs"
-VirtualScriptAliasIP  "/www/hosts/%0/cgi-bin"
    - - -
    top
    -
    -

    Hébergement virtuel de masse avec -mod_rewrite

    - -

    -L'hébergement virtuel de masse peut aussi être effectué en utilisant -mod_rewrite, soit à l'aide de simples directives RewriteRule, soit en utilisant des -techniques plus compliquées comme le stockage externe des définitions -des serveurs virtuels, ces dernières étant accessibles via des -directives RewriteMap. Ces -techniques sont décrites dans la documentation sur la réécriture.

    - -
    top
    -
    -

    Hébergement virtuel en masse avec mod_macro

    - -

    Une autre option pour générer dynamiquement des serveurs virtuels : -mod_macro ; ce module permet de créer un modèle de serveur virtuel que -vous pourrez invoquer pour des noms d'hôtes multiples. La section -Usage de la documentation du module présente un exemple qui -illustre cette méthode. -

    -
    -
    -

    Langues Disponibles:  en  | - fr  | - ko  | - tr 

    -
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    -
    - \ No newline at end of file diff --git a/docs/manual/vhosts/mass.html.fr.utf8 b/docs/manual/vhosts/mass.html.fr.utf8 new file mode 100644 index 0000000000..eadec901be --- /dev/null +++ b/docs/manual/vhosts/mass.html.fr.utf8 @@ -0,0 +1,364 @@ + + + + + +Hébergement virtuel de masse configuré dynamiquement - Serveur HTTP Apache Version 2.5 + + + + + + +
    +

    Modules | Directives | FAQ | Glossaire | Plan du site

    +

    Serveur HTTP Apache Version 2.5

    +
    +
    <-
    +

    Hébergement virtuel de masse configuré dynamiquement

    +
    +

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

    +
    + + +

    Ce document propose une méthode performante pour servir un nombre + quelconque d'hôtes virtuels avec le serveur HTTP Apache. Un document séparé décrit comment + utiliser mod_rewrite pour gérer l'hébergement + virtuel de masse dynamique. +

    + +
    + +
    top
    +
    +

    A qui ce document est-il destiné ?

    + +

    Les techniques décrites ici vous concernent si votre + httpd.conf contient de nombreuses sections + <VirtualHost> très semblables, + dans le style :

    + +
    <VirtualHost 111.22.33.44>
+    ServerName                 customer-1.example.com
+    DocumentRoot        "/www/hosts/customer-1.example.com/docs"
+    ScriptAlias  "/cgi-bin/"
+    "/www/hosts/customer-1.example.com/cgi-bin"
+</VirtualHost>
+
+<VirtualHost 111.22.33.44>
+    ServerName                 customer-2.example.com
+    DocumentRoot        "/www/hosts/customer-2.example.com/docs"
+    ScriptAlias  "/cgi-bin/" "/www/hosts/customer-2.example.com/cgi-bin"
+</VirtualHost>
+
+<VirtualHost 111.22.33.44>
+    ServerName                 customer-N.example.com
+    DocumentRoot        "/www/hosts/customer-N.example.com/docs"
+    ScriptAlias  "/cgi-bin/" "/www/hosts/customer-N.example.com/cgi-bin"
+</VirtualHost>
    + + +

    Nous voulons remplacer toutes les configurations + <VirtualHost> par un mécanisme qui les génère + dynamiquement. Ceci présente certains avantages :

    + +
      +
    1. Votre fichier de configuration est plus petit, ainsi Apache + démarre plus rapidement et consomme moins de mémoire. Et ce qui + est peut-être le plus important, le fichier de configuration plus + petit est plus facile à maintenir, et le risque d'erreurs en est + diminué d'autant. +
      2. + +
    2. Pour ajouter des serveurs virtuels, il suffit de créer les + répertoires appropriés dans le système de fichiers et les entrées + dans le DNS - il n'est plus nécessaire de reconfigurer ou de + redémarrer Apache.
      3. +
    + +

    Le principal désavantage réside dans le fait que vous ne pouvez + pas définir un fichier journal différent pour chaque serveur + virtuel. De toute façon, ce serait une mauvaise idée si vous avez de + nombreux serveurs virtuels, car cela nécessiterait un nombre important de descripteurs de + fichier. Il est préférable de rediriger les journaux via un pipe ou + une file fifo vers un + programme, et faire en sorte que ce dernier éclate les journaux + en un journal par serveur virtuel. L'utilitaire split-logfile + constitue un exemple de ce traitement.

    + +
    top
    +
    +

    Vue d'ensemble

    + +

    Un serveur virtuel peut être défini par deux informations : son + adresse IP, et le contenu de l'en-tête Host: de la + requête HTTP. La technique d'hébergement virtuel dynamique de masse + utilisée ici consiste à insérer automatiquement ces informations + dans le chemin du fichier à utiliser pour répondre à la requête. On + peut y parvenir assez facilement en utilisant + mod_vhost_alias avec Apache httpd, mais on peut aussi + utiliser mod_rewrite.

    +

    Par défaut, ces deux modules + sont désactivés ; vous devez activer l'un d'eux lors de la + compilation et de la configuration d'Apache httpd si vous voulez utiliser + cette technique.

    + +

    Certains paramètres doivent être extraits de la requête pour que le serveur + dynamique se présente comme un serveur dynamique normal. Le plus + important est le nom du serveur, que le serveur utilise pour générer des + URLs d'auto-référencement, etc... Il est défini via la directive + ServerName, et les CGIs peuvent s'y référer via la + variable d'environnement SERVER_NAME. Sa véritable + valeur utilisée à l'exécution est contrôlée par la définition de la + directive + UseCanonicalName. Avec + UseCanonicalName Off, le nom du serveur correspond au + contenu de l'en-tête Host: de la requête. Avec + UseCanonicalName DNS, il est extrait d'une recherche + DNS inverse sur l'adresse IP du serveur virtuel. La première + configuration est utilisée pour l'hébergement virtuel dynamique par + nom, et la deuxième pour l'hébergement virtuel dynamique par IP. Si + httpd ne peut pas déterminer le nom du serveur, soit parce qu'il + n'y a pas d'en-tête Host:, soit parce que la recherche + DNS a échoué, il prend en compte la valeur définie par la directive + ServerName.

    + +

    L'autre paramètre à extraire est la racine des documents (définie + via la directive DocumentRoot et disponible pour les + scripts CGI via la variable d'environnement DOCUMENT_ROOT). + Dans une configuration classique, il est utilisé par le module core + pour faire correspondre les URIs aux noms de fichiers, mais lorsque + la configuration du serveur comporte des serveurs virtuels, ce + traitement doit être pris en charge par un autre module (soit + mod_vhost_alias, soit mod_rewrite), qui + utilise un méthode de correspondance différente. Aucun de ces + modules ne se chargeant de définir la variable d'environnement + DOCUMENT_ROOT, si des CGIs ou des documents SSI + doivent en faire usage, ils obtiendront une valeur erronée.

    + +
    top
    +
    +

    Hébergement virtuel +dynamique avec mod_vhost_alias

    + +

    Cet extrait de fichier httpd.conf implémente + l'hébergement virtuel décrit dans la section À qui ce document est-il destiné ? ci-dessus + en utilisant mod_vhost_alias.

    + +
    # extrait le nom du serveur de l'en-tête Host:
+UseCanonicalName Off
+
+# ce format de journal peut être éclaté en journaux par serveur virtuel
+# à l'aide du premier champ via l'utilitaire split-logfile
+LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon
+CustomLog "logs/access_log" vcommon
+
+# inclut le nom du serveur dans les noms de fichiers ressources
+# nécessaires aux traitements des requêtes
+VirtualDocumentRoot "/www/hosts/%0/docs"
+VirtualScriptAlias  "/www/hosts/%0/cgi-bin"
    + + +

    Pour changer cette configuration en solution de serveur virtuel + par IP, il suffit de remplacer UseCanonicalName + Off par UseCanonicalName DNS. Le nom du serveur + inséré dans le nom de fichier sera alors déduit de l'adresse IP du + serveur virtuel. La variable %0 fait référence au nom + de serveur de la requête, tel qu'il est indiqué dans l'en-tête + Host:.

    + +

    Voir la documentation du module mod_vhost_alias + pour d'avantages d'exemples d'utilisation.

    + +
    top
    +
    +

    Système de serveurs virtuels dynamiques +simplifié

    + +

    Il s'agit d'une adaptation du système ci-dessus, ajusté pour un + serveur d'hébergement web de FAI. Grâce à la variable + %2, on peut extraire des sous-chaînes de caractères du + nom du serveur pour les utiliser dans le nom de fichier afin, par + exemple, de définir /home/user/www comme emplacement des + documents pour www.user.example.com. Un seul répertoire + cgi-bin suffit pour l'ensemble des + serveurs virtuels.

    + +
    UseCanonicalName Off
+
+LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon
+CustomLog "logs/access_log" vcommon
+
+# insertion d'une partie du nom du serveur dans les noms de fichiers
+VirtualDocumentRoot "/home/%2/www"
+
+# répertoire cgi-bin unique
+ScriptAlias  "/cgi-bin/"  "/www/std-cgi/"
    + + +

    Vous trouverez des exemples plus élaborés d'utilisation de la + directive VirtualDocumentRoot dans la documentation du + module mod_vhost_alias.

    + +
    top
    +
    +

    Utiliser plusieurs systèmes +d'hébergement virtuel sur le même serveur

    + +

    Moyennant une configuration un peu plus compliquée, vous pouvez + contrôler la portée des différentes configurations d'hébergement + virtuel à l'aide des directives <VirtualHost> + normales de httpd. Par exemple, on peut associer une adresse IP pour + les pages d'accueil des clients en général, et une autre pour les + clients commerciaux avec la configuration suivante. Cette + configuration peut être combinée avec les sections + <VirtualHost> conventionnelles, comme indiqué + plus loin.

    + +
    UseCanonicalName Off
+
+LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon
+
+<Directory "/www/commercial">
+    Options FollowSymLinks
+    AllowOverride All
+</Directory>
+
+<Directory "/www/homepages">
+    Options FollowSymLinks
+    AllowOverride None
+</Directory>
+
+<VirtualHost 111.22.33.44>
+    ServerName www.commercial.example.com
+    
+    CustomLog "logs/access_log.commercial" vcommon
+    
+    VirtualDocumentRoot "/www/commercial/%0/docs"
+    VirtualScriptAlias  "/www/commercial/%0/cgi-bin"
+</VirtualHost>
+
+<VirtualHost 111.22.33.45>
+    ServerName www.homepages.example.com
+    
+    CustomLog "logs/access_log.homepages" vcommon
+    
+    VirtualDocumentRoot "/www/homepages/%0/docs"
+    ScriptAlias         "/cgi-bin/" "/www/std-cgi/"
+</VirtualHost>
    + + +
    +

    Note

    +

    Si le premier bloc VirtualHost ne comporte pas de + directive ServerName, c'est + le nom issu d'une recherche DNS inverse à partir de l'adresse IP + du serveur virtuel qui sera utilisé. Si ce nom ne correspond pas + à celui que vous voulez utiliser, vous pouvez ajouter une entrée + de remplacement (par exemple ServerName + none.example.com) pour éviter ce comportement.

    +
    + +
    top
    +
    +

    Pour un hébergement virtuel par IP plus +efficace

    + +

    Les changements de configuration suggérés pour transformer le premier exemple en hébergement virtuel par IP + conduisent à une configuration peu efficace. Chaque requête + nécessite une nouvelle recherche DNS. Pour éviter cette surcharge de + travail, le système de fichiers peut être organisé pour correspondre + aux adresses IP, plutôt qu'aux noms de serveurs, supprimant par + la-même la nécessité d'une recherche DNS. La journalisation doit + aussi être adaptée pour fonctionner sur un tel système.

    + +
    # obtention du nom du serveur par recherche DNS inverse
+# sur l'adresse IP
+UseCanonicalName DNS
+
+# insertion de l'adresse IP dans les journaux afin de pouvoir les
+# éclater
+LogFormat "%A %h %l %u %t \"%r\" %s %b" vcommon
+CustomLog "logs/access_log" vcommon
+
+# insertion de l'adresse IP dans les noms de fichiers
+VirtualDocumentRootIP "/www/hosts/%0/docs"
+VirtualScriptAliasIP  "/www/hosts/%0/cgi-bin"
    + + +
    top
    +
    +

    Hébergement virtuel de masse avec +mod_rewrite

    + +

    +L'hébergement virtuel de masse peut aussi être effectué en utilisant +mod_rewrite, soit à l'aide de simples directives RewriteRule, soit en utilisant des +techniques plus compliquées comme le stockage externe des définitions +des serveurs virtuels, ces dernières étant accessibles via des +directives RewriteMap. Ces +techniques sont décrites dans la documentation sur la réécriture.

    + +
    top
    +
    +

    Hébergement virtuel en masse avec mod_macro

    + +

    Une autre option pour générer dynamiquement des serveurs virtuels : +mod_macro ; ce module permet de créer un modèle de serveur virtuel que +vous pourrez invoquer pour des noms d'hôtes multiples. La section +Usage de la documentation du module présente un exemple qui +illustre cette méthode. +

    +
    +
    +

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

    +
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    +
    + \ No newline at end of file diff --git a/docs/manual/vhosts/name-based.html.en b/docs/manual/vhosts/name-based.html.en index 9e4282419b..78bfeb88b8 100644 --- a/docs/manual/vhosts/name-based.html.en +++ b/docs/manual/vhosts/name-based.html.en @@ -25,10 +25,10 @@

    Available Languages:  de  |  en  | - fr  | + fr  |  ja  |  ko  | - tr 

    + tr 

    This document describes when and how to use name-based virtual hosts.

    @@ -193,10 +193,10 @@

    Available Languages:  de  |  en  | - fr  | + fr  |  ja  |  ko  | - tr 

    + tr 

    top

    Comments

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    - - -
    -

    Modules | Directives | FAQ | Glossaire | Plan du site

    -

    Serveur HTTP Apache Version 2.5

    -
    -
    <-
    -

    Support Apache des serveurs virtuels par nom

    -
    -

    Langues Disponibles:  de  | - en  | - fr  | - ja  | - ko  | - tr 

    -
    - -

    Ce document décrit quand et comment utiliser des serveurs - virtuels par nom.

    -
    - -
    top
    -
    -

    Serveurs virtuels par nom vs. par IP

    - -

    Les serveurs virtuels par IP utilisent l'adresse IP - de la connexion afin de déterminer quel serveur virtuel doit - répondre. Par conséquent, vous devez disposer d'adresses IP - différentes pour chaque serveur.

    - -

    Avec un hébergement - virtuel par nom, le serveur s'appuie sur les informations - transmises par le client dans les en-têtes HTTP de ses requêtes. - La technique présentée ici vous permet de disposer de serveurs - virtuels différents partagés sur une même adresse IP.

    - -

    L'hébergement virtuel par nom est habituellement plus simple, - car il vous suffit de configurer votre serveur DNS pour que - chaque domaine pointe sur l'adresse IP dont vous disposez, et de - configurer votre serveur Apache HTTP afin qu'il reconnaisse - ces domaines. Il réduit aussi la pénurie en adresses IP. Par - conséquent, vous devriez utiliser l'hébergement virtuel par - nom, sauf dans le cas où vous utiliseriez des équipements qui - nécessitent un hébergement basé sur IP. Les raisons historiques de - l'hébergement basé sur IP dans un but de support de certains clients ne - s'appliquent plus à un serveur web d'usage général.

    - -

    La sélection du serveur virtuel en fonction du nom s'opère en - dehors de l'algorithme de sélection du serveur virtuel en fonction - de l'adresse IP, ce qui signifie que les recherches du point de vue - du nom du serveur ne s'effectuent que parmi le jeu de serveurs - virtuels pour lesquels la correspondance avec la paire adresse - IP/port est la plus exacte.

    - -
    top
    -
    -

    Comment le serveur sélectionne-t-il le serveur -virtuel basé sur le nom approprié

    - -

    Il est important de savoir que la première étape de la résolution - de serveur virtuel basée sur le nom est une résolution basée sur IP. - La résolution de serveur virtuel basée sur le nom ne fait que - choisir le serveur virtuel basé sur le nom le plus approprié, en se - limitant aux candidats qui conviennent le mieux du point de vue IP. - La résolution basée sur IP est sans objet si l'on - utilise un caractère générique (*) pour l'adresse IP dans - toutes les directives VirtualHost.

    - -

    A l'arrivée d'une requête, le serveur va rechercher l'argument de - section <VirtualHost> présentant la meilleure - (la plus exacte) correspondance avec la paire adresse IP/port - utilisée dans la requête. Si plusieurs serveurs virtuels possèdent - cette même paire adresse IP/port, Apache va ensuite comparer les - valeurs des directives ServerName et ServerAlias avec le nom de serveur - présent dans la requête.

    - -

    Si vous ne définissez pas de directive ServerName pour un serveur virtuel à base - de nom, le serveur utilisera par défaut le nom de domaine - entièrement qualifié (FQDN) déduit du nom d'hôte système. Cette - configuration sans nom de serveur explicite peut conduire à des - erreurs de choix du serveur virtuel à utiliser et est déconseillée.

    - -

    Le serveur virtuel à base de nom - par défaut pour une paire adresse IP/port

    -

    Si aucune directive ServerName ou ServerAlias ne correspond dans - la liste de serveurs virtuels présentant la meilleure correspondance - du point de vue adresse IP/port, c'est le premier serveur - virtuel de cette liste qui sera utilisé.

    - - -
    top
    -
    -

    Utilisation de serveurs virtuels par nom

    - -
    Modules ApparentésDirectives Apparentées
    - - -

    La première étape consiste à créer une section - <VirtualHost> - pour chacun des serveurs à définir. Dans chaque section - <VirtualHost>, - vous devez définir au minimum une directive - ServerName pour désigner - le serveur concerné et une directive - DocumentRoot pour préciser - l'emplacement sur le système de fichiers du contenu de ce serveur.

    - -

    Le serveur principal disparaît

    -

    Toute requête qui ne correspond à aucune section <VirtualHost> existante - est traitée avec la configuration du serveur principal, sans - tenir compte du nom d'hôte ou de la directive ServerName.

    - -

    Lorsque vous ajoutez un serveur virtuel basé sur le nom à un - serveur existant, et si les caractéristiques de ce serveur - virtuel correspondent à des combinaisons IP/port préexistantes, - les requêtes seront alors traitées par un serveur virtuel - explicite. Dans ce cas, il est en général judicieux de créer un - serveur virtuel par défaut - comportant une directive ServerName correspondant au nom du - serveur principal. De nouveaux domaines sur les mêmes interface - et port, mais nécessitant des configurations distinctes, - pourront alors être ajoutés en tant que serveurs virtuels - spécifiques (et non par défaut).

    -
    - -

    Héritage du nom de serveur

    -

    Il est toujours préférable de définir une directive ServerName au niveau de chaque serveur - virtuel à base de nom. Si un serveur virtuel ne définit pas - de directive ServerName, le - nom de ce serveur virtuel sera hérité du serveur principal. Si - aucun nom de serveur n'a été explicitement défini au niveau du - serveur principal, le serveur tentera de déterminer son nom via - une résolution de nom DNS inverse sur la première adresse - d'écoute. Dans tous les cas, ce nom de serveur hérité influencera - la sélection du serveur virtuel à base de nom, c'est pourquoi il - est toujours préférable de définir une directive ServerName pour chaque serveur virtuel - à base de nom.

    -
    - -

    Par exemple, supposez que vous hébergez le domaine - www.example.com et que vous souhaitez ajouter le - serveur virtuel other.example.com qui pointe sur - la même adresse IP. Il vous suffit d'ajouter la configuration - suivante à httpd.conf :

    - - 
    <VirtualHost *:80>
-    # Le premier serveur virtuel de la liste est aussi le
-    # serveur par défaut pour *:80
-    ServerName www.example.com
-    ServerAlias example.com
-    DocumentRoot "/www/domain"
-</VirtualHost>
-
-<VirtualHost *:80>
-    ServerName other.example.com
-    DocumentRoot "/www/otherdomain"
-</VirtualHost>
    - - -

    Autrement, vous pouvez spécifiez une adresse IP explicite - à la place de * dans la directive - <VirtualHost>. - Par exemple, cette méthode est utile si vous souhaitez faire - tourner quelques serveurs virtuels par nom sur une même adresse - IP, et d'autres, soit par IP, soit basés sur un autre jeu de - serveurs virtuels par nom sur une autre adresse IP.

    - -

    Plusieurs serveurs sont accessibles par plus d'un nom. Il - suffit de placer la directive - ServerAlias dans une section - <VirtualHost>. - Par exemple, dans la première section - <VirtualHost> - ci-dessus, la directive ServerAlias - indique aux utilisateurs les autres noms permis pour accéder au - même site Web :

    - - 
    ServerAlias example.com *.example.com
    - - -

    ainsi, toutes les requêtes portant sur un domaine - example.com seront servies par le serveur virtuel - www.example.com. Les caractères joker * - et ? peuvent être utilisés pour les correspondances. - Bien entendu, vous ne pouvez pas inventer des noms et les placer - dans une directive ServerName - ou ServerAlias. Tout d'abord, votre serveur DNS - doit être correctement configuré pour lier ces noms à une - adresse IP associée avec votre serveur.

    - -

    La recherche du serveur virtuel à base de nom qui correspond au - plus près à la requête s'effectue parmi les <virtualhost> selon leur - ordre d'apparition dans le fichier de configuration. Le premier - serveur virtuel dont le ServerName ou le ServerAlias correspond est utilisé, sans - priorité particulière en cas de présence de caractères génériques - (que ce soit pour le ServerName ou le ServerAlias).

    - -

    La liste complète des noms dans la section VirtualHost sont traités comme une - directive ServerAlias sans - caractères génériques.

    - -

    Finalement, vous pouvez affiner la configuration des serveurs - virtuels en plaçant d'autres directives à l'intérieur des sections - <VirtualHost>. - La plupart des directives peut être placée dans ces sections en - y changeant seulement la configuration du serveur virtuel associé. - Pour déterminer si une directive particulière est permise, - consultez le contexte de la - directive. Le jeu de directives configurées dans le contexte - du serveur principal (en dehors de toutes sections - <VirtualHost>) - sera utilisé seulement s'il n'y a pas de configuration contraire - par un serveur virtuel.

    - -
    -
    -

    Langues Disponibles:  de  | - en  | - fr  | - ja  | - ko  | - tr 

    -
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    -
    - \ No newline at end of file diff --git a/docs/manual/vhosts/name-based.html.fr.utf8 b/docs/manual/vhosts/name-based.html.fr.utf8 new file mode 100644 index 0000000000..a1a727c788 --- /dev/null +++ b/docs/manual/vhosts/name-based.html.fr.utf8 @@ -0,0 +1,267 @@ + + + + + +Support Apache des serveurs virtuels par nom - Serveur HTTP Apache Version 2.5 + + + + + + +
    +

    Modules | Directives | FAQ | Glossaire | Plan du site

    +

    Serveur HTTP Apache Version 2.5

    +
    +
    <-
    +

    Support Apache des serveurs virtuels par nom

    +
    +

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

    +
    + +

    Ce document décrit quand et comment utiliser des serveurs + virtuels par nom.

    +
    + +
    top
    +
    +

    Serveurs virtuels par nom vs. par IP

    + +

    Les serveurs virtuels par IP utilisent l'adresse IP + de la connexion afin de déterminer quel serveur virtuel doit + répondre. Par conséquent, vous devez disposer d'adresses IP + différentes pour chaque serveur.

    + +

    Avec un hébergement + virtuel par nom, le serveur s'appuie sur les informations + transmises par le client dans les en-têtes HTTP de ses requêtes. + La technique présentée ici vous permet de disposer de serveurs + virtuels différents partagés sur une même adresse IP.

    + +

    L'hébergement virtuel par nom est habituellement plus simple, + car il vous suffit de configurer votre serveur DNS pour que + chaque domaine pointe sur l'adresse IP dont vous disposez, et de + configurer votre serveur Apache HTTP afin qu'il reconnaisse + ces domaines. Il réduit aussi la pénurie en adresses IP. Par + conséquent, vous devriez utiliser l'hébergement virtuel par + nom, sauf dans le cas où vous utiliseriez des équipements qui + nécessitent un hébergement basé sur IP. Les raisons historiques de + l'hébergement basé sur IP dans un but de support de certains clients ne + s'appliquent plus à un serveur web d'usage général.

    + +

    La sélection du serveur virtuel en fonction du nom s'opère en + dehors de l'algorithme de sélection du serveur virtuel en fonction + de l'adresse IP, ce qui signifie que les recherches du point de vue + du nom du serveur ne s'effectuent que parmi le jeu de serveurs + virtuels pour lesquels la correspondance avec la paire adresse + IP/port est la plus exacte.

    + +
    top
    +
    +

    Comment le serveur sélectionne-t-il le serveur +virtuel basé sur le nom approprié

    + +

    Il est important de savoir que la première étape de la résolution + de serveur virtuel basée sur le nom est une résolution basée sur IP. + La résolution de serveur virtuel basée sur le nom ne fait que + choisir le serveur virtuel basé sur le nom le plus approprié, en se + limitant aux candidats qui conviennent le mieux du point de vue IP. + La résolution basée sur IP est sans objet si l'on + utilise un caractère générique (*) pour l'adresse IP dans + toutes les directives VirtualHost.

    + +

    A l'arrivée d'une requête, le serveur va rechercher l'argument de + section <VirtualHost> présentant la meilleure + (la plus exacte) correspondance avec la paire adresse IP/port + utilisée dans la requête. Si plusieurs serveurs virtuels possèdent + cette même paire adresse IP/port, Apache va ensuite comparer les + valeurs des directives ServerName et ServerAlias avec le nom de serveur + présent dans la requête.

    + +

    Si vous ne définissez pas de directive ServerName pour un serveur virtuel à base + de nom, le serveur utilisera par défaut le nom de domaine + entièrement qualifié (FQDN) déduit du nom d'hôte système. Cette + configuration sans nom de serveur explicite peut conduire à des + erreurs de choix du serveur virtuel à utiliser et est déconseillée.

    + +

    Le serveur virtuel à base de nom + par défaut pour une paire adresse IP/port

    +

    Si aucune directive ServerName ou ServerAlias ne correspond dans + la liste de serveurs virtuels présentant la meilleure correspondance + du point de vue adresse IP/port, c'est le premier serveur + virtuel de cette liste qui sera utilisé.

    + + +
    top
    +
    +

    Utilisation de serveurs virtuels par nom

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

    La première étape consiste à créer une section + <VirtualHost> + pour chacun des serveurs à définir. Dans chaque section + <VirtualHost>, + vous devez définir au minimum une directive + ServerName pour désigner + le serveur concerné et une directive + DocumentRoot pour préciser + l'emplacement sur le système de fichiers du contenu de ce serveur.

    + +

    Le serveur principal disparaît

    +

    Toute requête qui ne correspond à aucune section <VirtualHost> existante + est traitée avec la configuration du serveur principal, sans + tenir compte du nom d'hôte ou de la directive ServerName.

    + +

    Lorsque vous ajoutez un serveur virtuel basé sur le nom à un + serveur existant, et si les caractéristiques de ce serveur + virtuel correspondent à des combinaisons IP/port préexistantes, + les requêtes seront alors traitées par un serveur virtuel + explicite. Dans ce cas, il est en général judicieux de créer un + serveur virtuel par défaut + comportant une directive ServerName correspondant au nom du + serveur principal. De nouveaux domaines sur les mêmes interface + et port, mais nécessitant des configurations distinctes, + pourront alors être ajoutés en tant que serveurs virtuels + spécifiques (et non par défaut).

    +
    + +

    Héritage du nom de serveur

    +

    Il est toujours préférable de définir une directive ServerName au niveau de chaque serveur + virtuel à base de nom. Si un serveur virtuel ne définit pas + de directive ServerName, le + nom de ce serveur virtuel sera hérité du serveur principal. Si + aucun nom de serveur n'a été explicitement défini au niveau du + serveur principal, le serveur tentera de déterminer son nom via + une résolution de nom DNS inverse sur la première adresse + d'écoute. Dans tous les cas, ce nom de serveur hérité influencera + la sélection du serveur virtuel à base de nom, c'est pourquoi il + est toujours préférable de définir une directive ServerName pour chaque serveur virtuel + à base de nom.

    +
    + +

    Par exemple, supposez que vous hébergez le domaine + www.example.com et que vous souhaitez ajouter le + serveur virtuel other.example.com qui pointe sur + la même adresse IP. Il vous suffit d'ajouter la configuration + suivante à httpd.conf :

    + + 
    <VirtualHost *:80>
+    # Le premier serveur virtuel de la liste est aussi le
+    # serveur par défaut pour *:80
+    ServerName www.example.com
+    ServerAlias example.com
+    DocumentRoot "/www/domain"
+</VirtualHost>
+
+<VirtualHost *:80>
+    ServerName other.example.com
+    DocumentRoot "/www/otherdomain"
+</VirtualHost>
    + + +

    Autrement, vous pouvez spécifiez une adresse IP explicite + à la place de * dans la directive + <VirtualHost>. + Par exemple, cette méthode est utile si vous souhaitez faire + tourner quelques serveurs virtuels par nom sur une même adresse + IP, et d'autres, soit par IP, soit basés sur un autre jeu de + serveurs virtuels par nom sur une autre adresse IP.

    + +

    Plusieurs serveurs sont accessibles par plus d'un nom. Il + suffit de placer la directive + ServerAlias dans une section + <VirtualHost>. + Par exemple, dans la première section + <VirtualHost> + ci-dessus, la directive ServerAlias + indique aux utilisateurs les autres noms permis pour accéder au + même site Web :

    + + 
    ServerAlias example.com *.example.com
    + + +

    ainsi, toutes les requêtes portant sur un domaine + example.com seront servies par le serveur virtuel + www.example.com. Les caractères joker * + et ? peuvent être utilisés pour les correspondances. + Bien entendu, vous ne pouvez pas inventer des noms et les placer + dans une directive ServerName + ou ServerAlias. Tout d'abord, votre serveur DNS + doit être correctement configuré pour lier ces noms à une + adresse IP associée avec votre serveur.

    + +

    La recherche du serveur virtuel à base de nom qui correspond au + plus près à la requête s'effectue parmi les <virtualhost> selon leur + ordre d'apparition dans le fichier de configuration. Le premier + serveur virtuel dont le ServerName ou le ServerAlias correspond est utilisé, sans + priorité particulière en cas de présence de caractères génériques + (que ce soit pour le ServerName ou le ServerAlias).

    + +

    La liste complète des noms dans la section VirtualHost sont traités comme une + directive ServerAlias sans + caractères génériques.

    + +

    Finalement, vous pouvez affiner la configuration des serveurs + virtuels en plaçant d'autres directives à l'intérieur des sections + <VirtualHost>. + La plupart des directives peut être placée dans ces sections en + y changeant seulement la configuration du serveur virtuel associé. + Pour déterminer si une directive particulière est permise, + consultez le contexte de la + directive. Le jeu de directives configurées dans le contexte + du serveur principal (en dehors de toutes sections + <VirtualHost>) + sera utilisé seulement s'il n'y a pas de configuration contraire + par un serveur virtuel.

    + +
    +
    +

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

    +
    top

    Commentaires

    Notice:
    This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.
    +
    + \ No newline at end of file -- cgit v1.2.3