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")

Location:
draft-ietf-httpbis/latest
Files:
14 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.
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r696 r697  
    24902490  <x:anchor-alias value="Connection-v"/>
    24912491<t>
    2492    The general-header field "Connection" allows the sender to specify
     2492   The "Connection" general-header field allows the sender to specify
    24932493   options that are desired for that particular connection and &MUST-NOT;
    24942494   be communicated by proxies over further connections.
     
    25532553  <x:anchor-alias value="Content-Length-v"/>
    25542554<t>
    2555    The entity-header field "Content-Length" indicates the size of the
     2555   The "Content-Length" entity-header field indicates the size of the
    25562556   entity-body, in number of OCTETs, sent to the recipient or,
    25572557   in the case of the HEAD method, the size of the entity-body that
     
    25932593  <x:anchor-alias value="Date-v"/>
    25942594<t>
    2595    The general-header field "Date" represents the date and time at which
     2595   The "Date" general-header field represents the date and time at which
    25962596   the message was originated, having the same semantics as orig-date in
    25972597   <xref target="RFC5322" x:fmt="of" x:sec="3.6.1"/>. The field value is an
     
    26732673  <x:anchor-alias value="Host-v"/>
    26742674<t>
    2675    The request-header field "Host" specifies the Internet host and port
     2675   The "Host" request-header field specifies the Internet host and port
    26762676   number of the resource being requested, as obtained from the original
    26772677   URI given by the user or referring resource (generally an http URI,
     
    27232723  <x:anchor-alias value="te-ext"/>
    27242724<t>
    2725    The request-header field "TE" indicates what extension transfer-codings
     2725   The "TE" request-header field indicates what extension transfer-codings
    27262726   it is willing to accept in the response and whether or not it is
    27272727   willing to accept trailer fields in a chunked transfer-coding. Its
     
    28022802  <x:anchor-alias value="Trailer-v"/>
    28032803<t>
    2804    The general field "Trailer" indicates that the given set of
     2804   The "Trailer" general-header field indicates that the given set of
    28052805   header fields is present in the trailer of a message encoded with
    28062806   chunked transfer-coding.
     
    28382838  <x:anchor-alias value="Transfer-Encoding-v"/>
    28392839<t>
    2840    The general-header "Transfer-Encoding" field indicates what (if any)
     2840   The "Transfer-Encoding" general-header field indicates what (if any)
    28412841   type of transformation has been applied to the message body in order
    28422842   to safely transfer it between the sender and the recipient. This
     
    28732873  <x:anchor-alias value="Upgrade-v"/>
    28742874<t>
    2875    The general-header "Upgrade" allows the client to specify what
     2875   The "Upgrade" general-header field allows the client to specify what
    28762876   additional communication protocols it supports and would like to use
    28772877   if the server finds it appropriate to switch protocols. The server
     
    29822982  <x:anchor-alias value="Via-v"/>
    29832983<t>
    2984    The general-header field "Via" &MUST; be used by gateways and proxies to
     2984   The "Via" general-header field &MUST; be used by gateways and proxies to
    29852985   indicate the intermediate protocols and recipients between the user
    29862986   agent and the server on requests, and between the origin server and
  • 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
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r695 r697  
    18681868  <x:anchor-alias value="Allow-v"/>
    18691869<t>
    1870       The response-header field "Allow" lists the set of methods advertised as
    1871       supported by the resource identified by the request-target. The purpose of
    1872       this field is strictly to inform the recipient of valid methods
    1873       associated with the resource. An Allow header field &MUST; be
    1874       present in a 405 (Method Not Allowed) response.
     1870   The "Allow" response-header field lists the set of methods advertised as
     1871   supported by the resource identified by the request-target. The purpose of
     1872   this field is strictly to inform the recipient of valid methods
     1873   associated with the resource. An Allow header field &MUST; be
     1874   present in a 405 (Method Not Allowed) response.
    18751875</t>
    18761876<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Allow"/><iref primary="true" item="Grammar" subitem="Allow-v"/>
     
    19041904  <x:anchor-alias value="expect-params"/>
    19051905<t>
    1906    The request-header field "Expect" is used to indicate that particular
     1906   The "Expect" request-header field is used to indicate that particular
    19071907   server behaviors are required by the client.
    19081908</t>
     
    19581958  <x:anchor-alias value="mailbox"/>
    19591959<t>
    1960    The request-header field "From", if given, &SHOULD; contain an Internet
     1960   The "From" request-header field, if given, &SHOULD; contain an Internet
    19611961   e-mail address for the human user who controls the requesting user
    19621962   agent. The address &SHOULD; be machine-usable, as defined by "mailbox"
     
    20062006  <x:anchor-alias value="Location-v"/>
    20072007<t>
    2008    The response-header field "Location" is used for the identification of a
     2008   The "Location" response-header field is used for the identification of a
    20092009   new resource or to redirect the recipient to a location other than the
    20102010   request-target for completion of the request.  For 201 (Created)
     
    20482048  <x:anchor-alias value="Max-Forwards-v"/>
    20492049<t>
    2050    The request-header "Max-Forwards" field provides a mechanism with the
     2050   The "Max-Forwards" request-header field provides a mechanism with the
    20512051   TRACE (<xref target="TRACE"/>) and OPTIONS (<xref target="OPTIONS"/>) methods to limit the
    20522052   number of proxies or gateways that can forward the request to the
     
    20852085  <x:anchor-alias value="Referer-v"/>
    20862086<t>
    2087    The request-header field "Referer" [sic] allows the client to specify, for
     2087   The "Referer" [sic] request-header field allows the client to specify, for
    20882088   the server's benefit, the address (URI) of the resource from which the
    20892089   request-target was obtained (the "referrer", although the header field is
     
    21652165  <x:anchor-alias value="Server-v"/>
    21662166<t>
    2167    The response-header field "Server" contains information about the
     2167   The "Server" response-header field contains information about the
    21682168   software used by the origin server to handle the request. The field
    21692169   can contain multiple product tokens (&product-tokens;) and comments
     
    22052205  <x:anchor-alias value="User-Agent-v"/>
    22062206<t>
    2207    The request-header field "User-Agent" contains information about the
     2207   The "User-Agent" request-header field contains information about the
    22082208   user agent originating the request. This is for statistical purposes,
    22092209   the tracing of protocol violations, and automated recognition of user
  • draft-ietf-httpbis/latest/p3-payload.html

    r690 r697  
    407407      <meta name="DC.Creator" content="Reschke, J. F.">
    408408      <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest">
    409       <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-05">
     409      <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-25">
    410410      <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616">
    411411      <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 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.">
     
    439439         </tr>
    440440         <tr>
    441             <td class="header left">Expires: March 9, 2010</td>
     441            <td class="header left">Expires: March 29, 2010</td>
    442442            <td class="header right">HP</td>
    443443         </tr>
     
    492492         <tr>
    493493            <td class="header left"></td>
    494             <td class="header right">September 5, 2009</td>
     494            <td class="header right">September 25, 2009</td>
    495495         </tr>
    496496      </table>
     
    516516      <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;.
    517517      </p>
    518       <p>This Internet-Draft will expire in March 9, 2010.</p>
     518      <p>This Internet-Draft will expire in March 29, 2010.</p>
    519519      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    520520      <p>Copyright © 2009 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    10101010      <div id="rfc.iref.h.1"></div>
    10111011      <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a id="header.accept" href="#header.accept">Accept</a></h2>
    1012       <p id="rfc.section.5.1.p.1">The request-header field "Accept" can be used to specify certain media types which are acceptable for the response. Accept
     1012      <p id="rfc.section.5.1.p.1">The "Accept" request-header field can be used to specify certain media types which are acceptable for the response. Accept
    10131013         headers can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of
    10141014         a request for an in-line image.
     
    11121112      <div id="rfc.iref.h.2"></div>
    11131113      <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a id="header.accept-charset" href="#header.accept-charset">Accept-Charset</a></h2>
    1114       <p id="rfc.section.5.2.p.1">The request-header field "Accept-Charset" can be used to indicate what character sets are acceptable for the response. This
     1114      <p id="rfc.section.5.2.p.1">The "Accept-Charset" request-header field can be used to indicate what character sets are acceptable for the response. This
    11151115         field allows clients capable of understanding more comprehensive or special-purpose character sets to signal that capability
    11161116         to a server which is capable of representing documents in those character sets.
     
    11351135      <div id="rfc.iref.h.3"></div>
    11361136      <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a>&nbsp;<a id="header.accept-encoding" href="#header.accept-encoding">Accept-Encoding</a></h2>
    1137       <p id="rfc.section.5.3.p.1">The request-header field "Accept-Encoding" is similar to Accept, but restricts the content-codings (<a href="#content.codings" title="Content Codings">Section&nbsp;2.2</a>) that are acceptable in the response.
     1137      <p id="rfc.section.5.3.p.1">The "Accept-Encoding" request-header field is similar to Accept, but restricts the content-codings (<a href="#content.codings" title="Content Codings">Section&nbsp;2.2</a>) that are acceptable in the response.
    11381138      </p>
    11391139      <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span>  <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a>    = "Accept-Encoding" ":" <a href="#core.rules" class="smpl">OWS</a>
     
    11861186      <div id="rfc.iref.h.4"></div>
    11871187      <h2 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4</a>&nbsp;<a id="header.accept-language" href="#header.accept-language">Accept-Language</a></h2>
    1188       <p id="rfc.section.5.4.p.1">The request-header field "Accept-Language" is similar to Accept, but restricts the set of natural languages that are preferred
     1188      <p id="rfc.section.5.4.p.1">The "Accept-Language" request-header field is similar to Accept, but restricts the set of natural languages that are preferred
    11891189         as a response to the request. Language tags are defined in <a href="#language.tags" title="Language Tags">Section&nbsp;2.4</a>.
    11901190      </p>
     
    12371237      <div id="rfc.iref.h.5"></div>
    12381238      <h2 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5</a>&nbsp;<a id="header.content-encoding" href="#header.content-encoding">Content-Encoding</a></h2>
    1239       <p id="rfc.section.5.5.p.1">The entity-header field "Content-Encoding" is used as a modifier to the media-type. When present, its value indicates what
     1239      <p id="rfc.section.5.5.p.1">The "Content-Encoding" entity-header field is used as a modifier to the media-type. When present, its value indicates what
    12401240         additional content codings have been applied to the entity-body, and thus what decoding mechanisms must be applied in order
    12411241         to obtain the media-type referenced by the Content-Type header field. Content-Encoding is primarily used to allow a document
     
    12601260      <div id="rfc.iref.h.6"></div>
    12611261      <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a>&nbsp;<a id="header.content-language" href="#header.content-language">Content-Language</a></h2>
    1262       <p id="rfc.section.5.6.p.1">The entity-header field "Content-Language" describes the natural language(s) of the intended audience for the enclosed entity.
     1262      <p id="rfc.section.5.6.p.1">The "Content-Language" entity-header field describes the natural language(s) of the intended audience for the enclosed entity.
    12631263         Note that this might not be equivalent to all the languages used within the entity-body.
    12641264      </p>
     
    12861286      <div id="rfc.iref.h.7"></div>
    12871287      <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a>&nbsp;<a id="header.content-location" href="#header.content-location">Content-Location</a></h2>
    1288       <p id="rfc.section.5.7.p.1">The entity-header field "Content-Location" <em class="bcp14">MAY</em> be used to supply the resource location for the entity enclosed in the message when that entity is accessible from a location
     1288      <p id="rfc.section.5.7.p.1">The "Content-Location" entity-header field <em class="bcp14">MAY</em> be used to supply the resource location for the entity enclosed in the message when that entity is accessible from a location
    12891289         separate from the requested resource's URI. A server <em class="bcp14">SHOULD</em> provide a Content-Location for the variant corresponding to the response entity; especially in the case where a resource has
    12901290         multiple entities associated with it, and those entities actually have separate locations by which they might be individually
     
    13081308      <div id="rfc.iref.h.8"></div>
    13091309      <h2 id="rfc.section.5.8"><a href="#rfc.section.5.8">5.8</a>&nbsp;<a id="header.content-md5" href="#header.content-md5">Content-MD5</a></h2>
    1310       <p id="rfc.section.5.8.p.1">The entity-header field "Content-MD5", as defined in <a href="#RFC1864" id="rfc.xref.RFC1864.1"><cite title="The Content-MD5 Header Field">[RFC1864]</cite></a>, is an MD5 digest of the entity-body for the purpose of providing an end-to-end message integrity check (MIC) of the entity-body.
     1310      <p id="rfc.section.5.8.p.1">The "Content-MD5" entity-header field, as defined in <a href="#RFC1864" id="rfc.xref.RFC1864.1"><cite title="The Content-MD5 Header Field">[RFC1864]</cite></a>, is an MD5 digest of the entity-body for the purpose of providing an end-to-end message integrity check (MIC) of the entity-body.
    13111311         (Note: a MIC is good for detecting accidental modification of the entity-body in transit, but is not proof against malicious
    13121312         attacks.)
     
    13461346      <div id="rfc.iref.h.9"></div>
    13471347      <h2 id="rfc.section.5.9"><a href="#rfc.section.5.9">5.9</a>&nbsp;<a id="header.content-type" href="#header.content-type">Content-Type</a></h2>
    1348       <p id="rfc.section.5.9.p.1">The entity-header field "Content-Type" indicates the media type of the entity-body sent to the recipient or, in the case of
     1348      <p id="rfc.section.5.9.p.1">The "Content-Type" entity-header field indicates the media type of the entity-body sent to the recipient or, in the case of
    13491349         the HEAD method, the media type that would have been sent had the request been a GET.
    13501350      </p>
     
    17761776      <div id="rfc.iref.c.12"></div>
    17771777      <h2 id="rfc.section.B.1"><a href="#rfc.section.B.1">B.1</a>&nbsp;<a id="content-disposition" href="#content-disposition">Content-Disposition</a></h2>
    1778       <p id="rfc.section.B.1.p.1">The Content-Disposition response-header field has been proposed as a means for the origin server to suggest a default filename
     1778      <p id="rfc.section.B.1.p.1">The "Content-Disposition" response-header field has been proposed as a means for the origin server to suggest a default filename
    17791779         if the user requests that the content is saved to a file. This usage is derived from the definition of Content-Disposition
    17801780         in <a href="#RFC2183" id="rfc.xref.RFC2183.3"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>.
  • draft-ietf-httpbis/latest/p3-payload.xml

    r690 r697  
    983983  <x:anchor-alias value="media-range"/>
    984984<t>
    985    The request-header field "Accept" can be used to specify certain media
     985   The "Accept" request-header field can be used to specify certain media
    986986   types which are acceptable for the response. Accept headers can be
    987987   used to indicate that the request is specifically limited to a small
     
    11101110  <x:anchor-alias value="Accept-Charset-v"/>
    11111111<t>
    1112    The request-header field "Accept-Charset" can be used to indicate what
     1112   The "Accept-Charset" request-header field can be used to indicate what
    11131113   character sets are acceptable for the response. This field allows
    11141114   clients capable of understanding more comprehensive or special-purpose
     
    11551155  <x:anchor-alias value="codings"/>
    11561156<t>
    1157    The request-header field "Accept-Encoding" is similar to Accept, but
     1157   The "Accept-Encoding" request-header field is similar to Accept, but
    11581158   restricts the content-codings (<xref target="content.codings"/>) that are acceptable in
    11591159   the response.
     
    12451245  <x:anchor-alias value="language-range"/>
    12461246<t>
    1247    The request-header field "Accept-Language" is similar to Accept, but
     1247   The "Accept-Language" request-header field is similar to Accept, but
    12481248   restricts the set of natural languages that are preferred as a
    12491249   response to the request. Language tags are defined in <xref target="language.tags"/>.
     
    13411341  <x:anchor-alias value="Content-Encoding-v"/>
    13421342<t>
    1343    The entity-header field "Content-Encoding" is used as a modifier to the
     1343   The "Content-Encoding" entity-header field is used as a modifier to the
    13441344   media-type. When present, its value indicates what additional content
    13451345   codings have been applied to the entity-body, and thus what decoding
     
    13911391  <x:anchor-alias value="Content-Language-v"/>
    13921392<t>
    1393    The entity-header field "Content-Language" describes the natural
     1393   The "Content-Language" entity-header field describes the natural
    13941394   language(s) of the intended audience for the enclosed entity. Note
    13951395   that this might not be equivalent to all the languages used within
     
    14451445  <x:anchor-alias value="Content-Location-v"/>
    14461446<t>
    1447    The entity-header field "Content-Location" &MAY; be used to supply the
     1447   The "Content-Location" entity-header field &MAY; be used to supply the
    14481448   resource location for the entity enclosed in the message when that
    14491449   entity is accessible from a location separate from the requested
     
    14961496  <x:anchor-alias value="Content-MD5-v"/>
    14971497<t>
    1498    The entity-header field "Content-MD5", as defined in <xref target="RFC1864"/>, is
     1498   The "Content-MD5" entity-header field, as defined in <xref target="RFC1864"/>, is
    14991499   an MD5 digest of the entity-body for the purpose of providing an
    15001500   end-to-end message integrity check (MIC) of the entity-body. (Note: a
     
    15731573  <x:anchor-alias value="Content-Type-v"/>
    15741574<t>
    1575    The entity-header field "Content-Type" indicates the media type of the
     1575   The "Content-Type" entity-header field indicates the media type of the
    15761576   entity-body sent to the recipient or, in the case of the HEAD method,
    15771577   the media type that would have been sent had the request been a GET.
     
    26752675  <x:anchor-alias value="filename-parm"/>
    26762676<t>
    2677    The Content-Disposition response-header field has been proposed as a
     2677   The "Content-Disposition" response-header field has been proposed as a
    26782678   means for the origin server to suggest a default filename if the user
    26792679   requests that the content is saved to a file. This usage is derived
  • draft-ietf-httpbis/latest/p4-conditional.html

    r689 r697  
    396396      <meta name="DC.Creator" content="Reschke, J. F.">
    397397      <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
    398       <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-01">
     398      <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-25">
    399399      <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616">
    400400      <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 4 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests.">
     
    428428         </tr>
    429429         <tr>
    430             <td class="header left">Expires: March 5, 2010</td>
     430            <td class="header left">Expires: March 29, 2010</td>
    431431            <td class="header right">HP</td>
    432432         </tr>
     
    481481         <tr>
    482482            <td class="header left"></td>
    483             <td class="header right">September 1, 2009</td>
     483            <td class="header right">September 25, 2009</td>
    484484         </tr>
    485485      </table>
     
    505505      <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;.
    506506      </p>
    507       <p>This Internet-Draft will expire in March 5, 2010.</p>
     507      <p>This Internet-Draft will expire in March 29, 2010.</p>
    508508      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    509509      <p>Copyright © 2009 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    858858      <div id="rfc.iref.h.1"></div>
    859859      <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="header.etag" href="#header.etag">ETag</a></h2>
    860       <p id="rfc.section.6.1.p.1">The response-header field "ETag" provides the current value of the entity tag (see <a href="#entity.tags" title="Entity Tags">Section&nbsp;2</a>) for the requested variant. The headers used with entity tags are described in Sections <a href="#header.if-match" id="rfc.xref.header.if-match.2" title="If-Match">6.2</a> and <a href="#header.if-none-match" id="rfc.xref.header.if-none-match.2" title="If-None-Match">6.4</a> of this document, and in <a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.4"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. The entity tag <em class="bcp14">MAY</em> be used for comparison with other entities from the same resource (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section&nbsp;4</a>).
     860      <p id="rfc.section.6.1.p.1">The "ETag" response-header field provides the current value of the entity tag (see <a href="#entity.tags" title="Entity Tags">Section&nbsp;2</a>) for the requested variant. The headers used with entity tags are described in Sections <a href="#header.if-match" id="rfc.xref.header.if-match.2" title="If-Match">6.2</a> and <a href="#header.if-none-match" id="rfc.xref.header.if-none-match.2" title="If-None-Match">6.4</a> of this document, and in <a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.4"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. The entity tag <em class="bcp14">MAY</em> be used for comparison with other entities from the same resource (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section&nbsp;4</a>).
    861861      </p>
    862862      <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span>  <a href="#header.etag" class="smpl">ETag</a>   = "ETag" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.etag" class="smpl">ETag-v</a>
     
    879879      <div id="rfc.iref.h.2"></div>
    880880      <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a id="header.if-match" href="#header.if-match">If-Match</a></h2>
    881       <p id="rfc.section.6.2.p.1">The request-header field "If-Match" is used with a method to make it conditional. A client that has one or more entities previously
     881      <p id="rfc.section.6.2.p.1">The "If-Match" request-header field is used with a method to make it conditional. A client that has one or more entities previously
    882882         obtained from the resource can verify that one of those entities is current by including a list of their associated entity
    883883         tags in the If-Match header field. Entity tags are defined in <a href="#entity.tags" title="Entity Tags">Section&nbsp;2</a>. The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead.
     
    912912      <div id="rfc.iref.h.3"></div>
    913913      <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;<a id="header.if-modified-since" href="#header.if-modified-since">If-Modified-Since</a></h2>
    914       <p id="rfc.section.6.3.p.1">The request-header field "If-Modified-Since" is used with a method to make it conditional: if the requested variant has not
     914      <p id="rfc.section.6.3.p.1">The "If-Modified-Since" request-header field is used with a method to make it conditional: if the requested variant has not
    915915         been modified since the time specified in this field, an entity will not be returned from the server; instead, a 304 (Not
    916916         Modified) response will be returned without any message-body.
     
    959959      <div id="rfc.iref.h.4"></div>
    960960      <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<a id="header.if-none-match" href="#header.if-none-match">If-None-Match</a></h2>
    961       <p id="rfc.section.6.4.p.1">The request-header field "If-None-Match" is used with a method to make it conditional. A client that has one or more entities
     961      <p id="rfc.section.6.4.p.1">The "If-None-Match" request-header field is used with a method to make it conditional. A client that has one or more entities
    962962         previously obtained from the resource can verify that none of those entities is current by including a list of their associated
    963963         entity tags in the If-None-Match header field. The purpose of this feature is to allow efficient updates of cached information
     
    993993      <div id="rfc.iref.h.5"></div>
    994994      <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a>&nbsp;<a id="header.if-unmodified-since" href="#header.if-unmodified-since">If-Unmodified-Since</a></h2>
    995       <p id="rfc.section.6.5.p.1">The request-header field "If-Unmodified-Since" is used with a method to make it conditional. If the requested resource has
     995      <p id="rfc.section.6.5.p.1">The "If-Unmodified-Since" request-header field is used with a method to make it conditional. If the requested resource has
    996996         not been modified since the time specified in this field, the server <em class="bcp14">SHOULD</em> perform the requested operation as if the If-Unmodified-Since header were not present.
    997997      </p>
     
    10131013      <div id="rfc.iref.h.6"></div>
    10141014      <h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a>&nbsp;<a id="header.last-modified" href="#header.last-modified">Last-Modified</a></h2>
    1015       <p id="rfc.section.6.6.p.1">The entity-header field "Last-Modified" indicates the date and time at which the origin server believes the variant was last
     1015      <p id="rfc.section.6.6.p.1">The "Last-Modified" entity-header field indicates the date and time at which the origin server believes the variant was last
    10161016         modified.
    10171017      </p>
  • draft-ietf-httpbis/latest/p4-conditional.xml

    r689 r697  
    688688  <x:anchor-alias value="ETag-v"/>
    689689<t>
    690    The response-header field "ETag" provides the current value of the
     690   The "ETag" response-header field provides the current value of the
    691691   entity tag (see <xref target="entity.tags"/>) for the requested variant.
    692692   The headers used with entity
     
    734734  <x:anchor-alias value="If-Match-v"/>
    735735<t>
    736    The request-header field "If-Match" is used with a method to make it
     736   The "If-Match" request-header field is used with a method to make it
    737737   conditional. A client that has one or more entities previously
    738738   obtained from the resource can verify that one of those entities is
     
    803803  <x:anchor-alias value="If-Modified-Since-v"/>
    804804<t>
    805    The request-header field "If-Modified-Since" is used with a method to
     805   The "If-Modified-Since" request-header field is used with a method to
    806806   make it conditional: if the requested variant has not been modified
    807807   since the time specified in this field, an entity will not be
     
    888888  <x:anchor-alias value="If-None-Match-v"/>
    889889<t>
    890    The request-header field "If-None-Match" is used with a method to make
     890   The "If-None-Match" request-header field is used with a method to make
    891891   it conditional. A client that has one or more entities previously
    892892   obtained from the resource can verify that none of those entities is
     
    965965  <x:anchor-alias value="If-Unmodified-Since-v"/>
    966966<t>
    967    The request-header field "If-Unmodified-Since" is used with a method to
     967   The "If-Unmodified-Since" request-header field is used with a method to
    968968   make it conditional. If the requested resource has not been modified
    969969   since the time specified in this field, the server &SHOULD; perform the
     
    10081008  <x:anchor-alias value="Last-Modified-v"/>
    10091009<t>
    1010    The entity-header field "Last-Modified" indicates the date and time at
     1010   The "Last-Modified" entity-header field indicates the date and time at
    10111011   which the origin server believes the variant was last modified.
    10121012</t>
  • draft-ietf-httpbis/latest/p5-range.html

    r689 r697  
    396396      <meta name="DC.Creator" content="Reschke, J. F.">
    397397      <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
    398       <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-01">
     398      <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-25">
    399399      <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616">
    400400      <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 5 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests.">
     
    428428         </tr>
    429429         <tr>
    430             <td class="header left">Expires: March 5, 2010</td>
     430            <td class="header left">Expires: March 29, 2010</td>
    431431            <td class="header right">HP</td>
    432432         </tr>
     
    481481         <tr>
    482482            <td class="header left"></td>
    483             <td class="header right">September 1, 2009</td>
     483            <td class="header right">September 25, 2009</td>
    484484         </tr>
    485485      </table>
     
    505505      <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;.
    506506      </p>
    507       <p>This Internet-Draft will expire in March 5, 2010.</p>
     507      <p>This Internet-Draft will expire in March 29, 2010.</p>
    508508      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    509509      <p>Copyright © 2009 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    694694      <div id="rfc.iref.h.1"></div>
    695695      <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a id="header.accept-ranges" href="#header.accept-ranges">Accept-Ranges</a></h2>
    696       <p id="rfc.section.5.1.p.1">The response-header "Accept-Ranges" field allows the server to indicate its acceptance of range requests for a resource:</p>
     696      <p id="rfc.section.5.1.p.1">The "Accept-Ranges" response-header field allows the server to indicate its acceptance of range requests for a resource:</p>
    697697      <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span>  <a href="#header.accept-ranges" class="smpl">Accept-Ranges</a>     = "Accept-Ranges" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.accept-ranges" class="smpl">Accept-Ranges-v</a>
    698698  <a href="#header.accept-ranges" class="smpl">Accept-Ranges-v</a>   = <a href="#header.accept-ranges" class="smpl">acceptable-ranges</a>
     
    710710      <div id="rfc.iref.h.2"></div>
    711711      <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a id="header.content-range" href="#header.content-range">Content-Range</a></h2>
    712       <p id="rfc.section.5.2.p.1">The entity-header "Content-Range" is sent with a partial entity-body to specify where in the full entity-body the partial
     712      <p id="rfc.section.5.2.p.1">The "Content-Range" entity-header field is sent with a partial entity-body to specify where in the full entity-body the partial
    713713         body should be applied. Range units are defined in <a href="#range.units" title="Range Units">Section&nbsp;2</a>.
    714714      </p>
     
    794794         to obtain the entire current entity-body.
    795795      </p>
    796       <p id="rfc.section.5.3.p.2">The request header "If-Range" allows a client to "short-circuit" the second request. Informally, its meaning is `if the entity
    797          is unchanged, send me the part(s) that I am missing; otherwise, send me the entire new entity'.
     796      <p id="rfc.section.5.3.p.2">The "If-Range" request-header field allows a client to "short-circuit" the second request. Informally, its meaning is `if
     797         the entity is unchanged, send me the part(s) that I am missing; otherwise, send me the entire new entity'.
    798798      </p>
    799799      <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span>  <a href="#header.if-range" class="smpl">If-Range</a>   = "If-Range" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.if-range" class="smpl">If-Range-v</a>
  • draft-ietf-httpbis/latest/p5-range.xml

    r689 r697  
    458458  <x:anchor-alias value="acceptable-ranges"/>
    459459<t>
    460       The response-header "Accept-Ranges" field allows the server to
    461       indicate its acceptance of range requests for a resource:
     460   The "Accept-Ranges" response-header field allows the server to
     461   indicate its acceptance of range requests for a resource:
    462462</t>
    463463<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Ranges"/><iref primary="true" item="Grammar" subitem="Accept-Ranges-v"/><iref primary="true" item="Grammar" subitem="acceptable-ranges"/>
     
    501501  <x:anchor-alias value="other-range-resp-spec"/>
    502502<t>
    503    The entity-header "Content-Range" is sent with a partial entity-body to
     503   The "Content-Range" entity-header field is sent with a partial entity-body to
    504504   specify where in the full entity-body the partial body should be
    505505   applied. Range units are defined in <xref target="range.units"/>.
     
    655655</t>
    656656<t>
    657    The request header "If-Range" allows a client to "short-circuit" the second
     657   The "If-Range" request-header field allows a client to "short-circuit" the second
    658658   request. Informally, its meaning is `if the entity is unchanged, send
    659659   me the part(s) that I am missing; otherwise, send me the entire new
  • draft-ietf-httpbis/latest/p6-cache.html

    r694 r697  
    398398      <meta name="DC.Creator" content="Reschke, J. F.">
    399399      <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    400       <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-16">
     400      <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-25">
    401401      <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616">
    402402      <meta name="DC.Description.Abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document is Part 6 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
     
    430430         </tr>
    431431         <tr>
    432             <td class="header left">Expires: March 20, 2010</td>
     432            <td class="header left">Expires: March 29, 2010</td>
    433433            <td class="header right">HP</td>
    434434         </tr>
     
    487487         <tr>
    488488            <td class="header left"></td>
    489             <td class="header right">September 16, 2009</td>
     489            <td class="header right">September 25, 2009</td>
    490490         </tr>
    491491      </table>
     
    511511      <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;.
    512512      </p>
    513       <p>This Internet-Draft will expire in March 20, 2010.</p>
     513      <p>This Internet-Draft will expire in March 29, 2010.</p>
    514514      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    515515      <p>Copyright © 2009 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    974974      <div id="rfc.iref.h.2"></div>
    975975      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="header.age" href="#header.age">Age</a></h2>
    976       <p id="rfc.section.3.1.p.1">The response-header field "Age" conveys the sender's estimate of the amount of time since the response (or its validation)
     976      <p id="rfc.section.3.1.p.1">The "Age" response-header field conveys the sender's estimate of the amount of time since the response (or its validation)
    977977         was generated at the origin server. Age values are calculated as specified in <a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>.
    978978      </p>
     
    992992      <div id="rfc.iref.h.3"></div>
    993993      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="header.cache-control" href="#header.cache-control">Cache-Control</a></h2>
    994       <p id="rfc.section.3.2.p.1">The general-header field "Cache-Control" is used to specify directives that <em class="bcp14">MUST</em> be obeyed by all caches along the request/response chain. The directives specify behavior intended to prevent caches from
     994      <p id="rfc.section.3.2.p.1">The "Cache-Control" general-header field is used to specify directives that <em class="bcp14">MUST</em> be obeyed by all caches along the request/response chain. The directives specify behavior intended to prevent caches from
    995995         adversely interfering with the request or response. Cache directives are unidirectional in that the presence of a directive
    996996         in a request does not imply that the same directive is to be given in the response.
     
    11951195      <div id="rfc.iref.h.4"></div>
    11961196      <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="header.expires" href="#header.expires">Expires</a></h2>
    1197       <p id="rfc.section.3.3.p.1">The entity-header field "Expires" gives the date/time after which the response is considered stale. See <a href="#expiration.model" title="Freshness Model">Section&nbsp;2.3</a> for further discussion of the freshness model.
     1197      <p id="rfc.section.3.3.p.1">The "Expires" entity-header field gives the date/time after which the response is considered stale. See <a href="#expiration.model" title="Freshness Model">Section&nbsp;2.3</a> for further discussion of the freshness model.
    11981198      </p>
    11991199      <p id="rfc.section.3.3.p.2">The presence of an Expires field does not imply that the original resource will change or cease to exist at, before, or after
     
    12171217      <div id="rfc.iref.h.5"></div>
    12181218      <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="header.pragma" href="#header.pragma">Pragma</a></h2>
    1219       <p id="rfc.section.3.4.p.1">The general-header field "Pragma" is used to include implementation-specific directives that might apply to any recipient
     1219      <p id="rfc.section.3.4.p.1">The "Pragma" general-header field is used to include implementation-specific directives that might apply to any recipient
    12201220         along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however,
    12211221         some systems <em class="bcp14">MAY</em> require that behavior be consistent with the directives.
     
    12611261      <div id="rfc.iref.h.7"></div>
    12621262      <h2 id="rfc.section.3.6"><a href="#rfc.section.3.6">3.6</a>&nbsp;<a id="header.warning" href="#header.warning">Warning</a></h2>
    1263       <p id="rfc.section.3.6.p.1">The general-header field "Warning" is used to carry additional information about the status or transformation of a message
     1263      <p id="rfc.section.3.6.p.1">The "Warning" general-header field is used to carry additional information about the status or transformation of a message
    12641264         that might not be reflected in the message. This information is typically used to warn about possible incorrectness introduced
    12651265         by caching operations or transformations applied to the entity body of the message.
  • draft-ietf-httpbis/latest/p6-cache.xml

    r694 r697  
    2929  <!ENTITY header-via                  "<xref target='Part1' x:rel='#header.via' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3030  <!ENTITY header-last-modified        "<xref target='Part4' x:rel='#header.last-modified' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    31   <!ENTITY header-fields             "<xref target='Part1' x:rel='#header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     31  <!ENTITY header-fields               "<xref target='Part1' x:rel='#header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3232  <!ENTITY message-length              "<xref target='Part1' x:rel='#message.length' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3333  <!ENTITY safe-methods                "<xref target='Part2' x:rel='#safe.methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     
    895895  <x:anchor-alias value="age-value"/>
    896896<t>
    897   The response-header field "Age" conveys the sender's estimate of the amount of time since
     897  The "Age" response-header field conveys the sender's estimate of the amount of time since
    898898  the response (or its validation) was generated at the origin server. Age values are
    899899  calculated as specified in <xref target="age.calculations" />.
     
    933933  <x:anchor-alias value="cache-response-directive"/>
    934934<t>
    935   The general-header field "Cache-Control" is used to specify directives that &MUST; be
     935  The "Cache-Control" general-header field is used to specify directives that &MUST; be
    936936  obeyed by all caches along the request/response chain. The directives specify behavior
    937937  intended to prevent caches from adversely interfering with the request or response. Cache
     
    12491249  <x:anchor-alias value="Expires-v"/>
    12501250<t>
    1251   The entity-header field "Expires" gives the date/time after which the response is
     1251  The "Expires" entity-header field gives the date/time after which the response is
    12521252  considered stale. See <xref target="expiration.model" /> for further discussion of the
    12531253  freshness model.
     
    12941294  <x:anchor-alias value="pragma-directive"/>
    12951295<t>
    1296   The general-header field "Pragma" is used to include implementation-specific directives
     1296  The "Pragma" general-header field is used to include implementation-specific directives
    12971297  that might apply to any recipient along the request/response chain. All pragma directives
    12981298  specify optional behavior from the viewpoint of the protocol; however, some systems
     
    13821382  <x:anchor-alias value="warn-text"/>
    13831383<t>
    1384   The general-header field "Warning" is used to carry additional information about the status
     1384  The "Warning" general-header field is used to carry additional information about the status
    13851385  or transformation of a message that might not be reflected in the message. This
    13861386  information is typically used to warn about possible incorrectness introduced by caching
  • draft-ietf-httpbis/latest/p7-auth.html

    r689 r697  
    390390      <meta name="DC.Creator" content="Reschke, J. F.">
    391391      <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
    392       <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-01">
     392      <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-25">
    393393      <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616">
    394394      <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 7 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 7 defines HTTP Authentication.">
     
    427427         </tr>
    428428         <tr>
    429             <td class="header left">Expires: March 5, 2010</td>
     429            <td class="header left">Expires: March 29, 2010</td>
    430430            <td class="header right">H. Frystyk</td>
    431431         </tr>
     
    476476         <tr>
    477477            <td class="header left"></td>
    478             <td class="header right">September 1, 2009</td>
     478            <td class="header right">September 25, 2009</td>
    479479         </tr>
    480480      </table>
     
    500500      <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;.
    501501      </p>
    502       <p>This Internet-Draft will expire in March 5, 2010.</p>
     502      <p>This Internet-Draft will expire in March 29, 2010.</p>
    503503      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    504504      <p>Copyright © 2009 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    628628      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="header.authorization" href="#header.authorization">Authorization</a></h2>
    629629      <p id="rfc.section.3.1.p.1">A user agent that wishes to authenticate itself with a server-- usually, but not necessarily, after receiving a 401 response--does
    630          so by including an Authorization request-header field with the request. The field "Authorization" consists of credentials
    631          containing the authentication information of the user agent for the realm of the resource being requested.
     630         so by including an "Authorization" request-header field with the request. The field value consists of credentials containing
     631         the authentication information of the user agent for the realm of the resource being requested.
    632632      </p>
    633633      <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.3"></span><span id="rfc.iref.g.4"></span>  <a href="#header.authorization" class="smpl">Authorization</a>   = "Authorization" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.authorization" class="smpl">Authorization-v</a>
     
    652652      <div id="rfc.iref.h.2"></div>
    653653      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="header.proxy-authenticate" href="#header.proxy-authenticate">Proxy-Authenticate</a></h2>
    654       <p id="rfc.section.3.2.p.1">The response-header field "Proxy-Authenticate" <em class="bcp14">MUST</em> be included as part of a 407 (Proxy Authentication Required) response. The field value consists of a challenge that indicates
     654      <p id="rfc.section.3.2.p.1">The "Proxy-Authenticate" response-header field <em class="bcp14">MUST</em> be included as part of a 407 (Proxy Authentication Required) response. The field value consists of a challenge that indicates
    655655         the authentication scheme and parameters applicable to the proxy for this request-target.
    656656      </p>
     
    665665      <div id="rfc.iref.h.3"></div>
    666666      <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="header.proxy-authorization" href="#header.proxy-authorization">Proxy-Authorization</a></h2>
    667       <p id="rfc.section.3.3.p.1">The request-header field "Proxy-Authorization" allows the client to identify itself (or its user) to a proxy which requires
     667      <p id="rfc.section.3.3.p.1">The "Proxy-Authorization" request-header field allows the client to identify itself (or its user) to a proxy which requires
    668668         authentication. The Proxy-Authorization field value consists of credentials containing the authentication information of the
    669669         user agent for the proxy and/or realm of the resource being requested.
     
    680680      <div id="rfc.iref.h.4"></div>
    681681      <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="header.www-authenticate" href="#header.www-authenticate">WWW-Authenticate</a></h2>
    682       <p id="rfc.section.3.4.p.1">The WWW-Authenticate response-header field <em class="bcp14">MUST</em> be included in 401 (Unauthorized) response messages. The field value consists of at least one challenge that indicates the
     682      <p id="rfc.section.3.4.p.1">The "WWW-Authenticate" response-header field <em class="bcp14">MUST</em> be included in 401 (Unauthorized) response messages. The field value consists of at least one challenge that indicates the
    683683         authentication scheme(s) and parameters applicable to the request-target.
    684684      </p>
  • draft-ietf-httpbis/latest/p7-auth.xml

    r689 r697  
    342342  <x:anchor-alias value="Authorization-v"/>
    343343<t>
    344       A user agent that wishes to authenticate itself with a server--
    345       usually, but not necessarily, after receiving a 401 response--does
    346       so by including an Authorization request-header field with the
    347       request.  The field "Authorization" consists of credentials
    348       containing the authentication information of the user agent for
    349       the realm of the resource being requested.
     344   A user agent that wishes to authenticate itself with a server--
     345   usually, but not necessarily, after receiving a 401 response--does
     346   so by including an "Authorization" request-header field with the
     347   request.  The field value consists of credentials
     348   containing the authentication information of the user agent for
     349   the realm of the resource being requested.
    350350</t>
    351351<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Authorization"/><iref primary="true" item="Grammar" subitem="Authorization-v"/>
     
    399399  <x:anchor-alias value="Proxy-Authenticate-v"/>
    400400<t>
    401    The response-header field "Proxy-Authenticate" &MUST; be included as part
     401   The "Proxy-Authenticate" response-header field &MUST; be included as part
    402402   of a 407 (Proxy Authentication Required) response. The field value
    403403   consists of a challenge that indicates the authentication scheme and
     
    427427  <x:anchor-alias value="Proxy-Authorization-v"/>
    428428<t>
    429    The request-header field "Proxy-Authorization" allows the client to
     429   The "Proxy-Authorization" request-header field allows the client to
    430430   identify itself (or its user) to a proxy which requires
    431431   authentication. The Proxy-Authorization field value consists of
     
    458458  <x:anchor-alias value="WWW-Authenticate-v"/>
    459459<t>
    460    The WWW-Authenticate response-header field &MUST; be included in 401
     460   The "WWW-Authenticate" response-header field &MUST; be included in 401
    461461   (Unauthorized) response messages. The field value consists of at
    462462   least one challenge that indicates the authentication scheme(s) and
Note: See TracChangeset for help on using the changeset viewer.