Ignore:
Timestamp:
Jan 26, 2012, 6:54:04 AM (8 years ago)
Author:
julian.reschke@…
Message:

spelling & grammar

Location:
draft-ietf-httpbis/latest
Files:
10 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.html

    r1511 r1514  
    358358  }
    359359  @bottom-center {
    360        content: "Expires July 28, 2012";
     360       content: "Expires July 29, 2012";
    361361  }
    362362  @bottom-right {
    … …  
    408408      <meta name="dct.creator" content="Reschke, J. F.">
    409409      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    410       <meta name="dct.issued" scheme="ISO8601" content="2012-01-25">
     410      <meta name="dct.issued" scheme="ISO8601" content="2012-01-26">
    411411      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    412412      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    … …  
    440440            </tr>
    441441            <tr>
    442                <td class="left">Expires: July 28, 2012</td>
     442               <td class="left">Expires: July 29, 2012</td>
    443443               <td class="right">HP</td>
    444444            </tr>
    … …  
    493493            <tr>
    494494               <td class="left"></td>
    495                <td class="right">January 25, 2012</td>
     495               <td class="right">January 26, 2012</td>
    496496            </tr>
    497497         </tbody>
    … …  
    526526         in progress”.
    527527      </p>
    528       <p>This Internet-Draft will expire on July 28, 2012.</p>
     528      <p>This Internet-Draft will expire on July 29, 2012.</p>
    529529      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    530530      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    10531053         by a proxy <em class="bcp14">MUST</em> be forwarded downstream unless the header field's field-name is listed in the message's Connection header-field (see <a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section&nbsp;8.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of all compliant intermediaries.
    10541054      </p>
    1055       <p id="rfc.section.2.6.p.8">Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as a tunnel) <em class="bcp14">MUST</em> send their own HTTP-Version in forwarded messages. In other words, they <em class="bcp14">MUST NOT</em> blindly forward the first line of an HTTP message without ensuring that the protocol version matches what the intermediary
     1055      <p id="rfc.section.2.6.p.8">Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as tunnels) <em class="bcp14">MUST</em> send their own HTTP-Version in forwarded messages. In other words, they <em class="bcp14">MUST NOT</em> blindly forward the first line of an HTTP message without ensuring that the protocol version matches what the intermediary
    10561056         understands, and is at least conditionally compliant to, for both the receiving and sending of messages. Forwarding an HTTP
    10571057         message without rewriting the HTTP-Version might result in communication errors when downstream recipients use the message
    … …  
    19641964            request includes a request body, and the server responds with a final status code before reading the entire request body from
    19651965            the transport connection, then the server <em class="bcp14">SHOULD NOT</em> close the transport connection until it has read the entire request, or until the client closes the connection. Otherwise,
    1966             the client might not reliably receive the response message. However, this requirement is not be construed as preventing a
    1967             server from defending itself against denial-of-service attacks, or from badly broken client implementations.
     1966            the client might not reliably receive the response message. However, this requirement ought not be construed as preventing
     1967            a server from defending itself against denial-of-service attacks, or from badly broken client implementations.
    19681968         </li>
    19691969      </ul>
    … …  
    21382138      <div id="rfc.iref.h.10"></div>
    21392139      <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a>&nbsp;<a id="header.te" href="#header.te">TE</a></h2>
    2140       <p id="rfc.section.8.4.p.1">The "TE" header field indicates what extension transfer-codings it is willing to accept in the response, and whether or not
    2141          it is willing to accept trailer fields in a chunked transfer-coding.
     2140      <p id="rfc.section.8.4.p.1">The "TE" header field indicates what extension transfer-codings the client is willing to accept in the response, and whether
     2141         or not it is willing to accept trailer fields in a chunked transfer-coding.
    21422142      </p>
    21432143      <p id="rfc.section.8.4.p.2">Its value consists of the keyword "trailers" and/or a comma-separated list of extension transfer-coding names with optional
    … …  
    21802180         </li>
    21812181      </ol>
    2182       <p id="rfc.section.8.4.p.9">If the TE field-value is empty or if no TE field is present, the only transfer-coding is "chunked". A message with no transfer-coding
    2183          is always acceptable.
     2182      <p id="rfc.section.8.4.p.9">If the TE field-value is empty or if no TE field is present, the only acceptable transfer-coding is "chunked". A message with
     2183         no transfer-coding is always acceptable.
    21842184      </p>
    21852185      <div id="rfc.iref.t.6"></div>
    … …  
    22252225</pre><p id="rfc.section.8.7.p.3">For example,</p>
    22262226      <div id="rfc.figure.u.60"></div><pre class="text">  Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
    2227 </pre><p id="rfc.section.8.7.p.5">The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other, incompatible
     2227</pre><p id="rfc.section.8.7.p.5">The Upgrade header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other, incompatible
    22282228         protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP
    22292229         with a higher major version number, even though the current request has been made using HTTP/1.1. This eases the difficult
    … …  
    26482648         configuration options they provide to proxy operators (especially the default configuration).
    26492649      </p>
    2650       <p id="rfc.section.10.5.p.4">Users of a proxy need to be aware that proxies are no trustworthier than the people who run them; HTTP itself cannot solve
     2650      <p id="rfc.section.10.5.p.4">Users of a proxy need to be aware that proxies are no more trustworthy than the people who run them; HTTP itself cannot solve
    26512651         this problem.
    26522652      </p>
    … …  
    29182918         designed, however, to make supporting previous versions easy. We would expect a general-purpose HTTP/1.1 server to understand
    29192919         any valid request in the format of HTTP/1.0 and respond appropriately with an HTTP/1.1 message that only uses features understood
    2920          (or safely ignored) by HTTP/1.0 clients. Likewise, would expect an HTTP/1.1 client to understand any valid HTTP/1.0 response.
     2920         (or safely ignored) by HTTP/1.0 clients. Likewise, we would expect an HTTP/1.1 client to understand any valid HTTP/1.0 response.
    29212921      </p>
    29222922      <p id="rfc.section.A.p.4">Since HTTP/0.9 did not support header fields in a request, there is no mechanism for it to support name-based virtual hosts

  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1511 r1514  
    896896<t>
    897897   Intermediaries that process HTTP messages (i.e., all intermediaries
    898    other than those acting as a tunnel) &MUST; send their own HTTP-Version
     898   other than those acting as tunnels) &MUST; send their own HTTP-Version
    899899   in forwarded messages.  In other words, they &MUST-NOT; blindly
    900900   forward the first line of an HTTP message without ensuring that the
    … …  
    27942794        or until the client closes the connection. Otherwise, the client
    27952795        might not reliably receive the response message. However, this
    2796         requirement is not be construed as preventing a server from
     2796        requirement ought not be construed as preventing a server from
    27972797        defending itself against denial-of-service attacks, or from
    27982798        badly broken client implementations.
    … …  
    30893089<t>
    30903090   The "TE" header field indicates what extension transfer-codings
    3091    it is willing to accept in the response, and whether or not it is
     3091   the client is willing to accept in the response, and whether or not it is
    30923092   willing to accept trailer fields in a chunked transfer-coding.
    30933093</t>
    … …  
    31573157<t>
    31583158   If the TE field-value is empty or if no TE field is present, the only
    3159    transfer-coding is "chunked". A message with no transfer-coding is
     3159   acceptable transfer-coding is "chunked". A message with no transfer-coding is
    31603160   always acceptable.
    31613161</t>
    … …  
    32493249<t>
    32503250   The Upgrade header field is intended to provide a simple mechanism
    3251    for transition from HTTP/1.1 to some other, incompatible protocol. It
     3251   for transitioning from HTTP/1.1 to some other, incompatible protocol. It
    32523252   does so by allowing the client to advertise its desire to use another
    32533253   protocol, such as a later version of HTTP with a higher major version
    … …  
    38383838</t>
    38393839<t>
    3840    Users of a proxy need to be aware that proxies are no trustworthier than
     3840   Users of a proxy need to be aware that proxies are no more trustworthy than
    38413841   the people who run them; HTTP itself cannot solve this problem.
    38423842</t>
    … …  
    48594859   any valid request in the format of HTTP/1.0 and respond appropriately
    48604860   with an HTTP/1.1 message that only uses features understood (or
    4861    safely ignored) by HTTP/1.0 clients.  Likewise, would expect
     4861   safely ignored) by HTTP/1.0 clients.  Likewise, we would expect
    48624862   an HTTP/1.1 client to understand any valid HTTP/1.0 response.
    48634863</t>

  • draft-ietf-httpbis/latest/p2-semantics.html

    r1512 r1514  
    358358  }
    359359  @bottom-center {
    360        content: "Expires July 28, 2012";
     360       content: "Expires July 29, 2012";
    361361  }
    362362  @bottom-right {
    … …  
    410410      <meta name="dct.creator" content="Reschke, J. F.">
    411411      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    412       <meta name="dct.issued" scheme="ISO8601" content="2012-01-25">
     412      <meta name="dct.issued" scheme="ISO8601" content="2012-01-26">
    413413      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    414414      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext 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.">
    … …  
    441441            </tr>
    442442            <tr>
    443                <td class="left">Expires: July 28, 2012</td>
     443               <td class="left">Expires: July 29, 2012</td>
    444444               <td class="right">HP</td>
    445445            </tr>
    … …  
    494494            <tr>
    495495               <td class="left"></td>
    496                <td class="right">January 25, 2012</td>
     496               <td class="right">January 26, 2012</td>
    497497            </tr>
    498498         </tbody>
    … …  
    524524         in progress”.
    525525      </p>
    526       <p>This Internet-Draft will expire on July 28, 2012.</p>
     526      <p>This Internet-Draft will expire on July 29, 2012.</p>
    527527      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    528528      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    22282228      </p>
    22292229      <p id="rfc.section.9.2.p.7">Clients can use the Date header field as well; in order to keep request messages small, they are advised not to include it
    2230          when it doesn't convey any useful information (as it is usually the case for requests that do not contain a payload).
     2230         when it doesn't convey any useful information (as is usually the case for requests that do not contain a payload).
    22312231      </p>
    22322232      <p id="rfc.section.9.2.p.8">The HTTP-date sent in a Date header field <em class="bcp14">SHOULD NOT</em> represent a date and time subsequent to the generation of the message. It <em class="bcp14">SHOULD</em> represent the best available approximation of the date and time of message generation, unless the implementation has no means
    … …  
    23212321      <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a>&nbsp;<a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h2>
    23222322      <p id="rfc.section.9.6.p.1">The "Max-Forwards" header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section&nbsp;6.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section&nbsp;6.2</a>) methods to limit the number of times that the request is forwarded by proxies. This can be useful when the client is attempting
    2323          to trace a request which appears to be failing or looping in mid-chain.
     2323         to trace a request which appears to be failing or looping mid-chain.
    23242324      </p>
    23252325      <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.31"></span>  <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*<a href="#notation" class="smpl">DIGIT</a>
    … …  
    23522352      <h2 id="rfc.section.9.8"><a href="#rfc.section.9.8">9.8</a>&nbsp;<a id="header.retry-after" href="#header.retry-after">Retry-After</a></h2>
    23532353      <p id="rfc.section.9.8.p.1">The header "Retry-After" field can be used with a 503 (Service Unavailable) response to indicate how long the service is expected
    2354          to be unavailable to the requesting client. This field <em class="bcp14">MAY</em> also be used with any 3xx (Redirection) response to indicate the minimum time the user-agent is asked wait before issuing
     2354         to be unavailable to the requesting client. This field <em class="bcp14">MAY</em> also be used with any 3xx (Redirection) response to indicate the minimum time the user-agent is asked to wait before issuing
    23552355         the redirected request.
    23562356      </p>
    … …  
    28312831         of From and Referer information.
    28322832      </p>
    2833       <p id="rfc.section.11.1.p.7">The User-Agent (<a href="#header.user-agent" id="rfc.xref.header.user-agent.3" title="User-Agent">Section&nbsp;9.10</a>) or Server (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section&nbsp;9.9</a>) header fields can sometimes be used to determine that a specific client or server have a particular security hole which
    2834          might be exploited. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently
    2835          has no better mechanism.
     2833      <p id="rfc.section.11.1.p.7">The User-Agent (<a href="#header.user-agent" id="rfc.xref.header.user-agent.3" title="User-Agent">Section&nbsp;9.10</a>) or Server (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section&nbsp;9.9</a>) header fields can sometimes be used to determine that a specific client or server has a particular security hole which might
     2834         be exploited. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently has
     2835         no better mechanism.
    28362836      </p>
    28372837      <p id="rfc.section.11.1.p.8">Furthermore, the User-Agent header field may contain enough entropy to be used, possibly in conjunction with other material,

  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1512 r1514  
    25662566   Clients can use the Date header field as well; in order to keep request
    25672567   messages small, they are advised not to include it when it doesn't convey
    2568    any useful information (as it is usually the case for requests that do not
     2568   any useful information (as is usually the case for requests that do not
    25692569   contain a payload).
    25702570</t>
    … …  
    27572757   methods to limit the number of times that the request is forwarded by
    27582758   proxies. This can be useful when the client is attempting to
    2759    trace a request which appears to be failing or looping in mid-chain.
     2759   trace a request which appears to be failing or looping mid-chain.
    27602760</t>
    27612761<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Max-Forwards"/>
    … …  
    28292829   be unavailable to the requesting client. This field &MAY; also be used
    28302830   with any 3xx (Redirection) response to indicate the minimum time the
    2831    user-agent is asked wait before issuing the redirected request.
     2831   user-agent is asked to wait before issuing the redirected request.
    28322832</t>
    28332833<t>
    … …  
    33503350   The User-Agent (<xref target="header.user-agent"/>) or Server (<xref
    33513351   target="header.server"/>) header fields can sometimes be used to determine
    3352    that a specific client or server have a particular security hole which might
     3352   that a specific client or server has a particular security hole which might
    33533353   be exploited. Unfortunately, this same information is often used for other
    33543354   valuable purposes for which HTTP currently has no better mechanism.

  • draft-ietf-httpbis/latest/p3-payload.html

    r1506 r1514  
    358358  }
    359359  @bottom-center {
    360        content: "Expires July 17, 2012";
     360       content: "Expires July 29, 2012";
    361361  }
    362362  @bottom-right {
    … …  
    409409      <meta name="dct.creator" content="Reschke, J. F.">
    410410      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest">
    411       <meta name="dct.issued" scheme="ISO8601" content="2012-01-14">
     411      <meta name="dct.issued" scheme="ISO8601" content="2012-01-26">
    412412      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    413413      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext 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.">
    … …  
    435435            </tr>
    436436            <tr>
    437                <td class="left">Expires: July 17, 2012</td>
     437               <td class="left">Expires: July 29, 2012</td>
    438438               <td class="right">J. Mogul</td>
    439439            </tr>
    … …  
    492492            <tr>
    493493               <td class="left"></td>
    494                <td class="right">January 14, 2012</td>
     494               <td class="right">January 26, 2012</td>
    495495            </tr>
    496496         </tbody>
    … …  
    520520         in progress”.
    521521      </p>
    522       <p>This Internet-Draft will expire on July 17, 2012.</p>
     522      <p>This Internet-Draft will expire on July 29, 2012.</p>
    523523      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    524524      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    753753         <li>Pointer to specification text</li>
    754754      </ul>
    755       <p id="rfc.section.2.2.1.p.3">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 5.1</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 5.1.2</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     755      <p id="rfc.section.2.2.1.p.3">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 5.1</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), unless the encoding transformation is identical (as is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 5.1.2</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    756756      </p>
    757757      <p id="rfc.section.2.2.1.p.4">Values to be added to this name space require a specification (see "Specification Required" in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of content coding defined in this section.
    … …  
    995995         <li>It might limit a public cache's ability to use the same response for multiple user's requests.</li>
    996996      </ol>
    997       <p id="rfc.section.5.1.p.4">Server-driven negotiation allows the user agent to specify its preferences, but it cannot expect responses to always honour
     997      <p id="rfc.section.5.1.p.4">Server-driven negotiation allows the user agent to specify its preferences, but it cannot expect responses to always honor
    998998         them. For example, the origin server might not implement server-driven negotiation, or it might decide that sending a response
    999999         that doesn't conform to them is better than sending a 406 (Not Acceptable) response.
    … …  
    14751475      </p>
    14761476      <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a id="privacy.issues.connected.to.accept.header.fields" href="#privacy.issues.connected.to.accept.header.fields">Privacy Issues Connected to Accept Header Fields</a></h2>
    1477       <p id="rfc.section.8.1.p.1">Accept headers fields can reveal information about the user to all servers which are accessed. The Accept-Language header
    1478          field in particular can reveal information the user would consider to be of a private nature, because the understanding of
    1479          particular languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer
    1480          the option to configure the contents of an Accept-Language header field to be sent in every request are strongly encouraged
    1481          to let the configuration process include a message which makes the user aware of the loss of privacy involved.
     1477      <p id="rfc.section.8.1.p.1">Accept header fields can reveal information about the user to all servers which are accessed. The Accept-Language header field
     1478         in particular can reveal information the user would consider to be of a private nature, because the understanding of particular
     1479         languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer the option
     1480         to configure the contents of an Accept-Language header field to be sent in every request are strongly encouraged to let the
     1481         configuration process include a message which makes the user aware of the loss of privacy involved.
    14821482      </p>
    14831483      <p id="rfc.section.8.1.p.2">An approach that limits the loss of privacy would be for a user agent to omit the sending of Accept-Language header fields

  • draft-ietf-httpbis/latest/p3-payload.xml

    r1506 r1514  
    456456<t>
    457457   Names of content codings &MUST-NOT; overlap with names of transfer codings
    458    (&transfer-codings;), unless the encoding transformation is identical (as it
     458   (&transfer-codings;), unless the encoding transformation is identical (as
    459459   is the case for the compression codings defined in
    460460   &compression-codings;).
    … …  
    858858<t>
    859859   Server-driven negotiation allows the user agent to specify its preferences,
    860    but it cannot expect responses to always honour them. For example, the origin
     860   but it cannot expect responses to always honor them. For example, the origin
    861861   server might not implement server-driven negotiation, or it might decide that
    862862   sending a response that doesn't conform to them is better than sending a 406
    … …  
    15981598<section title="Privacy Issues Connected to Accept Header Fields" anchor="privacy.issues.connected.to.accept.header.fields">
    15991599<t>
    1600    Accept headers fields can reveal information about the user to all
     1600   Accept header fields can reveal information about the user to all
    16011601   servers which are accessed. The Accept-Language header field in particular
    16021602   can reveal information the user would consider to be of a private

  • draft-ietf-httpbis/latest/p4-conditional.html

    r1504 r1514  
    358358  }
    359359  @bottom-center {
    360        content: "Expires July 7, 2012";
     360       content: "Expires July 29, 2012";
    361361  }
    362362  @bottom-right {
    … …  
    405405      <meta name="dct.creator" content="Reschke, J. F.">
    406406      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
    407       <meta name="dct.issued" scheme="ISO8601" content="2012-01-04">
     407      <meta name="dct.issued" scheme="ISO8601" content="2012-01-26">
    408408      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    409409      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext 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.">
    … …  
    431431            </tr>
    432432            <tr>
    433                <td class="left">Expires: July 7, 2012</td>
     433               <td class="left">Expires: July 29, 2012</td>
    434434               <td class="right">J. Mogul</td>
    435435            </tr>
    … …  
    488488            <tr>
    489489               <td class="left"></td>
    490                <td class="right">January 4, 2012</td>
     490               <td class="right">January 26, 2012</td>
    491491            </tr>
    492492         </tbody>
    … …  
    518518         in progress”.
    519519      </p>
    520       <p>This Internet-Draft will expire on July 7, 2012.</p>
     520      <p>This Internet-Draft will expire on July 29, 2012.</p>
    521521      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    522522      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    979979  If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
    980980  If-Match: *
    981 </pre><p id="rfc.section.3.1.p.8">The result of a request having both an If-Match header field and either an If-None-Match or an If-Modified-Since header fields
     981</pre><p id="rfc.section.3.1.p.8">The result of a request having both an If-Match header field and either an If-None-Match or an If-Modified-Since header field
    982982         is undefined by this specification.
    983983      </p>
    … …  
    10131013  If-None-Match: *
    10141014</pre><p id="rfc.section.3.2.p.9">The result of a request having both an If-None-Match header field and either an If-Match or an If-Unmodified-Since header
    1015          fields is undefined by this specification.
     1015         field is undefined by this specification.
    10161016      </p>
    10171017      <div id="rfc.iref.i.3"></div>
    … …  
    10601060      </ul>
    10611061      <p id="rfc.section.3.3.p.7">The result of a request having both an If-Modified-Since header field and either an If-Match or an If-Unmodified-Since header
    1062          fields is undefined by this specification.
     1062         field is undefined by this specification.
    10631063      </p>
    10641064      <div id="rfc.iref.i.4"></div>
    … …  
    10781078      </p>
    10791079      <p id="rfc.section.3.4.p.7">The result of a request having both an If-Unmodified-Since header field and either an If-None-Match or an If-Modified-Since
    1080          header fields is undefined by this specification.
     1080         header field is undefined by this specification.
    10811081      </p>
    10821082      <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a id="header.if-range" href="#header.if-range">If-Range</a></h2>

  • draft-ietf-httpbis/latest/p4-conditional.xml

    r1500 r1514  
    866866<t>
    867867   The result of a request having both an If-Match header field and
    868    either an If-None-Match or an If-Modified-Since header fields is
     868   either an If-None-Match or an If-Modified-Since header field is
    869869   undefined by this specification.
    870870</t>
    … …  
    936936<t>
    937937   The result of a request having both an If-None-Match header field and
    938    either an If-Match or an If-Unmodified-Since header fields is
     938   either an If-Match or an If-Unmodified-Since header field is
    939939   undefined by this specification.
    940940</t>
    … …  
    10191019<t>
    10201020   The result of a request having both an If-Modified-Since header field
    1021    and either an If-Match or an If-Unmodified-Since header fields is
     1021   and either an If-Match or an If-Unmodified-Since header field is
    10221022   undefined by this specification.
    10231023</t>
    … …  
    10581058   The result of a request having both an If-Unmodified-Since header
    10591059   field and either an If-None-Match or an If-Modified-Since header
    1060    fields is undefined by this specification.
     1060   field is undefined by this specification.
    10611061</t>
    10621062</section>

  • draft-ietf-httpbis/latest/p6-cache.html

    r1513 r1514  
    812812         <li>the "no-store" cache directive (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.1" title="Cache-Control">Section&nbsp;3.2</a>) does not appear in request or response header fields, and
    813813         </li>
    814          <li>the "private" cache response directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a> does not appear in the response, if the cache is shared, and
     814         <li>the "private" cache response directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>) does not appear in the response, if the cache is shared, and
    815815         </li>
    816816         <li>the "Authorization" header field (see <a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.1"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>) does not appear in the request, if the cache is shared, unless the response explicitly allows it (see <a href="#caching.authenticated.responses" title="Shared Caching of Authenticated Responses">Section&nbsp;2.6</a>), and

  • draft-ietf-httpbis/latest/p6-cache.xml

    r1513 r1514  
    550550      header fields, and</t>
    551551      <t>the "private" cache response directive (see <xref
    552       target="cache-response-directive" /> does not appear in the response, if
     552      target="cache-response-directive" />) does not appear in the response, if
    553553      the cache is shared, and</t>
    554554      <t>the "Authorization" header field (see &header-authorization;) does not
Note: See TracChangeset for help on using the changeset viewer.