Changeset 2312
- Timestamp:
- 27/07/13 13:13:33 (9 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r2311 r2312 2960 2960 <p id="rfc.section.A.2.p.25">The asterisk form of the request-target is only allowed in the OPTIONS method. (<a href="#request-target" title="Request Target">Section 5.3</a>) 2961 2961 </p> 2962 <p id="rfc.section.A.2.p.26">Exactly when "close" connection options have to be sent has been clarified. (<a href="#header.connection" id="rfc.xref.header.connection.9" title="Connection">Section 6.1</a>) 2963 </p> 2964 <p id="rfc.section.A.2.p.27">"hop-by-hop" header fields are required to appear in the Connection header field; just because they're defined as hop-by-hop 2962 <p id="rfc.section.A.2.p.26">Gateways do not need to generate <a href="#header.via" class="smpl">Via</a> header fields anymore. (<a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section 5.7.1</a>) 2963 </p> 2964 <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.9" title="Connection">Section 6.1</a>) 2965 </p> 2966 <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 2965 2967 in this specification doesn't exempt them. (<a href="#header.connection" id="rfc.xref.header.connection.10" title="Connection">Section 6.1</a>) 2966 2968 </p> 2967 <p id="rfc.section.A.2.p.2 8">The limit of two connections per server has been removed. (<a href="#persistent.connections" title="Persistence">Section 6.3</a>)2968 </p> 2969 <p id="rfc.section.A.2.p. 29">An idempotent sequence of requests is no longer required to be retried. (<a href="#persistent.connections" title="Persistence">Section 6.3</a>)2970 </p> 2971 <p id="rfc.section.A.2.p.3 0">The requirement to retry requests under certain circumstances when the server prematurely closes the connection has been removed.2969 <p id="rfc.section.A.2.p.29">The limit of two connections per server has been removed. (<a href="#persistent.connections" title="Persistence">Section 6.3</a>) 2970 </p> 2971 <p id="rfc.section.A.2.p.30">An idempotent sequence of requests is no longer required to be retried. (<a href="#persistent.connections" title="Persistence">Section 6.3</a>) 2972 </p> 2973 <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. 2972 2974 (<a href="#persistent.connections" title="Persistence">Section 6.3</a>) 2973 2975 </p> 2974 <p id="rfc.section.A.2.p.3 1">Some extraneous requirements about when servers are allowed to close connections prematurely have been removed. (<a href="#persistent.connections" title="Persistence">Section 6.3</a>)2975 </p> 2976 <p id="rfc.section.A.2.p.3 2">The semantics of the <a href="#header.upgrade" class="smpl">Upgrade</a> header field is now defined in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). Furthermore, the ordering in the field value is now significant. (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section 6.7</a>)2977 </p> 2978 <p id="rfc.section.A.2.p.3 3">Registration of Transfer Codings now requires IETF Review (<a href="#transfer.coding.registry" title="Transfer Coding Registry">Section 7.4</a>)2979 </p> 2980 <p id="rfc.section.A.2.p.3 4">The meaning of the "deflate" content coding has been clarified. (<a href="#deflate.coding" title="Deflate Coding">Section 4.2.2</a>)2981 </p> 2982 <p id="rfc.section.A.2.p.3 5">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 7.5</a>)2983 </p> 2984 <p id="rfc.section.A.2.p.3 6">Issues with the Keep-Alive and Proxy-Connection header fields in requests are pointed out, with use of the latter being discouraged2976 <p id="rfc.section.A.2.p.32">Some extraneous requirements about when servers are allowed to close connections prematurely have been removed. (<a href="#persistent.connections" title="Persistence">Section 6.3</a>) 2977 </p> 2978 <p id="rfc.section.A.2.p.33">The semantics of the <a href="#header.upgrade" class="smpl">Upgrade</a> header field is now defined in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). Furthermore, the ordering in the field value is now significant. (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section 6.7</a>) 2979 </p> 2980 <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 7.4</a>) 2981 </p> 2982 <p id="rfc.section.A.2.p.35">The meaning of the "deflate" content coding has been clarified. (<a href="#deflate.coding" title="Deflate Coding">Section 4.2.2</a>) 2983 </p> 2984 <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 7.5</a>) 2985 </p> 2986 <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 2985 2987 altogether. (<a href="#compatibility.with.http.1.0.persistent.connections" title="Keep-Alive Connections">Appendix A.1.2</a>) 2986 2988 </p> 2987 <p id="rfc.section.A.2.p.3 7">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">Appendix B</a>)2989 <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">Appendix B</a>) 2988 2990 </p> 2989 2991 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="abnf.extension" href="#abnf.extension">ABNF list extension: #rule</a></h1> … … 3554 3556 </li> 3555 3557 <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul> 3556 <li>Via header field <a href="#rfc.iref.v.1"><b>5.7.1</b></a>, <a href="#rfc.xref.header.via.1">7.1</a> </li>3558 <li>Via header field <a href="#rfc.iref.v.1"><b>5.7.1</b></a>, <a href="#rfc.xref.header.via.1">7.1</a>, <a href="#rfc.xref.header.via.2">A.2</a></li> 3557 3559 </ul> 3558 3560 </li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r2311 r2312 5007 5007 </t> 5008 5008 <t> 5009 Gateways do not need to generate <x:ref>Via</x:ref> header fields anymore. 5010 (<xref target="header.via"/>) 5011 </t> 5012 <t> 5009 5013 Exactly when "close" connection options have to be sent has been clarified. 5010 5014 (<xref target="header.connection"/>)
Note: See TracChangeset
for help on using the changeset viewer.