W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1995

Moving HTTP 1.0 to informational

From: Paul Hoffman <paulh@imc.org>
Date: Tue, 26 Dec 1995 09:38:38 -0800
Message-Id: <v02140403ad05e276a498@[165.227.10.43]>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
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 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:38 EDT