Changeset 865 for draft-ietf-httpbis


Ignore:
Timestamp:
Jul 22, 2010, 12:04:55 AM (9 years ago)
Author:
fielding@…
Message:

regenerate html

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

Legend:

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

    r859 r865  
    404404      <meta name="dct.creator" content="Reschke, J. F.">
    405405      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    406       <meta name="dct.issued" scheme="ISO8601" content="2010-07-21">
     406      <meta name="dct.issued" scheme="ISO8601" content="2010-07-22">
    407407      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    408408      <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 1 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the &#34;http&#34; and &#34;https&#34; Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations.">
     
    435435            </tr>
    436436            <tr>
    437                <td class="left">Expires: January 22, 2011</td>
     437               <td class="left">Expires: January 23, 2011</td>
    438438               <td class="right">HP</td>
    439439            </tr>
     
    488488            <tr>
    489489               <td class="left"></td>
    490                <td class="right">July 21, 2010</td>
     490               <td class="right">July 22, 2010</td>
    491491            </tr>
    492492         </tbody>
     
    516516         in progress”.
    517517      </p>
    518       <p>This Internet-Draft will expire in January 22, 2011.</p>
     518      <p>This Internet-Draft will expire in January 23, 2011.</p>
    519519      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    520520      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    11191119      <p id="rfc.section.3.p.2">An HTTP message can either be a request from client to server or a response from server to client. Syntactically, the two
    11201120         types of message differ only in the start-line, which is either a Request-Line (for requests) or a Status-Line (for responses),
    1121          and in the algorithm for determining the length of the message-body (<a href="#message.body.length">Paragraph&nbsp;7</a>). In theory, a client could receive requests and a server could receive responses, distinguishing them by their different
     1121         and in the algorithm for determining the length of the message-body (<a href="#message.body" title="Message Body">Section&nbsp;3.3</a>). In theory, a client could receive requests and a server could receive responses, distinguishing them by their different
    11221122         start-line formats, but in practice servers are implemented to only expect a request (a response is interpreted as an unknown
    11231123         or invalid request method) and clients are implemented to only expect a response.
     
    12201220         (Informational), 204 (No Content), and 304 (Not Modified) responses <em class="bcp14">MUST NOT</em> include a message-body. All other responses do include a message-body, although the body <em class="bcp14">MAY</em> be of zero length.
    12211221      </p>
    1222       <div id="message.body.length">
    1223          <p id="rfc.section.3.3.p.7">The length of the message-body is determined by one of the following (in order of precedence):</p>
    1224       </div>
     1222      <p id="rfc.section.3.3.p.7">The length of the message-body is determined by one of the following (in order of precedence):</p>
    12251223      <p id="rfc.section.3.3.p.8"> </p>
    12261224      <ol>
     
    15701568      </p>
    15711569      <p id="rfc.section.6.2.p.6">Whenever a transfer-coding is applied to a payload body, the set of transfer-codings <em class="bcp14">MUST</em> include "chunked", unless the message indicates it is terminated by closing the connection. When the "chunked" transfer-coding
    1572          is used, it <em class="bcp14">MUST</em> be the last transfer-coding applied to form the message-body. The "chunked" transfer-coding <em class="bcp14">MUST NOT</em> be applied more than once to a message-body. These rules allow the recipient to determine the message-body length of the message
    1573          (<a href="#message.body.length">Paragraph&nbsp;7</a>).
     1570         is used, it <em class="bcp14">MUST</em> be the last transfer-coding applied to form the message-body. The "chunked" transfer-coding <em class="bcp14">MUST NOT</em> be applied more than once to a message-body.
    15741571      </p>
    15751572      <p id="rfc.section.6.2.p.7">Transfer-codings are analogous to the Content-Transfer-Encoding values of MIME, which were designed to enable safe transport
    15761573         of binary data over a 7-bit transport service (<a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>, <a href="http://tools.ietf.org/html/rfc2045#section-6">Section 6</a>). However, safe transport has a different focus for an 8bit-clean transfer protocol. In HTTP, the only unsafe characteristic
    1577          of message-bodies is the difficulty in determining the exact body length (<a href="#message.body.length">Paragraph&nbsp;7</a>), or the desire to encrypt data over a shared transport.
     1574         of message-bodies is the difficulty in determining the exact message body length (<a href="#message.body" title="Message Body">Section&nbsp;3.3</a>), or the desire to encrypt data over a shared transport.
    15781575      </p>
    15791576      <p id="rfc.section.6.2.p.8">A server that receives a request message with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> respond with 501 (Not Implemented) and then close the connection. A server <em class="bcp14">MUST NOT</em> send transfer-codings to an HTTP/1.0 client.
     
    17631760      <p id="rfc.section.7.1.2.1.p.4">Clients and servers <em class="bcp14">SHOULD NOT</em> assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Compatibility with HTTP/1.0 Persistent Connections">Appendix&nbsp;B.2</a> for more information on backward compatibility with HTTP/1.0 clients.
    17641761      </p>
    1765       <p id="rfc.section.7.1.2.1.p.5">In order to remain persistent, all messages on the connection <em class="bcp14">MUST</em> have a self-defined message length (i.e., one not defined by closure of the connection), as described in <a href="#message.body.length">Paragraph&nbsp;7</a>.
     1762      <p id="rfc.section.7.1.2.1.p.5">In order to remain persistent, all messages on the connection <em class="bcp14">MUST</em> have a self-defined message length (i.e., one not defined by closure of the connection), as described in <a href="#message.body" title="Message Body">Section&nbsp;3.3</a>.
    17661763      </p>
    17671764      <h4 id="rfc.section.7.1.2.2"><a href="#rfc.section.7.1.2.2">7.1.2.2</a>&nbsp;<a id="pipelining" href="#pipelining">Pipelining</a></h4>
     
    20272024      <div id="rfc.figure.u.62"></div><pre class="text">  Content-Length: 3495
    20282025</pre><p id="rfc.section.9.2.p.5">Implementations <em class="bcp14">SHOULD</em> use this field to indicate the message-body length when no transfer-coding is being applied and the payload's body length
    2029          can be determined prior to being transferred.
    2030       </p>
    2031       <p id="rfc.section.9.2.p.6">Any Content-Length greater than or equal to zero is a valid value. <a href="#message.body.length">Paragraph&nbsp;7</a> describes how to determine the length of a message-body if a Content-Length is not given.
    2032       </p>
    2033       <p id="rfc.section.9.2.p.7">Note that the meaning of this field is significantly different from the corresponding definition in MIME, where it is an optional
    2034          field used within the "message/external-body" content-type.
     2026         can be determined prior to being transferred. <a href="#message.body" title="Message Body">Section&nbsp;3.3</a> describes how recipients determine the length of a message-body.
     2027      </p>
     2028      <p id="rfc.section.9.2.p.6">Any Content-Length greater than or equal to zero is a valid value.</p>
     2029      <p id="rfc.section.9.2.p.7">Note that the use of this field in HTTP is significantly different from the corresponding definition in MIME, where it is
     2030         an optional field used within the "message/external-body" content-type.
    20352031      </p>
    20362032      <div id="rfc.iref.d.3"></div>
     
    29562952      <p id="rfc.section.B.3.p.2">Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow
    29572953         for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are
    2958          computed. (Sections <a href="#transfer.codings" title="Transfer Codings">6.2</a>, <a href="#message.body.length">3.3.p.7</a>, <a href="#header.content-length" id="rfc.xref.header.content-length.3" title="Content-Length">9.2</a>, see also <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>)
     2954         computed. (Sections <a href="#transfer.codings" title="Transfer Codings">6.2</a>, <a href="#message.body" title="Message Body">3.3</a>, <a href="#header.content-length" id="rfc.xref.header.content-length.3" title="Content-Length">9.2</a>, see also <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>)
    29592955      </p>
    29602956      <p id="rfc.section.B.3.p.3">The use and interpretation of HTTP version numbers has been clarified by <a href="#RFC2145" id="rfc.xref.RFC2145.3"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a>. Require proxies to upgrade requests to highest protocol version they support to deal with problems discovered in HTTP/1.0
     
    29812977      <p id="rfc.section.B.4.p.3">Clarify that HTTP-Version is case sensitive. (<a href="#http.version" title="HTTP Version">Section&nbsp;2.5</a>)
    29822978      </p>
    2983       <p id="rfc.section.B.4.p.4">Remove reference to non-existent identity transfer-coding value tokens. (Sections <a href="#transfer.codings" title="Transfer Codings">6.2</a> and <a href="#message.body.length">3.3.p.7</a>)
     2979      <p id="rfc.section.B.4.p.4">Remove reference to non-existent identity transfer-coding value tokens. (Sections <a href="#transfer.codings" title="Transfer Codings">6.2</a> and <a href="#message.body" title="Message Body">3.3</a>)
    29842980      </p>
    29852981      <p id="rfc.section.B.4.p.5">Require that invalid whitespace around field-names be rejected. (<a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>)
  • draft-ietf-httpbis/latest/p2-semantics.html

    r861 r865  
    403403      <meta name="dct.creator" content="Reschke, J. F.">
    404404      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    405       <meta name="dct.issued" scheme="ISO8601" content="2010-07-21">
     405      <meta name="dct.issued" scheme="ISO8601" content="2010-07-22">
    406406      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    407407      <meta name="dct.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.">
     
    434434            </tr>
    435435            <tr>
    436                <td class="left">Expires: January 22, 2011</td>
     436               <td class="left">Expires: January 23, 2011</td>
    437437               <td class="right">HP</td>
    438438            </tr>
     
    487487            <tr>
    488488               <td class="left"></td>
    489                <td class="right">July 21, 2010</td>
     489               <td class="right">July 22, 2010</td>
    490490            </tr>
    491491         </tbody>
     
    514514         in progress”.
    515515      </p>
    516       <p>This Internet-Draft will expire in January 22, 2011.</p>
     516      <p>This Internet-Draft will expire in January 23, 2011.</p>
    517517      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    518518      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
  • draft-ietf-httpbis/latest/p3-payload.html

    r859 r865  
    401401      <meta name="dct.creator" content="Reschke, J. F.">
    402402      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest">
    403       <meta name="dct.issued" scheme="ISO8601" content="2010-07-21">
     403      <meta name="dct.issued" scheme="ISO8601" content="2010-07-22">
    404404      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    405405      <meta name="dct.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.">
     
    427427            </tr>
    428428            <tr>
    429                <td class="left">Expires: January 22, 2011</td>
     429               <td class="left">Expires: January 23, 2011</td>
    430430               <td class="right">J. Mogul</td>
    431431            </tr>
     
    484484            <tr>
    485485               <td class="left"></td>
    486                <td class="right">July 21, 2010</td>
     486               <td class="right">July 22, 2010</td>
    487487            </tr>
    488488         </tbody>
     
    510510         in progress”.
    511511      </p>
    512       <p>This Internet-Draft will expire in January 22, 2011.</p>
     512      <p>This Internet-Draft will expire in January 23, 2011.</p>
    513513      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    514514      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
  • draft-ietf-httpbis/latest/p6-cache.html

    r861 r865  
    402402      <meta name="dct.creator" content="Reschke, J. F.">
    403403      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    404       <meta name="dct.issued" scheme="ISO8601" content="2010-07-21">
     404      <meta name="dct.issued" scheme="ISO8601" content="2010-07-22">
    405405      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    406406      <meta name="dct.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.">
     
    428428            </tr>
    429429            <tr>
    430                <td class="left">Expires: January 22, 2011</td>
     430               <td class="left">Expires: January 23, 2011</td>
    431431               <td class="right">J. Mogul</td>
    432432            </tr>
     
    489489            <tr>
    490490               <td class="left"></td>
    491                <td class="right">July 21, 2010</td>
     491               <td class="right">July 22, 2010</td>
    492492            </tr>
    493493         </tbody>
     
    515515         in progress”.
    516516      </p>
    517       <p>This Internet-Draft will expire in January 22, 2011.</p>
     517      <p>This Internet-Draft will expire in January 23, 2011.</p>
    518518      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    519519      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
  • draft-ietf-httpbis/latest/p7-auth.html

    r861 r865  
    394394      <meta name="dct.creator" content="Reschke, J. F.">
    395395      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
    396       <meta name="dct.issued" scheme="ISO8601" content="2010-07-21">
     396      <meta name="dct.issued" scheme="ISO8601" content="2010-07-22">
    397397      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    398398      <meta name="dct.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.">
     
    425425            </tr>
    426426            <tr>
    427                <td class="left">Expires: January 22, 2011</td>
     427               <td class="left">Expires: January 23, 2011</td>
    428428               <td class="right">HP</td>
    429429            </tr>
     
    478478            <tr>
    479479               <td class="left"></td>
    480                <td class="right">July 21, 2010</td>
     480               <td class="right">July 22, 2010</td>
    481481            </tr>
    482482         </tbody>
     
    504504         in progress”.
    505505      </p>
    506       <p>This Internet-Draft will expire in January 22, 2011.</p>
     506      <p>This Internet-Draft will expire in January 23, 2011.</p>
    507507      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    508508      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
Note: See TracChangeset for help on using the changeset viewer.