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.xml

    r987 r994  
    398398<t>
    399399   HTTP uses charset in two contexts: within an Accept-Charset request
    400    header (in which the charset value is an unquoted token) and as the
    401    value of a parameter in a Content-Type header (within a request or
     400   header field (in which the charset value is an unquoted token) and as the
     401   value of a parameter in a Content-Type header field (within a request or
    402402   response), in which case the parameter value of the charset parameter
    403403   can be quoted.
     
    410410<section title="Missing Charset" anchor="missing.charset">
    411411<t>
    412    Some HTTP/1.0 software has interpreted a Content-Type header without
     412   Some HTTP/1.0 software has interpreted a Content-Type header field without
    413413   charset parameter incorrectly to mean "recipient should guess".
    414414   Senders wishing to defeat this behavior &MAY; include a charset
     
    478478        The default (identity) encoding; the use of no transformation
    479479        whatsoever. This content-coding is used only in the Accept-Encoding
    480         header, and &SHOULD-NOT;  be used in the Content-Encoding
    481         header.
     480        header field, and &SHOULD-NOT;  be used in the Content-Encoding
     481        header field.
    482482  </t></list>
    483483</t>
     
    979979<t>
    980980   The "Accept" request-header field can be used by user agents to specify
    981    response media types that are acceptable. Accept headers can be used to
     981   response media types that are acceptable. Accept header fields can be used to
    982982   indicate that the request is specifically limited to a small set of desired
    983983   types, as in the case of a request for an in-line image.
     
    11331133</t>
    11341134<t>
    1135    If no Accept-Charset header is present, the default is that any
    1136    character set is acceptable. If an Accept-Charset header is present,
     1135   If no Accept-Charset header field is present, the default is that any
     1136   character set is acceptable. If an Accept-Charset header field is present,
    11371137   and if the server cannot send a response which is acceptable
    1138    according to the Accept-Charset header, then the server &SHOULD; send
     1138   according to the Accept-Charset header field, then the server &SHOULD; send
    11391139   an error response with the 406 (Not Acceptable) status code, though
    11401140   the sending of an unacceptable response is also allowed.
     
    12011201   If an Accept-Encoding field is present in a request, and if the
    12021202   server cannot send a response which is acceptable according to the
    1203    Accept-Encoding header, then the server &SHOULD; send an error response
     1203   Accept-Encoding header field, then the server &SHOULD; send an error response
    12041204   with the 406 (Not Acceptable) status code.
    12051205</t>
     
    12791279<t>
    12801280   It might be contrary to the privacy expectations of the user to send
    1281    an Accept-Language header with the complete linguistic preferences of
     1281   an Accept-Language header field with the complete linguistic preferences of
    12821282   the user in every request. For a discussion of this issue, see
    1283    <xref target="privacy.issues.connected.to.accept.headers"/>.
     1283   <xref target="privacy.issues.connected.to.accept.header.fields"/>.
    12841284</t>
    12851285<t>
     
    15411541   There are several consequences of this. The payload for composite
    15421542   types &MAY; contain many body-parts, each with its own MIME and HTTP
    1543    headers (including Content-MD5, Content-Transfer-Encoding, and
    1544    Content-Encoding headers). If a body-part has a Content-Transfer-Encoding
    1545    or Content-Encoding header, it is assumed that the content
     1543   header fields (including Content-MD5, Content-Transfer-Encoding, and
     1544   Content-Encoding header fields). If a body-part has a Content-Transfer-Encoding
     1545   or Content-Encoding header field, it is assumed that the content
    15461546   of the body-part has had the encoding applied, and the body-part is
    15471547   included in the Content-MD5 digest as is -- i.e., after the
     
    17301730</t>
    17311731
    1732 <section title="Privacy Issues Connected to Accept Headers" anchor="privacy.issues.connected.to.accept.headers">
    1733 <t>
    1734    Accept request-headers can reveal information about the user to all
    1735    servers which are accessed. The Accept-Language header in particular
     1732<section title="Privacy Issues Connected to Accept Header Fields" anchor="privacy.issues.connected.to.accept.header.fields">
     1733<t>
     1734   Accept request-headers fields can reveal information about the user to all
     1735   servers which are accessed. The Accept-Language header field in particular
    17361736   can reveal information the user would consider to be of a private
    17371737   nature, because the understanding of particular languages is often
    17381738   strongly correlated to the membership of a particular ethnic group.
    17391739   User agents which offer the option to configure the contents of an
    1740    Accept-Language header to be sent in every request are strongly
     1740   Accept-Language header field to be sent in every request are strongly
    17411741   encouraged to let the configuration process include a message which
    17421742   makes the user aware of the loss of privacy involved.
     
    17441744<t>
    17451745   An approach that limits the loss of privacy would be for a user agent
    1746    to omit the sending of Accept-Language headers by default, and to ask
    1747    the user whether or not to start sending Accept-Language headers to a
     1746   to omit the sending of Accept-Language header fields by default, and to ask
     1747   the user whether or not to start sending Accept-Language header fields to a
    17481748   server if it detects, by looking for any Vary response-header fields
    17491749   generated by the server, that such sending could improve the quality
     
    17621762   privacy, user agents ought to be conservative in offering accept
    17631763   header configuration options to end users. As an extreme privacy
    1764    measure, proxies could filter the accept headers in relayed requests.
     1764   measure, proxies could filter the accept header fields in relayed requests.
    17651765   General purpose user agents which provide a high degree of header
    17661766   configurability &SHOULD; warn users about the loss of privacy which can
     
    26472647</t>
    26482648<t>
    2649    A number of other headers, such as Content-Disposition and Title,
     2649   A number of other header fields, such as Content-Disposition and Title,
    26502650   from SMTP and MIME are also often implemented (see <xref target="RFC2076"/>).
    26512651</t>
     
    26602660  Remove base URI setting semantics for Content-Location due to poor
    26612661  implementation support, which was caused by too many broken servers emitting
    2662   bogus Content-Location headers, and also the potentially undesirable effect
     2662  bogus Content-Location header fields, and also the potentially undesirable effect
    26632663  of potentially breaking relative links in content-negotiated resources.
    26642664  (<xref target="header.content-location"/>)
     
    28552855</t>
    28562856<t>
    2857   Ongoing work on IANA Message Header Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>):
     2857  Ongoing work on IANA Message Header Field Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>):
    28582858  <list style="symbols">
    28592859    <t>
    2860       Reference RFC 3984, and update header registrations for headers defined
     2860      Reference RFC 3984, and update header field registrations for headers defined
    28612861      in this document.
    28622862    </t>
     
    29172917    <t>
    29182918      Rewrite ABNFs to spell out whitespace rules, factor out
    2919       header value format definitions.
     2919      header field value format definitions.
    29202920    </t>
    29212921  </list>
Note: See TracChangeset for help on using the changeset viewer.