archive-de.com » DE » K » KW-BERLIN.DE

Total: 256

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

Or switch to "Titles and links view".
  • Server and Supporting Programs - Apache HTTP Server
    ab Apache HTTP server benchmarking tool apxs APache eXtenSion tool configure Configure the source tree dbmmanage Create and update user authentication files in DBM format for basic authentication htcacheclean Clean up the disk cache htdigest Create and update user authentication files for digest authentication htdbm Manipulate DBM password databases htpasswd Create and update user authentication files for basic authentication httxt2dbm Create dbm files for use with RewriteMap logresolve Resolve hostnames

    Original URL path: http://xserve.kw-berlin.de/manual/programs/ (2016-02-16)
    Open archived version from archive


  • Binding - Apache HTTP Server
    respond to requests from any of the listed addresses and ports For example to make the server accept connections on both port 80 and port 8000 on all interfaces use Listen 80 Listen 8000 To make the server accept connections on port 80 for one interface and port 8000 on another use Listen 192 0 2 1 80 Listen 192 0 2 5 8000 IPv6 addresses must be enclosed in square brackets as in the following example Listen 2001 db8 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 to handle requests 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 On systems where it is disallowed by default a special configure parameter can change this behavior for Apache On the other hand on some platforms such as Linux and Tru64 the only way to handle both IPv6 and IPv4 is to use mapped addresses 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 enable v4 mapped is the default on all platforms except 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

    Original URL path: http://xserve.kw-berlin.de/manual/bind.html (2016-02-16)
    Open archived version from archive

  • Configuration Files - Apache HTTP Server
    used in configuration file lines using the syntax ENVVAR If ENVVAR is the name of a valid environment variable the value of that variable is substituted into that spot in the configuration file line and processing continues as if that text were found directly in the configuration file If the ENVVAR variable is not found the characters ENVVAR are left unchanged for use by later stages in the config file processing The maximum length of a line in the configuration file after environment variable substitution joining any continued lines and removing leading and trailing white space is 8192 characters 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

    Original URL path: http://xserve.kw-berlin.de/manual/configuring.html (2016-02-16)
    Open archived version from archive

  • Configuration Sections - Apache HTTP Server
    private html Order allow deny Deny from all Files To address files found in a particular part of the filesystem the Files 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

    Original URL path: http://xserve.kw-berlin.de/manual/sections.html (2016-02-16)
    Open archived version from archive

  • Caching Guide - Apache HTTP Server
    s maxage directive of the Cache Control header unless the CacheIgnoreNoLastMod directive has been used to require otherwise If the response includes the private option in a Cache Control header it will not be stored unless the CacheStorePrivate has been used to require otherwise Likewise if the response includes the no store option in a Cache Control header it will not be stored unless the CacheStoreNoStore has been used A response will not be stored if it includes a Vary header containing the match all What Should Not be Cached In short any content which is highly time sensitive or which varies depending on the particulars of the request that are not covered by HTTP negotiation should not be cached If you have dynamic content which changes depending on the IP address of the requester or changes every 5 minutes it should almost certainly not be cached If on the other hand the content served differs depending on the values of various HTTP headers it might be possible to cache it intelligently through the use of a Vary header Variable Negotiated Content If a response with a Vary header is received by mod cache when requesting content by the backend it will attempt to handle it intelligently If possible mod cache will detect the headers attributed in the Vary response in future requests and serve the correct cached response If for example a response is received with a vary header such as Vary negotiate accept language accept charset mod cache will only serve the cached content to requesters with accept language and accept charset headers matching those of the original request Security Considerations Authorization and Access Control Using mod cache is very much like having a built in reverse proxy Requests will be served by the caching module unless it determines that the backend should be queried When caching local resources this drastically changes the security model of Apache As traversing a filesystem hierarchy to examine potential htaccess files would be a very expensive operation partially defeating the point of caching to speed up requests mod cache makes no decision about whether a cached entity is authorised for serving In other words if mod cache has cached some content it will be served from the cache as long as that content has not expired If for example your configuration permits access to a resource by IP address you should ensure that this content is not cached You can do this by using the CacheDisable directive or mod expires Left unchecked mod cache very much like a reverse proxy would cache the content when served and then serve it to any client on any IP address Local exploits As requests to end users can be served from the cache the cache itself can become a target for those wishing to deface or interfere with content It is important to bear in mind that the cache must at all times be writable by the user which Apache is running as This is in stark contrast to the usually recommended situation of maintaining all content unwritable by the Apache user If the Apache user is compromised for example through a flaw in a CGI process it is possible that the cache may be targeted When using mod disk cache it is relatively easy to insert or modify a cached entity This presents a somewhat elevated risk in comparison to the other types of attack it is possible to make as the Apache user If you are using mod disk cache you should bear this in mind ensure you upgrade Apache when security upgrades are announced and run CGI processes as a non Apache user using suEXEC if possible Cache Poisoning When running Apache as a caching proxy server there is also the potential for so called cache poisoning Cache Poisoning is a broad term for attacks in which an attacker causes the proxy server to retrieve incorrect and usually undesirable content from the backend For example if the DNS servers used by your system running Apache are vulnerable to DNS cache poisoning an attacker may be able to control where Apache connects to when requesting content from the origin server Another example is so called HTTP request smuggling attacks This document is not the correct place for an in depth discussion of HTTP request smuggling instead try your favourite search engine however it is important to be aware that it is possible to make a series of requests and to exploit a vulnerability on an origin webserver such that the attacker can entirely control the content retrieved by the proxy File Handle Caching Related Modules Related Directives mod file cache mod mem cache CacheFile CacheEnable CacheDisable The act of opening a file can itself be a source of delay particularly on network filesystems By maintaining a cache of open file descriptors for commonly served files Apache can avoid this delay Currently Apache provides two different implementations of File Handle Caching CacheFile The most basic form of caching present in Apache is the file handle caching provided by mod file cache Rather than caching file contents this cache maintains a table of open file descriptors Files to be cached in this manner are specified in the configuration file using the CacheFile directive The CacheFile directive instructs Apache to open the file when Apache is started and to re use this file handle for all subsequent access to this file CacheFile usr local apache2 htdocs index html If you intend to cache a large number of files in this manner you must ensure that your operating system s limit for the number of open files is set appropriately Although using CacheFile does not cause the file contents to be cached per se it does mean that if the file changes while Apache is running these changes will not be picked up The file will be consistently served as it was when Apache was started If the file is removed while Apache is running Apache will

    Original URL path: http://xserve.kw-berlin.de/manual/caching.html (2016-02-16)
    Open archived version from archive

  • Content Negotiation - Apache HTTP Server
    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 is any other type Some browsers routinely send wildcards in addition to explicit types they can handle For example Accept text html text plain image gif image jpeg The intention

    Original URL path: http://xserve.kw-berlin.de/manual/content-negotiation.html (2016-02-16)
    Open archived version from archive

  • Dynamic Shared Object (DSO) Support - Apache HTTP Server
    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 for the DSO

    Original URL path: http://xserve.kw-berlin.de/manual/dso.html (2016-02-16)
    Open archived version from archive

  • Environment Variables in Apache - Apache HTTP Server
    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 variable 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 gzip If you have the DEFLATE filter activated this environment variable will ignore the accept encoding setting of your browser and will send compressed output unconditionally 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 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 only text html When set to a value of 1 this variable disables the DEFLATE output filter provided by mod deflate for content types other than text html If you d rather use statically compressed files mod negotiation evaluates the variable as well not only for gzip but for all encodings that differ from identity no gzip When set the DEFLATE filter of mod deflate will be turned off and mod negotiation will refuse to deliver encoded resources no cache Available in versions 2 2 12 and later When set

    Original URL path: http://xserve.kw-berlin.de/manual/env.html (2016-02-16)
    Open archived version from archive



  •