Changeset 2401
- Timestamp:
- 15/09/13 01:06:52 (9 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 8 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r2400 r2401 1167 1167 and the first header field <em class="bcp14">MUST</em> either reject the message as invalid or consume each whitespace-preceded line without further processing of it (i.e., ignore 1168 1168 the entire line, along with any subsequent lines preceded by whitespace, until a properly formed header field is received 1169 or the header blockis terminated).1169 or the header section is terminated). 1170 1170 </p> 1171 1171 <p id="rfc.section.3.p.7">The presence of such whitespace in a request might be an attempt to trick a server into ignoring that field or processing … … 1324 1324 </p> 1325 1325 <h3 id="rfc.section.3.2.5"><a href="#rfc.section.3.2.5">3.2.5</a> <a id="field.limits" href="#field.limits">Field Limits</a></h3> 1326 <p id="rfc.section.3.2.5.p.1">HTTP does not place a pre-defined limit on the length of each header field or on the length of the header blockas a whole,1326 <p id="rfc.section.3.2.5.p.1">HTTP does not place a pre-defined limit on the length of each header field or on the length of the header section as a whole, 1327 1327 as described in <a href="#conformance" title="Conformance and Error Handling">Section 2.5</a>. Various ad-hoc limitations on individual header field length are found in practice, often depending on the specific field 1328 1328 semantics. … … 1452 1452 <p id="rfc.section.3.3.2.p.9">A server <em class="bcp14">MUST NOT</em> send a Content-Length header field in any response with a status code of <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> or <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>. A server <em class="bcp14">MUST NOT</em> send a Content-Length header field in any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). 1453 1453 </p> 1454 <p id="rfc.section.3.3.2.p.10">Aside from the cases defined above, in the absence of Transfer-Encoding, an origin server <em class="bcp14">SHOULD</em> send a Content-Length header field when the payload body size is known prior to sending the complete header block. This will1455 allow downstream recipients to measure transfer progress, know when a received message is complete, and potentially reuse1454 <p id="rfc.section.3.3.2.p.10">Aside from the cases defined above, in the absence of Transfer-Encoding, an origin server <em class="bcp14">SHOULD</em> send a Content-Length header field when the payload body size is known prior to sending the complete header section. This 1455 will allow downstream recipients to measure transfer progress, know when a received message is complete, and potentially reuse 1456 1456 the connection for additional requests. 1457 1457 </p> … … 1541 1541 a supposedly chunked transfer coding fails, <em class="bcp14">MUST</em> record the message as incomplete. Cache requirements for incomplete responses are defined in <a href="p6-cache.html#response.cacheability" title="Storing Responses in Caches">Section 3</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>. 1542 1542 </p> 1543 <p id="rfc.section.3.4.p.3">If a response terminates in the middle of the header block (before the empty line is received) and the status code might rely1544 on header fields to convey the full meaning of the response, then the client cannot assume that meaning has been conveyed;1543 <p id="rfc.section.3.4.p.3">If a response terminates in the middle of the header section (before the empty line is received) and the status code might 1544 rely on header fields to convey the full meaning of the response, then the client cannot assume that meaning has been conveyed; 1545 1545 the client might need to repeat the request in order to determine what action to take next. 1546 1546 </p> … … 1548 1548 not been received. A message that uses a valid <a href="#header.content-length" class="smpl">Content-Length</a> is incomplete if the size of the message body received (in octets) is less than the value given by Content-Length. A response 1549 1549 that has neither chunked transfer coding nor Content-Length is terminated by closure of the connection, and thus is considered 1550 complete regardless of the number of message body octets received, provided that the header blockwas received intact.1550 complete regardless of the number of message body octets received, provided that the header section was received intact. 1551 1551 </p> 1552 1552 <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a> <a id="message.robustness" href="#message.robustness">Message Parsing Robustness</a></h2> … … 1621 1621 <p id="rfc.section.4.1.1.p.1">A trailer allows the sender to include additional fields at the end of a chunked message in order to supply metadata that 1622 1622 might be dynamically generated while the message body is sent, such as a message integrity check, digital signature, or post-processing 1623 status. The trailer fields are identical to header fields, except they are sent in a chunked trailer instead of the message 1624 header block.1623 status. The trailer fields are identical to header fields, except they are sent in a chunked trailer instead of the message's 1624 header section. 1625 1625 </p> 1626 1626 <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.75"></span> <a href="#chunked.trailer.part" class="smpl">trailer-part</a> = *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> ) … … 2638 2638 a Denial of Service against implementations that accept fields with unlimited lengths. 2639 2639 </p> 2640 <p id="rfc.section.9.3.p.2">To promote interoperability, this specification makes specific recommendations for minimum size limits on request-line (<a href="#request.line" title="Request Line">Section 3.1.1</a>) and blocks ofheader fields (<a href="#header.fields" title="Header Fields">Section 3.2</a>). These are minimum recommendations, chosen to be supportable even by implementations with limited resources; it is expected2640 <p id="rfc.section.9.3.p.2">To promote interoperability, this specification makes specific recommendations for minimum size limits on request-line (<a href="#request.line" title="Request Line">Section 3.1.1</a>) and header fields (<a href="#header.fields" title="Header Fields">Section 3.2</a>). These are minimum recommendations, chosen to be supportable even by implementations with limited resources; it is expected 2641 2641 that most implementations will choose substantially higher limits. 2642 2642 </p> -
draft-ietf-httpbis/latest/p1-messaging.xml
r2400 r2401 1072 1072 (i.e., ignore the entire line, along with any subsequent lines preceded 1073 1073 by whitespace, until a properly formed header field is received or the 1074 header blockis terminated).1074 header section is terminated). 1075 1075 </t> 1076 1076 <t> … … 1414 1414 <t> 1415 1415 HTTP does not place a pre-defined limit on the length of each header field 1416 or on the length of the header blockas a whole, as described in1416 or on the length of the header section as a whole, as described in 1417 1417 <xref target="conformance"/>. Various ad-hoc limitations on individual 1418 1418 header field length are found in practice, often depending on the specific … … 1701 1701 Aside from the cases defined above, in the absence of Transfer-Encoding, 1702 1702 an origin server &SHOULD; send a Content-Length header field when the 1703 payload body size is known prior to sending the complete header block.1703 payload body size is known prior to sending the complete header section. 1704 1704 This will allow downstream recipients to measure transfer progress, 1705 1705 know when a received message is complete, and potentially reuse the … … 1874 1874 </t> 1875 1875 <t> 1876 If a response terminates in the middle of the header block(before the1876 If a response terminates in the middle of the header section (before the 1877 1877 empty line is received) and the status code might rely on header fields to 1878 1878 convey the full meaning of the response, then the client cannot assume … … 1888 1888 transfer coding nor Content-Length is terminated by closure of the 1889 1889 connection, and thus is considered complete regardless of the number of 1890 message body octets received, provided that the header blockwas received1890 message body octets received, provided that the header section was received 1891 1891 intact. 1892 1892 </t> … … 2032 2032 check, digital signature, or post-processing status. The trailer fields are 2033 2033 identical to header fields, except they are sent in a chunked trailer 2034 instead of the message header block.2034 instead of the message's header section. 2035 2035 </t> 2036 2036 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="trailer-part"/> … … 3822 3822 recommendations for minimum size limits on request-line 3823 3823 (<xref target="request.line"/>) 3824 and blocks ofheader fields (<xref target="header.fields"/>). These are3824 and header fields (<xref target="header.fields"/>). These are 3825 3825 minimum recommendations, chosen to be supportable even by implementations 3826 3826 with limited resources; it is expected that most implementations will -
draft-ietf-httpbis/latest/p2-semantics.html
r2400 r2401 1297 1297 <tr> 1298 1298 <td class="left">HEAD</td> 1299 <td class="left">Same as GET, but only transfer the status line and header block.</td>1299 <td class="left">Same as GET, but only transfer the status line and header section.</td> 1300 1300 <td class="left"><a href="#HEAD" id="rfc.xref.HEAD.1" title="HEAD">4.3.2</a></td> 1301 1301 </tr> … … 1416 1416 <h3 id="rfc.section.4.3.2"><a href="#rfc.section.4.3.2">4.3.2</a> <a id="HEAD" href="#HEAD">HEAD</a></h3> 1417 1417 <div id="rfc.iref.h.1"></div> 1418 <p id="rfc.section.4.3.2.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> send a message body in the response (i.e., the response terminates at the end of the header block). The server <em class="bcp14">SHOULD</em> send the same header fields in response to a HEAD request as it would have sent if the request had been a GET, except that1418 <p id="rfc.section.4.3.2.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> send a message body in the response (i.e., the response terminates at the end of the header section). The server <em class="bcp14">SHOULD</em> send the same header fields in response to a HEAD request as it would have sent if the request had been a GET, except that 1419 1419 the payload header fields (<a href="#payload" title="Payload Semantics">Section 3.3</a>) <em class="bcp14">MAY</em> be omitted. This method can be used for obtaining metadata about the selected representation without transferring the representation 1420 1420 data and is often used for testing hypertext links for validity, accessibility, and recent modification. … … 1561 1561 </pre><p id="rfc.section.4.3.6.p.5">The recipient proxy can establish a tunnel either by directly connecting to the request-target or, if configured to use another 1562 1562 proxy, by forwarding the CONNECT request to the next inbound proxy. Any <a href="#status.2xx" class="smpl">2xx (Successful)</a> response indicates that the sender (and all inbound proxies) will switch to tunnel mode immediately after the blank line that 1563 concludes the successful response's header block; data received after that blank line is from the server identified by the1563 concludes the successful response's header section; data received after that blank line is from the server identified by the 1564 1564 request-target. Any response other than a successful response indicates that the tunnel has not yet been formed and that the 1565 1565 connection remains governed by HTTP. … … 2417 2417 <p id="rfc.section.6.2.p.1">The <dfn>1xx (Informational)</dfn> class of status code indicates an interim response for communicating connection status or request progress prior to completing 2418 2418 the requested action and sending a final response. All 1xx responses consist of only the status-line and optional header fields, 2419 and thus are terminated by the empty line at the end of the header block. Since HTTP/1.0 did not define any 1xx status codes,2419 and thus are terminated by the empty line at the end of the header section. Since HTTP/1.0 did not define any 1xx status codes, 2420 2420 servers <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client except under experimental conditions. 2421 2421 </p> … … 2470 2470 </dl> 2471 2471 <p id="rfc.section.6.3.1.p.2">Aside from responses to CONNECT, a 200 response always has a payload, though an origin server <em class="bcp14">MAY</em> generate a payload body of zero length. If no payload is desired, an origin server ought to send <dfn>204 (No Content)</dfn> instead. For CONNECT, no payload is allowed because the successful result is a tunnel, which begins immediately after the 2472 200 response header block.2472 200 response header section. 2473 2473 </p> 2474 2474 <p id="rfc.section.6.3.1.p.3">A 200 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#Part6" id="rfc.xref.Part6.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). … … 2987 2987 in Coordinated Universal Time. An origin server <em class="bcp14">MAY</em> send a Date header field if the response is in the <a href="#status.1xx" class="smpl">1xx (Informational)</a> or <a href="#status.5xx" class="smpl">5xx (Server Error)</a> class of status codes. An origin server <em class="bcp14">MUST</em> send a Date header field in all other cases. 2988 2988 </p> 2989 <p id="rfc.section.7.1.1.2.p.7">A recipient with a clock that receives a response message without a Date header field <em class="bcp14">MUST</em> record the time it was received and append a corresponding Date header field to the message's header blockif it is cached2989 <p id="rfc.section.7.1.1.2.p.7">A recipient with a clock that receives a response message without a Date header field <em class="bcp14">MUST</em> record the time it was received and append a corresponding Date header field to the message's header section if it is cached 2990 2990 or forwarded downstream. 2991 2991 </p> -
draft-ietf-httpbis/latest/p2-semantics.xml
r2400 r2401 1131 1131 <c><xref target="GET" format="counter"/></c> 1132 1132 <c>HEAD</c> 1133 <c>Same as GET, but only transfer the status line and header block.</c>1133 <c>Same as GET, but only transfer the status line and header section.</c> 1134 1134 <c><xref target="HEAD" format="counter"/></c> 1135 1135 <c>POST</c> … … 1335 1335 The HEAD method is identical to GET except that the server &MUST-NOT; 1336 1336 send a message body in the response (i.e., the response terminates at the 1337 end of the header block). The server &SHOULD; send the same header fields1337 end of the header section). The server &SHOULD; send the same header fields 1338 1338 in response to a HEAD request as it would have sent if the request had been 1339 1339 a GET, except that the payload header fields (<xref target="payload"/>) … … 1639 1639 that the sender (and all inbound proxies) will switch to tunnel mode 1640 1640 immediately after the blank line that concludes the successful response's 1641 header block; data received after that blank line is from the server1641 header section; data received after that blank line is from the server 1642 1642 identified by the request-target. 1643 1643 Any response other than a successful response indicates that the tunnel … … 2724 2724 All 1xx responses consist of only the status-line and optional header 2725 2725 fields, and thus are terminated by the empty line at the end of the header 2726 block.2726 section. 2727 2727 Since HTTP/1.0 did not define any 1xx status codes, servers &MUST-NOT; send 2728 2728 a 1xx response to an HTTP/1.0 client except under experimental conditions. … … 2832 2832 <x:dfn>204 (No Content)</x:dfn> instead. 2833 2833 For CONNECT, no payload is allowed because the successful result is a 2834 tunnel, which begins immediately after the 200 response header block.2834 tunnel, which begins immediately after the 200 response header section. 2835 2835 </t> 2836 2836 <t> … … 3858 3858 A recipient with a clock that receives a response message without a Date 3859 3859 header field &MUST; record the time it was received and append a 3860 corresponding Date header field to the message's header blockif it is3860 corresponding Date header field to the message's header section if it is 3861 3861 cached or forwarded downstream. 3862 3862 </t> -
draft-ietf-httpbis/latest/p5-range.html
r2378 r2401 446 446 } 447 447 @bottom-center { 448 content: "Expires March 1 7, 2014";448 content: "Expires March 18, 2014"; 449 449 } 450 450 @bottom-right { … … 489 489 <meta name="dct.creator" content="Reschke, J. F."> 490 490 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest"> 491 <meta name="dct.issued" scheme="ISO8601" content="2013-09-1 3">491 <meta name="dct.issued" scheme="ISO8601" content="2013-09-14"> 492 492 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 493 493 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests."> … … 515 515 </tr> 516 516 <tr> 517 <td class="left">Expires: March 1 7, 2014</td>517 <td class="left">Expires: March 18, 2014</td> 518 518 <td class="right">J. Reschke, Editor</td> 519 519 </tr> … … 524 524 <tr> 525 525 <td class="left"></td> 526 <td class="right">September 1 3, 2013</td>526 <td class="right">September 14, 2013</td> 527 527 </tr> 528 528 </tbody> … … 549 549 in progress”. 550 550 </p> 551 <p>This Internet-Draft will expire on March 1 7, 2014.</p>551 <p>This Internet-Draft will expire on March 18, 2014.</p> 552 552 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 553 553 <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 801 801 ... 26012 bytes of partial image data ... 802 802 </pre><p id="rfc.section.4.1.p.4">If multiple parts are being transferred, the server generating the 206 response <em class="bcp14">MUST</em> generate a "multipart/byteranges" payload, as defined in <a href="#internet.media.type.multipart.byteranges" title="Internet Media Type multipart/byteranges">Appendix A</a>, and a <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> header field containing the multipart/byteranges media type and its required boundary parameter. To avoid confusion with single 803 part responses, a server <em class="bcp14">MUST NOT</em> generate a <a href="#header.content-range" class="smpl">Content-Range</a> header field in the HTTP header blockof a multiple part response (this field will be sent in each part instead).803 part responses, a server <em class="bcp14">MUST NOT</em> generate a <a href="#header.content-range" class="smpl">Content-Range</a> header field in the HTTP header section of a multiple part response (this field will be sent in each part instead). 804 804 </p> 805 805 <p id="rfc.section.4.1.p.5">Within the header area of each body part in the multipart payload, the server <em class="bcp14">MUST</em> generate a <a href="#header.content-range" class="smpl">Content-Range</a> header field corresponding to the range being enclosed in that body part. If the selected representation would have had a <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> header field in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response, the server <em class="bcp14">SHOULD</em> generate that same <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> field in the header area of each body part. For example: -
draft-ietf-httpbis/latest/p5-range.xml
r2378 r2401 536 536 multipart/byteranges media type and its required boundary parameter. 537 537 To avoid confusion with single part responses, a server &MUST-NOT; generate 538 a <x:ref>Content-Range</x:ref> header field in the HTTP header blockof a538 a <x:ref>Content-Range</x:ref> header field in the HTTP header section of a 539 539 multiple part response (this field will be sent in each part instead). 540 540 </t> -
draft-ietf-httpbis/latest/p6-cache.html
r2400 r2401 779 779 </p> 780 780 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="incomplete.responses" href="#incomplete.responses">Storing Incomplete Responses</a></h2> 781 <p id="rfc.section.3.1.p.1">A response message is considered complete when all of the octets indicated by the message framing (<a href="#Part1" id="rfc.xref.Part1.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) are received prior to the connection being closed. If the request method is GET, the response status code is <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a>, and the entire response header blockhas been received, a cache <em class="bcp14">MAY</em> store an incomplete response message body if the cache entry is recorded as incomplete. Likewise, a <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a> response <em class="bcp14">MAY</em> be stored as if it were an incomplete <a href="p2-semantics.html#status.200" class="smpl">200781 <p id="rfc.section.3.1.p.1">A response message is considered complete when all of the octets indicated by the message framing (<a href="#Part1" id="rfc.xref.Part1.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) are received prior to the connection being closed. If the request method is GET, the response status code is <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a>, and the entire response header section has been received, a cache <em class="bcp14">MAY</em> store an incomplete response message body if the cache entry is recorded as incomplete. Likewise, a <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a> response <em class="bcp14">MAY</em> be stored as if it were an incomplete <a href="p2-semantics.html#status.200" class="smpl">200 782 782 (OK)</a> cache entry. However, a cache <em class="bcp14">MUST NOT</em> store incomplete or partial content responses if it does not support the <a href="p5-range.html#header.range" class="smpl">Range</a> and <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> header fields or if it does not understand the range units used in those fields. 783 783 </p> -
draft-ietf-httpbis/latest/p6-cache.xml
r2400 r2401 323 323 by the message framing (&messaging;) are received prior to the connection 324 324 being closed. If the request method is GET, the response status code is 325 <x:ref>200 (OK)</x:ref>, and the entire response header blockhas been received, a325 <x:ref>200 (OK)</x:ref>, and the entire response header section has been received, a 326 326 cache &MAY; store an incomplete response message body if the cache entry is 327 327 recorded as incomplete. Likewise, a <x:ref>206 (Partial Content)</x:ref>
Note: See TracChangeset
for help on using the changeset viewer.