Ignore:
Timestamp:
Sep 7, 2010, 4:46:12 AM (9 years ago)
Author:
julian.reschke@…
Message:

Uniform use of 'header field' (see #234)

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p3-payload.html

    r987 r994  
    402402      <meta name="dct.creator" content="Reschke, J. F.">
    403403      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest">
    404       <meta name="dct.issued" scheme="ISO8601" content="2010-09-03">
     404      <meta name="dct.issued" scheme="ISO8601" content="2010-09-07">
    405405      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    406406      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation.">
     
    428428            </tr>
    429429            <tr>
    430                <td class="left">Expires: March 7, 2011</td>
     430               <td class="left">Expires: March 11, 2011</td>
    431431               <td class="right">J. Mogul</td>
    432432            </tr>
     
    485485            <tr>
    486486               <td class="left"></td>
    487                <td class="right">September 3, 2010</td>
     487               <td class="right">September 7, 2010</td>
    488488            </tr>
    489489         </tbody>
     
    511511         in progress”.
    512512      </p>
    513       <p>This Internet-Draft will expire on March 7, 2011.</p>
     513      <p>This Internet-Draft will expire on March 11, 2011.</p>
    514514      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    515515      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    589589         </li>
    590590         <li class="tocline0">8.&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul class="toc">
    591                <li class="tocline1">8.1&nbsp;&nbsp;&nbsp;<a href="#privacy.issues.connected.to.accept.headers">Privacy Issues Connected to Accept Headers</a></li>
     591               <li class="tocline1">8.1&nbsp;&nbsp;&nbsp;<a href="#privacy.issues.connected.to.accept.header.fields">Privacy Issues Connected to Accept Header Fields</a></li>
    592592            </ul>
    593593         </li>
     
    706706         Character Set registry <em class="bcp14">MUST</em> represent the character set defined by that registry. Applications <em class="bcp14">SHOULD</em> limit their use of character sets to those defined by the IANA registry.
    707707      </p>
    708       <p id="rfc.section.2.1.p.7">HTTP uses charset in two contexts: within an Accept-Charset request header (in which the charset value is an unquoted token)
    709          and as the value of a parameter in a Content-Type header (within a request or response), in which case the parameter value
    710          of the charset parameter can be quoted.
     708      <p id="rfc.section.2.1.p.7">HTTP uses charset in two contexts: within an Accept-Charset request header field (in which the charset value is an unquoted
     709         token) and as the value of a parameter in a Content-Type header field (within a request or response), in which case the parameter
     710         value of the charset parameter can be quoted.
    711711      </p>
    712712      <p id="rfc.section.2.1.p.8">Implementors need to be aware of IETF character set requirements <a href="#RFC3629" id="rfc.xref.RFC3629.1"><cite title="UTF-8, a transformation format of ISO 10646">[RFC3629]</cite></a>  <a href="#RFC2277" id="rfc.xref.RFC2277.1"><cite title="IETF Policy on Character Sets and Languages">[RFC2277]</cite></a>.
    713713      </p>
    714714      <h3 id="rfc.section.2.1.1"><a href="#rfc.section.2.1.1">2.1.1</a>&nbsp;<a id="missing.charset" href="#missing.charset">Missing Charset</a></h3>
    715       <p id="rfc.section.2.1.1.p.1">Some HTTP/1.0 software has interpreted a Content-Type header without charset parameter incorrectly to mean "recipient should
    716          guess". Senders wishing to defeat this behavior <em class="bcp14">MAY</em> include a charset parameter even when the charset is ISO-8859-1 (<a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a>) and <em class="bcp14">SHOULD</em> do so when it is known that it will not confuse the recipient.
     715      <p id="rfc.section.2.1.1.p.1">Some HTTP/1.0 software has interpreted a Content-Type header field without charset parameter incorrectly to mean "recipient
     716         should guess". Senders wishing to defeat this behavior <em class="bcp14">MAY</em> include a charset parameter even when the charset is ISO-8859-1 (<a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a>) and <em class="bcp14">SHOULD</em> do so when it is known that it will not confuse the recipient.
    717717      </p>
    718718      <p id="rfc.section.2.1.1.p.2">Unfortunately, some older HTTP/1.0 clients did not deal properly with an explicit charset parameter. HTTP/1.1 recipients <em class="bcp14">MUST</em> respect the charset label provided by the sender; and those user agents that have a provision to "guess" a charset <em class="bcp14">MUST</em> use the charset from the content-type field if they support that charset, rather than the recipient's preference, when initially
     
    751751      <ul class="empty">
    752752         <li>The default (identity) encoding; the use of no transformation whatsoever. This content-coding is used only in the Accept-Encoding
    753             header, and <em class="bcp14">SHOULD NOT</em> be used in the Content-Encoding header.
     753            header field, and <em class="bcp14">SHOULD NOT</em> be used in the Content-Encoding header field.
    754754         </li>
    755755      </ul>
     
    996996      <div id="rfc.iref.h.1"></div>
    997997      <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="header.accept" href="#header.accept">Accept</a></h2>
    998       <p id="rfc.section.6.1.p.1">The "Accept" request-header field can be used by user agents to specify response media types that are acceptable. Accept headers
    999          can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of a request
    1000          for an in-line image.
     998      <p id="rfc.section.6.1.p.1">The "Accept" request-header field can be used by user agents to specify response media types that are acceptable. Accept header
     999         fields can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of
     1000         a request for an in-line image.
    10011001      </p>
    10021002      <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span>  <a href="#header.accept" class="smpl">Accept</a>   = "Accept" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.accept" class="smpl">Accept-v</a>
     
    11151115         mentioned.
    11161116      </p>
    1117       <p id="rfc.section.6.2.p.6">If no Accept-Charset header is present, the default is that any character set is acceptable. If an Accept-Charset header is
    1118          present, and if the server cannot send a response which is acceptable according to the Accept-Charset header, then the server <em class="bcp14">SHOULD</em> send an error response with the 406 (Not Acceptable) status code, though the sending of an unacceptable response is also allowed.
     1117      <p id="rfc.section.6.2.p.6">If no Accept-Charset header field is present, the default is that any character set is acceptable. If an Accept-Charset header
     1118         field is present, and if the server cannot send a response which is acceptable according to the Accept-Charset header field,
     1119         then the server <em class="bcp14">SHOULD</em> send an error response with the 406 (Not Acceptable) status code, though the sending of an unacceptable response is also allowed.
    11191120      </p>
    11201121      <div id="rfc.iref.a.3"></div>
     
    11511152      </ol>
    11521153      <p id="rfc.section.6.3.p.7">If an Accept-Encoding field is present in a request, and if the server cannot send a response which is acceptable according
    1153          to the Accept-Encoding header, then the server <em class="bcp14">SHOULD</em> send an error response with the 406 (Not Acceptable) status code.
     1154         to the Accept-Encoding header field, then the server <em class="bcp14">SHOULD</em> send an error response with the 406 (Not Acceptable) status code.
    11541155      </p>
    11551156      <p id="rfc.section.6.3.p.8">If no Accept-Encoding field is present in a request, the server <em class="bcp14">MAY</em> assume that the client will accept any content coding. In this case, if "identity" is one of the available content-codings,
     
    11931194         </p>
    11941195      </div>
    1195       <p id="rfc.section.6.4.p.8">It might be contrary to the privacy expectations of the user to send an Accept-Language header with the complete linguistic
    1196          preferences of the user in every request. For a discussion of this issue, see <a href="#privacy.issues.connected.to.accept.headers" title="Privacy Issues Connected to Accept Headers">Section&nbsp;8.1</a>.
     1196      <p id="rfc.section.6.4.p.8">It might be contrary to the privacy expectations of the user to send an Accept-Language header field with the complete linguistic
     1197         preferences of the user in every request. For a discussion of this issue, see <a href="#privacy.issues.connected.to.accept.header.fields" title="Privacy Issues Connected to Accept Header Fields">Section&nbsp;8.1</a>.
    11971198      </p>
    11981199      <p id="rfc.section.6.4.p.9">As intelligibility is highly dependent on the individual user, it is recommended that client applications make the choice
     
    13191320         but this does not change how the digest is computed as defined in the preceding paragraph.
    13201321      </p>
    1321       <p id="rfc.section.6.8.p.6">There are several consequences of this. The payload for composite types <em class="bcp14">MAY</em> contain many body-parts, each with its own MIME and HTTP headers (including Content-MD5, Content-Transfer-Encoding, and Content-Encoding
    1322          headers). If a body-part has a Content-Transfer-Encoding or Content-Encoding header, it is assumed that the content of the
    1323          body-part has had the encoding applied, and the body-part is included in the Content-MD5 digest as is -- i.e., after the application.
    1324          The Transfer-Encoding header field is not allowed within body-parts.
     1322      <p id="rfc.section.6.8.p.6">There are several consequences of this. The payload for composite types <em class="bcp14">MAY</em> contain many body-parts, each with its own MIME and HTTP header fields (including Content-MD5, Content-Transfer-Encoding,
     1323         and Content-Encoding header fields). If a body-part has a Content-Transfer-Encoding or Content-Encoding header field, it is
     1324         assumed that the content of the body-part has had the encoding applied, and the body-part is included in the Content-MD5 digest
     1325         as is -- i.e., after the application. The Transfer-Encoding header field is not allowed within body-parts.
    13251326      </p>
    13261327      <p id="rfc.section.6.8.p.7">Conversion of all line breaks to CRLF <em class="bcp14">MUST NOT</em> be done before computing or checking the digest: the line break convention used in the text actually transmitted <em class="bcp14">MUST</em> be left unaltered when computing the digest.
     
    14871488         make some suggestions for reducing security risks.
    14881489      </p>
    1489       <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a id="privacy.issues.connected.to.accept.headers" href="#privacy.issues.connected.to.accept.headers">Privacy Issues Connected to Accept Headers</a></h2>
    1490       <p id="rfc.section.8.1.p.1">Accept request-headers can reveal information about the user to all servers which are accessed. The Accept-Language header
    1491          in particular can reveal information the user would consider to be of a private nature, because the understanding of particular
    1492          languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer the option
    1493          to configure the contents of an Accept-Language header to be sent in every request are strongly encouraged to let the configuration
    1494          process include a message which makes the user aware of the loss of privacy involved.
    1495       </p>
    1496       <p id="rfc.section.8.1.p.2">An approach that limits the loss of privacy would be for a user agent to omit the sending of Accept-Language headers by default,
    1497          and to ask the user whether or not to start sending Accept-Language headers to a server if it detects, by looking for any
    1498          Vary response-header fields generated by the server, that such sending could improve the quality of service.
     1490      <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a id="privacy.issues.connected.to.accept.header.fields" href="#privacy.issues.connected.to.accept.header.fields">Privacy Issues Connected to Accept Header Fields</a></h2>
     1491      <p id="rfc.section.8.1.p.1">Accept request-headers fields can reveal information about the user to all servers which are accessed. The Accept-Language
     1492         header field in particular can reveal information the user would consider to be of a private nature, because the understanding
     1493         of particular languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer
     1494         the option to configure the contents of an Accept-Language header field to be sent in every request are strongly encouraged
     1495         to let the configuration process include a message which makes the user aware of the loss of privacy involved.
     1496      </p>
     1497      <p id="rfc.section.8.1.p.2">An approach that limits the loss of privacy would be for a user agent to omit the sending of Accept-Language header fields
     1498         by default, and to ask the user whether or not to start sending Accept-Language header fields to a server if it detects, by
     1499         looking for any Vary response-header fields generated by the server, that such sending could improve the quality of service.
    14991500      </p>
    15001501      <p id="rfc.section.8.1.p.3">Elaborate user-customized accept header fields sent in every request, in particular if these include quality values, can be
     
    15041505         also serve as a long-lived user identifier. In environments where proxies are used to enhance privacy, user agents ought to
    15051506         be conservative in offering accept header configuration options to end users. As an extreme privacy measure, proxies could
    1506          filter the accept headers in relayed requests. General purpose user agents which provide a high degree of header configurability <em class="bcp14">SHOULD</em> warn users about the loss of privacy which can be involved.
     1507         filter the accept header fields in relayed requests. General purpose user agents which provide a high degree of header configurability <em class="bcp14">SHOULD</em> warn users about the loss of privacy which can be involved.
    15071508      </p>
    15081509      <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="ack" href="#ack">Acknowledgments</a></h1>
     
    17571758         experimental deployment found lacking that are now addressed in the base HTTP/1.1 specification.
    17581759      </p>
    1759       <p id="rfc.section.B.p.2">A number of other headers, such as Content-Disposition and Title, from SMTP and MIME are also often implemented (see <a href="#RFC2076" id="rfc.xref.RFC2076.1"><cite title="Common Internet Message Headers">[RFC2076]</cite></a>).
     1760      <p id="rfc.section.B.p.2">A number of other header fields, such as Content-Disposition and Title, from SMTP and MIME are also often implemented (see <a href="#RFC2076" id="rfc.xref.RFC2076.1"><cite title="Common Internet Message Headers">[RFC2076]</cite></a>).
    17601761      </p>
    17611762      <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h1>
     
    17631764      </p>
    17641765      <p id="rfc.section.C.p.2">Remove base URI setting semantics for Content-Location due to poor implementation support, which was caused by too many broken
    1765          servers emitting bogus Content-Location headers, and also the potentially undesirable effect of potentially breaking relative
    1766          links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.3" title="Content-Location">Section&nbsp;6.7</a>)
     1766         servers emitting bogus Content-Location header fields, and also the potentially undesirable effect of potentially breaking
     1767         relative links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.3" title="Content-Location">Section&nbsp;6.7</a>)
    17671768      </p>
    17681769      <p id="rfc.section.C.p.3">Remove reference to non-existant identity transfer-coding value tokens. (<a href="#no.content-transfer-encoding" title="No Content-Transfer-Encoding">Appendix&nbsp;A.5</a>)
     
    19011902         </li>
    19021903      </ul>
    1903       <p id="rfc.section.E.4.p.2">Ongoing work on IANA Message Header Registration (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>&gt;):
     1904      <p id="rfc.section.E.4.p.2">Ongoing work on IANA Message Header Field Registration (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>&gt;):
    19041905      </p>
    19051906      <ul>
    1906          <li>Reference RFC 3984, and update header registrations for headers defined in this document.</li>
     1907         <li>Reference RFC 3984, and update header field registrations for headers defined in this document.</li>
    19071908      </ul>
    19081909      <h2 id="rfc.section.E.5"><a href="#rfc.section.E.5">E.5</a>&nbsp;<a id="changes.since.03" href="#changes.since.03">Since draft-ietf-httpbis-p3-payload-03</a></h2>
     
    19321933         <li>Use "/" instead of "|" for alternatives.</li>
    19331934         <li>Introduce new ABNF rules for "bad" whitespace ("BWS"), optional whitespace ("OWS") and required whitespace ("RWS").</li>
    1934          <li>Rewrite ABNFs to spell out whitespace rules, factor out header value format definitions.</li>
     1935         <li>Rewrite ABNFs to spell out whitespace rules, factor out header field value format definitions.</li>
    19351936      </ul>
    19361937      <h2 id="rfc.section.E.7"><a href="#rfc.section.E.7">E.7</a>&nbsp;<a id="changes.since.05" href="#changes.since.05">Since draft-ietf-httpbis-p3-payload-05</a></h2>
Note: See TracChangeset for help on using the changeset viewer.