* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Changeset 1514


Ignore:
Timestamp:
2012-01-26 06:54:04 (2 years ago)
Author:
julian.reschke@gmx.de
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.