Ce module est une extension et s'inspire fortement du module d'Apache 1.3 mod_mmap_static.

Description:	Met en cache une liste de gestionnaires de fichiers au -démarrage
Syntaxe:	`CacheFile chemin_fichier [chemin fichier] ...`
Contexte:	configuration du serveur
Statut:	Expérimental
Module:	mod_file_cache

Description:	Charge au démarrage une liste de fichiers en -mémoire
Syntaxe:	`MMapFile chemin fichier [chemin_fichier] ...`
Contexte:	configuration du serveur
Statut:	Expérimental
Module:	mod_file_cache

Description:	Met en cache une liste de gestionnaires de fichiers au +démarrage
Syntaxe:	`CacheFile chemin_fichier [chemin fichier] ...`
Contexte:	configuration du serveur
Statut:	Expérimental
Module:	mod_file_cache

Description:	Charge au démarrage une liste de fichiers en +mémoire
Syntaxe:	`MMapFile chemin fichier [chemin_fichier] ...`
Contexte:	configuration du serveur
Statut:	Expérimental
Module:	mod_file_cache

설명:	시작시 여러 파일 핸들을 캐쉬한다
문법:	`CacheFile file-path [file-path] ...`
사용장소:	주서버설정
상태:	Experimental
모듈:	mod_file_cache

설명:	시작시 여러 파일을 메모리에 대응한다
문법:	`MMapFile file-path [file-path] ...`
사용장소:	주서버설정
상태:	Experimental
모듈:	mod_file_cache

설명:	시작시 여러 파일 핸들을 캐쉬한다
문법:	`CacheFile file-path [file-path] ...`
사용장소:	주서버설정
상태:	Experimental
모듈:	mod_file_cache

설명:	시작시 여러 파일을 메모리에 대응한다
문법:	`MMapFile file-path [file-path] ...`
사용장소:	주서버설정
상태:	Experimental
모듈:	mod_file_cache

AddOutputFilterByType Directive

@@ -98,7 +292,7 @@ being moved to INCLUDES filter and then by the DEFLATE filter.

<Location /cgi-bin/>
+    <Location "/cgi-bin/">
     Options Includes
     AddOutputFilterByType INCLUDES;DEFLATE text/html
 </Location>
@@ -294,200 +488,6 @@ for a complete reference and examples.
 
 
-
-
-Smart Filtering
-    In the traditional filtering model, filters are inserted unconditionally
-    using AddOutputFilter and family.
-    Each filter then needs to determine whether to run, and there is little
-    flexibility available for server admins to allow the chain to be
-    configured dynamically.
-
-    mod_filter by contrast gives server administrators a
-    great deal of flexibility in configuring the filter chain.  In fact,
-    filters can be inserted based on complex boolean
-    expressions This generalises the limited
-    flexibility offered by AddOutputFilterByType.
-

-
-Filter Declarations, Providers and Chains
-    
-    

-    Figure 1: The traditional filter model
-
-    In the traditional model, output filters are a simple chain
-    from the content generator (handler) to the client.  This works well
-    provided the filter chain can be correctly configured, but presents
-    problems when the filters need to be configured dynamically based on
-    the outcome of the handler.
-
-    
-    

-    Figure 2: The mod_filter model
-
-    mod_filter works by introducing indirection into
-    the filter chain.  Instead of inserting filters in the chain, we insert
-    a filter harness which in turn dispatches conditionally
-    to a filter provider.  Any content filter may be used as a provider
-    to mod_filter; no change to existing filter modules
-    is required (although it may be possible to simplify them).  There can be
-    multiple providers for one filter, but no more than one provider will
-    run for any single request.
-
-    A filter chain comprises any number of instances of the filter
-    harness, each of which may have any number of providers.  A special
-    case is that of a single provider with unconditional dispatch: this
-    is equivalent to inserting the provider filter directly into the chain.
-

-
-Configuring the Chain
-    There are three stages to configuring a filter chain with
-    mod_filter. For details of the directives, see below.
-
-    
-    Declare Filters
-    The FilterDeclare directive
-    declares a filter, assigning it a name and filter type.  Required
-    only if the filter is not the default type AP_FTYPE_RESOURCE.
-
-    Register Providers
-    The FilterProvider
-    directive registers a provider with a filter. The filter may have
-    been declared with FilterDeclare; if not, FilterProvider will implicitly
-    declare it with the default type AP_FTYPE_RESOURCE. The provider
-    must have been
-    registered with ap_register_output_filter by some module.
-    The final argument to FilterProvider is an expression: the provider will be
-    selected to run for a request if and only if the expression evaluates
-    to true.  The expression may evaluate HTTP request or response
-    headers, environment variables, or the Handler used by this request.
-    Unlike earlier versions, mod_filter now supports complex expressions
-    involving multiple criteria with AND / OR logic (&& / ||)
-    and brackets. The details of the expression syntax are described in
-    the ap_expr documentation.
-
-    Configure the Chain
-    The above directives build components of a smart filter chain,
-    but do not configure it to run.  The FilterChain directive builds a filter chain from smart
-    filters declared, offering the flexibility to insert filters at the
-    beginning or end of the chain, remove a filter, or clear the chain.
-
-

