Changeset 2369
- Timestamp:
- 04/09/13 11:49:18 (9 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 10 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r2365 r2369 446 446 } 447 447 @bottom-center { 448 content: "Expires March 5, 2014";448 content: "Expires March 8, 2014"; 449 449 } 450 450 @bottom-right { … … 488 488 <meta name="dct.creator" content="Reschke, J. F."> 489 489 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 490 <meta name="dct.issued" scheme="ISO8601" content="2013-09-0 1">490 <meta name="dct.issued" scheme="ISO8601" content="2013-09-04"> 491 491 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 492 492 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 517 517 <tr> 518 518 <td class="left">Intended status: Standards Track</td> 519 <td class="right">September 1, 2013</td>519 <td class="right">September 4, 2013</td> 520 520 </tr> 521 521 <tr> 522 <td class="left">Expires: March 5, 2014</td>522 <td class="left">Expires: March 8, 2014</td> 523 523 <td class="right"></td> 524 524 </tr> … … 548 548 in progress”. 549 549 </p> 550 <p>This Internet-Draft will expire on March 5, 2014.</p>550 <p>This Internet-Draft will expire on March 8, 2014.</p> 551 551 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 552 552 <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 2971 2971 <p id="rfc.section.A.2.p.1">HTTP's approach to error handling has been explained. (<a href="#conformance" title="Conformance and Error Handling">Section 2.5</a>) 2972 2972 </p> 2973 <p id="rfc.section.A.2.p.2">The expectation to support HTTP/0.9 requests has been removed.</p> 2974 <p id="rfc.section.A.2.p.3">The term "Effective Request URI" has been introduced. (<a href="#effective.request.uri" title="Effective Request URI">Section 5.5</a>) 2975 </p> 2976 <p id="rfc.section.A.2.p.4">HTTP messages can be (and often are) buffered by implementations; despite it sometimes being available as a stream, HTTP is 2977 fundamentally a message-oriented protocol. (<a href="#http.message" title="Message Format">Section 3</a>) 2978 </p> 2979 <p id="rfc.section.A.2.p.5">Minimum supported sizes for various protocol elements have been suggested, to improve interoperability.</p> 2980 <p id="rfc.section.A.2.p.6">Header fields that span multiple lines ("line folding") are deprecated. (<a href="#field.parsing" title="Field Parsing">Section 3.2.4</a>) 2981 </p> 2982 <p id="rfc.section.A.2.p.7">The HTTP-version ABNF production has been clarified to be case-sensitive. Additionally, version numbers has been restricted 2973 <p id="rfc.section.A.2.p.2">The HTTP-version ABNF production has been clarified to be case-sensitive. Additionally, version numbers has been restricted 2983 2974 to single digits, due to the fact that implementations are known to handle multi-digit version numbers incorrectly. (<a href="#http.version" title="Protocol Versioning">Section 2.6</a>) 2984 2975 </p> 2985 <p id="rfc.section.A.2.p.8">The HTTPS URI scheme is now defined by this specification; previously, it was done in <a href="http://tools.ietf.org/html/rfc2818#section-2.4">Section 2.4</a> of <a href="#RFC2818" id="rfc.xref.RFC2818.3"><cite title="HTTP Over TLS">[RFC2818]</cite></a>. (<a href="#https.uri" title="https URI scheme">Section 2.7.2</a>) 2986 </p> 2987 <p id="rfc.section.A.2.p.9">The HTTPS URI scheme implies end-to-end security. (<a href="#https.uri" title="https URI scheme">Section 2.7.2</a>) 2988 </p> 2989 <p id="rfc.section.A.2.p.10">Userinfo (i.e., username and password) are now disallowed in HTTP and HTTPS URIs, because of security issues related to their 2976 <p id="rfc.section.A.2.p.3">Userinfo (i.e., username and password) are now disallowed in HTTP and HTTPS URIs, because of security issues related to their 2990 2977 transmission on the wire. (<a href="#http.uri" title="http URI scheme">Section 2.7.1</a>) 2991 2978 </p> 2992 <p id="rfc.section.A.2.p.11">Invalid whitespace around field-names is now required to be rejected, because accepting it represents a security vulnerability. 2993 (<a href="#header.fields" title="Header Fields">Section 3.2</a>) 2994 </p> 2995 <p id="rfc.section.A.2.p.12">The ABNF productions defining header fields now only list the field value. (<a href="#header.fields" title="Header Fields">Section 3.2</a>) 2996 </p> 2997 <p id="rfc.section.A.2.p.13">Rules about implicit linear whitespace between certain grammar productions have been removed; now whitespace is only allowed 2979 <p id="rfc.section.A.2.p.4">The HTTPS URI scheme is now defined by this specification; previously, it was done in <a href="http://tools.ietf.org/html/rfc2818#section-2.4">Section 2.4</a> of <a href="#RFC2818" id="rfc.xref.RFC2818.3"><cite title="HTTP Over TLS">[RFC2818]</cite></a>. Furthermore, it implies end-to-end security. (<a href="#https.uri" title="https URI scheme">Section 2.7.2</a>) 2980 </p> 2981 <p id="rfc.section.A.2.p.5">HTTP messages can be (and often are) buffered by implementations; despite it sometimes being available as a stream, HTTP is 2982 fundamentally a message-oriented protocol. Minimum supported sizes for various protocol elements have been suggested, to improve 2983 interoperability. (<a href="#http.message" title="Message Format">Section 3</a>) 2984 </p> 2985 <p id="rfc.section.A.2.p.6">Invalid whitespace around field-names is now required to be rejected, because accepting it represents a security vulnerability. 2986 The ABNF productions defining header fields now only list the field value. (<a href="#header.fields" title="Header Fields">Section 3.2</a>) 2987 </p> 2988 <p id="rfc.section.A.2.p.7">Rules about implicit linear whitespace between certain grammar productions have been removed; now whitespace is only allowed 2998 2989 where specifically defined in the ABNF. (<a href="#whitespace" title="Whitespace">Section 3.2.3</a>) 2999 2990 </p> 3000 <p id="rfc.section.A.2.p.14">The NUL octet is no longer allowed in comment and quoted-string text, and handling of backslash-escaping in them has been 3001 clarified. (<a href="#field.components" title="Field value components">Section 3.2.6</a>) 3002 </p> 3003 <p id="rfc.section.A.2.p.15">The quoted-pair rule no longer allows escaping control characters other than HTAB. (<a href="#field.components" title="Field value components">Section 3.2.6</a>) 3004 </p> 3005 <p id="rfc.section.A.2.p.16">Non-ASCII content in header fields and the reason phrase has been obsoleted and made opaque (the TEXT rule was removed). (<a href="#field.components" title="Field value components">Section 3.2.6</a>) 3006 </p> 3007 <p id="rfc.section.A.2.p.17">Bogus "<a href="#header.content-length" class="smpl">Content-Length</a>" header fields are now required to be handled as errors by recipients. (<a href="#header.content-length" id="rfc.xref.header.content-length.2" title="Content-Length">Section 3.3.2</a>) 3008 </p> 3009 <p id="rfc.section.A.2.p.18">The "identity" transfer coding token has been removed. (Sections <a href="#message.body" title="Message Body">3.3</a> and <a href="#transfer.codings" title="Transfer Codings">4</a>) 3010 </p> 3011 <p id="rfc.section.A.2.p.19">The algorithm for determining the message body length has been clarified to indicate all of the special cases (e.g., driven 3012 by methods or status codes) that affect it, and that new protocol elements cannot define such special cases. (<a href="#message.body.length" title="Message Body Length">Section 3.3.3</a>) 3013 </p> 3014 <p id="rfc.section.A.2.p.20">"multipart/byteranges" is no longer a way of determining message body length detection. (<a href="#message.body.length" title="Message Body Length">Section 3.3.3</a>) 3015 </p> 3016 <p id="rfc.section.A.2.p.21">CONNECT is a new, special case in determining message body length. (<a href="#message.body.length" title="Message Body Length">Section 3.3.3</a>) 3017 </p> 3018 <p id="rfc.section.A.2.p.22">Chunk length does not include the count of the octets in the chunk header and trailer. (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a>) 3019 </p> 3020 <p id="rfc.section.A.2.p.23">Use of chunk extensions is deprecated, and line folding in them is disallowed. (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a>) 3021 </p> 3022 <p id="rfc.section.A.2.p.24">The segment + query components of RFC 3986 have been used to define the request-target, instead of abs_path from RFC 1808. 3023 (<a href="#request-target" title="Request Target">Section 5.3</a>) 3024 </p> 3025 <p id="rfc.section.A.2.p.25">The asterisk-form of the request-target is only allowed in the OPTIONS method. (<a href="#request-target" title="Request Target">Section 5.3</a>) 3026 </p> 3027 <p id="rfc.section.A.2.p.26">Gateways do not need to generate <a href="#header.via" class="smpl">Via</a> header fields anymore. (<a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section 5.7.1</a>) 3028 </p> 3029 <p id="rfc.section.A.2.p.27">Exactly when "close" connection options have to be sent has been clarified. (<a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section 6.1</a>) 3030 </p> 3031 <p id="rfc.section.A.2.p.28">"hop-by-hop" header fields are required to appear in the Connection header field; just because they're defined as hop-by-hop 3032 in this specification doesn't exempt them. (<a href="#header.connection" id="rfc.xref.header.connection.9" title="Connection">Section 6.1</a>) 3033 </p> 3034 <p id="rfc.section.A.2.p.29">The limit of two connections per server has been removed. (<a href="#persistent.connections" title="Persistence">Section 6.3</a>) 3035 </p> 3036 <p id="rfc.section.A.2.p.30">An idempotent sequence of requests is no longer required to be retried. (<a href="#persistent.connections" title="Persistence">Section 6.3</a>) 3037 </p> 3038 <p id="rfc.section.A.2.p.31">The requirement to retry requests under certain circumstances when the server prematurely closes the connection has been removed. 3039 (<a href="#persistent.connections" title="Persistence">Section 6.3</a>) 3040 </p> 3041 <p id="rfc.section.A.2.p.32">Some extraneous requirements about when servers are allowed to close connections prematurely have been removed. (<a href="#persistent.connections" title="Persistence">Section 6.3</a>) 3042 </p> 3043 <p id="rfc.section.A.2.p.33">The semantics of the <a href="#header.upgrade" class="smpl">Upgrade</a> header field is now defined in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). Furthermore, the ordering in the field value is now significant. (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section 6.7</a>) 3044 </p> 3045 <p id="rfc.section.A.2.p.34">Registration of Transfer Codings now requires IETF Review (<a href="#transfer.coding.registry" title="Transfer Coding Registry">Section 8.4</a>) 3046 </p> 3047 <p id="rfc.section.A.2.p.35">The meaning of the "deflate" content coding has been clarified. (<a href="#deflate.coding" title="Deflate Coding">Section 4.2.2</a>) 3048 </p> 3049 <p id="rfc.section.A.2.p.36">This specification now defines the Upgrade Token Registry, previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.2">Section 7.2</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#upgrade.token.registry" title="Upgrade Token Registry">Section 8.5</a>) 3050 </p> 3051 <p id="rfc.section.A.2.p.37">Issues with the Keep-Alive and Proxy-Connection header fields in requests are pointed out, with use of the latter being discouraged 2991 <p id="rfc.section.A.2.p.8">Header fields that span multiple lines ("line folding") are deprecated. (<a href="#field.parsing" title="Field Parsing">Section 3.2.4</a>) 2992 </p> 2993 <p id="rfc.section.A.2.p.9">The NUL octet is no longer allowed in comment and quoted-string text, and handling of backslash-escaping in them has been 2994 clarified. The quoted-pair rule no longer allows escaping control characters other than HTAB. Non-ASCII content in header 2995 fields and the reason phrase has been obsoleted and made opaque (the TEXT rule was removed). (<a href="#field.components" title="Field value components">Section 3.2.6</a>) 2996 </p> 2997 <p id="rfc.section.A.2.p.10">Bogus "<a href="#header.content-length" class="smpl">Content-Length</a>" header fields are now required to be handled as errors by recipients. (<a href="#header.content-length" id="rfc.xref.header.content-length.2" title="Content-Length">Section 3.3.2</a>) 2998 </p> 2999 <p id="rfc.section.A.2.p.11">The algorithm for determining the message body length has been clarified to indicate all of the special cases (e.g., driven 3000 by methods or status codes) that affect it, and that new protocol elements cannot define such special cases. CONNECT is a 3001 new, special case in determining message body length. "multipart/byteranges" is no longer a way of determining message body 3002 length detection. (<a href="#message.body.length" title="Message Body Length">Section 3.3.3</a>) 3003 </p> 3004 <p id="rfc.section.A.2.p.12">The "identity" transfer coding token has been removed. (Sections <a href="#message.body" title="Message Body">3.3</a> and <a href="#transfer.codings" title="Transfer Codings">4</a>) 3005 </p> 3006 <p id="rfc.section.A.2.p.13">Chunk length does not include the count of the octets in the chunk header and trailer. Use of chunk extensions is deprecated, 3007 and line folding in them is disallowed. (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a>) 3008 </p> 3009 <p id="rfc.section.A.2.p.14">The meaning of the "deflate" content coding has been clarified. (<a href="#deflate.coding" title="Deflate Coding">Section 4.2.2</a>) 3010 </p> 3011 <p id="rfc.section.A.2.p.15">The segment + query components of RFC 3986 have been used to define the request-target, instead of abs_path from RFC 1808. 3012 The asterisk-form of the request-target is only allowed in the OPTIONS method. (<a href="#request-target" title="Request Target">Section 5.3</a>) 3013 </p> 3014 <p id="rfc.section.A.2.p.16">The term "Effective Request URI" has been introduced. (<a href="#effective.request.uri" title="Effective Request URI">Section 5.5</a>) 3015 </p> 3016 <p id="rfc.section.A.2.p.17">Gateways do not need to generate <a href="#header.via" class="smpl">Via</a> header fields anymore. (<a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section 5.7.1</a>) 3017 </p> 3018 <p id="rfc.section.A.2.p.18">Exactly when "close" connection options have to be sent has been clarified. Also, "hop-by-hop" header fields are required 3019 to appear in the Connection header field; just because they're defined as hop-by-hop in this specification doesn't exempt 3020 them. (<a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section 6.1</a>) 3021 </p> 3022 <p id="rfc.section.A.2.p.19">The limit of two connections per server has been removed. An idempotent sequence of requests is no longer required to be retried. 3023 The requirement to retry requests under certain circumstances when the server prematurely closes the connection has been removed. 3024 Also, some extraneous requirements about when servers are allowed to close connections prematurely have been removed. (<a href="#persistent.connections" title="Persistence">Section 6.3</a>) 3025 </p> 3026 <p id="rfc.section.A.2.p.20">The semantics of the <a href="#header.upgrade" class="smpl">Upgrade</a> header field is now defined in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). Furthermore, the ordering in the field value is now significant. (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section 6.7</a>) 3027 </p> 3028 <p id="rfc.section.A.2.p.21">Empty list elements in list productions (e.g., a list header field containing ", ,") have been deprecated. (<a href="#abnf.extension" title="ABNF list extension: #rule">Section 7</a>) 3029 </p> 3030 <p id="rfc.section.A.2.p.22">Registration of Transfer Codings now requires IETF Review (<a href="#transfer.coding.registry" title="Transfer Coding Registry">Section 8.4</a>) 3031 </p> 3032 <p id="rfc.section.A.2.p.23">This specification now defines the Upgrade Token Registry, previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.2">Section 7.2</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#upgrade.token.registry" title="Upgrade Token Registry">Section 8.5</a>) 3033 </p> 3034 <p id="rfc.section.A.2.p.24">The expectation to support HTTP/0.9 requests has been removed. (<a href="#compatibility" title="HTTP Version History">Appendix A</a>) 3035 </p> 3036 <p id="rfc.section.A.2.p.25">Issues with the Keep-Alive and Proxy-Connection header fields in requests are pointed out, with use of the latter being discouraged 3052 3037 altogether. (<a href="#compatibility.with.http.1.0.persistent.connections" title="Keep-Alive Connections">Appendix A.1.2</a>) 3053 </p>3054 <p id="rfc.section.A.2.p.38">Empty list elements in list productions (e.g., a list header field containing ", ,") have been deprecated. (<a href="#abnf.extension" title="ABNF list extension: #rule">Section 7</a>)3055 3038 </p> 3056 3039 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> … … 3296 3279 <li>chunked (Coding Format) <a href="#rfc.iref.c.6">3.3.1</a>, <a href="#rfc.iref.c.8">3.3.3</a>, <a href="#rfc.iref.c.9"><b>4.1</b></a></li> 3297 3280 <li>client <a href="#rfc.iref.c.1"><b>2.1</b></a></li> 3298 <li>close <a href="#rfc.xref.header.connection.1">3.2.1</a>, <a href="#rfc.xref.header.connection.2">4.3</a>, <a href="#rfc.xref.header.connection.3">5.7</a>, <a href="#rfc.iref.c.12"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.xref.persistent.tear-down.2">6.3.2</a>, <a href="#rfc.iref.c.14">6.6</a>, <a href="#rfc.xref.header.connection.4">6.6</a>, <a href="#rfc.xref.header.connection.5">6.7</a>, <a href="#rfc.xref.header.connection.6">8.1</a>, <a href="#rfc.xref.header.connection.7">8.1</a>, <a href="#rfc.xref.header.connection.8">A.2</a> , <a href="#rfc.xref.header.connection.9">A.2</a></li>3281 <li>close <a href="#rfc.xref.header.connection.1">3.2.1</a>, <a href="#rfc.xref.header.connection.2">4.3</a>, <a href="#rfc.xref.header.connection.3">5.7</a>, <a href="#rfc.iref.c.12"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.xref.persistent.tear-down.2">6.3.2</a>, <a href="#rfc.iref.c.14">6.6</a>, <a href="#rfc.xref.header.connection.4">6.6</a>, <a href="#rfc.xref.header.connection.5">6.7</a>, <a href="#rfc.xref.header.connection.6">8.1</a>, <a href="#rfc.xref.header.connection.7">8.1</a>, <a href="#rfc.xref.header.connection.8">A.2</a></li> 3299 3282 <li>compress (Coding Format) <a href="#rfc.iref.c.10">4.2.1</a></li> 3300 3283 <li>connection <a href="#rfc.iref.c.2"><b>2.1</b></a></li> 3301 <li>Connection header field <a href="#rfc.xref.header.connection.1">3.2.1</a>, <a href="#rfc.xref.header.connection.2">4.3</a>, <a href="#rfc.xref.header.connection.3">5.7</a>, <a href="#rfc.iref.c.11"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.xref.persistent.tear-down.2">6.3.2</a>, <a href="#rfc.iref.c.13">6.6</a>, <a href="#rfc.xref.header.connection.4">6.6</a>, <a href="#rfc.xref.header.connection.5">6.7</a>, <a href="#rfc.xref.header.connection.6">8.1</a>, <a href="#rfc.xref.header.connection.7">8.1</a>, <a href="#rfc.xref.header.connection.8">A.2</a> , <a href="#rfc.xref.header.connection.9">A.2</a></li>3284 <li>Connection header field <a href="#rfc.xref.header.connection.1">3.2.1</a>, <a href="#rfc.xref.header.connection.2">4.3</a>, <a href="#rfc.xref.header.connection.3">5.7</a>, <a href="#rfc.iref.c.11"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.xref.persistent.tear-down.2">6.3.2</a>, <a href="#rfc.iref.c.13">6.6</a>, <a href="#rfc.xref.header.connection.4">6.6</a>, <a href="#rfc.xref.header.connection.5">6.7</a>, <a href="#rfc.xref.header.connection.6">8.1</a>, <a href="#rfc.xref.header.connection.7">8.1</a>, <a href="#rfc.xref.header.connection.8">A.2</a></li> 3302 3285 <li>Content-Length header field <a href="#rfc.iref.c.7"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">8.1</a>, <a href="#rfc.xref.header.content-length.2">A.2</a></li> 3303 3286 </ul> -
draft-ietf-httpbis/latest/p1-messaging.xml
r2365 r2369 5025 5025 <t> 5026 5026 HTTP's approach to error handling has been explained. 5027 (<xref target="conformance"/>) 5028 </t> 5029 <t> 5030 The expectation to support HTTP/0.9 requests has been removed. 5031 </t> 5032 <t> 5033 The term "Effective Request URI" has been introduced. 5034 (<xref target="effective.request.uri" />) 5035 </t> 5036 <t> 5037 HTTP messages can be (and often are) buffered by implementations; despite 5038 it sometimes being available as a stream, HTTP is fundamentally a 5039 message-oriented protocol. 5040 (<xref target="http.message" />) 5041 </t> 5042 <t> 5043 Minimum supported sizes for various protocol elements have been 5044 suggested, to improve interoperability. 5045 </t> 5046 <t> 5047 Header fields that span multiple lines ("line folding") are deprecated. 5048 (<xref target="field.parsing" />) 5027 (<xref target="conformance" />) 5049 5028 </t> 5050 5029 <t> … … 5056 5035 </t> 5057 5036 <t> 5058 The HTTPS URI scheme is now defined by this specification; previously,5059 it was done in <xref target="RFC2818" x:fmt="of" x:sec="2.4"/>.5060 (<xref target="https.uri"/>)5061 </t>5062 <t>5063 The HTTPS URI scheme implies end-to-end security.5064 (<xref target="https.uri"/>)5065 </t>5066 <t>5067 5037 Userinfo (i.e., username and password) are now disallowed in HTTP and 5068 5038 HTTPS URIs, because of security issues related to their transmission on the … … 5071 5041 </t> 5072 5042 <t> 5043 The HTTPS URI scheme is now defined by this specification; previously, 5044 it was done in <xref target="RFC2818" x:fmt="of" x:sec="2.4"/>. 5045 Furthermore, it implies end-to-end security. 5046 (<xref target="https.uri"/>) 5047 </t> 5048 <t> 5049 HTTP messages can be (and often are) buffered by implementations; despite 5050 it sometimes being available as a stream, HTTP is fundamentally a 5051 message-oriented protocol. 5052 Minimum supported sizes for various protocol elements have been 5053 suggested, to improve interoperability. 5054 (<xref target="http.message" />) 5055 </t> 5056 <t> 5073 5057 Invalid whitespace around field-names is now required to be rejected, 5074 5058 because accepting it represents a security vulnerability. 5075 (<xref target="header.fields"/>)5076 </t>5077 <t>5078 5059 The ABNF productions defining header fields now only list the field value. 5079 5060 (<xref target="header.fields"/>) … … 5085 5066 (<xref target="whitespace"/>) 5086 5067 </t> 5068 <t> 5069 Header fields that span multiple lines ("line folding") are deprecated. 5070 (<xref target="field.parsing" />) 5071 </t> 5087 5072 <t> 5088 5073 The NUL octet is no longer allowed in comment and quoted-string text, and 5089 5074 handling of backslash-escaping in them has been clarified. 5090 (<xref target="field.components"/>)5091 </t>5092 <t>5093 5075 The quoted-pair rule no longer allows escaping control characters other than 5094 5076 HTAB. 5095 (<xref target="field.components"/>)5096 </t>5097 <t>5098 5077 Non-ASCII content in header fields and the reason phrase has been obsoleted 5099 5078 and made opaque (the TEXT rule was removed). 5100 5079 (<xref target="field.components"/>) 5101 </t> 5080 </t> 5102 5081 <t> 5103 5082 Bogus "<x:ref>Content-Length</x:ref>" header fields are now required to be 5104 5083 handled as errors by recipients. 5105 5084 (<xref target="header.content-length"/>) 5106 </t>5107 <t>5108 The "identity" transfer coding token has been removed.5109 (Sections <xref format="counter" target="message.body"/> and5110 <xref format="counter" target="transfer.codings"/>)5111 5085 </t> 5112 5086 <t> … … 5115 5089 codes) that affect it, and that new protocol elements cannot define such 5116 5090 special cases. 5117 (<xref target="message.body.length"/>) 5118 </t> 5119 <t> 5091 CONNECT is a new, special case in determining message body length. 5120 5092 "multipart/byteranges" is no longer a way of determining message body length 5121 5093 detection. … … 5123 5095 </t> 5124 5096 <t> 5125 CONNECT is a new, special case in determining message body length. 5126 (<xref target="message.body.length"/>) 5097 The "identity" transfer coding token has been removed. 5098 (Sections <xref format="counter" target="message.body"/> and 5099 <xref format="counter" target="transfer.codings"/>) 5127 5100 </t> 5128 5101 <t> 5129 5102 Chunk length does not include the count of the octets in the 5130 5103 chunk header and trailer. 5131 (<xref target="chunked.encoding"/>)5132 </t>5133 <t>5134 5104 Use of chunk extensions is deprecated, and line folding in them is 5135 5105 disallowed. … … 5137 5107 </t> 5138 5108 <t> 5109 The meaning of the "deflate" content coding has been clarified. 5110 (<xref target="deflate.coding" />) 5111 </t> 5112 <t> 5139 5113 The segment + query components of RFC 3986 have been used to define the 5140 5114 request-target, instead of abs_path from RFC 1808. 5141 (<xref target="request-target"/>)5142 </t>5143 <t>5144 5115 The asterisk-form of the request-target is only allowed in the OPTIONS 5145 5116 method. … … 5147 5118 </t> 5148 5119 <t> 5120 The term "Effective Request URI" has been introduced. 5121 (<xref target="effective.request.uri" />) 5122 </t> 5123 <t> 5149 5124 Gateways do not need to generate <x:ref>Via</x:ref> header fields anymore. 5150 5125 (<xref target="header.via"/>) … … 5152 5127 <t> 5153 5128 Exactly when "close" connection options have to be sent has been clarified. 5154 (<xref target="header.connection"/>) 5155 </t> 5156 <t> 5157 "hop-by-hop" header fields are required to appear in the Connection header 5129 Also, "hop-by-hop" header fields are required to appear in the Connection header 5158 5130 field; just because they're defined as hop-by-hop in this specification 5159 5131 doesn't exempt them. … … 5162 5134 <t> 5163 5135 The limit of two connections per server has been removed. 5164 (<xref target="persistent.connections"/>)5165 </t>5166 <t>5167 5136 An idempotent sequence of requests is no longer required to be retried. 5168 (<xref target="persistent.connections"/>)5169 </t>5170 <t>5171 5137 The requirement to retry requests under certain circumstances when the 5172 5138 server prematurely closes the connection has been removed. 5173 (<xref target="persistent.connections"/>) 5174 </t> 5175 <t> 5176 Some extraneous requirements about when servers are allowed to close 5139 Also, some extraneous requirements about when servers are allowed to close 5177 5140 connections prematurely have been removed. 5178 5141 (<xref target="persistent.connections"/>) … … 5186 5149 </t> 5187 5150 <t> 5151 Empty list elements in list productions (e.g., a list header field containing 5152 ", ,") have been deprecated. 5153 (<xref target="abnf.extension"/>) 5154 </t> 5155 <t> 5188 5156 Registration of Transfer Codings now requires IETF Review 5189 5157 (<xref target="transfer.coding.registry"/>) 5190 </t>5191 <t>5192 The meaning of the "deflate" content coding has been clarified.5193 (<xref target="deflate.coding" />)5194 5158 </t> 5195 5159 <t> … … 5199 5163 </t> 5200 5164 <t> 5165 The expectation to support HTTP/0.9 requests has been removed. 5166 (<xref target="compatibility"/>) 5167 </t> 5168 <t> 5201 5169 Issues with the Keep-Alive and Proxy-Connection header fields in requests 5202 5170 are pointed out, with use of the latter being discouraged altogether. 5203 5171 (<xref target="compatibility.with.http.1.0.persistent.connections" />) 5204 </t>5205 <t>5206 Empty list elements in list productions (e.g., a list header field containing5207 ", ,") have been deprecated.5208 (<xref target="abnf.extension"/>)5209 5172 </t> 5210 5173 </section> -
draft-ietf-httpbis/latest/p2-semantics.html
r2367 r2369 446 446 } 447 447 @bottom-center { 448 content: "Expires March 7, 2014";448 content: "Expires March 8, 2014"; 449 449 } 450 450 @bottom-right { … … 491 491 <meta name="dct.creator" content="Reschke, J. F."> 492 492 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 493 <meta name="dct.issued" scheme="ISO8601" content="2013-09-0 3">493 <meta name="dct.issued" scheme="ISO8601" content="2013-09-04"> 494 494 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 495 495 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation."> … … 519 519 <tr> 520 520 <td class="left">Intended status: Standards Track</td> 521 <td class="right">September 3, 2013</td>521 <td class="right">September 4, 2013</td> 522 522 </tr> 523 523 <tr> 524 <td class="left">Expires: March 7, 2014</td>524 <td class="left">Expires: March 8, 2014</td> 525 525 <td class="right"></td> 526 526 </tr> … … 550 550 in progress”. 551 551 </p> 552 <p>This Internet-Draft will expire on March 7, 2014.</p>552 <p>This Internet-Draft will expire on March 8, 2014.</p> 553 553 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 554 554 <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 4244 4244 semantics into separate documents for the core features, conditional requests, partial requests, caching, and authentication. 4245 4245 The conformance language has been revised to clearly target requirements and the terminology has been improved to distinguish 4246 payload from representations and representations from resources. An algorithm has been added for determining if a payload 4247 is associated with a specific identifier (<a href="#identifying.payload" title="Identifying a Representation">Section 3.1.4.1</a>). 4246 payload from representations and representations from resources. 4248 4247 </p> 4249 4248 <p id="rfc.section.B.p.2">A new requirement has been added that semantics embedded in a URI should be disabled when those semantics are inconsistent 4250 with the request method, since this is a common cause of interoperability failure. 4251 </p> 4252 <p id="rfc.section.B.p.3"> The default charset of ISO-8859-1 for text media types has been removed; the default is now whatever the media type definition4253 says (<a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section 3.1.1.3</a>). Likewise, special treatment of ISO-8859-1 has been removed from the <a href="#header.accept-charset" class="smpl">Accept-Charset</a> header field (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.3" title="Accept-Charset">Section 5.3.3</a>).4254 < /p>4255 <p id="rfc.section.B.p.4">The Content-Disposition header field has been removed since it is now defined by <a href="#RFC6266" id="rfc.xref.RFC6266.1"><cite title="Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)">[RFC6266]</cite></a>.4249 with the request method, since this is a common cause of interoperability failure. (<a href="#resources" title="Resources">Section 2</a>) 4250 </p> 4251 <p id="rfc.section.B.p.3">An algorithm has been added for determining if a payload is associated with a specific identifier. (<a href="#identifying.payload" title="Identifying a Representation">Section 3.1.4.1</a>) 4252 </p> 4253 <p id="rfc.section.B.p.4">The default charset of ISO-8859-1 for text media types has been removed; the default is now whatever the media type definition 4254 says. Likewise, special treatment of ISO-8859-1 has been removed from the <a href="#header.accept-charset" class="smpl">Accept-Charset</a> header field. (<a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section 3.1.1.3</a> and <a href="#header.accept-charset" id="rfc.xref.header.accept-charset.3" title="Accept-Charset">Section 5.3.3</a>) 4256 4255 </p> 4257 4256 <p id="rfc.section.B.p.5">The definition of <a href="#header.content-location" class="smpl">Content-Location</a> has been changed to no longer affect the base URI for resolving relative URI references, due to poor implementation support 4258 and the undesirable effect of potentially breaking relative links in content-negotiated resources (<a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location">Section 3.1.4.2</a>). 4259 </p> 4260 <p id="rfc.section.B.p.6">The Content-MD5 header field has been removed because it was inconsistently implemented with respect to partial responses.</p> 4261 <p id="rfc.section.B.p.7">To be consistent with the method-neutral parsing algorithm of <a href="#Part1" id="rfc.xref.Part1.49"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, the definition of GET has been relaxed so that requests can have a body, even though a body has no meaning for GET (<a href="#GET" id="rfc.xref.GET.5" title="GET">Section 4.3.1</a>). 4262 </p> 4263 <p id="rfc.section.B.p.8">Servers are no longer required to handle all Content-* header fields and use of <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> has been explicitly banned in PUT requests (<a href="#PUT" id="rfc.xref.PUT.4" title="PUT">Section 4.3.4</a>). 4264 </p> 4265 <p id="rfc.section.B.p.9">Definition of the CONNECT method has been moved from <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> to this specification (<a href="#CONNECT" id="rfc.xref.CONNECT.3" title="CONNECT">Section 4.3.6</a>). 4266 </p> 4267 <p id="rfc.section.B.p.10">The <a href="#OPTIONS" class="smpl">OPTIONS</a> (<a href="#OPTIONS" id="rfc.xref.OPTIONS.4" title="OPTIONS">Section 4.3.7</a>) and <a href="#TRACE" class="smpl">TRACE</a> (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section 4.3.8</a>) request methods have been defined as being safe. 4268 </p> 4269 <p id="rfc.section.B.p.11">The definition of <a href="#header.expect" class="smpl">Expect</a> has been fixed to allow parameters for value-less expectations and simplified to allow trailing semicolons (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section 5.1.1</a>). 4270 </p> 4271 <p id="rfc.section.B.p.12">The <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section 5.1.2</a>) has been restricted to the <a href="#OPTIONS" class="smpl">OPTIONS</a> and <a href="#TRACE" class="smpl">TRACE</a> methods; previously, extension methods could have used it as well. 4272 </p> 4273 <p id="rfc.section.B.p.13">The "about:blank" URI has been suggested as a value for the <a href="#header.referer" class="smpl">Referer</a> header field when no referring URI is applicable, which distinguishes that case from others where the Referer field is not 4274 sent or has been removed (<a href="#header.referer" id="rfc.xref.header.referer.4" title="Referer">Section 5.5.2</a>). 4275 </p> 4276 <p id="rfc.section.B.p.14">The <a href="#status.201" class="smpl">201 (Created)</a> status description has been changed to allow for the possibility that more than one resource has been created (<a href="#status.201" id="rfc.xref.status.201.3" title="201 Created">Section 6.3.2</a>). 4277 </p> 4278 <p id="rfc.section.B.p.15">The definition of <a href="#status.203" class="smpl">203 (Non-Authoritative Information)</a> has been broadened to include cases of payload transformations as well (<a href="#status.203" id="rfc.xref.status.203.3" title="203 Non-Authoritative Information">Section 6.3.4</a>). 4279 </p> 4280 <p id="rfc.section.B.p.16">The redirect status codes <a href="#status.301" class="smpl">301</a>, <a href="#status.302" class="smpl">302</a>, and <a href="#status.307" class="smpl">307</a> no longer have normative requirements on response payloads and user interaction (<a href="#status.3xx" id="rfc.xref.status.3xx.1" title="Redirection 3xx">Section 6.4</a>). 4281 </p> 4282 <p id="rfc.section.B.p.17">The request methods that are safe to automatically redirect is no longer a closed set; user agents are able to make that determination 4283 based upon the request method semantics (<a href="#status.3xx" id="rfc.xref.status.3xx.2" title="Redirection 3xx">Section 6.4</a>). 4257 and the undesirable effect of potentially breaking relative links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location">Section 3.1.4.2</a>) 4258 </p> 4259 <p id="rfc.section.B.p.6">To be consistent with the method-neutral parsing algorithm of <a href="#Part1" id="rfc.xref.Part1.49"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, the definition of GET has been relaxed so that requests can have a body, even though a body has no meaning for GET (<a href="#GET" id="rfc.xref.GET.5" title="GET">Section 4.3.1</a>). 4260 </p> 4261 <p id="rfc.section.B.p.7">Servers are no longer required to handle all Content-* header fields and use of <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> has been explicitly banned in PUT requests (<a href="#PUT" id="rfc.xref.PUT.4" title="PUT">Section 4.3.4</a>). 4262 </p> 4263 <p id="rfc.section.B.p.8">Definition of the CONNECT method has been moved from <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> to this specification. (<a href="#CONNECT" id="rfc.xref.CONNECT.3" title="CONNECT">Section 4.3.6</a>) 4264 </p> 4265 <p id="rfc.section.B.p.9">The <a href="#OPTIONS" class="smpl">OPTIONS</a> and <a href="#TRACE" class="smpl">TRACE</a> request methods have been defined as being safe. (<a href="#OPTIONS" id="rfc.xref.OPTIONS.4" title="OPTIONS">Section 4.3.7</a> and <a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section 4.3.8</a>) 4266 </p> 4267 <p id="rfc.section.B.p.10">The definition of the <a href="#header.expect" class="smpl">Expect</a> header field has been fixed to allow parameters for value-less expectations and simplified to allow trailing semicolons. (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section 5.1.1</a>) 4268 </p> 4269 <p id="rfc.section.B.p.11">The <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field has been restricted to the <a href="#OPTIONS" class="smpl">OPTIONS</a> and <a href="#TRACE" class="smpl">TRACE</a> methods; previously, extension methods could have used it as well. (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section 5.1.2</a>) 4270 </p> 4271 <p id="rfc.section.B.p.12">The "about:blank" URI has been suggested as a value for the <a href="#header.referer" class="smpl">Referer</a> header field when no referring URI is applicable, which distinguishes that case from others where the Referer field is not 4272 sent or has been removed. (<a href="#header.referer" id="rfc.xref.header.referer.4" title="Referer">Section 5.5.2</a>) 4273 </p> 4274 <p id="rfc.section.B.p.13">The following status codes are now cacheable (that is, they can be stored and reused by a cache without explicit freshness 4275 information present): 204, 404, 405, 414, 501. (<a href="#status.codes" title="Response Status Codes">Section 6</a>) 4276 </p> 4277 <p id="rfc.section.B.p.14">The <a href="#status.201" class="smpl">201 (Created)</a> status description has been changed to allow for the possibility that more than one resource has been created. (<a href="#status.201" id="rfc.xref.status.201.3" title="201 Created">Section 6.3.2</a>) 4278 </p> 4279 <p id="rfc.section.B.p.15">The definition of <a href="#status.203" class="smpl">203 (Non-Authoritative Information)</a> has been broadened to include cases of payload transformations as well. (<a href="#status.203" id="rfc.xref.status.203.3" title="203 Non-Authoritative Information">Section 6.3.4</a>) 4280 </p> 4281 <p id="rfc.section.B.p.16">The set of request methods that are safe to automatically redirect is no longer closed; user agents are able to make that 4282 determination based upon the request method semantics. The redirect status codes <a href="#status.301" class="smpl">301</a>, <a href="#status.302" class="smpl">302</a>, and <a href="#status.307" class="smpl">307</a> no longer have normative requirements on response payloads and user interaction. (<a href="#status.3xx" id="rfc.xref.status.3xx.1" title="Redirection 3xx">Section 6.4</a>) 4283 </p> 4284 <p id="rfc.section.B.p.17">The status codes <a href="#status.301" class="smpl">301</a> and <a href="#status.302" class="smpl">302</a> have been changed to allow user agents to rewrite the method from POST to GET. (Sections <a href="#status.301" id="rfc.xref.status.301.3" title="301 Moved Permanently">6.4.2</a> and <a href="#status.302" id="rfc.xref.status.302.3" title="302 Found">6.4.3</a>) 4284 4285 </p> 4285 4286 <p id="rfc.section.B.p.18">The description of 303 (See Other) status code has been changed to allow it to be cached if explicit freshness information 4286 is given, and a specific definition has been added for a 303 response to GET (<a href="#status.303" id="rfc.xref.status.303.3" title="303 See Other">Section 6.4.4</a>). 4287 </p> 4288 <p id="rfc.section.B.p.19">The status codes <a href="#status.301" class="smpl">301</a> and <a href="#status.302" class="smpl">302</a> (sections <a href="#status.301" id="rfc.xref.status.301.3" title="301 Moved Permanently">6.4.2</a> and <a href="#status.302" id="rfc.xref.status.302.3" title="302 Found">6.4.3</a>) have been changed to allow user agents to rewrite the method from POST to GET. 4289 </p> 4290 <p id="rfc.section.B.p.20">The <a href="#status.305" class="smpl">305 (Use Proxy)</a> status code has been deprecated due to security concerns regarding in-band configuration of a proxy (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section 6.4.5</a>). 4291 </p> 4292 <p id="rfc.section.B.p.21">The <a href="#status.400" class="smpl">400 (Bad Request)</a> status code has been relaxed so that it isn't limited to syntax errors (<a href="#status.400" id="rfc.xref.status.400.3" title="400 Bad Request">Section 6.5.1</a>). 4293 </p> 4294 <p id="rfc.section.B.p.22">The <a href="#status.426" class="smpl">426 (Upgrade Required)</a> status code has been incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> (<a href="#status.426" id="rfc.xref.status.426.3" title="426 Upgrade Required">Section 6.5.15</a>). 4295 </p> 4296 <p id="rfc.section.B.p.23">The following status codes are now cacheable (that is, they can be stored and reused by a cache without explicit freshness 4297 information present): 204, 404, 405, 414, 501. 4287 is given, and a specific definition has been added for a 303 response to GET. (<a href="#status.303" id="rfc.xref.status.303.3" title="303 See Other">Section 6.4.4</a>) 4288 </p> 4289 <p id="rfc.section.B.p.19">The <a href="#status.305" class="smpl">305 (Use Proxy)</a> status code has been deprecated due to security concerns regarding in-band configuration of a proxy. (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section 6.4.5</a>) 4290 </p> 4291 <p id="rfc.section.B.p.20">The <a href="#status.400" class="smpl">400 (Bad Request)</a> status code has been relaxed so that it isn't limited to syntax errors. (<a href="#status.400" id="rfc.xref.status.400.3" title="400 Bad Request">Section 6.5.1</a>) 4292 </p> 4293 <p id="rfc.section.B.p.21">The <a href="#status.426" class="smpl">426 (Upgrade Required)</a> status code has been incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#status.426" id="rfc.xref.status.426.3" title="426 Upgrade Required">Section 6.5.15</a>) 4294 </p> 4295 <p id="rfc.section.B.p.22">The target of requirements on HTTP-date and the Date header field have been reduced to those systems generating the date, 4296 rather than all systems sending a date. (<a href="#origination.date" title="Origination Date">Section 7.1.1</a>) 4297 </p> 4298 <p id="rfc.section.B.p.23">The syntax of the <a href="#header.location" class="smpl">Location</a> header field has been changed to allow all URI references, including relative references and fragments, along with some clarifications 4299 as to when use of fragments would not be appropriate. (<a href="#header.location" id="rfc.xref.header.location.6" title="Location">Section 7.1.2</a>) 4298 4300 </p> 4299 4301 <p id="rfc.section.B.p.24"><a href="#header.allow" class="smpl">Allow</a> has been reclassified as a response header field, removing the option to specify it in a PUT request. Requirements relating 4300 to the content of Allow have been relaxed; correspondingly, clients are not required to always trust its value (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section 7.4.1</a>). 4301 </p> 4302 <p id="rfc.section.B.p.25">The target of requirements on HTTP-date and the Date header field have been reduced to those systems generating the date, 4303 rather than all systems sending a date (<a href="#origination.date" title="Origination Date">Section 7.1.1</a>). 4304 </p> 4305 <p id="rfc.section.B.p.26">The syntax of the <a href="#header.location" class="smpl">Location</a> header field has been changed to allow all URI references, including relative references and fragments, along with some clarifications 4306 as to when use of fragments would not be appropriate (<a href="#header.location" id="rfc.xref.header.location.6" title="Location">Section 7.1.2</a>). 4307 </p> 4308 <p id="rfc.section.B.p.27">A Method Registry has been defined (<a href="#method.registry" title="Method Registry">Section 8.1</a>). 4309 </p> 4310 <p id="rfc.section.B.p.28">The Status Code Registry (<a href="#status.code.registry" title="Status Code Registry">Section 8.2</a>) has been redefined by this specification; previously, it was defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. 4311 </p> 4312 <p id="rfc.section.B.p.29">Registration of Content Codings has been changed to require IETF Review (<a href="#content.coding.registry" title="Content Coding Registry">Section 8.4</a>). 4313 </p> 4302 to the content of Allow have been relaxed; correspondingly, clients are not required to always trust its value. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section 7.4.1</a>) 4303 </p> 4304 <p id="rfc.section.B.p.25">A Method Registry has been defined. (<a href="#method.registry" title="Method Registry">Section 8.1</a>) 4305 </p> 4306 <p id="rfc.section.B.p.26">The Status Code Registry has been redefined by this specification; previously, it was defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#status.code.registry" title="Status Code Registry">Section 8.2</a>) 4307 </p> 4308 <p id="rfc.section.B.p.27">Registration of Content Codings has been changed to require IETF Review. (<a href="#content.coding.registry" title="Content Coding Registry">Section 8.4</a>) 4309 </p> 4310 <p id="rfc.section.B.p.28">The Content-Disposition header field has been removed since it is now defined by <a href="#RFC6266" id="rfc.xref.RFC6266.1"><cite title="Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)">[RFC6266]</cite></a>. 4311 </p> 4312 <p id="rfc.section.B.p.29">The Content-MD5 header field has been removed because it was inconsistently implemented with respect to partial responses.</p> 4314 4313 <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <a id="imported.abnf" href="#imported.abnf">Imported ABNF</a></h1> 4315 4314 <p id="rfc.section.C.p.1">The following core rules are included by reference, as defined in <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a> of <a href="#RFC5234" id="rfc.xref.RFC5234.3"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG … … 4569 4568 <li>306 (Unused) (status code) <a href="#rfc.iref.75"><b>6.4.6</b></a>, <a href="#rfc.xref.status.306.1">8.2.3</a></li> 4570 4569 <li>307 Temporary Redirect (status code) <a href="#rfc.xref.status.307.1">6.1</a>, <a href="#rfc.iref.75"><b>6.4.7</b></a>, <a href="#rfc.xref.status.307.2">8.2.3</a></li> 4571 <li>3xx Redirection (status code class) <a href="#rfc.iref.74"><b>6.4</b></a>, <a href="#rfc.xref.status.3xx.1">B</a> , <a href="#rfc.xref.status.3xx.2">B</a></li>4570 <li>3xx Redirection (status code class) <a href="#rfc.iref.74"><b>6.4</b></a>, <a href="#rfc.xref.status.3xx.1">B</a></li> 4572 4571 </ul> 4573 4572 </li> … … 4911 4910 <li>1xx Informational <a href="#rfc.iref.s.3"><b>6.2</b></a></li> 4912 4911 <li>2xx Successful <a href="#rfc.iref.s.4"><b>6.3</b></a></li> 4913 <li>3xx Redirection <a href="#rfc.iref.s.5"><b>6.4</b></a>, <a href="#rfc.xref.status.3xx.1">B</a> , <a href="#rfc.xref.status.3xx.2">B</a></li>4912 <li>3xx Redirection <a href="#rfc.iref.s.5"><b>6.4</b></a>, <a href="#rfc.xref.status.3xx.1">B</a></li> 4914 4913 <li>4xx Client Error <a href="#rfc.iref.s.6"><b>6.5</b></a></li> 4915 4914 <li>5xx Server Error <a href="#rfc.iref.s.7"><b>6.6</b></a></li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r2367 r2369 5952 5952 improved to distinguish payload from representations and representations 5953 5953 from resources. 5954 An algorithm has been added for determining if a payload is associated with5955 a specific identifier (<xref target="identifying.payload" />).5956 5954 </t> 5957 5955 <t> … … 5959 5957 should be disabled when those semantics are inconsistent with the request 5960 5958 method, since this is a common cause of interoperability failure. 5959 (<xref target="resources"/>) 5960 </t> 5961 <t> 5962 An algorithm has been added for determining if a payload is associated with 5963 a specific identifier. 5964 (<xref target="identifying.payload" />) 5961 5965 </t> 5962 5966 <t> 5963 5967 The default charset of ISO-8859-1 for text media types has been removed; 5964 the default is now whatever the media type definition says 5965 (<xref target="canonicalization.and.text.defaults"/>). Likewise, 5968 the default is now whatever the media type definition says. Likewise, 5966 5969 special treatment of ISO-8859-1 has been removed from the 5967 <x:ref>Accept-Charset</x:ref> header field 5968 (<xref target="header.accept-charset"/>). 5969 </t> 5970 <t> 5971 The Content-Disposition header field has been removed since it is now 5972 defined by <xref target="RFC6266"/>. 5970 <x:ref>Accept-Charset</x:ref> header field. 5971 (<xref target="canonicalization.and.text.defaults"/> and <xref target="header.accept-charset"/>) 5973 5972 </t> 5974 5973 <t> … … 5976 5975 longer affect the base URI for resolving relative URI references, due to 5977 5976 poor implementation support and the undesirable effect of potentially 5978 breaking relative links in content-negotiated resources 5979 (<xref target="header.content-location"/>). 5980 </t> 5981 <t> 5982 The Content-MD5 header field has been removed because it was inconsistently 5983 implemented with respect to partial responses. 5977 breaking relative links in content-negotiated resources. 5978 (<xref target="header.content-location"/>) 5984 5979 </t> 5985 5980 <t> … … 5996 5991 <t> 5997 5992 Definition of the CONNECT method has been moved from 5998 <xref target="RFC2817"/> to this specification (<xref target="CONNECT"/>).5999 </t> 6000 < t>6001 The <x:ref>OPTIONS</x:ref> (<xref target="OPTIONS"/>) and 6002 <x:ref>TRACE</x:ref> (<xref target="TRACE"/>)request methods have been5993 <xref target="RFC2817"/> to this specification. 5994 (<xref target="CONNECT"/>) 5995 </t> 5996 <t> 5997 The <x:ref>OPTIONS</x:ref> and <x:ref>TRACE</x:ref> request methods have been 6003 5998 defined as being safe. 6004 </t> 6005 <t> 6006 The definition of <x:ref>Expect</x:ref> has been fixed to allow 5999 (<xref target="OPTIONS"/> and <xref target="TRACE"/>) 6000 </t> 6001 <t> 6002 The definition of the <x:ref>Expect</x:ref> header field has been fixed to allow 6007 6003 parameters for value-less expectations and simplified to allow trailing 6008 semicolons (<xref target="header.expect"/>).6009 </t> 6010 < t>6011 The <x:ref>Max-Forwards</x:ref> header field 6012 (<xref target="header.max-forwards"/>)has been restricted to the6004 semicolons. 6005 (<xref target="header.expect"/>) 6006 </t> 6007 <t> 6008 The <x:ref>Max-Forwards</x:ref> header field has been restricted to the 6013 6009 <x:ref>OPTIONS</x:ref> and <x:ref>TRACE</x:ref> methods; previously, 6014 6010 extension methods could have used it as well. 6011 (<xref target="header.max-forwards"/>) 6015 6012 </t> 6016 6013 <t> … … 6018 6015 <x:ref>Referer</x:ref> header field when no referring URI is applicable, 6019 6016 which distinguishes that case from others where the Referer field is 6020 not sent or has been removed (<xref target="header.referer"/>). 6021 </t> 6022 <t> 6023 The <x:ref>201 (Created)</x:ref> status description has been changed to 6024 allow for the possibility that more than one resource has been created 6025 (<xref target="status.201"/>). 6026 </t> 6027 <t> 6028 The definition of <x:ref>203 (Non-Authoritative Information)</x:ref> has 6029 been broadened to include cases of payload transformations as well 6030 (<xref target="status.203"/>). 6031 </t> 6032 <t> 6033 The redirect status codes <x:ref>301</x:ref>, <x:ref>302</x:ref>, and 6034 <x:ref>307</x:ref> no longer have normative requirements on response 6035 payloads and user interaction (<xref target="status.3xx"/>). 6036 </t> 6037 <t> 6038 The request methods that are safe to automatically redirect is no 6039 longer a closed set; user agents are able to make that determination 6040 based upon the request method semantics (<xref target="status.3xx"/>). 6041 </t> 6042 <t> 6043 The description of 303 (See Other) status code has been changed to allow 6044 it to be cached if explicit freshness information is given, and a specific 6045 definition has been added for a 303 response to GET 6046 (<xref target="status.303"/>). 6047 </t> 6048 <t> 6049 The status codes <x:ref>301</x:ref> and <x:ref>302</x:ref> 6050 (sections <xref format="counter" target="status.301"/> and 6051 <xref format="counter" target="status.302"/>) have been changed to allow 6052 user agents to rewrite the method from POST to GET. 6053 </t> 6054 <t> 6055 The <x:ref>305 (Use Proxy)</x:ref> status code has been deprecated due to 6056 security concerns regarding in-band configuration of a proxy 6057 (<xref target="status.305"/>). 6058 </t> 6059 <t> 6060 The <x:ref>400 (Bad Request)</x:ref> status code has been relaxed so that 6061 it isn't limited to syntax errors (<xref target="status.400"/>). 6062 </t> 6063 <t> 6064 The <x:ref>426 (Upgrade Required)</x:ref> status code has been incorporated 6065 from <xref target="RFC2817"/> (<xref target="status.426"/>). 6017 not sent or has been removed. 6018 (<xref target="header.referer"/>) 6066 6019 </t> 6067 6020 <t> … … 6069 6022 reused by a cache without explicit freshness information present): 204, 404, 6070 6023 405, 414, 501. 6024 (<xref target="status.codes"/>) 6025 </t> 6026 <t> 6027 The <x:ref>201 (Created)</x:ref> status description has been changed to 6028 allow for the possibility that more than one resource has been created. 6029 (<xref target="status.201"/>) 6030 </t> 6031 <t> 6032 The definition of <x:ref>203 (Non-Authoritative Information)</x:ref> has 6033 been broadened to include cases of payload transformations as well. 6034 (<xref target="status.203"/>) 6035 </t> 6036 <t> 6037 The set of request methods that are safe to automatically redirect is no 6038 longer closed; user agents are able to make that determination 6039 based upon the request method semantics. 6040 The redirect status codes <x:ref>301</x:ref>, <x:ref>302</x:ref>, and 6041 <x:ref>307</x:ref> no longer have normative requirements on response 6042 payloads and user interaction. 6043 (<xref target="status.3xx"/>) 6044 </t> 6045 <t> 6046 The status codes <x:ref>301</x:ref> and <x:ref>302</x:ref> have been 6047 changed to allow user agents to rewrite the method from POST to GET. 6048 (Sections <xref format="counter" target="status.301"/> and 6049 <xref format="counter" target="status.302"/>) 6050 </t> 6051 <t> 6052 The description of 303 (See Other) status code has been changed to allow 6053 it to be cached if explicit freshness information is given, and a specific 6054 definition has been added for a 303 response to GET. 6055 (<xref target="status.303"/>) 6056 </t> 6057 <t> 6058 The <x:ref>305 (Use Proxy)</x:ref> status code has been deprecated due to 6059 security concerns regarding in-band configuration of a proxy. 6060 (<xref target="status.305"/>) 6061 </t> 6062 <t> 6063 The <x:ref>400 (Bad Request)</x:ref> status code has been relaxed so that 6064 it isn't limited to syntax errors. 6065 (<xref target="status.400"/>) 6066 </t> 6067 <t> 6068 The <x:ref>426 (Upgrade Required)</x:ref> status code has been incorporated 6069 from <xref target="RFC2817"/>. 6070 (<xref target="status.426"/>) 6071 </t> 6072 <t> 6073 The target of requirements on HTTP-date and the Date header field have been 6074 reduced to those systems generating the date, rather than all systems 6075 sending a date. 6076 (<xref target="origination.date"/>) 6077 </t> 6078 <t> 6079 The syntax of the <x:ref>Location</x:ref> header field has been changed 6080 to allow all URI references, including relative references and fragments, 6081 along with some clarifications as to when use of fragments would not be 6082 appropriate. 6083 (<xref target="header.location"/>) 6071 6084 </t> 6072 6085 <t> … … 6074 6087 removing the option to specify it in a PUT request. 6075 6088 Requirements relating to the content of Allow have been relaxed; 6076 correspondingly, clients are not required to always trust its value 6077 (<xref target="header.allow"/>). 6078 </t> 6079 <t> 6080 The target of requirements on HTTP-date and the Date header field have been 6081 reduced to those systems generating the date, rather than all systems 6082 sending a date (<xref target="origination.date"/>). 6083 </t> 6084 <t> 6085 The syntax of the <x:ref>Location</x:ref> header field has been changed 6086 to allow all URI references, including relative references and fragments, 6087 along with some clarifications as to when use of fragments would not be 6088 appropriate (<xref target="header.location"/>). 6089 </t> 6090 <t> 6091 A Method Registry has been defined (<xref target="method.registry"/>). 6092 </t> 6093 <t> 6094 The Status Code Registry (<xref target="status.code.registry"/>) has been 6089 correspondingly, clients are not required to always trust its value. 6090 (<xref target="header.allow"/>) 6091 </t> 6092 <t> 6093 A Method Registry has been defined. 6094 (<xref target="method.registry"/>) 6095 </t> 6096 <t> 6097 The Status Code Registry has been 6095 6098 redefined by this specification; previously, it was defined in 6096 6099 <xref target="RFC2817" x:fmt="of" x:sec="7.1"/>. 6097 </t> 6098 <t> 6099 Registration of Content Codings has been changed to require IETF Review 6100 (<xref target="content.coding.registry"/>). 6100 (<xref target="status.code.registry"/>) 6101 </t> 6102 <t> 6103 Registration of Content Codings has been changed to require IETF Review. 6104 (<xref target="content.coding.registry"/>) 6105 </t> 6106 <t> 6107 The Content-Disposition header field has been removed since it is now 6108 defined by <xref target="RFC6266"/>. 6109 </t> 6110 <t> 6111 The Content-MD5 header field has been removed because it was inconsistently 6112 implemented with respect to partial responses. 6101 6113 </t> 6102 6114 </section> -
draft-ietf-httpbis/latest/p4-conditional.html
r2365 r2369 446 446 } 447 447 @bottom-center { 448 content: "Expires March 5, 2014";448 content: "Expires March 8, 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-p4-conditional-latest"> 491 <meta name="dct.issued" scheme="ISO8601" content="2013-09-0 1">491 <meta name="dct.issued" scheme="ISO8601" content="2013-09-04"> 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 HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false."> … … 515 515 </tr> 516 516 <tr> 517 <td class="left">Expires: March 5, 2014</td>518 <td class="right">September 1, 2013</td>517 <td class="left">Expires: March 8, 2014</td> 518 <td class="right">September 4, 2013</td> 519 519 </tr> 520 520 </tbody> … … 543 543 in progress”. 544 544 </p> 545 <p>This Internet-Draft will expire on March 5, 2014.</p>545 <p>This Internet-Draft will expire on March 8, 2014.</p> 546 546 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 547 547 <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1338 1338 <p id="rfc.section.A.p.1">The definition of validator weakness has been expanded and clarified. (<a href="#weak.and.strong.validators" title="Weak versus Strong">Section 2.1</a>) 1339 1339 </p> 1340 <p id="rfc.section.A.p.2">Weak entity-tags are now allowed in all requests except range requests (Sections <a href="#weak.and.strong.validators" title="Weak versus Strong">2.1</a> and <a href="#header.if-none-match" id="rfc.xref.header.if-none-match.2" title="If-None-Match">3.2</a>).1340 <p id="rfc.section.A.p.2">Weak entity-tags are now allowed in all requests except range requests. (Sections <a href="#weak.and.strong.validators" title="Weak versus Strong">2.1</a> and <a href="#header.if-none-match" id="rfc.xref.header.if-none-match.2" title="If-None-Match">3.2</a>) 1341 1341 </p> 1342 1342 <p id="rfc.section.A.p.3">The <a href="#header.etag" class="smpl">ETag</a> header field ABNF has been changed to not use quoted-string, thus avoiding escaping issues. (<a href="#header.etag" id="rfc.xref.header.etag.3" title="ETag">Section 2.3</a>) -
draft-ietf-httpbis/latest/p4-conditional.xml
r2365 r2369 1517 1517 </t> 1518 1518 <t> 1519 Weak entity-tags are now allowed in all requests except range requests 1519 Weak entity-tags are now allowed in all requests except range requests. 1520 1520 (Sections <xref target="weak.and.strong.validators" format="counter"/> and 1521 <xref target="header.if-none-match" format="counter"/>) .1521 <xref target="header.if-none-match" format="counter"/>) 1522 1522 </t> 1523 1523 <t> -
draft-ietf-httpbis/latest/p5-range.html
r2365 r2369 446 446 } 447 447 @bottom-center { 448 content: "Expires March 5, 2014";448 content: "Expires March 8, 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-0 1">491 <meta name="dct.issued" scheme="ISO8601" content="2013-09-04"> 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 5, 2014</td>517 <td class="left">Expires: March 8, 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, 2013</td>526 <td class="right">September 4, 2013</td> 527 527 </tr> 528 528 </tbody> … … 549 549 in progress”. 550 550 </p> 551 <p>This Internet-Draft will expire on March 5, 2014.</p>551 <p>This Internet-Draft will expire on March 8, 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> … … 1225 1225 --THIS_STRING_SEPARATES-- 1226 1226 </pre><h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h1> 1227 <p id="rfc.section.B.p.1"> A weak validator cannot be used in a <a href="#status.206" class="smpl">206</a> response. (<a href="#status.206" id="rfc.xref.status.206.2" title="206 Partial Content">Section 4.1</a>)1228 </p>1229 < p id="rfc.section.B.p.2">The Content-Range header field only has meaning when the status code explicitly defines its use. (<a href="#header.content-range" id="rfc.xref.header.content-range.4" title="Content-Range">Section 4.2</a>)1230 < /p>1231 < p id="rfc.section.B.p.3">Servers are given more leeway in how they respond to a range request, in order to mitigate abuse by malicious (or just greedy)1232 clients.1233 </p> 1234 <p id="rfc.section.B.p.4"> multipart/byteranges can consist of a single part. (<a href="#internet.media.type.multipart.byteranges" title="Internet Media Type multipart/byteranges">Appendix A</a>)1235 </p> 1236 <p id="rfc.section.B.p.5"> This specification introduces a Range Unit Registry. (<a href="#range.unit.registry" title="Range Unit Registry">Section 5.1</a>)1227 <p id="rfc.section.B.p.1">Servers are given more leeway in how they respond to a range request, in order to mitigate abuse by malicious (or just greedy) 1228 clients. (<a href="#header.range" id="rfc.xref.header.range.5" title="Range">Section 3.1</a>) 1229 </p> 1230 <p id="rfc.section.B.p.2">A weak validator cannot be used in a <a href="#status.206" class="smpl">206</a> response. (<a href="#status.206" id="rfc.xref.status.206.2" title="206 Partial Content">Section 4.1</a>) 1231 </p> 1232 <p id="rfc.section.B.p.3">The Content-Range header field only has meaning when the status code explicitly defines its use. (<a href="#header.content-range" id="rfc.xref.header.content-range.4" title="Content-Range">Section 4.2</a>) 1233 </p> 1234 <p id="rfc.section.B.p.4">This specification introduces a Range Unit Registry. (<a href="#range.unit.registry" title="Range Unit Registry">Section 5.1</a>) 1235 </p> 1236 <p id="rfc.section.B.p.5">multipart/byteranges can consist of a single part. (<a href="#internet.media.type.multipart.byteranges" title="Internet Media Type multipart/byteranges">Appendix A</a>) 1237 1237 </p> 1238 1238 <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <a id="imported.abnf" href="#imported.abnf">Imported ABNF</a></h1> … … 1453 1453 </li> 1454 1454 <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul> 1455 <li>Range header field <a href="#rfc.xref.header.range.1">2</a>, <a href="#rfc.iref.r.1"><b>3.1</b></a>, <a href="#rfc.xref.header.range.2">4.1</a>, <a href="#rfc.xref.header.range.3">4.4</a>, <a href="#rfc.xref.header.range.4">5.3</a> </li>1455 <li>Range header field <a href="#rfc.xref.header.range.1">2</a>, <a href="#rfc.iref.r.1"><b>3.1</b></a>, <a href="#rfc.xref.header.range.2">4.1</a>, <a href="#rfc.xref.header.range.3">4.4</a>, <a href="#rfc.xref.header.range.4">5.3</a>, <a href="#rfc.xref.header.range.5">B</a></li> 1456 1456 <li><em>RFC2046</em> <a href="#RFC2046"><b>8.1</b></a>, <a href="#rfc.xref.RFC2046.1">A</a>, <a href="#rfc.xref.RFC2046.2">A</a><ul> 1457 1457 <li><em>Section 5.1</em> <a href="#rfc.xref.RFC2046.1">A</a></li> -
draft-ietf-httpbis/latest/p5-range.xml
r2365 r2369 1358 1358 1359 1359 <section title="Changes from RFC 2616" anchor="changes.from.rfc.2616"> 1360 1360 <t> 1361 Servers are given more leeway in how they respond to a range request, 1362 in order to mitigate abuse by malicious (or just greedy) clients. 1363 (<xref target="header.range"/>) 1364 </t> 1361 1365 <t> 1362 1366 A weak validator cannot be used in a <x:ref>206</x:ref> response. … … 1369 1373 </t> 1370 1374 <t> 1371 Servers are given more leeway in how they respond to a range request,1372 in order to mitigate abuse by malicious (or just greedy) clients.1375 This specification introduces a Range Unit Registry. 1376 (<xref target="range.unit.registry"/>) 1373 1377 </t> 1374 1378 <t> 1375 1379 multipart/byteranges can consist of a single part. 1376 1380 (<xref target="internet.media.type.multipart.byteranges"/>) 1377 </t>1378 <t>1379 This specification introduces a Range Unit Registry.1380 (<xref target="range.unit.registry"/>)1381 1381 </t> 1382 1382 </section> -
draft-ietf-httpbis/latest/p6-cache.html
r2368 r2369 1859 1859 </div> 1860 1860 <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h1> 1861 <p id="rfc.section.A.p.1">Caching-related text has been substantially rewritten for clarity.</p> 1862 <p id="rfc.section.A.p.2">The algorithm for calculating age is now less conservative. (<a href="#age.calculations" title="Calculating Age">Section 4.1.3</a>) 1863 </p> 1864 <p id="rfc.section.A.p.3">Caches are now required to handle dates with timezones as if they're invalid, because it's not possible to accurately guess. 1865 (<a href="#age.calculations" title="Calculating Age">Section 4.1.3</a>) 1866 </p> 1867 <p id="rfc.section.A.p.4">The <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> response header field is no longer used to determine the appropriate response to use when validating. (<a href="#validation.model" title="Validation">Section 4.2</a>) 1868 </p> 1869 <p id="rfc.section.A.p.5">The algorithm for selecting a cached negotiated response to use has been clarified in several ways. In particular, it now 1861 <p id="rfc.section.A.p.1">The specification has been substantially rewritten for clarity.</p> 1862 <p id="rfc.section.A.p.2">The conditions under which an authenticated response can be cached have been clarified. (<a href="#caching.authenticated.responses" title="Storing Responses to Authenticated Requests">Section 3.2</a>) 1863 </p> 1864 <p id="rfc.section.A.p.3">New status codes can now define that caches are allowed to use heuristic freshness with them. Caches are now allowed to calculate 1865 heuristic freshness for URIs with query components. (<a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a>) 1866 </p> 1867 <p id="rfc.section.A.p.4">The algorithm for calculating age is now less conservative. Caches are now required to handle dates with timezones as if they're 1868 invalid, because it's not possible to accurately guess. (<a href="#age.calculations" title="Calculating Age">Section 4.1.3</a>) 1869 </p> 1870 <p id="rfc.section.A.p.5">The <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> response header field is no longer used to determine the appropriate response to use when validating. (<a href="#validation.model" title="Validation">Section 4.2</a>) 1871 </p> 1872 <p id="rfc.section.A.p.6">The algorithm for selecting a cached negotiated response to use has been clarified in several ways. In particular, it now 1870 1873 explicitly allows header-specific canonicalization when processing selecting header fields. (<a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section 4.3</a>) 1871 1874 </p> 1872 <p id="rfc.section.A.p.6">Requirements regarding denial of service attack avoidance when performing invalidation have been clarified. (<a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 6</a>) 1873 </p> 1874 <p id="rfc.section.A.p.7">Cache invalidation only occurs when a successful response is received. (<a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 6</a>) 1875 </p> 1876 <p id="rfc.section.A.p.8">The conditions under which an authenticated response can be cached have been clarified. (<a href="#caching.authenticated.responses" title="Storing Responses to Authenticated Requests">Section 3.2</a>) 1877 </p> 1878 <p id="rfc.section.A.p.9">The one-year limit on Expires header field values has been removed; instead, the reasoning for using a sensible value is given. 1879 (<a href="#header.expires" id="rfc.xref.header.expires.5" title="Expires">Section 7.3</a>) 1880 </p> 1881 <p id="rfc.section.A.p.10">The Pragma header field is now only defined for backwards compatibility; future pragmas are deprecated. (<a href="#header.pragma" id="rfc.xref.header.pragma.3" title="Pragma">Section 7.4</a>) 1882 </p> 1883 <p id="rfc.section.A.p.11">Cache directives are explicitly defined to be case-insensitive. (<a href="#header.cache-control" id="rfc.xref.header.cache-control.3" title="Cache-Control">Section 7.2</a>) 1884 </p> 1885 <p id="rfc.section.A.p.12">Handling of multiple instances of cache directives when only one is expected is now defined. (<a href="#header.cache-control" id="rfc.xref.header.cache-control.4" title="Cache-Control">Section 7.2</a>) 1886 </p> 1887 <p id="rfc.section.A.p.13">The qualified forms of the private and no-cache cache directives are noted to not be widely implemented; e.g., "private=foo" 1875 <p id="rfc.section.A.p.7">Requirements regarding denial of service attack avoidance when performing invalidation have been clarified. (<a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 6</a>) 1876 </p> 1877 <p id="rfc.section.A.p.8">Cache invalidation only occurs when a successful response is received. (<a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 6</a>) 1878 </p> 1879 <p id="rfc.section.A.p.9">Cache directives are explicitly defined to be case-insensitive. Handling of multiple instances of cache directives when only 1880 one is expected is now defined. (<a href="#header.cache-control" id="rfc.xref.header.cache-control.3" title="Cache-Control">Section 7.2</a>) 1881 </p> 1882 <p id="rfc.section.A.p.10">The "no-store" cache request directive doesn't apply to responses; i.e., a cache can satisfy a request with no-store on it, 1883 and does not invalidate it. (<a href="#cache-request-directive.no-store" title="no-store">Section 7.2.1.5</a>) 1884 </p> 1885 <p id="rfc.section.A.p.11">The qualified forms of the private and no-cache cache directives are noted to not be widely implemented; e.g., "private=foo" 1888 1886 is interpreted by many caches as simply "private". Additionally, the meaning of the qualified form of no-cache has been clarified. 1889 1887 (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section 7.2.2</a>) 1890 1888 </p> 1891 <p id="rfc.section.A.p.14">The "no-store" cache request directive doesn't apply to responses; i.e., a cache can satisfy a request with no-store on it, 1892 and does not invalidate it. (<a href="#cache-request-directive.no-store" title="no-store">Section 7.2.1.5</a>) 1893 </p> 1894 <p id="rfc.section.A.p.15">The "no-cache" response cache directive's meaning has been clarified. (<a href="#cache-response-directive.no-cache" title="no-cache">Section 7.2.2.2</a>) 1895 </p> 1896 <p id="rfc.section.A.p.16">New status codes can now define that caches are allowed to use heuristic freshness with them. (<a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a>) 1897 </p> 1898 <p id="rfc.section.A.p.17">Caches are now allow to calculate heuristic freshness for URLs with query components. (<a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a>) 1899 </p> 1900 <p id="rfc.section.A.p.18">Some requirements regarding production of the <a href="#header.warning" class="smpl">Warning</a> header fields have been relaxed, as it is not widely implemented. Furthermore, presence of the warn-date component has been 1889 <p id="rfc.section.A.p.12">The "no-cache" response cache directive's meaning has been clarified. (<a href="#cache-response-directive.no-cache" title="no-cache">Section 7.2.2.2</a>) 1890 </p> 1891 <p id="rfc.section.A.p.13">The one-year limit on <a href="#header.expires" class="smpl">Expires</a> header field values has been removed; instead, the reasoning for using a sensible value is given. (<a href="#header.expires" id="rfc.xref.header.expires.5" title="Expires">Section 7.3</a>) 1892 </p> 1893 <p id="rfc.section.A.p.14">The <a href="#header.pragma" class="smpl">Pragma</a> header field is now only defined for backwards compatibility; future pragmas are deprecated. (<a href="#header.pragma" id="rfc.xref.header.pragma.3" title="Pragma">Section 7.4</a>) 1894 </p> 1895 <p id="rfc.section.A.p.15">Some requirements regarding production of the <a href="#header.warning" class="smpl">Warning</a> header fields have been relaxed, as it is not widely implemented. Furthermore, presence of the warn-date component has been 1901 1896 made required (dropping requirements specific to HTTP/1.0). Finally, the <a href="#header.warning" class="smpl">Warning</a> header field no longer uses RFC 2047 encoding, nor allows multiple languages, as these aspects were not implemented. (<a href="#header.warning" id="rfc.xref.header.warning.6" title="Warning">Section 7.5</a>) 1902 1897 </p> 1903 <p id="rfc.section.A.p.1 9">This specification introduces the Cache Directive and Warn Code Registries, and defines considerations for new cache directives.1904 (<a href="#cache. control.extensions" title="Cache Control Extensions">Section 7.2.3</a> and <a href="#warn.code.extensions" title="Warn Code Extensions">Section 7.5.8</a>)1898 <p id="rfc.section.A.p.16">This specification introduces the Cache Directive and Warn Code Registries, and defines considerations for new cache directives. 1899 (<a href="#cache.directive.registry" title="Cache Directive Registry">Section 9.1</a> and <a href="#warn.code.registry" title="Warn Code Registry">Section 9.2</a>) 1905 1900 </p> 1906 1901 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="imported.abnf" href="#imported.abnf">Imported ABNF</a></h1> … … 2062 2057 <li>cache entry <a href="#rfc.iref.c.2">2</a></li> 2063 2058 <li>cache key <a href="#rfc.iref.c.3">2</a>, <a href="#rfc.iref.c.4">2</a></li> 2064 <li>Cache-Control header field <a href="#rfc.xref.header.cache-control.1">3</a>, <a href="#rfc.iref.c.5"><b>7.2</b></a>, <a href="#rfc.xref.header.cache-control.2">9.3</a>, <a href="#rfc.xref.header.cache-control.3">A</a> , <a href="#rfc.xref.header.cache-control.4">A</a></li>2059 <li>Cache-Control header field <a href="#rfc.xref.header.cache-control.1">3</a>, <a href="#rfc.iref.c.5"><b>7.2</b></a>, <a href="#rfc.xref.header.cache-control.2">9.3</a>, <a href="#rfc.xref.header.cache-control.3">A</a></li> 2065 2060 </ul> 2066 2061 </li> -
draft-ietf-httpbis/latest/p6-cache.xml
r2368 r2369 2363 2363 <section anchor="changes.from.rfc.2616" title="Changes from RFC 2616"> 2364 2364 <t> 2365 Caching-related text has been substantially rewritten for clarity. 2365 The specification has been substantially rewritten for clarity. 2366 </t> 2367 <t> 2368 The conditions under which an authenticated response can be cached have been 2369 clarified. 2370 (<xref target="caching.authenticated.responses" />) 2371 </t> 2372 <t> 2373 New status codes can now define that caches are allowed to use heuristic 2374 freshness with them. 2375 Caches are now allowed to calculate heuristic freshness for URIs with query 2376 components. 2377 (<xref target="heuristic.freshness" />) 2366 2378 </t> 2367 2379 <t> 2368 2380 The algorithm for calculating age is now less conservative. 2369 (<xref target="age.calculations"/>)2370 </t>2371 <t>2372 2381 Caches are now required to handle dates with timezones as if they're 2373 2382 invalid, because it's not possible to accurately guess. … … 2395 2404 </t> 2396 2405 <t> 2397 The conditions under which an authenticated response can be cached have been2398 clarified.2399 (<xref target="caching.authenticated.responses" />)2400 </t>2401 <t>2402 The one-year limit on Expires header field values has been removed; instead,2403 the reasoning for using a sensible value is given.2404 (<xref target="header.expires" />)2405 </t>2406 <t>2407 The Pragma header field is now only defined for backwards compatibility;2408 future pragmas are deprecated.2409 (<xref target="header.pragma" />)2410 </t>2411 <t>2412 2406 Cache directives are explicitly defined to be case-insensitive. 2413 (<xref target="header.cache-control" />)2414 </t>2415 <t>2416 2407 Handling of multiple instances of cache directives when only one is 2417 2408 expected is now defined. 2418 2409 (<xref target="header.cache-control" />) 2410 </t> 2411 <t> 2412 The "no-store" cache request directive doesn't apply to responses; i.e., 2413 a cache can satisfy a request with no-store on it, and does not invalidate 2414 it. 2415 (<xref target="cache-request-directive.no-store" />) 2419 2416 </t> 2420 2417 <t> … … 2426 2423 </t> 2427 2424 <t> 2428 The "no-store" cache request directive doesn't apply to responses; i.e.,2429 a cache can satisfy a request with no-store on it, and does not invalidate2430 it.2431 (<xref target="cache-request-directive.no-store" />)2432 </t>2433 <t>2434 2425 The "no-cache" response cache directive's meaning has been clarified. 2435 2426 (<xref target="cache-response-directive.no-cache" />) 2436 2427 </t> 2437 2428 <t> 2438 New status codes can now define that caches are allowed to use heuristic2439 freshness with them.2440 (<xref target="he uristic.freshness" />)2441 </t> 2442 <t> 2443 Caches are now allow to calculate heuristic freshness for URLs with query2444 components.2445 (<xref target="he uristic.freshness" />)2429 The one-year limit on <x:ref>Expires</x:ref> header field values has been removed; instead, 2430 the reasoning for using a sensible value is given. 2431 (<xref target="header.expires" />) 2432 </t> 2433 <t> 2434 The <x:ref>Pragma</x:ref> header field is now only defined for backwards compatibility; 2435 future pragmas are deprecated. 2436 (<xref target="header.pragma" />) 2446 2437 </t> 2447 2438 <t> … … 2457 2448 This specification introduces the Cache Directive and Warn Code Registries, 2458 2449 and defines considerations for new cache directives. 2459 (<xref target="cache. control.extensions"/> and <xref target="warn.code.extensions"/>)2450 (<xref target="cache.directive.registry"/> and <xref target="warn.code.registry"/>) 2460 2451 </t> 2461 2452 </section>
Note: See TracChangeset
for help on using the changeset viewer.