Ignore:
Timestamp:
Sep 25, 2009, 7:43:16 AM (10 years ago)
Author:
julian.reschke@…
Message:

editorial: rephrase header introductions ("the *-header field 'foobar'" -> "the "foobar" *-header field")

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r696 r697  
    18131813      <div id="rfc.iref.h.6"></div>
    18141814      <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a>&nbsp;<a id="header.connection" href="#header.connection">Connection</a></h2>
    1815       <p id="rfc.section.9.1.p.1">The general-header field "Connection" allows the sender to specify options that are desired for that particular connection
     1815      <p id="rfc.section.9.1.p.1">The "Connection" general-header field allows the sender to specify options that are desired for that particular connection
    18161816         and <em class="bcp14">MUST NOT</em> be communicated by proxies over further connections.
    18171817      </p>
     
    18431843      <div id="rfc.iref.h.7"></div>
    18441844      <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a>&nbsp;<a id="header.content-length" href="#header.content-length">Content-Length</a></h2>
    1845       <p id="rfc.section.9.2.p.1">The entity-header field "Content-Length" indicates the size of the entity-body, in number of OCTETs, sent to the recipient
     1845      <p id="rfc.section.9.2.p.1">The "Content-Length" entity-header field indicates the size of the entity-body, in number of OCTETs, sent to the recipient
    18461846         or, in the case of the HEAD method, the size of the entity-body that would have been sent had the request been a GET.
    18471847      </p>
     
    18611861      <div id="rfc.iref.h.8"></div>
    18621862      <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a>&nbsp;<a id="header.date" href="#header.date">Date</a></h2>
    1863       <p id="rfc.section.9.3.p.1">The general-header field "Date" represents the date and time at which the message was originated, having the same semantics
     1863      <p id="rfc.section.9.3.p.1">The "Date" general-header field represents the date and time at which the message was originated, having the same semantics
    18641864         as orig-date in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as described in <a href="#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section&nbsp;6.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.
    18651865      </p>
     
    18981898      <div id="rfc.iref.h.10"></div>
    18991899      <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a>&nbsp;<a id="header.host" href="#header.host">Host</a></h2>
    1900       <p id="rfc.section.9.4.p.1">The request-header field "Host" specifies the Internet host and port number of the resource being requested, as obtained from
     1900      <p id="rfc.section.9.4.p.1">The "Host" request-header field specifies the Internet host and port number of the resource being requested, as obtained from
    19011901         the original URI given by the user or referring resource (generally an http URI, as described in <a href="#http.uri" title="http URI scheme">Section&nbsp;2.6.1</a>). The Host field value <em class="bcp14">MUST</em> represent the naming authority of the origin server or gateway given by the original URL. This allows the origin server or
    19021902         gateway to differentiate between internally-ambiguous URLs, such as the root "/" URL of a server for multiple host names on
     
    19191919      <div id="rfc.iref.h.11"></div>
    19201920      <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a>&nbsp;<a id="header.te" href="#header.te">TE</a></h2>
    1921       <p id="rfc.section.9.5.p.1">The request-header field "TE" indicates what extension transfer-codings it is willing to accept in the response and whether
     1921      <p id="rfc.section.9.5.p.1">The "TE" request-header field indicates what extension transfer-codings it is willing to accept in the response and whether
    19221922         or not it is willing to accept trailer fields in a chunked transfer-coding. Its value may consist of the keyword "trailers"
    19231923         and/or a comma-separated list of extension transfer-coding names with optional accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>).
     
    19661966      <div id="rfc.iref.h.12"></div>
    19671967      <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a>&nbsp;<a id="header.trailer" href="#header.trailer">Trailer</a></h2>
    1968       <p id="rfc.section.9.6.p.1">The general field "Trailer" indicates that the given set of header fields is present in the trailer of a message encoded with
    1969          chunked transfer-coding.
     1968      <p id="rfc.section.9.6.p.1">The "Trailer" general-header field indicates that the given set of header fields is present in the trailer of a message encoded
     1969         with chunked transfer-coding.
    19701970      </p>
    19711971      <div id="rfc.figure.u.62"></div><pre class="inline"><span id="rfc.iref.g.103"></span><span id="rfc.iref.g.104"></span>  <a href="#header.trailer" class="smpl">Trailer</a>   = "Trailer" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.trailer" class="smpl">Trailer-v</a>
     
    19861986      <div id="rfc.iref.h.13"></div>
    19871987      <h2 id="rfc.section.9.7"><a href="#rfc.section.9.7">9.7</a>&nbsp;<a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h2>
    1988       <p id="rfc.section.9.7.p.1">The general-header "Transfer-Encoding" field indicates what (if any) type of transformation has been applied to the message
     1988      <p id="rfc.section.9.7.p.1">The "Transfer-Encoding" general-header field indicates what (if any) type of transformation has been applied to the message
    19891989         body in order to safely transfer it between the sender and the recipient. This differs from the content-coding in that the
    19901990         transfer-coding is a property of the message, not of the entity.
     
    20022002      <div id="rfc.iref.h.14"></div>
    20032003      <h2 id="rfc.section.9.8"><a href="#rfc.section.9.8">9.8</a>&nbsp;<a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2>
    2004       <p id="rfc.section.9.8.p.1">The general-header "Upgrade" allows the client to specify what additional communication protocols it supports and would like
    2005          to use if the server finds it appropriate to switch protocols. The server <em class="bcp14">MUST</em> use the Upgrade header field within a 101 (Switching Protocols) response to indicate which protocol(s) are being switched.
     2004      <p id="rfc.section.9.8.p.1">The "Upgrade" general-header field allows the client to specify what additional communication protocols it supports and would
     2005         like to use if the server finds it appropriate to switch protocols. The server <em class="bcp14">MUST</em> use the Upgrade header field within a 101 (Switching Protocols) response to indicate which protocol(s) are being switched.
    20062006      </p>
    20072007      <div id="rfc.figure.u.65"></div><pre class="inline"><span id="rfc.iref.g.107"></span><span id="rfc.iref.g.108"></span>  <a href="#header.upgrade" class="smpl">Upgrade</a>   = "Upgrade" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.upgrade" class="smpl">Upgrade-v</a>
     
    20572057      <div id="rfc.iref.h.15"></div>
    20582058      <h2 id="rfc.section.9.9"><a href="#rfc.section.9.9">9.9</a>&nbsp;<a id="header.via" href="#header.via">Via</a></h2>
    2059       <p id="rfc.section.9.9.p.1">The general-header field "Via" <em class="bcp14">MUST</em> be used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server
     2059      <p id="rfc.section.9.9.p.1">The "Via" general-header field <em class="bcp14">MUST</em> be used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server
    20602060         on requests, and between the origin server and the client on responses. It is analogous to the "Received" field defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.7">Section 3.6.7</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.5"><cite title="Internet Message Format">[RFC5322]</cite></a> and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities
    20612061         of all senders along the request/response chain.
Note: See TracChangeset for help on using the changeset viewer.