-
-Filtering and Response Status
-    mod_filter normally only runs filters on responses with
-    HTTP status 200 (OK).  If you want to filter documents with
-    other response statuses, you can set the filter-errordocs
-    environment variable, and it will work on all responses
-    regardless of status.  To refine this further, you can use
-    expression conditions with FilterProvider.
-

-
-Upgrading from Apache HTTP Server 2.2 Configuration
-    The FilterProvider
-    directive has changed from httpd 2.2: the match and
-    dispatch arguments are replaced with a single but
-    more versatile expression.  In general, you can convert
-    a match/dispatch pair to the two sides of an expression, using
-    something like:
-    "dispatch = 'match'"
-    The Request headers, Response headers and Environment variables
-    are now interpreted from syntax %{req:foo},
-    %{resp:foo} and %{env:foo} respectively.
-    The variables %{HANDLER} and %{CONTENT_TYPE}
-    are also supported.
-    Note that the match no longer support substring matches.  They can be
-    replaced by regular expression matches.
-

-
-Examples
-    
-    Server side Includes (SSI)
-    A simple case of replacing AddOutputFilterByType
-    FilterDeclare SSI
-FilterProvider SSI INCLUDES "%{CONTENT_TYPE} =~ m|^text/html|"
-FilterChain SSI
-
-    
-
-    Server side Includes (SSI)
-    The same as the above but dispatching on handler (classic
-    SSI behaviour; .shtml files get processed).
-    FilterProvider SSI INCLUDES "%{HANDLER} = 'server-parsed'"
-FilterChain SSI
-
-    
-
-    Emulating mod_gzip with mod_deflate
-    Insert INFLATE filter only if "gzip" is NOT in the
-    Accept-Encoding header.  This filter runs with ftype CONTENT_SET.
-    FilterDeclare gzip CONTENT_SET
-FilterProvider gzip inflate "%{req:Accept-Encoding} !~ /gzip/"
-FilterChain gzip
-
-    
-
-    Image Downsampling
-    Suppose we want to downsample all web images, and have filters
-    for GIF, JPEG and PNG.
-    FilterProvider unpack jpeg_unpack "%{CONTENT_TYPE} = 'image/jpeg'"
-FilterProvider unpack gif_unpack "%{CONTENT_TYPE} = 'image/gif'"
-FilterProvider unpack png_unpack "%{CONTENT_TYPE} = 'image/png'"
-
-FilterProvider downsample downsample_filter "%{CONTENT_TYPE} = m|^image/(jpeg|gif|png)|"
-FilterProtocol downsample "change=yes"
-
-FilterProvider repack jpeg_pack "%{CONTENT_TYPE} = 'image/jpeg'"
-FilterProvider repack gif_pack "%{CONTENT_TYPE} = 'image/gif'"
-FilterProvider repack png_pack "%{CONTENT_TYPE} = 'image/png'"
-<Location /image-filter>
-    FilterChain unpack downsample repack
-</Location>
-
-    
-    
-

-
-Protocol Handling
-    Historically, each filter is responsible for ensuring that whatever
-    changes it makes are correctly represented in the HTTP response headers,
-    and that it does not run when it would make an illegal change.  This
-    imposes a burden on filter authors to re-implement some common
-    functionality in every filter:
-
-    
-    Many filters will change the content, invalidating existing content
-    tags, checksums, hashes, and lengths.
-
-    Filters that require an entire, unbroken response in input need to
-    ensure they don't get byteranges from a backend.
-
-    Filters that transform output in a filter need to ensure they don't
-    violate a Cache-Control: no-transform header from the
-    backend.
-
-    Filters may make responses uncacheable.
-    
-
-    mod_filter aims to offer generic handling of these
-    details of filter implementation, reducing the complexity required of
-    content filter modules. This is work-in-progress; the
-    FilterProtocol implements
-    some of this functionality for back-compatibility with Apache 2.0
-    modules.  For httpd 2.1 and later, the
-    ap_register_output_filter_protocol and
-    ap_filter_protocol API enables filter modules to
-    declare their own behaviour.
-
-    At the same time, mod_filter should not interfere
-    with a filter that wants to handle all aspects of the protocol.  By
-    default (i.e. in the absence of any FilterProtocol directives), mod_filter
-    will leave the headers untouched.
-
-    At the time of writing, this feature is largely untested,
-    as modules in common use are designed to work with 2.0.
-    Modules using it should test it carefully.
-
 
 
 Available Languages:  en 

