Changeset 2312


Ignore:
Timestamp:
Jul 27, 2013, 6:13:33 AM (6 years ago)
Author:
julian.reschke@…
Message:

add gateway/via requirement change to the changes list (see #460)

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

Legend:

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

    r2311 r2312  
    29602960      <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>)
    29612961      </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&nbsp;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&nbsp;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&nbsp;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
    29652967         in this specification doesn't exempt them. (<a href="#header.connection" id="rfc.xref.header.connection.10" title="Connection">Section&nbsp;6.1</a>)
    29662968      </p>
    2967       <p id="rfc.section.A.2.p.28">The limit of two connections per server has been removed. (<a href="#persistent.connections" title="Persistence">Section&nbsp;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&nbsp;6.3</a>)
    2970       </p>
    2971       <p id="rfc.section.A.2.p.30">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&nbsp;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&nbsp;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.
    29722974         (<a href="#persistent.connections" title="Persistence">Section&nbsp;6.3</a>)
    29732975      </p>
    2974       <p id="rfc.section.A.2.p.31">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>)
    2975       </p>
    2976       <p id="rfc.section.A.2.p.32">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>)
    2977       </p>
    2978       <p id="rfc.section.A.2.p.33">Registration of Transfer Codings now requires IETF Review (<a href="#transfer.coding.registry" title="Transfer Coding Registry">Section&nbsp;7.4</a>)
    2979       </p>
    2980       <p id="rfc.section.A.2.p.34">The meaning of the "deflate" content coding has been clarified. (<a href="#deflate.coding" title="Deflate Coding">Section&nbsp;4.2.2</a>)
    2981       </p>
    2982       <p id="rfc.section.A.2.p.35">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;7.5</a>)
    2983       </p>
    2984       <p id="rfc.section.A.2.p.36">Issues with the Keep-Alive and Proxy-Connection header fields in requests are pointed out, with use of the latter being discouraged
     2976      <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>)
     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&nbsp;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&nbsp;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&nbsp;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&nbsp;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
    29852987         altogether. (<a href="#compatibility.with.http.1.0.persistent.connections" title="Keep-Alive Connections">Appendix&nbsp;A.1.2</a>)
    29862988      </p>
    2987       <p id="rfc.section.A.2.p.37">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&nbsp;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&nbsp;B</a>)
    29882990      </p>
    29892991      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="abnf.extension" href="#abnf.extension">ABNF list extension: #rule</a></h1>
     
    35543556            </li>
    35553557            <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul>
    3556                   <li>Via header field&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    35573559               </ul>
    35583560            </li>
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r2311 r2312  
    50075007</t>
    50085008<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>
    50095013  Exactly when "close" connection options have to be sent has been clarified.
    50105014  (<xref target="header.connection"/>)
Note: See TracChangeset for help on using the changeset viewer.