- From: Koen Holtman <koen@win.tue.nl>
- Date: Thu, 1 Feb 1996 00:40:16 +0100 (MET)
- To: conneg@organic.com, http-caching@pa.dec.com
- Cc: koen@win.tue.nl (Koen Holtman)
I'm mailing this document to both the content negotiation and the
caching mailing lists.
For the caching list: yes, this is very long, but it does, among other
things, specify how the interaction between content negotiation and
caching can work. I don't know if such a specification can be much
shorter. Some text can be skipped if you are only interested in
caching.
For the content negotiation list: this is an update on the draft I
sent on Sunday. Now would be a good time to read this document. I
will not write more text before I get some feedback.
--------snip!---------
New content negotiation sections
================================
Koen Holtman, koen@win.tue.nl
version 2, 31 Jan 1996
INTRODUCTION
Parts of this document are unfinished.
This document contains new versions of some sections in the HTTP
1.1-01 draft that describe content negotiation. The text below
reflects the consensus of the content negotiation subgroup, as I
perceive it now, but also adds a many details not previously discussed
in the content negotiation subgroup or the caching subgroup.
The intention is that these new versions replace the old versions in
the HTTP 1.1 draft.
This text is also written to transmit my view how the interaction
between content negotiation and caching should work to the caching
subgroup.
I claim that the mechanisms defined here are powerful enough to allow
efficient caching of all kinds of content negotiation, and that they
are still simple enough to allow implementation.
I also claim that the mechanisms cannot be made much simpler without
affecting cachability, the power of the negotiation mechanism, or
both.
The text blocks marked with ## signs are comments. Some of them will
be removed in later versions of this document, others may be kept
until the last version, but should be removed when text is taken from
this document and put into a HTTP 1.1 draft.
I'm a bit disturbed as the increase in length of the text below with
respect to the old Chapter 12, but I can't find anything I'd want to
take out, so I guess the increase in length just reflects (our
increased understanding of the) complexity of content negotiation.
The text below follows the structure of the 1.1 draft. The beginning
is therefore not necessarily the best place to start reading! A good
reading order may be:
1 introduction of Section 12
2 header descriptions
3 response code descriptions
4 Sections 12.1, 12.2
5 Section xx.yy (Caching issues connected to content negotiation)
6 Section pp.qq.
Koen.
-----------------------------------------------------
[##
Changes wrt version mailed to conneg list on Sunday:
- added introduction
- new sections
- new comments
- grammar check done
- send-no-body-for replaced by variant-if-modified-since
- changed the word `field' to `attribute' or `directive' several times
##]
-----------------------------------------------------
[## Question to be resolved: Should a rudimentary feature negotiation
facilities that work for 90% of the cases be added as a stopgap?? I
wonder if we won't be doing the web community a disservice if we delay
a 90% solution in order to construct a 99% solution for HTTP 1.2 After
all, most negotiation that happens now is on tables vs. no tables, not
on language or MIME type. ##]
[## Question to be resolved: should URI and Location really be called
entity headers? ##]
-----------------------------------------------------
9.3 Redirection 3xx
[.....]
300 Multiple Choices
The requested resource is a negotiable resource and the server is
engaging in reactive content negotiation (Section 12). This response
may only be generated if specific conditions given in Section 12.2 are
met. The response must include an URI header describing the variants
bound to the resource, allowing a user agent to automatically select
and retrieve a variant if appropriate. Unless it was a HEAD request,
the response may include an entity. If an entity is included, this
entity must give the user the option to select the most appropriate
variant manually must never be included. The suggested entity media
type as given in the Content-Type response header is "text/html". If
the service author finds it appropriate for a user agent that does not
implement a variant selection algorithm to automatically retrieve a
certain variant, then a Location response header giving the URI of
that variant may be included in the response. This response is
cachable, subject to the restrictions specified in the caching related
directives of the included URI header, if such directives are present.
[.....]
9.4 Client Error 4xx
[.....]
406 None Acceptable
The requested resource is a negotiable resource and the server is
engaging in reactive content negotiation (Section 12). The response
must include an URI header describing the variants bound to the
resource, allowing a user agent to automatically select and retrieve a
variant if appropriate. Unless it was a HEAD request, the response
should include an entity that describes the variants bound to the
negotiable resource in a form that gives the user the option to select
the most appropriate variant manually. The suggested entity media
type as given in the Content-Type response header is "text/html". If
the service author finds it appropriate for a user agent that does not
implement a variant selection algorithm to automatically retrieve a
certain variant, then a Location response header giving the URI of
that variant should be included in the response. This response is
cachable, subject to the restrictions specified in the caching related
directives of the included URI header, if such directives are present.
-----------------------------------------------------
### Todo (maybe): Include improved descriptions of Accept* headers
### here
### Todo: introduce reactive-on-wildcard directive for the Accept header.
### Todo: adjust terminology in the description of the Location header.
-----------------------------------------------------
10.42 URI
[## Note: the "mirror" and "name" directives found in the URI header
of the 1.1-01 draft have been deleted from this URI header definition.
These directives have nothing to do with content negotiation, and they
make the definition of the role of the URI header as indicating
negotiability a lot more difficult. The content negotiation subgroup
advises that "mirror" and "name" functionality, if kept in the next
HTTP 1.1 draft, is put in one or two other headers.##]
If an URI entity-header header is present in a response, this
indicates that the resource is negotiable (Section 12). The URI
header field describes the variants bound to the negotiable resource.
The URI header field can also contain directives that control the
cachability and express the variance of the URI header, and, for some
response codes, the whole response.
URI-header = "URI" ":" 1#( uri-variant | uri-caching )
uri-variant = "{" "variant" <"> URI <"> source-quality
[ "{" "type" <"> media-type <"> "}" ]
[ "{" "language" <"> 1#language-tag <"> "}" ]
[ "{" "encoding" <"> 1#content-coding <"> "}" ]
[ "{" "length" 1*DIGIT "}" ]
[ "{" "description" quoted-string "}" ]
"}"
source-quality = qvalue
uri-caching = "{" "cache-control" 1#cache-directive "}"
| "{" "vary" 1#vary-directive "}"
[##Note: the uri-caching directives are supposed to replicate the
caching and vary features offered for normal responses by the
Cache-Control and Vary response headers. The syntax below should be
adjusted to the syntax of the Cache-Control and Vary response
headers.##]
Any URI specified in this field can be absolute or relative to the
Request-URI.
For each of the variants bound to the negotiable resource, the URI
header must include a "variant" form describing that variant.
The source-quality attribute given in a variant description is
measured by the content provider as representing the amount of
degradation from the original source. For example, a picture
originally in JPEG form would have a lower source quality when
translated to the XBM format, and much lower source quality when
translated to an ASCII-art representation. Note, however, that this
is a function of the source -- an original piece of ASCII-art may
degrade in quality if it is captured in JPEG form. If variants are
not converted from one source, but constructed separately to represent
the same abstract information in different ways, then the source
quality values can be used to express differences in quality between
the variants.
An example URI header for a negotiable resource with the URI
http://www.w3.org/pub/WWW/TheProject is:
URI: {variant "TheProject.fr.html" 1.0
{type "text/html"} {language "fr"}},
{variant "TheProject.en.html" 1.0
{type "text/html"} {language "en"}},
{variant "TheProject.fr.txt" 0.7
{type "text/plain"} {language "fr"}},
{variant "TheProject.en.txt" 0.8
{type "text/plain"} {language "en"}}
which indicates that the negotiable resource binds to four individual
variant resources that differ in media type and natural language.
The type, language, encoding, and length attributes of a variant
description refer to their Content-* header counterparts. Though all
attributes are optional, it is often desirable to include as many
attributes as possible as this will increase the quality of the
negotiation process.
The description attribute is meant to provide a textual description of
some properties of the variant, to be displayed by a user agent when
showing the list of all variants bound to a negotiable resource (see
Section 12). This attribute can be included if the URI and normal
attributes of a variant are considered too opaque to allow
interpretation by the user.
[##Note: the text below may need some editing depending on changes to
the Cache-control header and the kind of Vary header introduced.##]
The cache-control directive of the URI header field can be used to
restrict the cachability of the URI header, and, for some response
codes, the other parts of the response. This directives duplicates
the control functionality offered for un-negotiated resources by the
Cache-Control header. The vary directive of the URI header field
expresses the variance of the the URI header, and, for some response
codes, the other parts of the response, on properties of the request.
This directive duplicates the functionality offered for un-negotiated
resources by the Vary header. Caching of negotiated resources is
covered in Section xx.yy. An example is:
URI: {variant "plan.html" 0.9
{type "text/html"}},
{variant "plan.wuxta.html" 0.2
{type "text/html"}
{description "Does not trigger bug in WuxtaWeb 1.x"}},
{variant "plan.dvi" 1.0
{type "text/x-dvi"}},
{vary User-Agent},
{cache-control max-age=1209600}
which indicates that the variant set bound to the resource varies on
the User-Agent request header. In responses to requests done with a
WuxtaWeb 1.x user agent, the server would presumably generate an URI
header with the same variants, while assigning a source quality of 0
to the plan.html variant and a source quality of 0.8 to the
plan.wuxta.html variant. The cache-control directive limits the
cachability of the URI header to two weeks, presumably because the
content author wants to have the possibility of adding more special
variants if bugs in other user agents are found.
[## Issue to be resolved: Should there be cookie and user-agent-prefix
variant description attributes as an alternative to varying on Cookie
and User-Agent? ##]
[## Note: adding feature negotiation would add a "feature" variant
description attribute in the URI header. This attribute would contain
feature identifiers, which are short codes for things like `user agent
supports HTML 3.0 tables', `user agent supports java', and the
negations of feature identifiers. ##]
-----------------------------------------------------
10.aa Variant-If-Modified-Since
The Variant-If-Modified-Since request-header is used with the GET
method on negotiable resources to make the transmission of a variant
in a preemptive negotiation response (Section 12.2) conditional. If
the selected variant resource has not been modified since the time
specified in this field, a copy of the resource will not be returned
from the server; instead, a 304 (not modified) response will be
returned without any Entity-Body.
Variant-If-Modified-Since =
"Variant-If-Modified-Since" ":" URI LWS HTTP-date
[## Todo: check if the LWS (linear whitespace) above is required in
the syntax description ##]
The URI specified in this field can be absolute or relative to the
Request-URI. A request can contain multiple Variant-If-Modified-Since
headers, but must not contain multiple Variant-If-Modified-Since
headers which refer to the same variant.
[## Todo (maybe): specify the exact semantics of conditional variant
GET requests, by giving an algorithm as is done in the
If-Modified-Since header description. Alternative: point to such an
exact description in Section 12.##]
[## Question to be resolved: Should we name this header Variant-IMS,
which is shorter? ##]
------------------------------------------------------
12. Content negotiation
Content negotiation is an optional feature of the HTTP protocol:
resources may be negotiable, but they need not be. If a resource is
negotiable, this changes the semantics of GET and HEAD transactions on
the resource. Other transactions are not affected.
A negotiable resource has a number of variants bound to it. The HTTP
content negotiation mechanisms allow for selection of the preferred
variant bound to a negotiable resource based on the the properties of
the variants and on the user agent preferences for the retrieval
action.
[## Note: `retrieval action' is a new term I had to introduce because
`request' is not entirely accurate here: with reactive negotiation,
one retrieval action causes two requests. ##]
A variant is a resource, identified by a variant URI, that provides a
representation of the content of a negotiable resource. A variant
must never be a negotiable resource itself. It is the responsibility
of the author of the negotiable resource, not the author of the
variant, to ensure that this restriction is not violated.
The negotiability of a resource is expressed by the URI response
header. If a 2xx, 3xx, or 406 class response does not include an URI
response header, then clients can treat the corresponding resource as
un-negotiable. If a response does include an URI response header,
then clients must treat the resource as negotiable. This has
implications for user agent behavior and for the behavior of caches.
Caching of negotiable and variant resources is treated in Section
[xx.yy].
The URI response header corresponding to a negotiable resource
describes the variants bound to the negotiable resource. User agents
can use the descriptions in the URI header to automatically retrieve
and display the variant which best fits the preferences for the
retrieval action.
When displaying a variant as the end result of a retrieval action on a
negotiable resource, a user agent should allow the user to review a
list of all variants bound to the negotiable resource, and to
initiate retrieval of another variant if desired. The list can be
annotated with some or all of the properties of the variants, as given
in the URI header of the negotiable resource.
When displaying a variant as the end result of a retrieval action on a
negotiable resource, a user agent should show the negotiable resource
URI, not the variant URI, as being the URI the contents of which were
retrieved. If the user agent stores a reference to the content
displayed for future use, it is the the negotiable resource URI, not
the variant URI, which should be stored.
HTTP/1.1 provides for two types of content negotiation: preemptive and
reactive. Preemptive negotiation is generally faster than reactive
negotiation, but it can only be used if sufficient information about
user agent preferences is present in the request on the negotiable
resource. Reactive negotiation can always be used. Therefore,
preemptive negotiation is best seen as mechanism that can sometimes
optimize on reactive negotiation transactions.
The If-Modified-Since header (Section 10.23) cannot make GET requests
on negotiable resources conditional. Servers should ignore this
header if it is present in a request on a negotiable resource.
12.1 Reactive negotiation
In reactive negotiation, the selection and retrieval of a variant
bound to the negotiable resource spans two transactions. In the first
transaction, the client transmits a request on the negotiable resource
URI, and the server responds with a 300 (multiple choices) or 406
(none acceptable) response, which includes an URI header describing
the variants bound to the negotiable resource. A 406 response may
always be generated, a 300 response may only be generated if specific
conditions given in Section 12.2 are met. The client can use the the
URI header in the 300 or 406 response to select the variant that
matches best to the preferences for the retrieval action.
In the second transaction, the user agent transmits a request on the
variant URI of the selected variant, and the server will typically
respond with a 200 (OK) response, though other response codes like 302
(moved temporarily) are also possible. Only the user agent needs to
know that the second request is part of a reactive negotiation
process, all other parties can treat it as a normal request on an
un-negotiated resource.
User agents should use the reactive variant selection algorithm below
when automatically selecting the best variant listed in an URI header.
User agents are allowed to use other variant selection algorithms, but
this is not recommended, as preemptive negotiation is defined to
optimize the case in which the reactive variant selection algorithm
below is used.
User agents that do not wish to implement a variant selection
algorithm can, by only using Accept request headers of a certain form
[##(*)##], force servers to only send 406 (none acceptable) responses
when engaging in reactive negotiation. They can then use the 406
response body to allow the user to select a variant manually, or use
the 406 response Location header, if present, to automatically fetch
the variant recommended by the server.
[##(*) note: 1.0 clients will always use Accept headers of the certain
form that forces a 406 response if no preemptive negotiation can be
done##]
In the first step of the reactive variant selection algorithm, the overall
quality for every variant listed in the URI header of the negotiable
resource is computed. The overall quality of a variant is a real
number Q in the range 0 through 1, where 0 is the minimum and 1 the
maximum value, defined as
Q = qs * qe * qc * ql * q * qml
The values qs,qe,qc,ql,q,qml for a particular variant are all
determined using the part of URI header field describing that variant,
called the variant description below.
qs The source quality factor for the variant is given by the
source-quality attribute in the variant description.
[## Todo: the text about the service author determining qs that was
here in the 1.1 draft should be moved to the section describing the
URI header##]
qe The encoding quality factor is 1 if there is no encoding
attribute in the variant description. If there is an encoding
attribute in the variant description, the encoding quality
factor is 1 if the user agent can decode a message with the
given content encoding, 0 otherwise.
[## Todo: describe format of content encoding attribute in the URI header
description]
qc The charset quality factor is 1 if there is no type attribute in
the variant description, or if the media type given in the
type attribute of the variant description does not have a
charset parameter. If there is a charset parameter, then the
charset quality factor is 1 if the user agent can process a
message with the given character set (Section 3.4), 0
otherwise. User agents must assign a charset quality factor
of 1 to the US-ASCII charset.
[## Should we have charset quality factors in the range 0 through 1
rather than plain 0 or 1 here? There have been some comments that
this is desirable##]
ql The language quality factor is 1 if there is no language
attribute in the variant description. If there is a language
attribute, then the language quality factor is the highest
quality factor assigned to any one of the listed languages
according to the user agent language preferences for the
retrieval action. User agents must assign a language quality
factor of at least 0.001 to every language.
[## Note: the 1.1-01 draft says: `If at least one variant has an
assigned content language, but the one currently under consideration
does not, then it should be assigned the value "ql=0.5".' I deleted
this requirement, service authors can more accurately use the qs
attribute to adjust things in situations where only some of the
variants have languages##]
q The media type quality factor is 1 if there is no type attribute in
the variant description. If there is a type attribute, then the
media type quality factor is the quality factor assigned to
the given media type in in the user agent media type
preferences for the retrieval action.
qml The maximum length quality factor is 1 if there is no length
attribute in the variant description. If there is a length
attribute in the variant description, then the maximum length
quality factor is 1 if the length given is less than or equal
to the maximum acceptable length according to the user agent
maximum length preferences for the retrieval action, 0
otherwise. Preferred maximum lengths are often equal to
`infinity'. The prefered maximum length for a variant can
vary on the type of the variant as given by the type attribute
in the variant description, if present.
In the second step of the the reactive variant selection algorithm,
the overall qualities of all variants are compared to select the best
variant. If there is one variant with the highest overall quality
value, then that variant is the best variant. If there are multiple
variants that share the highest overall quality value, then the
variant that is listed first in the URI header is the best variant.
If all variants have an overall quality value of zero, a user agent
should not automatically retrieve the first variant, but stop the
reactive negotiation process, allowing the user can decide on the next
action.
12.2 Preemptive negotiation
In preemptive negotiation, the selection and retrieval of a variant
bound to the negotiable resource is done in a single transaction,
saving one round trip time over reactive negotiation. A preemptive
negotiation response must only be generated by a server if the request
on the negotiable resource contains enough information about the
capabilities and preferences of the user agent to allow the server to
determine which variant would be chosen if the reactive variant
selection algorithm outlined above were used by the user agent in
reactive negotiation.
A preemptive negotiation response must always contain an URI header
describing the variants bound to the negotiable resource, and a
Location header that gives the variant URI of the best variant as
determined by the server.
The status code of a preemptive negotiation response can never be 300
or 406, as these status codes indicate reactive negotiation. A
preemptive response contains a representation of the best variant
resource, which has the URI given the Location header of the response,
and the status code of the response is part of that representation.
The representation of the best variant resource consists of a `virtual
response', as generated by the server, using HTTP semantics for
un-negotiated resources, to a `virtual request' on the variant URI.
The virtual response can be constructed by taking the actual
preemptive negotiation response, and deleting the URI and Location
headers.
The virtual request can be constructed by taking the actual request on
the negotiable resource, replacing the request URI by the variant URI
as given in the Location response header, deleting all
Variant-If-Modified-Since headers, and, if there was a
Variant-If-Modified-Since header with an URI matching the variant URI
as given in the Location response header, adding an If-Modified-Since
header with the date given by that Variant-If-Modified-Since header.
Clients can use the virtual response to display the contents of the
best variant resource. Clients may present the information in a
virtual response as being controlled by the author of the variant
resource, not the author of the negotiable resource on which the
actual request was made. It is the responsibility of the server to
ensure that variant resource author indeed has this control. Section
[pp.qq] discusses the implications of this rule on server design and
administration. Clients that get a reactive negotiation response
directly from an origin server must reject this response as a probable
spoofing attempt if the Location header in the response gives the URI
of a variant resource not located on the same origin server. If the
client is a proxy, it must never pass on the rejected response to its
own clients, it can generate a 502 (bad gateway) response instead.
User agents can transmit information about their capabilities and
preferences for a retrieval action using the various accept request
headers. If the accept headers present in a request on a negotiable
resource contain enough information, a server will be able to generate
a preemptive negotiation response. As most resources will be
un-negotiable, user agents are encouraged to send empty or small
accept headers, or even omit some accept headers entirely, by default.
If a user agent knows or discovers that an origin server provides
negotiated resources, it is encouraged to use data from the negotiated
responses received so far to dynamically add or extend accept headers
sent to the origin server in future requests, in order to increase the
probability that preemptive negotiation can be used instead of the
slower reactive negotiation.
Servers that want to support preemptive negotiation must use the
preemptive variant selection algorithm below. This algorithm can be
applied to determine
o whether a preemptive negotiation response may be sent, and if so,
which variant must be selected as the best variant
o whether a 300 (multiple choices) reactive negotiation response
may be sent.
The algorithm uses the variant descriptions for each of the available
variants, as will be included in the URI header of the response, and
the Accept headers of the request as input.
In the first step of the preemptive variant selection algorithm, the
overall quality for every variant bound to the negotiable resource is
computed. The overall quality of a variant is a real number Q in the
range 0 through 1, where 0 is the minimum and 1 the maximum value,
defined as
Q = qs * qe * qc * ql * q * qml
The values qs,qe,qc,ql,q,qml for a particular variant are all
determined using the variant description of the particular variant and
the Accept headers of the request.
The overall quality values computed in the preemptive algorithm are
not necessarily equal to the overall quality values values computed in
the reactive algorithm of Section 12.1.
qs The source quality factor for the variant is given by the
source-quality attribute in the variant description.
###################################################################
[## Todo: paste and edit other parameter descriptions from 1.1-00
draft. Alternative: put these descriptions in the subsections of the
individual accept headers and point to them here. Second
alternative: do both. This todo has no connection to caching, so it
does not have a high priority. ##]
###################################################################
In the second step of the preemptive negotiation variant selection
algorithm, the overall qualities of all variants are compared to
select the best one. If there is one variant with the highest overall
quality value, then that variant is the best variant. If there are
multiple variants that share the highest overall quality value, then
the variant that is listed first in the URI header is the best
variant.
In the third step of the preemptive negotiation variant selection
algorithm, it is determined whether a preemptive negotiation response
may be sent to return the best variant found, and also whether a 300
whether a 300 (multiple choices) reactive negotiation response may be
sent.
If the best variant has an overall quality value of zero, then the
server must not not generate a preemptive response, nor must it
generate a reactive response with the 300 (multiple choices) response
code. It should generate a reactive response with the 406 (none
acceptable) response code.
If the best variant has a quality factor greater than zero, and the
Accept header of the request does not contain a reactive-on-wildcard
directive, then the server may generate a preemptive response with the
URI of the best variant in the Location header. It may also generate
a reactive response with the 300 (multiple choices) response code. It
should not generate a reactive response with the 406 (none acceptable)
response code.
If the best variant has a quality factor greater than zero, and the
Accept header of the request contains a reactive-on-wildcard
directive, and the type quality factor (q) of the best variant was
derived from an Accept header media range containing an asterisk "*"
wildcard character, then the server must not not generate a preemptive
response, nor must it generate a reactive response with the 300
(multiple choices) response code. It should generate a reactive
response with the 406 (none acceptable) response code.
If the best variant has a quality factor greater than zero, and the
Accept header of the request contains a reactive-on-wildcard
directive, and the type quality factor (q) of the best variant was not
derived from an Accept header media range containing an asterisk "*"
wildcard character, then the server may generate a preemptive response
with the URI of the best variant in the Location header. It may also
generate a reactive response with the 300 (multiple choices) response
code. It should not generate a reactive response with the 406 (none
acceptable) response code.
An origin server should not generate a preemptive response if the best
variant resource is located on another origin server, because clients
must reject such responses as probable spoofing attempts. In this
case, the server should generate a reactive response with the 300
(multiple choices) response code instead. Proxies may generate a
preemptive response if the negotiable resource and the best variant
resource are located on different origin servers.
------------------------------------------------------
xx.yy Caching issues connected to content negotiation
[##Note: the text below may need some editing depending on changes to
the Cache-control header and the kind of Vary header introduced.##]
Below, the caching of the responses in the first transaction in a
reactive negotiation process (Section 12.1), and the caching of
preemptive negotiation responses (Section 12.2) is discussed. For the
second transaction in a reactive negotiation process, which is done on
an un-negotiated variant resource (at least if no errors are made by
the author of the negotiable resource), the normal caching rules
apply.
To generate a response to a new request on a negotiable resource, a
proxy or user agent cache may sometimes re-use parts of old responses.
The URI header in an old response from the negotiable resource may be
re-used provided that
o any caching restrictions specified by the caching related request
headers of the new request, if present, and the cache-control
directive of the URI header, is present, are met, and provided
that
o if a vary directive is present in the URI header, then the old
request and the new request match according to the matching
function specified by the vary directive.
[##Note: the text above assumes that the Vary header is defined as
generating a request matching function##]
If an URI header that may be re-used is present, then the proxy may
assume that the resource requested is still a negotiable resource. In
other cases, no assumptions about negotiability or un-negotiability of
the resource must be made.
The response headers and response body of a reactive negotiation
response (a response with a 300 or 406 response code) may be re-used
if the URI header in the such a response may be re-used.
A virtual response included in a preemptive negotiation response may
be re-used provided that
o any caching restrictions specified by the caching related request
headers of the new request, if present, and in the caching related
headers of the virtual response, if present, are met, and provided
that
o if a Vary response header is present in the virtual response, then the
old request and the new request match according to the matching
function specified by the vary directive.
[##Note: the text above assumes that the Vary header is defined as
generating a request matching function##]
A real response for a variant, that is a response generated by a
request on the URI of that variant, is re-usable if
o any caching restrictions specified by the caching related request
headers of the new request, if present, and in the caching related
headers of the real response, if present, are met, and provided
that
o if a Vary response header is present in the real response, then
the old request on the variant URI and the new request match
according to the matching function specified by the vary
directive.
[##Note: the text above assumes that the Vary header is defined as
generating a request matching function##]
If a proxy or user agent cache gets a new request on negotiable
resource, and it has a re-usable URI header for that request, then it
may apply the reactive variant selection algorithm from Section 12.2
to the re-usable URI header and the request accept headers to
determine which types of negotiation responses it is allowed to send.
Note that the algorithm always allows the server to send a 406 (none
acceptable) reactive negotiation response.
If a certain response can be sent by the proxy or user agent cache,
then this response must be constructed from re-usable components only,
according to the restrictions below.
The URI header in the response must be the URI header re-used in the
the reactive variant selection algorithm.
If the response is a 300 or 406 reactive negotiation response and an
entity is included, then this entity must either be constructed from
the contents of the URI header re-used, or be taken from a re-usable
300 or 406 response that has an URI header identical to the URI header
re-used. A Location header may only be included in the response if it
has been taken from a re-usable 300 or 406 response that has an URI
header identical to the URI header re-used.
If the response is a preemptive negotiation response, then the
Location header included should give the URI of the best variant as
determined by the variant selection algorithm.
The virtual part of the response, which is the preemptive negotiation
response with the URI and Location headers deleted, should be
identical to either a re-usable virtual response for the best variant,
a re-usable real response for the best variant, or the response to a
new request on the best variant URI made by the cache, where the new
request is constructed according to the rules for the construction of
a virtual request given in Section 12.2.
[## Todo: the above description does not take new virtual 304 (not
modified) responses into account, which may be generated (I believe)
without there being an old re-usable 304 (not modified) response. The
text above needs to be extended to account for this. (Are 304
responses re-usable anyway? Or can they just be generated on the fly
using re-usable 200 responses? Either view will work I guess) ##]
[## Todo: discuss the use of Variant-If-Modified-Since headers, and
the modification of a 304 (not modified) response into a 200 response
that includes a variant body by using a cached re-usable 200
response.##]
[##Todo: somewhere, there should be text saying that caches should
throw away older cachable URI headers and variant responses if they
receive newer ones##]
------------------------------------------------------
pp.qq Security considerations connected to content negotiation
#### - spoofing using Location headers.
###Clients may present the information in a virtual response as being
###controlled by the author of the variant resource, not the author of
###the negotiable resource on which the actual request was made. It
###is the responsibility of the server to ensure that variant resource
###author indeed has this control. This section discusses the
###implications of this rule on server design and administration.
###Basically, if you run a server with multiple non-cooperating users,
###you have to either trust those people who may author scripts (CGI
###or other kinds), or you have to restrict the CGI script mechanism
###to either reject or restrict preemptive negotiation responses made
###by scripts (including nph CGI scripts, which means that you will
###have to parse the headers they generate).
[end of text]
Received on Thursday, 1 February 1996 00:02:39 UTC