Modified: httpd/httpd/trunk/docs/manual/mod/mod_filter.xml
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_filter.xml?rev=1673892&r1=1673891&r2=1673892&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/mod_filter.xml (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_filter.xml Wed Apr 15 17:46:53 2015
@@ -193,7 +193,7 @@ FilterProtocol downsample "change=yes"
 FilterProvider repack jpeg_pack "%{CONTENT_TYPE} = 'image/jpeg'"
 FilterProvider repack gif_pack "%{CONTENT_TYPE} = 'image/gif'"
 FilterProvider repack png_pack "%{CONTENT_TYPE} = 'image/png'"
-<Location /image-filter>
+<Location "/image-filter">
     FilterChain unpack downsample repack
 </Location>
     
@@ -281,7 +281,7 @@ being moved to mod_filter
 
     
-<Location /cgi-bin/>
+<Location "/cgi-bin/">
     Options Includes
     AddOutputFilterByType INCLUDES;DEFLATE text/html
 </Location>

Modified: httpd/httpd/trunk/docs/manual/mod/mod_firehose.html.en
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_firehose.html.en?rev=1673892&r1=1673891&r2=1673892&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/mod_firehose.html.en (original)
+++ httpd/httpd/trunk/docs/manual/mod/mod_firehose.html.en Wed Apr 15 17:46:53 2015
@@ -70,6 +70,96 @@
 firehose
 Comments
 
+
+Enabling a Firehose
+    
+
+    To enable the module, it should be compiled and loaded
+    in to your running Apache configuration, and the directives below
+    used to record the data you are interested in.
+    
+    It is possible to record both incoming and outgoing data to
+    the same filename if desired, as the direction of flow is recorded
+    within each fragment.
+
+    It is possible to write to both normal files and fifos (pipes).
+    In the case of fifos, mod_firehose ensures that the packet size is
+    no larger than PIPE_BUF to ensure writes are atomic.
+
+    If a pipe is being used, something must be reading from the pipe
+    before httpd is started for the pipe to be successfully opened for
+    write. If the request to open the pipe fails, mod_firehose will
+    silently stand down and not record anything, and the server will
+    keep running as normal.
+
+    By default, all attempts to write will block the server. If the
+    webserver has been built against APR v2.0 or later, and an optional
+    "nonblock" parameter is specified all file writes will be non
+    blocking, and buffer overflows will cause debugging data to be lost.
+    In this case it is possible to prioritise the running of the server
+    over the recording of firehose data.
+
+

+
+Stream Format
+    
+
+    The server typically serves multiple connections simultaneously,
+    and as a result requests and responses need to be multiplexed before
+    being written to the firehose.
+    
+    The fragment format is designed as clear text, so that a firehose
+    can be opened with and inspected by a normal text editor.
+    Alternatively, the firehose tool can be used to
+    demultiplex the firehose back into individual requests or
+    connections.
+
+    The size of the multiplexed fragments is governed by PIPE_BUF,
+    the maximum size of write the system is prepared to perform
+    atomically. By keeping the multiplexed fragments below PIPE_BUF in
+    size, the module guarantees that data from different fragments does
+    not interleave. The size of PIPE_BUF varies on different operating
+    systems.
+
+    The BNF for the fragment format is as follows:
+
+     stream = 0*(fragment)
+
+ fragment = header CRLF body CRLF
+
+ header = length SPC timestamp SPC ( request | response ) SPC uuid SPC count
+
+ length = <up to 16 byte hex fragment length>
+ timestamp = <up to 16 byte hex timestamp microseconds since 1970>
+ request = "<"
+ response = ">"
+ uuid = <formatted uuid of the connection>
+ count = <hex fragment number in the connection>
+
+ body = <the binary content of the fragment>
+
+ SPC = <a single space>
+ CRLF = <a carriage return, followed by a line feed>
+
+    All fragments for a connection or a request will share the same
+    UUID, depending on whether connections or requests are being recorded.
+    If connections are being recorded, multiple requests may appear within
+    a connection. A fragment with a zero length indicates the end of the
+    connection.
+
+    Fragments may go missing or be dropped if the process reading the
+    fragments is too slow. If this happens, gaps will exist in the
+    connection counter numbering. A warning will be logged in the error
+    log to indicate the UUID and counter of the dropped fragment, so it
+    can be confirmed the fragment was dropped.
+
+    It is possible that the terminating empty fragment may not appear,
+    caused by the httpd process crashing, or being terminated ungracefully.
+    The terminating fragment may be dropped if the process reading the
+    fragments is not fast enough.
+
+
+
 FirehoseConnectionInput Directive

Description:	assigns an output filter to a particular media-type

@@ -183,96 +273,6 @@ later. -

Enabling a Firehose

- - -

To enable the module, it should be compiled and loaded - in to your running Apache configuration, and the directives below - used to record the data you are interested in.

- -

It is possible to record both incoming and outgoing data to - the same filename if desired, as the direction of flow is recorded - within each fragment.

- -

It is possible to write to both normal files and fifos (pipes). - In the case of fifos, mod_firehose ensures that the packet size is - no larger than PIPE_BUF to ensure writes are atomic.

- -

If a pipe is being used, something must be reading from the pipe - before httpd is started for the pipe to be successfully opened for - write. If the request to open the pipe fails, mod_firehose will - silently stand down and not record anything, and the server will - keep running as normal.

- -

By default, all attempts to write will block the server. If the - webserver has been built against APR v2.0 or later, and an optional - "nonblock" parameter is specified all file writes will be non - blocking, and buffer overflows will cause debugging data to be lost. - In this case it is possible to prioritise the running of the server - over the recording of firehose data.

- -

Stream Format

- - -

The server typically serves multiple connections simultaneously, - and as a result requests and responses need to be multiplexed before - being written to the firehose.

- -

The fragment format is designed as clear text, so that a firehose - can be opened with and inspected by a normal text editor. - Alternatively, the firehose tool can be used to - demultiplex the firehose back into individual requests or - connections.

- -

The size of the multiplexed fragments is governed by PIPE_BUF, - the maximum size of write the system is prepared to perform - atomically. By keeping the multiplexed fragments below PIPE_BUF in - size, the module guarantees that data from different fragments does - not interleave. The size of PIPE_BUF varies on different operating - systems.

- -

The BNF for the fragment format is as follows:

- -

 stream = 0*(fragment)
-
- fragment = header CRLF body CRLF
-
- header = length SPC timestamp SPC ( request | response ) SPC uuid SPC count
-
- length = <up to 16 byte hex fragment length>
- timestamp = <up to 16 byte hex timestamp microseconds since 1970>
- request = "<"
- response = ">"
- uuid = <formatted uuid of the connection>
- count = <hex fragment number in the connection>
-
- body = <the binary content of the fragment>
-
- SPC = <a single space>
- CRLF = <a carriage return, followed by a line feed>

- -

All fragments for a connection or a request will share the same - UUID, depending on whether connections or requests are being recorded. - If connections are being recorded, multiple requests may appear within - a connection. A fragment with a zero length indicates the end of the - connection.

- -

Fragments may go missing or be dropped if the process reading the - fragments is too slow. If this happens, gaps will exist in the - connection counter numbering. A warning will be logged in the error - log to indicate the UUID and counter of the dropped fragment, so it - can be confirmed the fragment was dropped.

- -

It is possible that the terminating empty fragment may not appear, - caused by the httpd process crashing, or being terminated ungracefully. - The terminating fragment may be dropped if the process reading the - fragments is not fast enough.

- -

Available Languages: en

Modified: httpd/httpd/trunk/docs/manual/mod/mod_headers.html.en URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_headers.html.en?rev=1673892&r1=1673891&r2=1673892&view=diff ============================================================================== --- httpd/httpd/trunk/docs/manual/mod/mod_headers.html.en (original) +++ httpd/httpd/trunk/docs/manual/mod/mod_headers.html.en Wed Apr 15 17:46:53 2015 @@ -52,6 +52,158 @@ headers

Comments

Order of Processing

+ +

The directives provided by mod_headers can + occur almost anywhere within the server configuration, and can be + limited in scope by enclosing them in configuration sections.

+ +

Order of processing is important and is affected both by the + order in the configuration file and by placement in configuration sections. These + two directives have a different effect if reversed:

+ +

RequestHeader append MirrorID "mirror 12"
+RequestHeader unset MirrorID

+ + +

This way round, the MirrorID header is not set. If + reversed, the MirrorID header is set to "mirror 12".

Early and Late Processing

mod_headers can be applied either early or late + in the request. The normal mode is late, when Request Headers are + set immediately before running the content generator and Response + Headers just as the response is sent down the wire. Always use + Late mode in an operational server.

+ +

Early mode is designed as a test/debugging aid for developers. + Directives defined using the early keyword are set + right at the beginning of processing the request. This means + they can be used to simulate different requests and set up test + cases, but it also means that headers may be changed at any time + by other modules before generating a Response.

+ +

Because early directives are processed before the request path's + configuration is traversed, early headers can only be set in a + main server or virtual host context. Early directives cannot depend + on a request path, so they will fail in contexts such as + <Directory> or + <Location>.

Examples

+ +

+ Copy all request headers that begin with "TS" to the + response headers: + +
```
Header echo ^TS
```
+ +
+ Add a header, MyHeader, to the response including a + timestamp for when the request was received and how long it + took to begin serving the request. This header can be used by + the client to intuit load on the server or in isolating + bottlenecks between the client and the server. + +
```
Header set MyHeader "%D %t"
```
+ + +
results in this header being added to the response:
+ +
+ MyHeader: D=3775428 t=991424704447256 +
+
+ Say hello to Joe + +
```
Header set MyHeader "Hello Joe. It took %D microseconds for Apache to serve this request."
```
+ + +
results in this header being added to the response:
+ +
+ MyHeader: Hello Joe. It took D=3775428 microseconds for Apache + to serve this request. +
+
+ Conditionally send MyHeader on the response if and + only if header MyRequestHeader is present on the request. + This is useful for constructing headers in response to some client + stimulus. Note that this example requires the services of the + mod_setenvif module. + +
```
SetEnvIf MyRequestHeader myvalue HAVE_MyRequestHeader
+Header set MyHeader "%D %t mytext" env=HAVE_MyRequestHeader
```
+ + +
If the header MyRequestHeader: myvalue is present on + the HTTP request, the response will contain the following header:
+ +
+ MyHeader: D=3775428 t=991424704447256 mytext +
+
+ Enable DAV to work with Apache running HTTP through SSL hardware + (problem + description) by replacing https: with + http: in the Destination header: + +
```
RequestHeader edit Destination ^https: http: early
```
+ +
+ Set the same header value under multiple nonexclusive conditions, + but do not duplicate the value in the final header. + If all of the following conditions applied to a request (i.e., + if the CGI, NO_CACHE and + NO_STORE environment variables all existed for the + request): + +
```
Header merge Cache-Control no-cache env=CGI
+Header merge Cache-Control no-cache env=NO_CACHE
+Header merge Cache-Control no-store env=NO_STORE
```
+ + +
then the response would contain the following header:
+ +
+ Cache-Control: no-cache, no-store +
+ +
If append was used instead of merge, + then the response would contain the following header:
+ +
+ Cache-Control: no-cache, no-cache, no-store +
+
+ Set a test cookie if and only if the client didn't send us a cookie +
```
Header set Set-Cookie testcookie "expr=-z %{req:Cookie}"
```
+ +
+ Append a Caching header for responses with a HTTP status code of 200 +
```
Header append Cache-Control s-maxage=600 "expr=%{REQUEST_STATUS} == 200"
```
+ +

Header Directive

Description:	Capture traffic coming into the server on each connection

@@ -392,158 +544,6 @@ available in 2.4.10 and later input filters to be overridden or modified.

Order of Processing

- -

The directives provided by mod_headers can - occur almost anywhere within the server configuration, and can be - limited in scope by enclosing them in configuration sections.

- -

Order of processing is important and is affected both by the - order in the configuration file and by placement in configuration sections. These - two directives have a different effect if reversed:

- -

RequestHeader append MirrorID "mirror 12"
-RequestHeader unset MirrorID

- - -

This way round, the MirrorID header is not set. If - reversed, the MirrorID header is set to "mirror 12".

Early and Late Processing

mod_headers can be applied either early or late - in the request. The normal mode is late, when Request Headers are - set immediately before running the content generator and Response - Headers just as the response is sent down the wire. Always use - Late mode in an operational server.

- -

Early mode is designed as a test/debugging aid for developers. - Directives defined using the early keyword are set - right at the beginning of processing the request. This means - they can be used to simulate different requests and set up test - cases, but it also means that headers may be changed at any time - by other modules before generating a Response.

- -

Because early directives are processed before the request path's - configuration is traversed, early headers can only be set in a - main server or virtual host context. Early directives cannot depend - on a request path, so they will fail in contexts such as - <Directory> or - <Location>.

Examples

- -

- Copy all request headers that begin with "TS" to the - response headers: - -
```
Header echo ^TS
```
- -
- Add a header, MyHeader, to the response including a - timestamp for when the request was received and how long it - took to begin serving the request. This header can be used by - the client to intuit load on the server or in isolating - bottlenecks between the client and the server. - -
```
Header set MyHeader "%D %t"
```
- - -
results in this header being added to the response:
- -
- MyHeader: D=3775428 t=991424704447256 -
-
- Say hello to Joe - -
```
Header set MyHeader "Hello Joe. It took %D microseconds for Apache to serve this request."
```
- - -
results in this header being added to the response:
- -
- MyHeader: Hello Joe. It took D=3775428 microseconds for Apache - to serve this request. -
-
- Conditionally send MyHeader on the response if and - only if header MyRequestHeader is present on the request. - This is useful for constructing headers in response to some client - stimulus. Note that this example requires the services of the - mod_setenvif module. - -
```
SetEnvIf MyRequestHeader myvalue HAVE_MyRequestHeader
-Header set MyHeader "%D %t mytext" env=HAVE_MyRequestHeader
```
- - -
If the header MyRequestHeader: myvalue is present on - the HTTP request, the response will contain the following header:
- -
- MyHeader: D=3775428 t=991424704447256 mytext -
-
- Enable DAV to work with Apache running HTTP through SSL hardware - (problem - description) by replacing https: with - http: in the Destination header: - -
```
RequestHeader edit Destination ^https: http: early
```
- -
- Set the same header value under multiple nonexclusive conditions, - but do not duplicate the value in the final header. - If all of the following conditions applied to a request (i.e., - if the CGI, NO_CACHE and - NO_STORE environment variables all existed for the - request): - -
```
Header merge Cache-Control no-cache env=CGI
-Header merge Cache-Control no-cache env=NO_CACHE
-Header merge Cache-Control no-store env=NO_STORE
```
- - -
then the response would contain the following header:
- -
- Cache-Control: no-cache, no-store -
- -
If append was used instead of merge, - then the response would contain the following header:
- -
- Cache-Control: no-cache, no-cache, no-store -
-
- Set a test cookie if and only if the client didn't send us a cookie -
```
Header set Set-Cookie testcookie "expr=-z %{req:Cookie}"
```
- -
- Append a Caching header for responses with a HTTP status code of 200 -
```
Header append Cache-Control s-maxage=600 "expr=%{REQUEST_STATUS} == 200"
```
- -

Available Languages: en | Modified: httpd/httpd/trunk/docs/manual/mod/mod_headers.html.fr URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_headers.html.fr?rev=1673892&r1=1673891&r2=1673892&view=diff ============================================================================== --- httpd/httpd/trunk/docs/manual/mod/mod_headers.html.fr (original) +++ httpd/httpd/trunk/docs/manual/mod/mod_headers.html.fr Wed Apr 15 17:46:53 2015 @@ -40,18 +40,185 @@ HTTP modifier les en-têtes de requêtes et de réponses HTTP. Les en-têtes peuvent être fusionnés, remplacés ou supprimés.

Chronologie du traitement

+ +

Les directives fournies par mod_headers peuvent + s'insérer presque partout dans la configuration du serveur, et on + peut limiter leur portée en les plaçant dans des sections de configuration.

+ +

La chronologie du traitement est importante et est affectée par + l'ordre d'apparition des directives dans le fichier de configuration + et par leur placement dans les sections de configuration. Ainsi, + ces deux directives ont un effet différent si leur ordre est inversé + :

+ +

RequestHeader append MirrorID "mirror 12"
+RequestHeader unset MirrorID

+ + +

Dans cet ordre, l'en-tête MirrorID n'est pas défini. + Si l'ordre des directives était inversé, l'en-tête + MirrorID serait défini à "mirror 12".

Traitement précoce et traitement +tardif

mod_headers peut agir soir précocement, soit + tardivement au niveau de la requête. Le mode normal est le mode + tardif, lorsque les en-têtes de requête sont définis, immédiatement + avant l'exécution du générateur de contenu, et pour les en-têtes de + réponse, juste au moment où la réponse est envoyée sur le réseau. + Utilisez toujours le mode tardif sur un serveur en production.

+ +

Le mode précoce a été conçu à des fins d'aide aux tests et au + débogage pour les développeurs. Les directives définies en utilisant + le mot-clé early sont censées agir au tout début du + traitement de la requête. Cela signifie que l'on peut les utiliser + pour simuler différentes requêtes et définir des situations de test, + tout en gardant à l'esprit que les en-têtes peuvent être modifiés à + tout moment par d'autres modules avant que le réponse ne soit + générée.

+ +

Comme les directives précoces sont traitées avant que le + chemin de la requête ne soit parcouru, les en-têtes + précoces ne peuvent être définis que dans un contexte de serveur + principal ou de serveur virtuel. Les directives précoces ne peuvent + pas dépendre d'un chemin de requête, si bien qu'elles échoueront + dans des contextes tels que <Directory> ou <Location>.

Exemples

+ +

+ Copie tous les en-têtes de requête qui commencent par "TS" vers + les en-têtes de la réponse : + +
```
Header echo ^TS
```
+ +
+ Ajoute à la réponse un en-tête, mon-en-tête, qui + contient un horodatage permettant de déterminer le moment où la + requête a été reçue, et le temps qui s'est écoulé jusqu'à ce que + la requête ait commencé à être servie. Cet en-tête peut être + utilisé par le client pour estimer la charge du serveur ou + isoler les goulets d'étranglement entre le client et le + serveur. + +
```
Header set mon-en-tête "%D %t"
```
+ + +
le résultat est l'ajout à la réponse d'un en-tête du type :
+ +
+ mon-en-tête: D=3775428 t=991424704447256 +
+
+ Dit Bonjour à Joe + +
+ Header set mon-en-tête "Bonjour Joe. Il a fallu %D microsecondes \ + à Apache pour servir cette requête." +
+ +
le résultat est l'ajout à la réponse d'un en-tête du type :
+ +
```
	Header set MyHeader "Bonjour Joe. Il a fallu D=3775428 microsecondes à Apache
+          pour servir cette requête."
```
+ +
+ Ajoute l'en-tête mon-en-tête à la réponse si et + seulement si l'en-tête mon-en-tête-requête est + présent dans la requête. Ceci peut s'avérer utile pour générer + des en-têtes de réponse "à la tête du client". Notez que cet + exemple nécessite les services du module + mod_setenvif. + +
```
SetEnvIf MyRequestHeader myvalue HAVE_MyRequestHeader
+Header set MyHeader "%D %t mytext" env=HAVE_MyRequestHeader
```
+ + +
Si l'en-tête mon-en-tête-requête: mavaleur est + présent dans la requête HTTP, la réponse contiendra un en-tête + du type :
+ +
+ mon-en-tête: D=3775428 t=991424704447256 montexte +
+
+ Permet à DAV de fonctionner avec Apache sur SSL (voir la description + du problème) en remplaçant https: par + http: dans l'en-tête Destination : + +
```
RequestHeader edit Destination ^https: http: early
```
+ +
+ Définit la valeur d'un même en-tête sous de multiples conditions + non exclusives, mais ne duplique pas une valeur déjà définie + dans l'en-tête qui en résulte. Si toutes les conditions + suivantes sont satisfaites pour une requête (en d'autres termes, + si les trois variables d'environnement CGI, + NO_CACHE et NO_STORE existent pour la + requête) : + +
```
Header merge Cache-Control no-cache env=CGI
+Header merge Cache-Control no-cache env=NO_CACHE
+Header merge Cache-Control no-store env=NO_STORE
```
+ + +
alors, la réponse contiendra l'en-tête suivant :
+ +
+ Cache-Control: no-cache, no-store +
+ +
Si append avait été utilisé à la place de + merge, la réponse aurait contenu l'en-tête suivant + :
+ +
+ Cache-Control: no-cache, no-cache, no-store +
+
+ Définit un cookie de test si et seulement si le client n'envoie + pas de cookie +
```
Header set Set-Cookie testcookie "expr=-z %{req:Cookie}"
```
+ +
+ Ajoute un en-tête de mise en cache pour les réponses avec un + code d'état HTTP de 200 +
```
Header append Cache-Control s-maxage=600 "expr=%{REQUEST_STATUS} == 200"
```
+ +

Directive Header

Description:	Configure HTTP response headers

@@ -438,173 +605,6 @@ version 2.4.10 d'Apache.

Chronologie du traitement

- -

Les directives fournies par mod_headers peuvent - s'insérer presque partout dans la configuration du serveur, et on - peut limiter leur portée en les plaçant dans des sections de configuration.

- -

La chronologie du traitement est importante et est affectée par - l'ordre d'apparition des directives dans le fichier de configuration - et par leur placement dans les sections de configuration. Ainsi, - ces deux directives ont un effet différent si leur ordre est inversé - :

- -

RequestHeader append MirrorID "mirror 12"
-RequestHeader unset MirrorID

- - -

Dans cet ordre, l'en-tête MirrorID n'est pas défini. - Si l'ordre des directives était inversé, l'en-tête - MirrorID serait défini à "mirror 12".

Traitement précoce et traitement -tardif

mod_headers peut agir soir précocement, soit - tardivement au niveau de la requête. Le mode normal est le mode - tardif, lorsque les en-têtes de requête sont définis, immédiatement - avant l'exécution du générateur de contenu, et pour les en-têtes de - réponse, juste au moment où la réponse est envoyée sur le réseau. - Utilisez toujours le mode tardif sur un serveur en production.

- -

Le mode précoce a été conçu à des fins d'aide aux tests et au - débogage pour les développeurs. Les directives définies en utilisant - le mot-clé early sont censées agir au tout début du - traitement de la requête. Cela signifie que l'on peut les utiliser - pour simuler différentes requêtes et définir des situations de test, - tout en gardant à l'esprit que les en-têtes peuvent être modifiés à - tout moment par d'autres modules avant que le réponse ne soit - générée.

- -

Comme les directives précoces sont traitées avant que le - chemin de la requête ne soit parcouru, les en-têtes - précoces ne peuvent être définis que dans un contexte de serveur - principal ou de serveur virtuel. Les directives précoces ne peuvent - pas dépendre d'un chemin de requête, si bien qu'elles échoueront - dans des contextes tels que <Directory> ou <Location>.

Exemples

- -

- Copie tous les en-têtes de requête qui commencent par "TS" vers - les en-têtes de la réponse : - -
```
Header echo ^TS
```
- -
- Ajoute à la réponse un en-tête, mon-en-tête, qui - contient un horodatage permettant de déterminer le moment où la - requête a été reçue, et le temps qui s'est écoulé jusqu'à ce que - la requête ait commencé à être servie. Cet en-tête peut être - utilisé par le client pour estimer la charge du serveur ou - isoler les goulets d'étranglement entre le client et le - serveur. - -
```
Header set mon-en-tête "%D %t"
```
- - -
le résultat est l'ajout à la réponse d'un en-tête du type :
- -
- mon-en-tête: D=3775428 t=991424704447256 -
-
- Dit Bonjour à Joe - -
- Header set mon-en-tête "Bonjour Joe. Il a fallu %D microsecondes \ - à Apache pour servir cette requête." -
- -
le résultat est l'ajout à la réponse d'un en-tête du type :
- -
```
	Header set MyHeader "Bonjour Joe. Il a fallu D=3775428 microsecondes à Apache
-          pour servir cette requête."
```
- -
- Ajoute l'en-tête mon-en-tête à la réponse si et - seulement si l'en-tête mon-en-tête-requête est - présent dans la requête. Ceci peut s'avérer utile pour générer - des en-têtes de réponse "à la tête du client". Notez que cet - exemple nécessite les services du module - mod_setenvif. - -
```
SetEnvIf MyRequestHeader myvalue HAVE_MyRequestHeader
-Header set MyHeader "%D %t mytext" env=HAVE_MyRequestHeader
```
- - -
Si l'en-tête mon-en-tête-requête: mavaleur est - présent dans la requête HTTP, la réponse contiendra un en-tête - du type :
- -
- mon-en-tête: D=3775428 t=991424704447256 montexte -
-
- Permet à DAV de fonctionner avec Apache sur SSL (voir la description - du problème) en remplaçant https: par - http: dans l'en-tête Destination : - -
```
RequestHeader edit Destination ^https: http: early
```
- -
- Définit la valeur d'un même en-tête sous de multiples conditions - non exclusives, mais ne duplique pas une valeur déjà définie - dans l'en-tête qui en résulte. Si toutes les conditions - suivantes sont satisfaites pour une requête (en d'autres termes, - si les trois variables d'environnement CGI, - NO_CACHE et NO_STORE existent pour la - requête) : - -
```
Header merge Cache-Control no-cache env=CGI
-Header merge Cache-Control no-cache env=NO_CACHE
-Header merge Cache-Control no-store env=NO_STORE
```
- - -
alors, la réponse contiendra l'en-tête suivant :
- -
- Cache-Control: no-cache, no-store -
- -
Si append avait été utilisé à la place de - merge, la réponse aurait contenu l'en-tête suivant - :
- -
- Cache-Control: no-cache, no-cache, no-store -
-
- Définit un cookie de test si et seulement si le client n'envoie - pas de cookie -
```
Header set Set-Cookie testcookie "expr=-z %{req:Cookie}"
```
- -
- Ajoute un en-tête de mise en cache pour les réponses avec un - code d'état HTTP de 200 -
```
Header append Cache-Control s-maxage=600 "expr=%{REQUEST_STATUS} == 200"
```
- -

Langues Disponibles: en |

Directives

Sujets

Directives

Sujets

Exemple

Exemple

Exemple

Exemple

지시어들

주제

지시어들

주제

예제

예제

예제

예제

Directives

Sujets

Sujets

Directives