Changeset 2369


Ignore:
Timestamp:
04/09/13 11:49:18 (9 years ago)
Author:
julian.reschke@…
Message:

(editorial) reorganize/tune changes sections (see #493)

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

Legend:

Unmodified
Added
Removed

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

    r2365 r2369  
    446446  }
    447447  @bottom-center {
    448        content: "Expires March 5, 2014";
     448       content: "Expires March 8, 2014";
    449449  }
    450450  @bottom-right {
    … …  
    488488      <meta name="dct.creator" content="Reschke, J. F.">
    489489      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    490       <meta name="dct.issued" scheme="ISO8601" content="2013-09-01">
     490      <meta name="dct.issued" scheme="ISO8601" content="2013-09-04">
    491491      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    492492      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    … …  
    517517            <tr>
    518518               <td class="left">Intended status: Standards Track</td>
    519                <td class="right">September 1, 2013</td>
     519               <td class="right">September 4, 2013</td>
    520520            </tr>
    521521            <tr>
    522                <td class="left">Expires: March 5, 2014</td>
     522               <td class="left">Expires: March 8, 2014</td>
    523523               <td class="right"></td>
    524524            </tr>
    … …  
    548548         in progress”.
    549549      </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>
    551551      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    552552      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    29712971      <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&nbsp;2.5</a>)
    29722972      </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&nbsp;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&nbsp;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&nbsp;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
    29832974         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&nbsp;2.6</a>)
    29842975      </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&nbsp;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&nbsp;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
    29902977         transmission on the wire. (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>)
    29912978      </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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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
    29982989         where specifically defined in the ABNF. (<a href="#whitespace" title="Whitespace">Section&nbsp;3.2.3</a>)
    29992990      </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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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
    30523037         altogether. (<a href="#compatibility.with.http.1.0.persistent.connections" title="Keep-Alive Connections">Appendix&nbsp;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&nbsp;7</a>)
    30553038      </p>
    30563039      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    … …  
    32963279                  <li>chunked (Coding Format)&nbsp;&nbsp;<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>
    32973280                  <li>client&nbsp;&nbsp;<a href="#rfc.iref.c.1"><b>2.1</b></a></li>
    3298                   <li>close&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    32993282                  <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.10">4.2.1</a></li>
    33003283                  <li>connection&nbsp;&nbsp;<a href="#rfc.iref.c.2"><b>2.1</b></a></li>
    3301                   <li>Connection header field&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    33023285                  <li>Content-Length header field&nbsp;&nbsp;<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>
    33033286               </ul>

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

    r2365 r2369  
    50255025<t>
    50265026  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" />)
    50495028</t>
    50505029<t>
    … …  
    50565035</t>
    50575036<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>
    50675037  Userinfo (i.e., username and password) are now disallowed in HTTP and
    50685038  HTTPS URIs, because of security issues related to their transmission on the
    … …  
    50715041</t>
    50725042<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>
    50735057  Invalid whitespace around field-names is now required to be rejected,
    50745058  because accepting it represents a security vulnerability.
    5075   (<xref target="header.fields"/>)
    5076 </t>
    5077 <t>
    50785059  The ABNF productions defining header fields now only list the field value.
    50795060  (<xref target="header.fields"/>)
    … …  
    50855066  (<xref target="whitespace"/>)
    50865067</t>
     5068<t>
     5069  Header fields that span multiple lines ("line folding") are deprecated.
     5070  (<xref target="field.parsing" />)
     5071</t>
    50875072<t> 
    50885073  The NUL octet is no longer allowed in comment and quoted-string text, and
    50895074  handling of backslash-escaping in them has been clarified.
    5090   (<xref target="field.components"/>)
    5091 </t> 
    5092 <t>
    50935075  The quoted-pair rule no longer allows escaping control characters other than
    50945076  HTAB.
    5095   (<xref target="field.components"/>)
    5096 </t>
    5097 <t>
    50985077  Non-ASCII content in header fields and the reason phrase has been obsoleted
    50995078  and made opaque (the TEXT rule was removed).
    51005079  (<xref target="field.components"/>)
    5101 </t>
     5080</t> 
    51025081<t>
    51035082  Bogus "<x:ref>Content-Length</x:ref>" header fields are now required to be
    51045083  handled as errors by recipients.
    51055084  (<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"/> and
    5110   <xref format="counter" target="transfer.codings"/>)
    51115085</t>
    51125086<t>
    … …  
    51155089  codes) that affect it, and that new protocol elements cannot define such
    51165090  special cases.
    5117   (<xref target="message.body.length"/>)
    5118 </t>
    5119 <t>
     5091  CONNECT is a new, special case in determining message body length.
    51205092  "multipart/byteranges" is no longer a way of determining message body length
    51215093  detection.
    … …  
    51235095</t>
    51245096<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"/>)
    51275100</t>
    51285101<t>
    51295102  Chunk length does not include the count of the octets in the
    51305103  chunk header and trailer.
    5131   (<xref target="chunked.encoding"/>)
    5132 </t>
    5133 <t>
    51345104  Use of chunk extensions is deprecated, and line folding in them is
    51355105  disallowed.
    … …  
    51375107</t>
    51385108<t>
     5109  The meaning of the "deflate" content coding has been clarified.
     5110  (<xref target="deflate.coding" />)
     5111</t>
     5112<t>
    51395113  The segment + query components of RFC 3986 have been used to define the
    51405114  request-target, instead of abs_path from RFC 1808.
    5141   (<xref target="request-target"/>)
    5142 </t>
    5143 <t>
    51445115  The asterisk-form of the request-target is only allowed in the OPTIONS
    51455116  method.
    … …  
    51475118</t>
    51485119<t>
     5120  The term "Effective Request URI" has been introduced.
     5121  (<xref target="effective.request.uri" />)
     5122</t>
     5123<t>
    51495124  Gateways do not need to generate <x:ref>Via</x:ref> header fields anymore.
    51505125  (<xref target="header.via"/>)
    … …  
    51525127<t>
    51535128  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
    51585130  field; just because they're defined as hop-by-hop in this specification
    51595131  doesn't exempt them.
    … …  
    51625134<t>
    51635135  The limit of two connections per server has been removed.
    5164   (<xref target="persistent.connections"/>)
    5165 </t>
    5166 <t>
    51675136  An idempotent sequence of requests is no longer required to be retried.
    5168   (<xref target="persistent.connections"/>)
    5169 </t>
    5170 <t>
    51715137  The requirement to retry requests under certain circumstances when the
    51725138  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
    51775140  connections prematurely have been removed.
    51785141  (<xref target="persistent.connections"/>)
    … …  
    51865149</t>
    51875150<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>
    51885156  Registration of Transfer Codings now requires IETF Review
    51895157  (<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" />)
    51945158</t>
    51955159<t>
    … …  
    51995163</t>
    52005164<t>
     5165  The expectation to support HTTP/0.9 requests has been removed.
     5166  (<xref target="compatibility"/>)
     5167</t>
     5168<t>
    52015169  Issues with the Keep-Alive and Proxy-Connection header fields in requests
    52025170  are pointed out, with use of the latter being discouraged altogether.
    52035171  (<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 containing
    5207   ", ,") have been deprecated.
    5208   (<xref target="abnf.extension"/>)
    52095172</t>
    52105173</section>

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

    r2367 r2369  
    446446  }
    447447  @bottom-center {
    448        content: "Expires March 7, 2014";
     448       content: "Expires March 8, 2014";
    449449  }
    450450  @bottom-right {
    … …  
    491491      <meta name="dct.creator" content="Reschke, J. F.">
    492492      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    493       <meta name="dct.issued" scheme="ISO8601" content="2013-09-03">
     493      <meta name="dct.issued" scheme="ISO8601" content="2013-09-04">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    495495      <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.">
    … …  
    519519            <tr>
    520520               <td class="left">Intended status: Standards Track</td>
    521                <td class="right">September 3, 2013</td>
     521               <td class="right">September 4, 2013</td>
    522522            </tr>
    523523            <tr>
    524                <td class="left">Expires: March 7, 2014</td>
     524               <td class="left">Expires: March 8, 2014</td>
    525525               <td class="right"></td>
    526526            </tr>
    … …  
    550550         in progress”.
    551551      </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>
    553553      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    554554      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    42444244         semantics into separate documents for the core features, conditional requests, partial requests, caching, and authentication.
    42454245         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&nbsp;3.1.4.1</a>).
     4246         payload from representations and representations from resources.
    42484247      </p>
    42494248      <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 definition
    4253          says (<a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;3.1.1.3</a> and <a href="#header.accept-charset" id="rfc.xref.header.accept-charset.3" title="Accept-Charset">Section&nbsp;5.3.3</a>)
    42564255      </p>
    42574256      <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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;4.3.7</a>) and <a href="#TRACE" class="smpl">TRACE</a> (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;4.3.7</a> and <a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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>)
    42844285      </p>
    42854286      <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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;7.1.2</a>)
    42984300      </p>
    42994301      <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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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>
    43144313      <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="imported.abnf" href="#imported.abnf">Imported ABNF</a></h1>
    43154314      <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
    … …  
    45694568                  <li>306 (Unused) (status code)&nbsp;&nbsp;<a href="#rfc.iref.75"><b>6.4.6</b></a>, <a href="#rfc.xref.status.306.1">8.2.3</a></li>
    45704569                  <li>307 Temporary Redirect (status code)&nbsp;&nbsp;<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)&nbsp;&nbsp;<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)&nbsp;&nbsp;<a href="#rfc.iref.74"><b>6.4</b></a>, <a href="#rfc.xref.status.3xx.1">B</a></li>
    45724571               </ul>
    45734572            </li>
    … …  
    49114910                        <li>1xx Informational&nbsp;&nbsp;<a href="#rfc.iref.s.3"><b>6.2</b></a></li>
    49124911                        <li>2xx Successful&nbsp;&nbsp;<a href="#rfc.iref.s.4"><b>6.3</b></a></li>
    4913                         <li>3xx Redirection&nbsp;&nbsp;<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&nbsp;&nbsp;<a href="#rfc.iref.s.5"><b>6.4</b></a>, <a href="#rfc.xref.status.3xx.1">B</a></li>
    49144913                        <li>4xx Client Error&nbsp;&nbsp;<a href="#rfc.iref.s.6"><b>6.5</b></a></li>
    49154914                        <li>5xx Server Error&nbsp;&nbsp;<a href="#rfc.iref.s.7"><b>6.6</b></a></li>

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

    r2367 r2369  
    59525952   improved to distinguish payload from representations and representations
    59535953   from resources.
    5954    An algorithm has been added for determining if a payload is associated with
    5955    a specific identifier (<xref target="identifying.payload" />).
    59565954</t>
    59575955<t>
    … …  
    59595957   should be disabled when those semantics are inconsistent with the request
    59605958   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" />)
    59615965</t>
    59625966<t>
    59635967   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,
    59665969   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"/>)
    59735972</t>
    59745973<t>
    … …  
    59765975   longer affect the base URI for resolving relative URI references, due to
    59775976   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"/>)
    59845979</t>
    59855980<t>
    … …  
    59965991<t>
    59975992   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 been
     5993   <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
    60035998   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
    60076003   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 the
     6004   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
    60136009   <x:ref>OPTIONS</x:ref> and <x:ref>TRACE</x:ref> methods; previously,
    60146010   extension methods could have used it as well.
     6011   (<xref target="header.max-forwards"/>)
    60156012</t>
    60166013<t>
    … …  
    60186015   <x:ref>Referer</x:ref> header field when no referring URI is applicable,
    60196016   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"/>)
    60666019</t>
    60676020<t>
    … …  
    60696022   reused by a cache without explicit freshness information present): 204, 404,
    60706023   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"/>)
    60716084</t>
    60726085<t>
    … …  
    60746087   removing the option to specify it in a PUT request.
    60756088   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
    60956098   redefined by this specification; previously, it was defined in
    60966099   <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.
    61016113</t>
    61026114</section>

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

    r2365 r2369  
    446446  }
    447447  @bottom-center {
    448        content: "Expires March 5, 2014";
     448       content: "Expires March 8, 2014";
    449449  }
    450450  @bottom-right {
    … …  
    489489      <meta name="dct.creator" content="Reschke, J. F.">
    490490      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
    491       <meta name="dct.issued" scheme="ISO8601" content="2013-09-01">
     491      <meta name="dct.issued" scheme="ISO8601" content="2013-09-04">
    492492      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    493493      <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.">
    … …  
    515515            </tr>
    516516            <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>
    519519            </tr>
    520520         </tbody>
    … …  
    543543         in progress”.
    544544      </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>
    546546      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    547547      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    13381338      <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&nbsp;2.1</a>)
    13391339      </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>)
    13411341      </p>
    13421342      <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&nbsp;2.3</a>)

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

    r2365 r2369  
    15171517</t>
    15181518<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.
    15201520  (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"/>)
    15221522</t>
    15231523<t>

  • draft-ietf-httpbis/latest/p5-range.html

    r2365 r2369  
    446446  }
    447447  @bottom-center {
    448        content: "Expires March 5, 2014";
     448       content: "Expires March 8, 2014";
    449449  }
    450450  @bottom-right {
    … …  
    489489      <meta name="dct.creator" content="Reschke, J. F.">
    490490      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
    491       <meta name="dct.issued" scheme="ISO8601" content="2013-09-01">
     491      <meta name="dct.issued" scheme="ISO8601" content="2013-09-04">
    492492      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    493493      <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.">
    … …  
    515515            </tr>
    516516            <tr>
    517                <td class="left">Expires: March 5, 2014</td>
     517               <td class="left">Expires: March 8, 2014</td>
    518518               <td class="right">J. Reschke, Editor</td>
    519519            </tr>
    … …  
    524524            <tr>
    525525               <td class="left"></td>
    526                <td class="right">September 1, 2013</td>
     526               <td class="right">September 4, 2013</td>
    527527            </tr>
    528528         </tbody>
    … …  
    549549         in progress”.
    550550      </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>
    552552      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    553553      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    12251225--THIS_STRING_SEPARATES--
    12261226</pre><h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;A</a>)
    12371237      </p>
    12381238      <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="imported.abnf" href="#imported.abnf">Imported ABNF</a></h1>
    … …  
    14531453            </li>
    14541454            <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul>
    1455                   <li>Range header field&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    14561456                  <li><em>RFC2046</em>&nbsp;&nbsp;<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>
    14571457                        <li><em>Section 5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.1">A</a></li>

  • draft-ietf-httpbis/latest/p5-range.xml

    r2365 r2369  
    13581358
    13591359<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>
    13611365<t>
    13621366  A weak validator cannot be used in a <x:ref>206</x:ref> response.
    … …  
    13691373</t>
    13701374<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"/>)
    13731377</t>
    13741378<t>
    13751379  multipart/byteranges can consist of a single part.
    13761380  (<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"/>)
    13811381</t>
    13821382</section>

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

    r2368 r2369  
    18591859      </div>
    18601860      <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;<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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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
    18701873         explicitly allows header-specific canonicalization when processing selecting header fields. (<a href="#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section&nbsp;4.3</a>)
    18711874      </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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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"
    18881886         is interpreted by many caches as simply "private". Additionally, the meaning of the qualified form of no-cache has been clarified.
    18891887         (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;7.2.2</a>)
    18901888      </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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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
    19011896         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&nbsp;7.5</a>)
    19021897      </p>
    1903       <p id="rfc.section.A.p.19">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&nbsp;7.2.3</a> and <a href="#warn.code.extensions" title="Warn Code Extensions">Section&nbsp;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&nbsp;9.1</a> and <a href="#warn.code.registry" title="Warn Code Registry">Section&nbsp;9.2</a>)
    19051900      </p>
    19061901      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="imported.abnf" href="#imported.abnf">Imported ABNF</a></h1>
    … …  
    20622057                  <li>cache entry&nbsp;&nbsp;<a href="#rfc.iref.c.2">2</a></li>
    20632058                  <li>cache key&nbsp;&nbsp;<a href="#rfc.iref.c.3">2</a>, <a href="#rfc.iref.c.4">2</a></li>
    2064                   <li>Cache-Control header field&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    20652060               </ul>
    20662061            </li>

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

    r2368 r2369  
    23632363<section anchor="changes.from.rfc.2616" title="Changes from RFC 2616">
    23642364<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" />)
    23662378</t>
    23672379<t>
    23682380  The algorithm for calculating age is now less conservative.
    2369   (<xref target="age.calculations"/>)
    2370 </t>
    2371 <t>
    23722381  Caches are now required to handle dates with timezones as if they're
    23732382  invalid, because it's not possible to accurately guess.
    … …  
    23952404</t>
    23962405<t>
    2397   The conditions under which an authenticated response can be cached have been
    2398   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>
    24122406  Cache directives are explicitly defined to be case-insensitive.
    2413   (<xref target="header.cache-control" />)
    2414 </t>
    2415 <t>
    24162407  Handling of multiple instances of cache directives when only one is
    24172408  expected is now defined.
    24182409  (<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" />)
    24192416</t>
    24202417<t>
    … …  
    24262423</t>
    24272424<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 invalidate
    2430   it.
    2431   (<xref target="cache-request-directive.no-store" />)
    2432 </t>
    2433 <t>
    24342425  The "no-cache" response cache directive's meaning has been clarified.
    24352426  (<xref target="cache-response-directive.no-cache" />)
    24362427</t>
    24372428<t>
    2438   New status codes can now define that caches are allowed to use heuristic
    2439   freshness with them.
    2440   (<xref target="heuristic.freshness" />)
    2441 </t>
    2442 <t>
    2443   Caches are now allow to calculate heuristic freshness for URLs with query
    2444   components.
    2445   (<xref target="heuristic.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" />)
    24462437</t>
    24472438<t>
    … …  
    24572448  This specification introduces the Cache Directive and Warn Code Registries,
    24582449  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"/>)
    24602451</t>
    24612452</section>
Note: See TracChangeset for help on using the changeset viewer.