453 lines
27 KiB
HTML
453 lines
27 KiB
HTML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE html
|
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
<html lang="en-us" xml:lang="en-us">
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
|
<meta name="security" content="public" />
|
|
<meta name="Robots" content="index,follow" />
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
|
<meta name="DC.Type" content="topic" />
|
|
<meta name="DC.Title" content="Content negotiation for HTTP Server (powered by Apache)" />
|
|
<meta name="abstract" content="This topic provides information on content negotiation, type-map files, MultiViews, negotiation methods, dimensions of negotiation, negotiation algorithm, media types, and wildcards." />
|
|
<meta name="description" content="This topic provides information on content negotiation, type-map files, MultiViews, negotiation methods, dimensions of negotiation, negotiation algorithm, media types, and wildcards." />
|
|
<meta name="DC.Relation" scheme="URI" content="rzaieconcepts.htm" />
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 2002,2006" />
|
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2002,2006" />
|
|
<meta name="DC.Format" content="XHTML" />
|
|
<meta name="DC.Identifier" content="rzaiecontent-negotiation" />
|
|
<meta name="DC.Language" content="en-us" />
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
|
<!-- US Government Users Restricted Rights -->
|
|
<!-- Use, duplication or disclosure restricted by -->
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
|
<title>Content negotiation for HTTP Server (powered by Apache)</title>
|
|
</head>
|
|
<body id="rzaiecontent-negotiation"><a name="rzaiecontent-negotiation"><!-- --></a>
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
|
<h1 class="topictitle1">Content negotiation for HTTP Server (powered by Apache)</h1>
|
|
<div><p>This topic provides information on content negotiation, type-map
|
|
files, MultiViews, negotiation methods, dimensions of negotiation, negotiation
|
|
algorithm, media types, and wildcards.</p>
|
|
<div class="important"><span class="importanttitle">Important:</span> Information
|
|
for this topic supports the latest PTF levels for HTTP Server for i5/OS .
|
|
It is recommended that you install the latest PTFs to upgrade to the latest
|
|
level of the HTTP Server for i5/OS. Some of the topics documented here are
|
|
not available prior to this update. See <a href="http://www-03.ibm.com/servers/eserver/iseries/software/http/services/service.html" target="_blank">http://www.ibm.com/servers/eserver/iseries/software/http/services/service.htm</a> <img src="www.gif" alt="Link outside Information Center" /> for more information. </div>
|
|
<p>A resource may be available in several different representations. For example,
|
|
it might be available in different languages or different media types, or
|
|
a combination. One way of selecting the most appropriate choice is to give
|
|
the user an index page, and let them select; however it is often possible
|
|
for the server to choose automatically. This works because browsers can send
|
|
as part of each request information about what representations it prefers.
|
|
For example, a browser could indicate that it would like to see information
|
|
in French, if possible, else English will do. Browsers indicate their preferences
|
|
by headers in the request. To request only French representations, the browser
|
|
would send:</p>
|
|
<pre class="block">Accept-Language: fr</pre>
|
|
<p>Note that this preference will only be applied when there is a choice of
|
|
representations and they vary by language.</p>
|
|
<p>As an example of a more complex request, this browser has been configured
|
|
to accept French and English, but prefers French, and to accept various media
|
|
types, preferring HTML over plain text or other text types, and preferring
|
|
GIF or JPEG over other media types, but also allowing any other media type
|
|
as a last resort: </p>
|
|
<pre class="block">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</pre>
|
|
<p>The HTTP Server (powered by Apache) supports 'server driven' content negotiation,
|
|
as defined in the HTTP/1.1 specification. It fully supports the Accept, Accept-Language,
|
|
Accept-Charset and Accept-Encoding request headers. The HTTP Server (powered
|
|
by Apache) also supports 'transparent' content negotiation, which is an experimental
|
|
negotiation protocol defined in RFC 2295 and RFC 2296. It does not offer support
|
|
for 'feature negotiation' as defined in these RFCs. </p>
|
|
<p>A <strong>resource</strong> is a conceptual entity identified by a URI (RFC 2396).
|
|
The HTTP Server (powered by Apache) provides access to <strong>representations</strong> of
|
|
the resource(s) within its namespace, with each representation in the form
|
|
of a sequence of bytes with a defined media type, character set, encoding,
|
|
or other. Each resource may be associated with zero, one, or more than one
|
|
representation at any given time. If multiple representations are available,
|
|
the resource is referred to as <strong>negotiable</strong> and each of its representations
|
|
is termed a <strong>variant</strong>. The ways in which the variants for a negotiable
|
|
resource vary are called the dimensions of negotiation. </p>
|
|
</div>
|
|
<div>
|
|
<div class="familylinks">
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzaieconcepts.htm" title="This topic provides concepts of functions on HTTP Server and IBM Web Administration for i5/OS interface.">Concepts of functions of HTTP Server</a></div>
|
|
</div>
|
|
</div><div class="nested1" id="negotiation"><a name="negotiation"><!-- --></a><h2 class="topictitle2">Content negotiation</h2>
|
|
<div><p>In order to negotiate a resource, the server needs to be given information
|
|
about each of the variants. This is done in one of two ways:</p>
|
|
<ul><li>Using a type -map (for example, a *.var file) which names the files containing
|
|
the variants explicitly.</li>
|
|
<li>Using a 'MultiViews' search, where the server does an implicit filename
|
|
pattern match and chooses from among the results. </li>
|
|
</ul>
|
|
</div>
|
|
</div>
|
|
<div class="nested1" id="typemap"><a name="typemap"><!-- --></a><h2 class="topictitle2">Using a type-map file </h2>
|
|
<div><p>A type map is a document which is associated with the handler named type-map
|
|
(or, for backwards-compatibility with older HTTP Server (powered by Apache)
|
|
configurations, the mime type application/x-type-map). Note that to use this
|
|
feature, you must have a handler set in the configuration that defines a file
|
|
suffix as type-map; this is best done with an AddHandler in the server configuration
|
|
file, as shown below. </p>
|
|
<pre class="block">AddHandler type-map var</pre>
|
|
<p>Type map files have an entry for each available variant; these entries
|
|
consist of contiguous HTTP-format header lines. Entries for different variants
|
|
are separated by blank lines. Blank lines are illegal within an entry. It
|
|
is conventional to begin a map file with an entry for the combined entity
|
|
as a whole (although this is not required, and if present will be ignored).
|
|
An example map file is:</p>
|
|
<pre class="block">URI: jkl
|
|
|
|
URI: jkl.en.html
|
|
Content-type: text/html
|
|
Content-language: en
|
|
|
|
URI: jkl.fr.de.html
|
|
Content-type: text/html;charset=iso-8859-2
|
|
Content-language: fr, de</pre>
|
|
<p>If the variants have different source qualities, that may be indicated
|
|
by the "qs" parameter to the media type, as in this picture (available as
|
|
jpeg, gif, or ASCII-art): </p>
|
|
<pre class="block">URI: jkl
|
|
|
|
URI: jkl.jpeg
|
|
Content-type: image/jpeg; Qs=0.8
|
|
|
|
URI: jkl.gif
|
|
Content-type: image/gif; Qs=0.5
|
|
|
|
URI: jkl.txt
|
|
Content-type: text/plain; Qs=0.01</pre>
|
|
<p>The "Qs" value can vary in the range 0.000 to 1.000. Note that any variant
|
|
with a "Qs" value of 0.000 will never be chosen. Variants with no "Qs" parameter
|
|
value are given a "Qs" factor of 1.0. The "Qs" parameter indicates the relative
|
|
'quality' of this variant compared to the other available variants, independent
|
|
of the client's capabilities. For example, a jpeg file is usually of higher
|
|
source quality than an ASCII file if its attempting to represent a photograph;
|
|
however, if the resource being represented is an original ASCII art, then
|
|
an ASCII representation would have a higher source quality than a jpeg representation.
|
|
A "Qs" value is therefore specific to a given variant depending on the nature
|
|
of the resource it represents. </p>
|
|
<p>The full list of headers recognized are: </p>
|
|
<dl class="block"><dt class="dlterm">URI</dt>
|
|
<dd>The uri of the file containing the variant (of the given media type, encoded
|
|
with the given content encoding). These are interpreted as URLs relative to
|
|
the map file; they must be on the same server, and they must refer to files
|
|
to which the client would be granted access if they were to be requested directly.</dd>
|
|
<dt class="dlterm">Content-Type</dt>
|
|
<dd>The media type --- charset, level and "Qs" parameters may be given. These
|
|
are often referred to as MIME types; typical media types are image/gif, text/plain,
|
|
or text/html; level=3. </dd>
|
|
<dt class="dlterm">Content-Language</dt>
|
|
<dd>The languages of the variant, specified as an Internet standard language
|
|
tag from RFC 1766 (for example, en for English, or kr for Korean). </dd>
|
|
<dt class="dlterm">Content-Encoding</dt>
|
|
<dd>If the file is compressed, or otherwise encoded, rather than containing
|
|
the actual raw data, this states how it was done. The HTTP Server (powered
|
|
by Apache) only recognizes encodings that are defined by an <a href="rzaiemod_mime.htm#addencoding">AddEncoding</a> directive.
|
|
This normally includes the encodings x-compress for compressed files, and
|
|
x-gzip for gzip'd files. The x- prefix is ignored for encoding comparisons. </dd>
|
|
<dt class="dlterm">Content-Length</dt>
|
|
<dd>The size of the file. Specifying content lengths in the type-map allows
|
|
the server to compare file sizes without checking the actual files. </dd>
|
|
<dt class="dlterm"></dt>
|
|
<dd></dd>
|
|
<dt class="dlterm">Description</dt>
|
|
<dd>A human-readable textual description of the variant. If the HTTP Server
|
|
(powered by Apache) cannot find any appropriate variant to return, it will
|
|
return an error response which lists all available variants instead. Such
|
|
a variant list will include the human-readable variant descriptions. </dd>
|
|
</dl>
|
|
</div>
|
|
</div>
|
|
<div class="nested1" id="multiviews"><a name="multiviews"><!-- --></a><h2 class="topictitle2">MultiViews</h2>
|
|
<div><p>MultiViews is a per-directory option, meaning it can be set with an Options
|
|
directive within a <Directory>, <Location> or <Files> container in
|
|
the configuration file, or (if AllowOverride is properly set) in .htaccess
|
|
files. Note that Options All does not set MultiViews; you have to ask for
|
|
it by name. </p>
|
|
<p>The effect of MultiViews is as follows: if the server receives a request
|
|
for /some/dir/jkl, if /some/dir has MultiViews enabled, and /some/dir/jkl
|
|
does not exist, then the server reads the directory looking for files named
|
|
jkl.*, and effectively fakes up a type map which names all those files, assigning
|
|
them the same media types and content-encodings it would have if the client
|
|
had asked for one of them by name. It then chooses the best match to the client's
|
|
requirements. </p>
|
|
<p>MultiViews may also apply to searches for the file named by the DirectoryIndex
|
|
directive, if the server is trying to index a directory. If the configuration
|
|
files specify:</p>
|
|
<pre class="block">DirectoryIndex index</pre>
|
|
<p>The server will arbitrate between index.html and index.html3 if both are
|
|
present. </p>
|
|
<p>If one of the files found when reading the directive is a CGI script, it
|
|
is not obvious what should happen. The code gives that case special treatment
|
|
--- if the request was a POST, or a GET with QUERY_ARGS or PATH_INFO, the
|
|
script is given an extremely high quality rating, and generally invoked; otherwise
|
|
it is given an extremely low quality rating, which generally causes one of
|
|
the other views (if any) to be retrieved.</p>
|
|
</div>
|
|
</div>
|
|
<div class="nested1" id="negotiatemethods"><a name="negotiatemethods"><!-- --></a><h2 class="topictitle2">The negotiation methods </h2>
|
|
<div><p>After the HTTP Server (powered by 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 the HTTP Server (powered by Apache) content
|
|
negotiation features. However the rest of this document explains the methods
|
|
used for those interested. </p>
|
|
<p>There are two negotiation methods: </p>
|
|
<ol><li><strong>Server driven negotiation with the HTTP Server (powered by Apache)
|
|
algorithm</strong> is used in the normal case. The HTTP Server (powered by Apache)
|
|
algorithm is explained in more detail below. When this algorithm is used,
|
|
the HTTP Server (powered by Apache) can sometimes 'fiddle' the quality factor
|
|
of a particular dimension to achieve a better result. The ways the HTTP Server
|
|
(powered by Apache) can fiddle quality factors is explained in more detail
|
|
below. </li>
|
|
<li><strong>Transparent content negotiation</strong> 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 the HTTP
|
|
Server (powered by Apache) to run the 'remote variant selection algorithm'
|
|
defined in RFC 2296.</li>
|
|
</ol>
|
|
</div>
|
|
</div>
|
|
<div class="nested1" id="dimensions"><a name="dimensions"><!-- --></a><h2 class="topictitle2">Dimensions of negotiation </h2>
|
|
<div><dl class="block"><dt class="dlterm">Media Type </dt>
|
|
<dd>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). </dd>
|
|
<dt class="dlterm">Language </dt>
|
|
<dd>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. </dd>
|
|
<dt class="dlterm">Encoding </dt>
|
|
<dd>Browser indicates preference with the Accept-Encoding header field. Each
|
|
item can have a quality factor. </dd>
|
|
<dt class="dlterm">Charset </dt>
|
|
<dd>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. </dd>
|
|
<dt class="dlterm">Client (Browser)</dt>
|
|
<dd>The User-Agent HTTP header is used to determine browser type.</dd>
|
|
</dl>
|
|
</div>
|
|
</div>
|
|
<div class="nested1" id="algorithm"><a name="algorithm"><!-- --></a><h2 class="topictitle2">The negotiation algorithm </h2>
|
|
<div><p>The HTTP Server (powered by 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: </p>
|
|
<ol><li>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. </li>
|
|
<li>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. <ol type="a"><li>Multiply the quality factor from the Accept header with the quality-of-source
|
|
factor for this variant's media type, and select the variants with the highest
|
|
value. </li>
|
|
<li>Select the variants with the highest language quality factor. </li>
|
|
<li>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). </li>
|
|
<li>Select the variants with the highest 'level' media parameter (used to
|
|
give the version of text/html media types). </li>
|
|
<li>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. </li>
|
|
<li>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.
|
|
</li>
|
|
<li>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 non-encoded variants. If either all variants are encoded or all variants
|
|
are not encoded, select all variants. </li>
|
|
<li>Select the variants that correspond to the User-Agent header received
|
|
on the HTTP Request. </li>
|
|
<li>Select the variants with the smallest content length. </li>
|
|
<li>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. </li>
|
|
</ol>
|
|
</li>
|
|
<li>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). </li>
|
|
<li>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. </li>
|
|
</ol>
|
|
</div>
|
|
</div>
|
|
<div class="nested1" id="editingvalues"><a name="editingvalues"><!-- --></a><h2 class="topictitle2">Editing quality values </h2>
|
|
<div><p>The HTTP Server (powered by Apache) sometimes changes the quality values
|
|
from what would be expected by a strict interpretation of the HTTP Server
|
|
(powered by 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.
|
|
</p>
|
|
</div>
|
|
</div>
|
|
<div class="nested1" id="mediawildcards"><a name="mediawildcards"><!-- --></a><h2 class="topictitle2">Media types and wildcards </h2>
|
|
<div><p>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 <tt>Accept: image/*, */*</tt>
|
|
would indicate that any type starting "image/" is acceptable, as is any other
|
|
type (so the first "image/*" is redundant). Some browsers routinely send wildcards
|
|
in addition to explicit types they can handle. For example, <tt>Accept: text/html,
|
|
text/plain, image/gif, image/jpeg, */*</tt>.</p>
|
|
<p>The intention of this is to indicate that the explicitly listed types are
|
|
preferred, but if a different representation is available, that is OK too.
|
|
However under the basic algorithm, as given above, the */* wildcard has exactly
|
|
equal preference to all the other types, so they are not being preferred.
|
|
The browser should really have sent a request with a lower quality (preference)
|
|
value for *.*, such as: <tt>Accept: text/html, text/plain, image/gif, image/jpeg,
|
|
*/*; q=0.01</tt>. </p>
|
|
<p>The explicit types have no quality factor, so they default to a preference
|
|
of 1.0 (the highest). The wildcard */* is given a low preference of 0.01,
|
|
so other types will only be returned if no variant matches an explicitly listed
|
|
type. </p>
|
|
<p>If the Accept: header contains <em>no</em> "q" factors at all, the HTTP Server
|
|
(powered by Apache) sets the "q" value of "*/*", if present, to 0.01 to emulate
|
|
the desired behavior. It also sets the "q" value of wildcards of the format
|
|
"type/*" to 0.02 (so these are preferred over matches against "*/*"). If any
|
|
media type on the Accept: header contains a "q" factor, these special values
|
|
are <em>not</em> applied, so requests from browsers which send the correct information
|
|
to start with work as expected. </p>
|
|
</div>
|
|
</div>
|
|
<div class="nested1" id="variants"><a name="variants"><!-- --></a><h2 class="topictitle2">Variants with no language </h2>
|
|
<div><p>If some of the variants for a particular resource have a language attribute,
|
|
and some do not, those variants with no language are given a very low language
|
|
quality factor of 0.001. </p>
|
|
<p>The reason for setting this language quality factor for variant with no
|
|
language to a very low value is to allow for a default variant which can be
|
|
supplied if none of the other variants match the browser's language preferences.
|
|
For example, consider the situation with three variants: </p>
|
|
<ul><li>jkl.en.html, language en </li>
|
|
<li>jkl.fr.html, language fr </li>
|
|
<li>jkl.html, no language </li>
|
|
</ul>
|
|
<p>The meaning of a variant with no language is that it is always acceptable
|
|
to the browser. If the request Accept-Language header includes either en or
|
|
fr (or both) one of jkl.en.html or jkl.fr.html will be returned. If the browser
|
|
does not list either en or fr as acceptable, jkl.html will be returned instead.
|
|
</p>
|
|
</div>
|
|
</div>
|
|
<div class="nested1" id="tcnegotiation"><a name="tcnegotiation"><!-- --></a><h2 class="topictitle2">Extensions to transparent content negotiation </h2>
|
|
<div><p>The HTTP Server (powered by Apache) extends the transparent content negotiation
|
|
protocol (RFC 2295) as follows. A new {encoding ..} element is used in variant
|
|
lists to label variants which are available with a specific content-encoding
|
|
only. The implementation of the RVSA/1.0 algorithm (RFC 2296) is extended
|
|
to recognize encoded variants in the list, and to use them as candidate variants
|
|
whenever their encodings are acceptable according to the Accept-Encoding request
|
|
header. The RVSA/1.0 implementation does not round computed quality factors
|
|
to 5 decimal places before choosing the best variant.</p>
|
|
</div>
|
|
</div>
|
|
<div class="nested1" id="hyperlinksnameconvent"><a name="hyperlinksnameconvent"><!-- --></a><h2 class="topictitle2">Notes on hyperlinks and naming conventions </h2>
|
|
<div><p>If you are using language negotiation you can choose between different
|
|
naming conventions, because files can have more than one extension, and the
|
|
order of the extensions is normally irrelevant (see <a href="rzaiemod_mime.htm">mod_mime</a> for details). </p>
|
|
<p>A typical file has a MIME-type extension (for example, html), maybe an
|
|
encoding extension (for example, gz), and of course a language extension (for
|
|
example, en) when we have different language variants of this file. </p>
|
|
<p>Examples: </p>
|
|
<ul><li>jkl.en.html </li>
|
|
<li>jkl.html.en </li>
|
|
<li>jkl.en.html.gz </li>
|
|
</ul>
|
|
<p>Examples of filenames together with valid and invalid hyperlinks: </p>
|
|
|
|
<div class="tablenoborder"><table cellpadding="4" cellspacing="0" summary="" frame="border" border="1" rules="all"><thead align="left"><tr><th align="left" valign="top" id="d0e315">Filename</th>
|
|
<th align="left" valign="top" id="d0e317">Valid hyperlink</th>
|
|
<th align="left" valign="top" id="d0e319">Invalid hyperlink</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody><tr><td align="left" valign="top" headers="d0e315 ">jkl.html.en</td>
|
|
<td align="left" valign="top" headers="d0e317 "><p>jkl</p>
|
|
<p>jkl.html</p>
|
|
</td>
|
|
<td align="left" valign="top" headers="d0e319 ">-</td>
|
|
</tr>
|
|
<tr><td align="left" valign="top" headers="d0e315 ">jkl.en.html</td>
|
|
<td align="left" valign="top" headers="d0e317 ">jkl</td>
|
|
<td align="left" valign="top" headers="d0e319 ">jkl.html</td>
|
|
</tr>
|
|
<tr><td align="left" valign="top" headers="d0e315 ">jkl.html.en.gz</td>
|
|
<td align="left" valign="top" headers="d0e317 "><p>jkl</p>
|
|
<p>jkl.html</p>
|
|
</td>
|
|
<td align="left" valign="top" headers="d0e319 "><p>jkl.gz</p>
|
|
<p>jkl.html.gz</p>
|
|
</td>
|
|
</tr>
|
|
<tr><td align="left" valign="top" headers="d0e315 ">jkl.en.html.gz</td>
|
|
<td align="left" valign="top" headers="d0e317 ">jkl</td>
|
|
<td align="left" valign="top" headers="d0e319 "><p>jkl.html</p>
|
|
<p>jkl.html.gz</p>
|
|
<p>jkl.gz</p>
|
|
</td>
|
|
</tr>
|
|
<tr><td align="left" valign="top" headers="d0e315 ">jkl.gz.html.en</td>
|
|
<td align="left" valign="top" headers="d0e317 "><p>jkl</p>
|
|
<p>jkl.gz</p>
|
|
<p>jkl.gz.html</p>
|
|
</td>
|
|
<td align="left" valign="top" headers="d0e319 ">jkl.html</td>
|
|
</tr>
|
|
<tr><td align="left" valign="top" headers="d0e315 ">jkl.html.gz.en</td>
|
|
<td align="left" valign="top" headers="d0e317 "><p>jkl</p>
|
|
<p>jkl.html</p>
|
|
<p>jkl.html.gz</p>
|
|
</td>
|
|
<td align="left" valign="top" headers="d0e319 ">jkl.gz</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
<p>Looking at the table above you will notice that it is always possible to
|
|
use the name without any extensions in an hyperlink (for example, jkl). The
|
|
advantage is that you can hide the actual type of a document rsp. file and
|
|
can change it later, for example, from html to shtml or cgi without changing
|
|
any hyperlink references. </p>
|
|
<p>If you want to continue to use a MIME-type in your hyperlinks (for example <tt>jkl.html</tt>)
|
|
the language extension (including an encoding extension if there is one) must
|
|
be on the right hand side of the MIME-type extension (for example, <tt>jkl.html.en</tt>).
|
|
</p>
|
|
</div>
|
|
</div>
|
|
<div class="nested1" id="caching"><a name="caching"><!-- --></a><h2 class="topictitle2">Notes on caching </h2>
|
|
<div><p>When a cache stores a representation, it associates it with the request
|
|
URL. The next time that URL is requested, the cache can use the stored representation.
|
|
But, if the resource is negotiable at the server, this might result in only
|
|
the first requested variant being cached and subsequent cache hits might return
|
|
the wrong response. To prevent this, the HTTP Server (powered by Apache) normally
|
|
marks all responses that are returned after content negotiation as non-cacheable
|
|
by HTTP/1.0 clients. The HTTP Server (powered by Apache) also supports the
|
|
HTTP/1.1 protocol features to allow caching of negotiated responses. </p>
|
|
<p>For requests which come from an HTTP/1.0 compliant client (either a browser
|
|
or a cache), the directive CacheNegotiatedDocs can be used to allow caching
|
|
of responses which were subject to negotiation. This directive can be given
|
|
in the server config or virtual host, and takes no arguments. It has no effect
|
|
on requests from HTTP/1.1 clients. </p>
|
|
</div>
|
|
</div>
|
|
|
|
</body>
|
|
</html> |