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/p2-semantics.html

    r695 r697  
    399399      <meta name="DC.Creator" content="Reschke, J. F.">
    400400      <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    401       <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-16">
     401      <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-25">
    402402      <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616">
    403403      <meta name="DC.Description.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 2 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request-header fields, response status codes, and response-header fields.">
     
    436436         </tr>
    437437         <tr>
    438             <td class="header left">Expires: March 20, 2010</td>
     438            <td class="header left">Expires: March 29, 2010</td>
    439439            <td class="header right">H. Frystyk</td>
    440440         </tr>
     
    485485         <tr>
    486486            <td class="header left"></td>
    487             <td class="header right">September 16, 2009</td>
     487            <td class="header right">September 25, 2009</td>
    488488         </tr>
    489489      </table>
     
    509509      <p>The list of Internet-Draft Shadow Directories can be accessed at &lt;<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>&gt;.
    510510      </p>
    511       <p>This Internet-Draft will expire in March 20, 2010.</p>
     511      <p>This Internet-Draft will expire in March 29, 2010.</p>
    512512      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    513513      <p>Copyright © 2009 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    15031503      <div id="rfc.iref.h.2"></div>
    15041504      <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a>&nbsp;<a id="header.allow" href="#header.allow">Allow</a></h2>
    1505       <p id="rfc.section.9.1.p.1">The response-header field "Allow" lists the set of methods advertised as supported by the resource identified by the request-target.
     1505      <p id="rfc.section.9.1.p.1">The "Allow" response-header field lists the set of methods advertised as supported by the resource identified by the request-target.
    15061506         The purpose of this field is strictly to inform the recipient of valid methods associated with the resource. An Allow header
    15071507         field <em class="bcp14">MUST</em> be present in a 405 (Method Not Allowed) response.
     
    15181518      <div id="rfc.iref.h.3"></div>
    15191519      <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a>&nbsp;<a id="header.expect" href="#header.expect">Expect</a></h2>
    1520       <p id="rfc.section.9.2.p.1">The request-header field "Expect" is used to indicate that particular server behaviors are required by the client.</p>
     1520      <p id="rfc.section.9.2.p.1">The "Expect" request-header field is used to indicate that particular server behaviors are required by the client.</p>
    15211521      <div id="rfc.figure.u.14"></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.expect" class="smpl">Expect</a>       = "Expect" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.expect" class="smpl">Expect-v</a>
    15221522  <a href="#header.expect" class="smpl">Expect-v</a>     = 1#<a href="#header.expect" class="smpl">expectation</a>
     
    15441544      <div id="rfc.iref.h.4"></div>
    15451545      <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a>&nbsp;<a id="header.from" href="#header.from">From</a></h2>
    1546       <p id="rfc.section.9.3.p.1">The request-header field "From", if given, <em class="bcp14">SHOULD</em> contain an Internet e-mail address for the human user who controls the requesting user agent. The address <em class="bcp14">SHOULD</em> be machine-usable, as defined by "mailbox" in <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>:
     1546      <p id="rfc.section.9.3.p.1">The "From" request-header field, if given, <em class="bcp14">SHOULD</em> contain an Internet e-mail address for the human user who controls the requesting user agent. The address <em class="bcp14">SHOULD</em> be machine-usable, as defined by "mailbox" in <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>:
    15471547      </p>
    15481548      <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span>  <a href="#header.from" class="smpl">From</a>    = "From" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.from" class="smpl">From-v</a>
     
    15661566      <div id="rfc.iref.h.5"></div>
    15671567      <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a>&nbsp;<a id="header.location" href="#header.location">Location</a></h2>
    1568       <p id="rfc.section.9.4.p.1">The response-header field "Location" is used for the identification of a new resource or to redirect the recipient to a location
     1568      <p id="rfc.section.9.4.p.1">The "Location" response-header field is used for the identification of a new resource or to redirect the recipient to a location
    15691569         other than the request-target for completion of the request. For 201 (Created) responses, the Location is that of the new
    15701570         resource which was created by the request. For 3xx responses, the location <em class="bcp14">SHOULD</em> indicate the server's preferred URI for automatic redirection to the resource. The field value consists of a single URI.
     
    15871587      <div id="rfc.iref.h.6"></div>
    15881588      <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a>&nbsp;<a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h2>
    1589       <p id="rfc.section.9.5.p.1">The request-header "Max-Forwards" field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section&nbsp;7.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section&nbsp;7.2</a>) methods to limit the number of proxies or gateways that can forward the request to the next inbound server. This can be
     1589      <p id="rfc.section.9.5.p.1">The "Max-Forwards" request-header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section&nbsp;7.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section&nbsp;7.2</a>) methods to limit the number of proxies or gateways that can forward the request to the next inbound server. This can be
    15901590         useful when the client is attempting to trace a request chain which appears to be failing or looping in mid-chain.
    15911591      </p>
     
    16011601      <div id="rfc.iref.h.7"></div>
    16021602      <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a>&nbsp;<a id="header.referer" href="#header.referer">Referer</a></h2>
    1603       <p id="rfc.section.9.6.p.1">The request-header field "Referer" [sic] allows the client to specify, for the server's benefit, the address (URI) of the
     1603      <p id="rfc.section.9.6.p.1">The "Referer" [sic] request-header field allows the client to specify, for the server's benefit, the address (URI) of the
    16041604         resource from which the request-target was obtained (the "referrer", although the header field is misspelled.).
    16051605      </p>
     
    16401640      <div id="rfc.iref.h.9"></div>
    16411641      <h2 id="rfc.section.9.8"><a href="#rfc.section.9.8">9.8</a>&nbsp;<a id="header.server" href="#header.server">Server</a></h2>
    1642       <p id="rfc.section.9.8.p.1">The response-header field "Server" contains information about the software used by the origin server to handle the request.
     1642      <p id="rfc.section.9.8.p.1">The "Server" response-header field contains information about the software used by the origin server to handle the request.
    16431643         The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance
    16441644         for identifying the application.
     
    16601660      <div id="rfc.iref.h.10"></div>
    16611661      <h2 id="rfc.section.9.9"><a href="#rfc.section.9.9">9.9</a>&nbsp;<a id="header.user-agent" href="#header.user-agent">User-Agent</a></h2>
    1662       <p id="rfc.section.9.9.p.1">The request-header field "User-Agent" contains information about the user agent originating the request. This is for statistical
     1662      <p id="rfc.section.9.9.p.1">The "User-Agent" request-header field contains information about the user agent originating the request. This is for statistical
    16631663         purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses
    16641664         to avoid particular user agent limitations. User agents <em class="bcp14">SHOULD</em> include this field with requests. The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments identifying the agent and any subproducts which form a significant part of the user agent. By convention, the
Note: See TracChangeset for help on using the changeset viewer.