archive-fr.com » FR » O » OBSPM.FR

Total: 155

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • Apache's Handler Use - Apache HTTP Server
    on location handlers can be specified without relation to file type This is advantageous both because it is a more elegant solution and because it also allows for both a type and a handler to be associated with a file See also Files with Multiple Extensions Handlers can either be built into the server or included in a module or they can be added with the Action directive The built in handlers in the standard distribution are as follows default handler Send the file using the default handler which is the handler used by default to handle static content core send as is Send file with HTTP headers as is mod asis cgi script Treat the file as a CGI script mod cgi imap file Parse as an imagemap rule file mod imap server info Get the server s configuration information mod info server status Get the server s status report mod status type map Parse as a type map file for content negotiation mod negotiation Examples Modifying static content using a CGI script The following directives will cause requests for files with the html extension to trigger the launch of the footer pl CGI script Action add footer cgi bin footer pl AddHandler add footer html Then the CGI script is responsible for sending the originally requested document pointed to by the PATH TRANSLATED environment variable and making whatever modifications or additions are desired Files with HTTP headers The following directives will enable the send as is handler which is used for files which contain their own HTTP headers All files in the web htdocs asis directory will be processed by the send as is handler regardless of their filename extensions Directory web htdocs asis SetHandler send as is Directory Programmer s Note In order to implement the handler

    Original URL path: http://ama09.obspm.fr/manual-2.0/handler.html (2015-11-16)
    Open archived version from archive


  • Server and Supporting Programs - Apache HTTP Server
    HTTP Server Index httpd Apache hypertext transfer protocol server apachectl Apache HTTP server control interface ab Apache HTTP server benchmarking tool apxs APache eXtenSion tool dbmmanage Create and update user authentication files in DBM format for basic authentication htdigest Create and update user authentication files for digest authentication htpasswd Create and update user authentication files for basic authentication logresolve Resolve hostnames for IP addresses in Apache logfiles rotatelogs Rotate Apache

    Original URL path: http://ama09.obspm.fr/manual-2.0/programs/ (2015-11-16)
    Open archived version from archive

  • Binding - Apache HTTP Server
    and ports For example to make the server accept connections on both port 80 and port 8000 use Listen 80 Listen 8000 To make the server accept connections on two specified interfaces and port numbers use Listen 192 170 2 1 80 Listen 192 170 2 5 8000 IPv6 addresses must be surrounded in square brackets as in the following example Listen fe80 a00 20ff fea7 ccea 80 Special IPv6 Considerations A growing number of platforms implement IPv6 and APR supports IPv6 on most of these platforms allowing Apache to allocate IPv6 sockets and handle requests which were sent over IPv6 One complicating factor for Apache administrators is whether or not an IPv6 socket can handle both IPv4 connections and IPv6 connections Handling IPv4 connections with an IPv6 socket uses IPv4 mapped IPv6 addresses which are allowed by default on most platforms but are disallowed by default on FreeBSD NetBSD and OpenBSD in order to match the system wide policy on those platforms But even on systems where it is disallowed by default a special configure parameter can change this behavior for Apache If you want Apache to handle IPv4 and IPv6 connections with a minimum of sockets which requires using IPv4 mapped IPv6 addresses specify the enable v4 mapped configure option and use generic Listen directives like the following Listen 80 With enable v4 mapped the Listen directives in the default configuration file created by Apache will use this form enable v4 mapped is the default on all platforms but FreeBSD NetBSD and OpenBSD so this is probably how your Apache was built If you want Apache to handle IPv4 connections only regardless of what your platform and APR will support specify an IPv4 address on all Listen directives as in the following examples Listen 0 0 0 0

    Original URL path: http://ama09.obspm.fr/manual-2.0/bind.html (2015-11-16)
    Open archived version from archive

  • Configuration Files - Apache HTTP Server
    arguments to directives are often case sensitive Lines that begin with the hash character are considered comments and are ignored Comments may not be included on a line after a configuration directive Blank lines and white space occurring before a directive are ignored so you may indent directives for clarity You can check your configuration files for syntax errors without starting the server by using apachectl configtest or the t command line option Modules Related Modules Related Directives mod so IfModule LoadModule Apache is a modular server This implies that only the most basic functionality is included in the core server Extended features are available through modules which can be loaded into Apache By default a base set of modules is included in the server at compile time If the server is compiled to use dynamically loaded modules then modules can be compiled separately and added at any time using the LoadModule directive Otherwise Apache must be recompiled to add or remove modules Configuration directives may be included conditional on a presence of a particular module by enclosing them in an IfModule block To see which modules are currently compiled into the server you can use the l command line option Scope of Directives Related Modules Related Directives Directory DirectoryMatch Files FilesMatch Location LocationMatch VirtualHost Directives placed in the main configuration files apply to the entire server If you wish to change the configuration for only a part of the server you can scope your directives by placing them in Directory DirectoryMatch Files FilesMatch Location and LocationMatch sections These sections limit the application of the directives which they enclose to particular filesystem locations or URLs They can also be nested allowing for very fine grained configuration Apache has the capability to serve many different websites simultaneously This is called Virtual

    Original URL path: http://ama09.obspm.fr/manual-2.0/configuring.html (2015-11-16)
    Open archived version from archive

  • Configuration Sections - Apache HTTP Server
    and Directory sections can be combined For example the following configuration will deny access to var web dir1 private html var web dir1 subdir2 private html var web dir1 subdir3 private html and any other instance of private html found under the var web dir1 directory Directory var web dir1 Files private html Order allow deny Deny from all Files Directory Webspace Containers The Location directive and its regex counterpart on the other hand change the configuration for content in the webspace For example the following configuration prevents access to any URL path that begins in private In particular it will apply to requests for http yoursite example com private http yoursite example com private123 and http yoursite example com private dir file html as well as any other requests starting with the private string Location private Order Allow Deny Deny from all Location The Location directive need not have anything to do with the filesystem For example the following example shows how to map a particular URL to an internal Apache handler provided by mod status No file called server status needs to exist in the filesystem Location server status SetHandler server status Location Wildcards and Regular Expressions The Directory Files and Location directives can each use shell style wildcard characters as in fnmatch from the C standard library The character matches any sequence of characters matches any single character and seq matches any character in seq The character will not be matched by any wildcard it must be specified explicitly If even more flexible matching is required each container has a regular expression regex counterpart DirectoryMatch FilesMatch and LocationMatch that allow perl compatible regular expressions to be used in choosing the matches But see the section below on configuration merging to find out how using regex sections will change how directives are applied A non regex wildcard section that changes the configuration of all user directories could look as follows Directory home public html Options Indexes Directory Using regex sections we can deny access to many types of image files at once FilesMatch i gif jpe g png Order allow deny Deny from all FilesMatch What to use When Choosing between filesystem containers and webspace containers is actually quite easy When applying directives to objects that reside in the filesystem always use Directory or Files When applying directives to objects that do not reside in the filesystem such as a webpage generated from a database use Location It is important to never use Location when trying to restrict access to objects in the filesystem This is because many different webspace locations URLs could map to the same filesystem location allowing your restrictions to be circumvented For example consider the following configuration Location dir Order allow deny Deny from all Location This works fine if the request is for http yoursite example com dir But what if you are on a case insensitive filesystem Then your restriction could be easily circumvented by requesting http yoursite example com DIR The

    Original URL path: http://ama09.obspm.fr/manual-2.0/sections.html (2015-11-16)
    Open archived version from archive

  • Content Negotiation - Apache HTTP Server
    are present and index cgi is there the server will run it If one of the files found when reading the directory does not have an extension recognized by mod mime to designate its Charset Content Type Language or Encoding then the result depends on the setting of the MultiViewsMatch directive This directive determines whether handlers filters and other extension types can participate in MultiViews negotiation The Negotiation Methods After Apache has obtained a list of the variants for a given resource either from a type map file or from the filenames in the directory it invokes one of two methods to decide on the best variant to return if any It is not necessary to know any of the details of how negotiation actually takes place in order to use Apache s content negotiation features However the rest of this document explains the methods used for those interested There are two negotiation methods Server driven negotiation with the Apache algorithm is used in the normal case The Apache algorithm is explained in more detail below When this algorithm is used Apache can sometimes fiddle the quality factor of a particular dimension to achieve a better result The ways Apache can fiddle quality factors is explained in more detail below Transparent content negotiation is used when the browser specifically requests this through the mechanism defined in RFC 2295 This negotiation method gives the browser full control over deciding on the best variant the result is therefore dependent on the specific algorithms used by the browser As part of the transparent negotiation process the browser can ask Apache to run the remote variant selection algorithm defined in RFC 2296 Dimensions of Negotiation Dimension Notes Media Type Browser indicates preferences with the Accept header field Each item can have an associated quality factor Variant description can also have a quality factor the qs parameter Language Browser indicates preferences with the Accept Language header field Each item can have a quality factor Variants can be associated with none one or more than one language Encoding Browser indicates preference with the Accept Encoding header field Each item can have a quality factor Charset Browser indicates preference with the Accept Charset header field Each item can have a quality factor Variants can indicate a charset as a parameter of the media type Apache Negotiation Algorithm Apache can use the following algorithm to select the best variant if any to return to the browser This algorithm is not further configurable It operates as follows First for each dimension of the negotiation check the appropriate Accept header field and assign a quality to each variant If the Accept header for any dimension implies that this variant is not acceptable eliminate it If no variants remain go to step 4 Select the best variant by a process of elimination Each of the following tests is applied in order Any variants not selected at each test are eliminated After each test if only one variant remains select it as the best match and proceed to step 3 If more than one variant remains move on to the next test Multiply the quality factor from the Accept header with the quality of source factor for this variants media type and select the variants with the highest value Select the variants with the highest language quality factor Select the variants with the best language match using either the order of languages in the Accept Language header if present or else the order of languages in the LanguagePriority directive if present Select the variants with the highest level media parameter used to give the version of text html media types Select variants with the best charset media parameters as given on the Accept Charset header line Charset ISO 8859 1 is acceptable unless explicitly excluded Variants with a text media type but not explicitly associated with a particular charset are assumed to be in ISO 8859 1 Select those variants which have associated charset media parameters that are not ISO 8859 1 If there are no such variants select all variants instead Select the variants with the best encoding If there are variants with an encoding that is acceptable to the user agent select only these variants Otherwise if there is a mix of encoded and non encoded variants select only the unencoded variants If either all variants are encoded or all variants are not encoded select all variants Select the variants with the smallest content length Select the first variant of those remaining This will be either the first listed in the type map file or when variants are read from the directory the one whose file name comes first when sorted using ASCII code order The algorithm has now selected one best variant so return it as the response The HTTP response header Vary is set to indicate the dimensions of negotiation browsers and caches can use this information when caching the resource End To get here means no variant was selected because none are acceptable to the browser Return a 406 status meaning No acceptable representation with a response body consisting of an HTML document listing the available variants Also set the HTTP Vary header to indicate the dimensions of variance Fiddling with Quality Values Apache sometimes changes the quality values from what would be expected by a strict interpretation of the Apache negotiation algorithm above This is to get a better result from the algorithm for browsers which do not send full or accurate information Some of the most popular browsers send Accept header information which would otherwise result in the selection of the wrong variant in many cases If a browser sends full and correct information these fiddles will not be applied Media Types and Wildcards The Accept request header indicates preferences for media types It can also include wildcard media types such as image or where the matches any string So a request including Accept image would indicate that any type starting image is acceptable as

    Original URL path: http://ama09.obspm.fr/manual-2.0/content-negotiation.html (2015-11-16)
    Open archived version from archive

  • Dynamic Shared Object (DSO) Support - Apache HTTP Server
    DSO s are usually called shared libraries or DSO libraries and named libfoo so or libfoo so 1 2 They reside in a system directory usually usr lib and the link to the executable program is established at build time by specifying lfoo to the linker command This hard codes library references into the executable program file so that at start time the Unix loader is able to locate libfoo so in usr lib in paths hard coded via linker options like R or in paths configured via the environment variable LD LIBRARY PATH It then resolves any yet unresolved symbols in the executable program which are available in the DSO Symbols in the executable program are usually not referenced by the DSO because it s a reusable library of general code and hence no further resolving has to be done The executable program has no need to do anything on its own to use the symbols from the DSO because the complete resolving is done by the Unix loader In fact the code to invoke ld so is part of the run time startup code which is linked into every executable program which has been bound non static The advantage of dynamic loading of common library code is obvious the library code needs to be stored only once in a system library like libc so saving disk space for every program In the second way the DSO s are usually called shared objects or DSO files and can be named with an arbitrary extension although the canonical name is foo so These files usually stay inside a program specific directory and there is no automatically established link to the executable program where they are used Instead the executable program manually loads the DSO at run time into its address space via dlopen At this time no resolving of symbols from the DSO for the executable program is done But instead the Unix loader automatically resolves any yet unresolved symbols in the DSO from the set of symbols exported by the executable program and its already loaded DSO libraries especially all symbols from the ubiquitous libc so This way the DSO gets knowledge of the executable program s symbol set as if it had been statically linked with it in the first place Finally to take advantage of the DSO s API the executable program has to resolve particular symbols from the DSO via dlsym for later use inside dispatch tables etc In other words The executable program has to manually resolve every symbol it needs to be able to use it The advantage of such a mechanism is that optional program parts need not be loaded and thus do not spend memory until they are needed by the program in question When required these program parts can be loaded dynamically to extend the base program s functionality Although this DSO mechanism sounds straightforward there is at least one difficult step here The resolving of symbols from the executable program

    Original URL path: http://ama09.obspm.fr/manual-2.0/dso.html (2015-11-16)
    Open archived version from archive

  • Environment Variables in Apache - Apache HTTP Server
    also provides SSI pages with the standard CGI environment variables as discussed above For more details see the SSI tutorial Access Control Access to the server can be controlled based on the value of environment variables using the allow from env and deny from env directives In combination with SetEnvIf this allows for flexible control of access to the server based on characteristics of the client For example you can use these directives to deny access to a particular browser User Agent Conditional Logging Environment variables can be logged in the access log using the LogFormat option e In addition the decision on whether or not to log requests can be made based on the status of environment variables using the conditional form of the CustomLog directive In combination with SetEnvIf this allows for flexible control of which requests are logged For example you can choose not to log requests for filenames ending in gif or you can choose to only log requests from clients which are outside your subnet Conditional Response Headers The Header directive can use the presence or absence of an environment variable to determine whether or not a certain HTTP header will be placed in the response to the client This allows for example a certain response header to be sent only if a corresponding header is received in the request from the client External Filter Activation External filters configured by mod ext filter using the ExtFilterDefine directive can by activated conditional on an environment variable using the disableenv and enableenv options URL Rewriting The ENV form of TestString in the RewriteCond allows mod rewrite s rewrite engine to make decisions conditional on environment variables Note that the variables accessible in mod rewrite without the ENV prefix are not actually environment variables Rather they are variables special to mod rewrite which cannot be accessed from other modules Special Purpose Environment Variables Interoperability problems have led to the introduction of mechanisms to modify the way Apache behaves when talking to particular clients To make these mechanisms as flexible as possible they are invoked by defining environment variables typically with BrowserMatch though SetEnv and PassEnv could also be used for example downgrade 1 0 This forces the request to be treated as a HTTP 1 0 request even if it was in a later dialect force no vary This causes any Vary fields to be removed from the response header before it is sent back to the client Some clients don t interpret this field correctly see the known client problems page setting this variable can work around this problem Setting this variable also implies force response 1 0 force response 1 0 This forces an HTTP 1 0 response to clients making an HTTP 1 0 request It was originally implemented as a result of a problem with AOL s proxies Some HTTP 1 0 clients may not behave correctly when given an HTTP 1 1 response and this can be used to interoperate with them gzip

    Original URL path: http://ama09.obspm.fr/manual-2.0/env.html (2015-11-16)
    Open archived version from archive



  •