- From: Paul Hoffman <paulh@imc.org>
- Date: Tue, 26 Dec 1995 09:38:38 -0800
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
- Message-Id: <v02140403ad05e276a498@[165.227.10.43]>
Greetings. This is the first round of the WG's efforts to change the
draft-ietf-http-v10-spec-04.txt document from a BCP draft to an informational
draft. Larry Masinter asked me to take charge of this effort in Dallas, and
here's the first result.
Bascially, there are three additions to the -04 draft and no changes. I'm
distributing this to the WG as essentially a set of diffs instead of a full
draft since the changes are localized and hopefully easy to follow.
Diff summary:
- Add a paragraph to section 1.1 indicating what the intended status of the
draft is to be.
- Add a new security section, 12.5, reflecting the recent discussion of
partial URLs and path component attacks.
- Add Appendix D, which puts back in most of what was removed from the draft
between the -01 and -02 steppings. This is:
- PUT, DELETE, LINK, and UNLINK request methods as new section D.1
- Section D.2 is all headers from the -01 stepping that were not in -04
*except*
- Content-Transfer-Encoding (feature already covered in section C.4)
- Forwarded (not implemented)
- Orig-URL (not implemented)
- Public (not implemented)
- Section 9 from -01, "Content Negotiation", is now section D.3
- Section 3.8 from -01, "Language Tags", is now section D.4
- Section 3.9 from -01, "Quality Values", is now section D.5
In new Appendix D, I have renumbered all the section cross-references to match
the -04 draft. Other than that, I did not change any of the wording from the
sections I moved from the -01 draft.
--Paul Hoffman
--Internet Mail Consortium
--============_-1392122978==_============
Content-Type: text/plain; name="BCP-to-info-00.txt"; charset="us-ascii"
Content-Disposition: attachment; filename="BCP-to-info-00.txt"
The following paragraph is added after the first paragraph of section 1.1 (Purpose):
This specification is for informational purposes only. It reflects
the consensus of the IETF HTTP Working Group about what features
would normally be found in an HTTP/1.0 implementation. These
features are split into two sections. The features for which there was
strong consensus about how they are implemented are listed in the
main body of this document. Features for which there was not strong
consensus are listed in Appendix D.
In -04, Section 12.5 is added:
12.5 Attacks Based On Path Names
Implementations of the HTTP servers should be careful to restrict the
documents returned by HTTP requests to be only those that were intended
by the administrators. If an HTTP server translates HTTP URIs directly
into file system calls, the server must take special care not to serve
files outside the desired directory tree. For example, Unix, Microsoft
Windows, and other operating systems use ".." as a path component to
indicate a directory level above the current one. A URL with such
constructs can be constructed to potentially allow access to files
outside the desired directory structure, and should thus be disallowed.
In -04, Appendix D is added:
D. Additional Features
This appendix documents features which were was not strong consensus in
the IETF HTTP Working Group. In some cases, there was strong consensus
that the feature was needed but disagreement about how it should be
implemented. In other cases, there was no general agreement on the
feature. Implementors who add the features in the Appendix should be
aware that software using these features are less likely to be
interoperable than software using the features from the main part of
this specification.
D.1 Additional Request Methods
D.1.1 PUT
The PUT method requests that the enclosed entity be stored under
the supplied Request-URI. If the Request-URI refers to an already
existing resource, the enclosed entity should be considered as a
modified version of the one residing on the origin server. If the
Request-URI does not point to an existing resource, and that URI is
capable of being defined as a new resource by the requesting user
agent, the origin server can create the resource with that URI. If
a new resource is created, the origin server must inform the user
agent via the 201 (created) response. If an existing resource is
modified, either the 200 (ok) or 204 (no content) response codes
should be sent to indicate successful completion of the request. If
the resource could not be created or modified with the Request-URI,
an appropriate error response should be given that reflects the
nature of the problem.
The fundamental difference between the POST and PUT requests is
reflected in the different meaning of the Request-URI. The URI in a
POST request identifies the resource that will handle the enclosed
entity as an appendage. That resource may be a data-accepting
process, a gateway to some other protocol, or a separate entity
that accepts annotations. In contrast, the URI in a PUT request
identifies the entity enclosed with the request -- the user agent
knows what URI is intended and the server must not attempt to apply
the request to some other resource. If the server desires that the
request be applied to a different URI, it must send a 301 (moved
permanently) response; the user agent may then make its own
decision regarding whether or not to redirect the request.
A single resource may be identified by many different URIs. For
example, an article may have a URI for identifying "the current
version" which is separate from the URI identifying each particular
version. In this case, a PUT request on a general URI may result in
several other URIs being defined by the origin server. The user
agent should be informed of these URIs via one or more URI header
fields in the response. The Location header field should be used to
identify the exact location URI if it is different than the
Request-URI.
A valid Content-Length is required on all HTTP/1.0 PUT requests. An
HTTP/1.0 server should respond with a 400 (bad request) message if
it cannot determine the length of the request message's content.
The client can create or modify relationships between the enclosed
entity and other existing resources by including Link header
fields, as described in Section D.2.6. As with POST, the server may
use the Link information to perform other operations as a result of
the request. However, no mandatory operation is imposed on the
origin server. The origin server may generate its own or additional
links to other resources.
The actual method for determining how the resource is placed, and
what happens to its predecessor, is defined entirely by the origin
server. If version control is implemented by the origin server,
then Link relationships should be defined by the server to help
identify and control revisions to a resource; suggested
relationship names include "Derived-From", "Obsoletes", and
"Updates".
Note: The model of sending an entire PUT request within a
single message, without first checking if the server is
willing to accept that data, will break if the server is
unwilling to accept the request or desires some form of
authentication beforehand. Worse, the client won't be
notified of the reason for error if a TCP reset is received
prior to reading the response buffer (see note in
Section 9.4). It should therefore be recognized that
HTTP/1.0 PUT and large POST requests will only work reliably
if the client's intentions and server's desires are
negotiated prior to the request.
D.1.2 DELETE
The DELETE method requests that the origin server delete the
resource identified by the Request-URI. This method may be
overridden by human intervention (or other means) on the origin
server. The client cannot be guaranteed that the operation has been
carried out, even if the status code returned from the origin
server indicates that the action has been completed successfully.
However, the server should not indicate success unless, at the time
the response is given, it intends to delete the resource or move it
to an inaccessible location.
A successful response should be 200 (ok) if the response includes
an entity describing the status, 202 (accepted) if the action has
not yet been enacted, or 204 (no content) if the response is OK but
does not include an entity.
D.1.3 LINK
The LINK method establishes one or more Link relationships between
the existing resource identified by the Request-URI and other
existing resources. The difference between LINK and other methods
allowing links to be established between resources is that the LINK
method does not allow any Entity-Body to be sent in the request and
does not result in the creation of new resources.
D.1.4 UNLINK
The UNLINK method removes one or more Link relationships from the
existing resource identified by the Request-URI. These
relationships may have been established using the LINK method or by
any other method supporting the Link header. The removal of a link
to a resource does not imply that the resource ceases to exist or
becomes inaccessible for future references.
D.2 Additional Header Field Definitions
This section defines the syntax and semantics of all standard
HTTP/1.0 header fields. For Entity-Header fields, both sender and
recipient refer to either the client or the server, depending on
who sends and who receives the entity.
D.2.1 Accept
The Accept header field can be used to indicate a list of media
ranges which are acceptable as a response to the request. The
asterisk "*" character is used to group media types into ranges,
with "*/*" indicating all media types and "type/*" indicating all
subtypes of that type. The set of ranges given by the client should
represent what types are acceptable given the context of the
request. The Accept field should only be used when the request is
specifically limited to a set of desired types, as in the case of a
request for an in-line image, or to indicate qualitative
preferences for specific media types.
The field may be folded onto several lines and more than one
occurrence of the field is allowed, with the semantics being the
same as if all the entries had been in one field value.
Accept = "Accept" ":" #(
media-range
[ ";" "q" "=" qvalue ]
[ ";" "mxb" "=" 1*DIGIT ] )
media-range = ( "*/*"
| ( type "/" "*" )
| ( type "/" subtype )
) *( ";" parameter )
The parameter q is used to indicate the quality factor, which
represents the user's preference for that range of media types. The
parameter mxb gives the maximum acceptable size of the Entity-Body,
in decimal number of octets, for that range of media types.
Section D.3 describes the content negotiation algorithm which makes
use of these values. The default values are: q=1 and mxb=undefined
(i.e., infinity).
The example
Accept: audio/*; q=0.2, audio/basic
should be interpreted as "I prefer audio/basic, but send me any
audio type if it is the best available after an 80% mark-down in
quality."
If no Accept header is present, then it is assumed that the client
accepts all media types with quality factor 1. This is equivalent
to the client sending the following accept header field:
Accept: */*; q=1
or
Accept: */*
A more elaborate example is
Accept: text/plain; q=0.5, text/html,
text/x-dvi; q=0.8; mxb=100000, text/x-c
Verbally, this would be interpreted as "text/html and text/x-c are
the preferred media types, but if they do not exist then send the
Entity-Body in text/x-dvi if the entity is less than 100000 bytes,
otherwise send text/plain."
Note: In earlier versions of this document, the mxs
parameter defined the maximum acceptable delay in seconds
before the response would arrive. This has been removed as
the server has no means of obtaining a useful reference
value. However, this does not prevent the client from
internally measuring the response time and optimizing the
Accept header field accordingly.
Media ranges can be overridden by more specific media ranges or
specific media types. If more than one media range applies to a
given type, the most specific reference has precedence. For example,
Accept: text/*, text/html, text/html;version=2.0, */*
have the following precedence:
1) text/html;version=2.0
2) text/html
3) text/*
4) */*
The quality value associated with a given type is determined by
finding the media range with the highest precedence which matches
that type. For example,
Accept: text/*;q=0.3, text/html;q=0.7, text/html;version=2.0,
*/*;q=0.5
would cause the following values to be associated:
text/html;version=2.0 = 1
text/html = 0.7
text/plain = 0.3
image/jpeg = 0.5
text/html;level=3 = 0.7
It must be emphasized that the Accept field should only be used
when it is necessary to restrict the response media types to a
subset of those possible or when the user has been permitted to
specify qualitative values for ranges of media types. If no quality
factors have been set by the user, and the context of the request
is such that the user agent is capable of saving the entity to a
file if the received media type is unknown, then the only
appropriate value for Accept is "*/*".
Note: A user agent may be provided with a default set of
quality values for certain media ranges. However, unless the
user agent is a completely closed system which cannot
interact with other rendering agents, this default set
should be configurable by the user.
D.2.2 Accept-Charset
The Accept-Charset request header field can be used to indicate a
list of preferred character set encodings other than the default
US-ASCII and ISO-8859-1. This field allows clients capable of
understanding more comprehensive or special-purpose character set
encodings to signal that capability to a server which is capable of
representing documents in those character set encodings.
Accept-Charset = "Accept-Charset" ":" #charset
Character set encoding values are described in Section 3.5. An
example is
Accept-Charset: iso-8859-5, unicode-1-1
The value of this field should not include "US-ASCII" or
"ISO-8859-1", since those values are always assumed by default. If
a resource is only available in a character set encoding other than
the defaults, and that character set encoding is not listed in the
Accept-Charset field, it is only acceptable for the server to send
the entity if the character set encoding can be identified by an
appropriate charset parameter on the media type or within the
format of the media type itself.
Note: User agents are not required to be able to render the
characters associated with the ISO-8859-1 character set
encoding. However, they must be able to interpret their
meaning to whatever extent is required to properly handle
messages in that character set encoding.
D.2.3 Accept-Encoding
The Accept-Encoding request header field is similar to Accept, but
restricts the encoding-mechanism values which are acceptable in the
response.
Accept-Encoding = "Accept-Encoding" ":"
#( encoding-mechanism )
An example of its use is
Accept-Encoding: compress, gzip
If no Accept-Encoding field is present in a request, the server
should assume that the client will accept any encoding-mechanism.
D.2.4 Accept-Language
The Accept-Language request header field is similar to Accept, but
restricts the set of natural languages that are preferred as a
response to the request.
Accept-Language = "Accept-Language" ":"
#( language-tag [ ";" "ql" "=" qvalue ] )
The language-tag is described in Section D.4. Each language may be
given an associated quality value which represents an estimate of
the user's comprehension of that language. The quality value
defaults to "ql=1" (100% comprehension) for listed languages. This
value may be used in the server's content negotiation algorithm
(Section D.3). For example,
Accept-Language: da, en-gb;ql=0.8, de;ql=0.55
would mean: "I prefer Danish, but will accept British English (with
80% comprehension) or German (with a 55% comprehension)."
If the server cannot fulfill the request with one or more of the
languages given, or if the languages only represent a subset of a
multi-linguistic Entity-Body, it is acceptable to serve the request
in an unspecified language. This is equivalent to asssigning a
quality value of "ql=0.001" to any unlisted language.
If no Accept-Language header is present in the request, the server
should assume that all languages are equally acceptable.
Note: As intelligibility is highly dependent on the
individual user, it is recommended that client applications
make the choice of linguistic preference available to the
user. If the choice is not made available, then the Accept-
Language header field must not be given in the request.
D.2.5 Content-Language
The Content-Language field describes the natural language(s) of the
intended audience for the enclosed entity. Note that this may not
be equivalent to all the languages used within the entity.
Content-Language = "Content-Language" ":" #language-tag
Language tags are defined in Section D.4. The primary purpose of
Content-Language is to allow a selective consumer to identify and
differentiate resources according to the consumer's own preferred
language. Thus, if the body content is intended only for a Danish-
literate audience, the appropriate field is
Content-Language: dk
If no Content-Language is specified, the default is that the
content is intended for all language audiences. This may mean that
the sender does not consider it to be specific to any natural
language, or that the sender does not know for which language it is
intended.
Multiple languages may be listed for content that is intended for
multiple audiences. For example, a rendition of the "Treaty of
Waitangi," presented simultaneously in the original Maori and
English versions, would call for
Content-Language: mi, en
However, just because multiple languages are present within an
entity does not mean that it is intended for multiple linguistic
audiences. An example would be a beginner's language primer, such
as "A First Lesson in Latin," which is clearly intended to be used
by an English-literate audience. In this case, the Content-Language
should only include "en".
Content-Language may be applied to any media type -- it should not
be limited to textual documents.
D.2.6 Link
The Link header provides a means for describing a relationship
between the entity and some other resource. An entity may include
multiple Link values. Links at the metainformation level typically
indicate relationships like hierarchical structure and navigation
paths. The Link field is semantically equivalent to the <LINK>
element in HTML [4].
Link = "Link" ":" #("<" URI ">"
[ ";" "rel" "=" relationship ]
[ ";" "rev" "=" relationship ]
[ ";" "title" "=" quoted-string ] )
relationship = sgml-name
| ( <"> sgml-name *( SP sgml-name) <"> )
sgml-name = ALPHA *( ALPHA | DIGIT | "." | "-" )
Relation values are not case-sensitive and may be extended within
the constraints of the sgml-name syntax. There are no predefined
link relationship values for HTTP/1.0. The title parameter may be
used to label the destination of a link such that it can be used as
identification within a human-readable menu. Examples of usage
include:
Link: <http://www.cern.ch/TheBook/chapter2>; rel="Previous"
Link: <mailto:timbl@w3.org>; rev="Made"; title="Tim Berners-Lee"
The first example indicates that the entity is previous to chapter2
in a logical navigation path. The second indicates that the person
responsible for making the resource available is identified by the
given e-mail address.
D.2.7 Retry-After
The Retry-After response header field can be used with a 503
(service unavailable) response to indicate how long the service is
expected to be unavailable to the requesting client. The value of
this field can be either an HTTP-date or an integer number of
seconds (in decimal) after the time of the response.
Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds )
Two examples of its use are
Retry-After: Wed, 14 Dec 1994 18:22:54 GMT
Retry-After: 120
In the latter example, the delay is 2 minutes.
D.2.8 Title
The Title header field indicates the title of the entity
Title = "Title" ":" *text
An example of the field is
Title: Hypertext Transfer Protocol -- HTTP/1.0
This field is isomorphic with the <TITLE> element in HTML [4].
D.2.9 URI
The URI-header field may contain some or all of the Uniform
Resource Identifiers (Section 3.2) by which the Request-URI
resource can be identified. There is no guarantee that the resource
can be accessed using the URI(s) specified.
URI-header = "URI" ":" #( "<" ( absoluteURI | relativeURI ) ">"
[ ";" vary ] *( ";" characteristic) )
vary = "vary" "="
( vary-dimension | ( <"> 1#vary-dimension <"> ) )
vary-dimension = "type" | "charset" | "language" | "encoding"
| "user-agent" | "version" | token
characteristic = ( "type={" media-type "}" )
| ( "language={" 1#language-tag "}" )
| ( "encoding={" 1#encoding-mechanism "}" )
| ( "length=" 1*DIGIT )
| ( "qs=" qvalue )
Any URI specified in this field can be either absolute or relative
to the Request-URI.
If the Location header field is present in a 2xx response, its
value defines an implicit URI header with the characteristic
parameters defined by the associated Content-* header fields.
The URI-header may be used by a client performing a POST request to
suggest a URI for the new entity. Whether or not the suggested URI
is used is entirely up to the server to decide. In any case, the
server's response must include the actual URI(s) of the new
resource if one is successfully created (status 201).
If a URI refers to a set of variants, then the dimensions of that
variance must be given with a vary parameter. One example is:
URI: <http://info.cern.ch/hypertext/WWW/TheProject.multi>;
vary="type,language"
which indicates that the URI covers a group of entities that vary
in media type and natural language. A request for that URI will
result in a response that depends upon the client's request headers
for Accept and Accept-Language. Similar dimensions exist for the
Accept-Encoding, Accept-Charset, and User-Agent header fields, as
demonstrated in the following example.
URI: <TheProject.ps>; vary="encoding,version";
type={application/postscript},
<TheProject.html>; vary="user-agent,charset,version";
type={text/html},
<TheProject.html3;v=25>; type={text/html; level=3}; qs=0.9
User agents may use this information to notify the user of
additional formats.
The vary parameter has an important effect on cache management,
particularly for caching intermediaries which service a diverse set
of user agents. Since the response to one user agent may differ
from the response to a second user agent if the two agents have
differing request profiles, a caching intermediary must keep track
of the content metainformation for resources with varying
dimensions. Thus, the vary parameter tells the intermediary what
entity headers must be part of the key for caching that URI. When
the caching proxy gets a request for that URI, it must forward the
request toward the origin server if the request profile includes a
variant dimension that has not already been cached.
If the origin server provides the characteristics of each
identified resource as part of the URI header, then the recipient
may improve its cached response behavior by attempting to duplicate
the content negotiation that would be provided by the server. This
is not required by the protocol, but may improve the accuracy or
timeliness of responses to the end-user.
D.3 Content Negotiation
Content negotiation is an optional feature of the HTTP protocol. It
is designed to allow for selection of a preferred content
representation, within a single request-response round-trip, and
without intervention from the user. However, this may not always be
desirable for the user and is sometimes unnecessary for the content
provider. Implementors are encouraged to provide mechanisms whereby
the amount of preemptive content negotiation, and the parameters of
that negotiation, are configurable by the user and server
maintainer.
The first step in the negotiation algorithm is for the server to
determine whether or not there are any content variants for the
requested resource. Content variants may be in the form of multiple
preexisting entities or a set of dynamic conversion filters. These
variants make up the set of entities which may be sent in response
to a request for the given Request-URI. In most cases, there will
only be one available form of the resource, and thus a single
"variant".
For each variant form of the resource, the server identifies a set
of quality values (Section D.5) which act as weights for measuring
the desirability of that resource as a response to the current
request. The calculated weights are all real numbers in the range
0 through 1, where 0 is the minimum and 1 the maximum value. The
maximum acceptable bytes for each media range and the size of the
resource variant are also factors in the equation.
The following parameters are included in the calculation:
qs Source quality 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 qs when translated to the XBM format,
and much lower qs 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. The qs value should
be assigned to each variant by the content provider; if no
qs value has been assigned, the default is generally
"qs=1". A server may define its own default qs value based
on the resource characteristics, but only if individual
resources can override those defaults.
qe Encoding quality is measured by comparing the variant's
applied encoding-mechanisms (Section 3.5) to those listed
in the request message's Accept-Encoding field. If the
variant has no assigned Content-Encoding, or if no Accept-
Encoding field is present, the value assigned is "qe=1". If
all of the variant's content encodings are listed in the
Accept-Encoding field, then the value assigned is "qe=1".
If any of the variant's content encodings are not listed in
the provided Accept-Encoding field, then the value assigned
is "qe=0.001".
qc Charset quality is measured by comparing the variant media-
type's charset parameter value (if any) to those character
set encodings (Section 3.4) listed in the request message's
Accept-Charset field. If the variant's media-type has no
charset parameter, or the variant's charset is US-ASCII or
ISO-8859-1, or if no Accept-Charset field is present, then
the value assigned is "qc=1". If the variant's charset is
listed in the Accept-Charset field, then the value assigned
is "qc=1". Otherwise, if the variant's charset is not
listed in the provided Accept-Encoding field, then the
value assigned is "qc=0.001".
ql Language quality is measured by comparing the variant's
assigned language tag(s) (Section D.4) to those listed in
the request message's Accept-Language field. If no variant
has an assigned Content-Language, or if no Accept-Language
field is present, the value assigned is "ql=1". 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". If any of the variant's
content languages are listed in the Accept-Language field,
then the value assigned is the maximum of the "ql"
parameter values for those language tags (Section D.2.4); if
there was no exact match and at least one of the Accept-
Language field values is a complete subtag prefix of the
content language tag(s), then the "ql" parameter value of
the largest matching prefix is used. If none of the
variant's content language tags or tag prefixes are listed
in the provided Accept-Language field, then the value
assigned is "ql=0.001".
q Media type quality is measured by comparing the variant's
assigned media type (Section 3.6) to those listed in the
request message's Accept field. If no Accept field is
given, then the value assigned is "q=1". If at least one
listed media range (Section D.2.1) matches the variant's
media type, then the "q" parameter value assigned to the
most specific of those matched is used (e.g.,
"text/html;version=3.0" is more specific than "text/html",
which is more specific than "text/*", which in turn is more
specific than "*/*"). If no media range in the provided
Accept field matches the variant's media type, then the
value assigned is "q=0".
mxb The maximum number of bytes in an Entity-Body that the
client will accept is also obtained from the matching of
the variant's assigned media type to those listed in the
request message's Accept field. If no Accept field is
given, or if no media range in the provided Accept field
matches the variant's media type, then the value assigned
is "mxb=undefined" (i.e., infinity). Otherwise, the value
used is that given to the "mxb" parameter in the media
range chosen above for the q value.
bs The actual number of bytes in the Entity-Body for the
variant when it is included in a response message. This
should equal the value of Content-Length.
The mapping function is defined as:
Q(qs,qe,qc,ql, { if mxb=undefined, then (qs*qe*qc*ql*q) }
q,mxb,bs) = { if mxb >= bs, then (qs*qe*qc*ql*q) }
{ if mxb < bs, then 0 }
The variants with a maximal value for the Q function represent the
preferred representation(s) of the entity; those with a Q values
less than the maximal value are therefore excluded from further
consideration. If multiple representations exist that only vary by
Content-Encoding, then the smallest representation (lowest bs) is
preferred.
If no variants remain with a value of Q greater than zero (0), the
server should respond with a 406 (none acceptable) response
message. If multiple variants remain with an equally high Q value,
the server may either choose one from those available and respond
with 200 (ok) or respond with 300 (multiple choices) and include an
entity describing the choices. In the latter case, the entity
should either be of type "text/html', such that the user can choose
from among the choices by following an exact link, or of some type
that would allow the user agent to perform the selection
automatically.
The 300 (multiple choices) response can be given even if the server
does not perform any winnowing of the representation choices via
the content negotiation algorithm described above. Furthermore, it
may include choices that were not considered as part of the
negotiation algorithm and resources that may be located at other
servers.
Servers that make use of content negotiated resources are strongly
encouraged to include URI response headers which accurately
describe the available variants and include the relevant parameters
necessary for the client (user agent or proxy) to evaluate those
variants.
The algorithm presented above assumes that the user agent has
correctly implemented the protocol and is accurately communicating
its intentions in the form of Accept-related header fields. The
server may alter its response if it knows that the particular
version of user agent software making the request has incorrectly
or inadequately implemented these fields.
D.4 Language Tags
A language tag identifies a natural language spoken, written, or
otherwise conveyed by human beings for communication of information
to other human beings. Computer languages are explicitly excluded.
The HTTP/1.0 protocol uses language tags within the
Accept-Language, Content-Language, and URI-header fields.
The syntax and registry of HTTP language tags is the same as that
defined by RFC 1766 [1]. In summary, a language tag is composed of
1 or more parts: A primary language tag and a possibly empty series
of subtags:
language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA
Whitespace is not allowed within the tag and all tags are not case-
sensitive. The namespace of language tags is administered by the
IANA. Example tags include:
en, en-US, en-cockney, i-cherokee, x-pig-latin
where any two-letter primary-tag is an ISO 639 language
abbreviation and any two-letter initial subtag is an ISO 3166
country code.
In the context of the Accept-Language header (Section D.2.4), a
language tag is not to be interpreted as a single token, as per
RFC 1766, but as a hierarchy. A server should consider that it has a
match when a language tag received in an Accept-Language header
matches the initial portion of the language tag of a document. An
exact match should be preferred. This interpretation allows a
browser to send, for example:
Accept-Language: en-US, en; ql=0.95
when the intent is to access, in order of preference, documents in
US-English ("en-US"), 'plain' or 'international' English ("en"),
and any other variant of English (initial "en-").
Note: Using the language tag as a hierarchy does not imply
that all languages with a common prefix will be understood
by those fluent in one or more of those languages; it simply
allows the user to request this commonality when it is true
for that user.
D.5 Quality Values
HTTP content negotiation (Section D.3) uses short "floating point"
numbers to indicate the relative importance ("weight") of various
negotiable parameters. The calculated weights are normalized to a
real number in the range 0 through 1, where 0 is the minimum and 1
the maximum value. In order to discourage misuse of this feature,
HTTP/1.0 applications must not generate more than three digits
after the decimal point. User configuration of these values should
also be limited in this fashion.
qvalue = ( "0" [ "." 0*3DIGIT ] )
| ( "." 0*3DIGIT )
| ( "1" [ "." 0*3("0") ] )
"Quality values" is a slight misnomer, since these values actually
measure relative degradation in perceived quality. Thus, a value of
"0.8" represents a 20% degradation from the optimum rather than a
statement of 80% quality.
--============_-1392122978==_============--
Received on Tuesday, 26 December 1995 09:44:07 UTC