Ignore:
Timestamp:
24/09/13 01:57:10 (7 years ago)
Author:
fielding@…
Message:

clarify that 100-continue needs to be answered with a 100 before any 101 and client needs to send entire request message before using the upgraded protocol

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

Legend:

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

    r2406 r2410  
    446446  }
    447447  @bottom-center {
    448        content: "Expires March 20, 2014";
     448       content: "Expires March 27, 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-16">
     490      <meta name="dct.issued" scheme="ISO8601" content="2013-09-23">
    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 16, 2013</td>
     519               <td class="right">September 23, 2013</td>
    520520            </tr>
    521521            <tr>
    522                <td class="left">Expires: March 20, 2014</td>
     522               <td class="left">Expires: March 27, 2014</td>
    523523               <td class="right"></td>
    524524            </tr>
     
    548548         in progress”.
    549549      </p>
    550       <p>This Internet-Draft will expire on March 20, 2014.</p>
     550      <p>This Internet-Draft will expire on March 27, 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>
     
    22152215         that might not implement the listed protocols. A server <em class="bcp14">MUST</em> ignore an Upgrade header field that is received in an HTTP/1.0 request.
    22162216      </p>
    2217       <p id="rfc.section.6.7.p.11">The Upgrade header field only applies to switching protocols on top of the existing connection; it cannot be used to switch
     2217      <p id="rfc.section.6.7.p.11">A client cannot begin using an upgraded protocol on the connection until it has completely sent the request message (i.e.,
     2218         the client can't change the protocol it is sending in the middle of a message). If a server receives both Upgrade and an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation (<a href="p2-semantics.html#header.expect" title="Expect">Section 5.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), the server <em class="bcp14">MUST</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response before sending a <a href="p2-semantics.html#status.101" class="smpl">101 (Switching Protocols)</a> response.
     2219      </p>
     2220      <p id="rfc.section.6.7.p.12">The Upgrade header field only applies to switching protocols on top of the existing connection; it cannot be used to switch
    22182221         the underlying connection (transport) protocol, nor to switch the existing communication to a different connection. For those
    2219          purposes, it is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 6.4</a> of <a href="#Part2" id="rfc.xref.Part2.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
    2220       </p>
    2221       <p id="rfc.section.6.7.p.12">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined
     2222         purposes, it is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 6.4</a> of <a href="#Part2" id="rfc.xref.Part2.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
     2223      </p>
     2224      <p id="rfc.section.6.7.p.13">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined
    22222225         by the HTTP version rules of <a href="#http.version" title="Protocol Versioning">Section&nbsp;2.6</a> and future updates to this specification. Additional tokens ought to be registered with IANA using the registration procedure
    22232226         defined in <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section&nbsp;8.5</a>.
     
    25182521         <li>Pointer to specification text</li>
    25192522      </ul>
    2520       <p id="rfc.section.8.4.1.p.2">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) unless the encoding transformation is identical, as is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;4.2</a>.
     2523      <p id="rfc.section.8.4.1.p.2">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.30"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) unless the encoding transformation is identical, as is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;4.2</a>.
    25212524      </p>
    25222525      <p id="rfc.section.8.4.1.p.3">Values to be added to this name space require IETF Review (see <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this specification.
     
    26562659         that most implementations will choose substantially higher limits.
    26572660      </p>
    2658       <p id="rfc.section.9.3.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.30"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 6.5</a> of <a href="#Part2" id="rfc.xref.Part2.31"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Additional status codes related to capacity limits have been defined by extensions to HTTP <a href="#RFC6585" id="rfc.xref.RFC6585.1"><cite title="Additional HTTP Status Codes">[RFC6585]</cite></a>.
     2661      <p id="rfc.section.9.3.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.31"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 6.5</a> of <a href="#Part2" id="rfc.xref.Part2.32"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Additional status codes related to capacity limits have been defined by extensions to HTTP <a href="#RFC6585" id="rfc.xref.RFC6585.1"><cite title="Additional HTTP Status Codes">[RFC6585]</cite></a>.
    26592662      </p>
    26602663      <p id="rfc.section.9.3.p.4">Recipients ought to carefully limit the extent to which they read other fields, including (but not limited to) request methods,
     
    34623465            </li>
    34633466            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    3464                   <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2.1</a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.14">3.3.1</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.16">3.3.2</a>, <a href="#rfc.xref.Part2.17">3.3.2</a>, <a href="#rfc.xref.Part2.18">4.3</a>, <a href="#rfc.xref.Part2.19">5.1</a>, <a href="#rfc.xref.Part2.20">5.3</a>, <a href="#rfc.xref.Part2.21">5.3</a>, <a href="#rfc.xref.Part2.22">5.6</a>, <a href="#rfc.xref.Part2.23">5.7.2</a>, <a href="#rfc.xref.Part2.24">5.7.2</a>, <a href="#rfc.xref.Part2.25">6.3.1</a>, <a href="#rfc.xref.Part2.26">6.3.2</a>, <a href="#rfc.xref.Part2.27">6.3.2</a>, <a href="#rfc.xref.Part2.28">6.7</a>, <a href="#rfc.xref.Part2.29">8.4.1</a>, <a href="#rfc.xref.Part2.30">9.3</a>, <a href="#rfc.xref.Part2.31">9.3</a>, <a href="#Part2"><b>11.1</b></a><ul>
     3467                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2.1</a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.14">3.3.1</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.16">3.3.2</a>, <a href="#rfc.xref.Part2.17">3.3.2</a>, <a href="#rfc.xref.Part2.18">4.3</a>, <a href="#rfc.xref.Part2.19">5.1</a>, <a href="#rfc.xref.Part2.20">5.3</a>, <a href="#rfc.xref.Part2.21">5.3</a>, <a href="#rfc.xref.Part2.22">5.6</a>, <a href="#rfc.xref.Part2.23">5.7.2</a>, <a href="#rfc.xref.Part2.24">5.7.2</a>, <a href="#rfc.xref.Part2.25">6.3.1</a>, <a href="#rfc.xref.Part2.26">6.3.2</a>, <a href="#rfc.xref.Part2.27">6.3.2</a>, <a href="#rfc.xref.Part2.28">6.7</a>, <a href="#rfc.xref.Part2.29">6.7</a>, <a href="#rfc.xref.Part2.30">8.4.1</a>, <a href="#rfc.xref.Part2.31">9.3</a>, <a href="#rfc.xref.Part2.32">9.3</a>, <a href="#Part2"><b>11.1</b></a><ul>
    34653468                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">2.7</a></li>
    34663469                        <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.15">3.3.2</a></li>
    3467                         <li><em>Section 3.1.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.29">8.4.1</a></li>
     3470                        <li><em>Section 3.1.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.30">8.4.1</a></li>
    34683471                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.23">5.7.2</a></li>
    34693472                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">3.1.1</a></li>
     
    34733476                        <li><em>Section 4.3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.14">3.3.1</a>, <a href="#rfc.xref.Part2.17">3.3.2</a>, <a href="#rfc.xref.Part2.20">5.3</a></li>
    34743477                        <li><em>Section 4.3.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.21">5.3</a></li>
     3478                        <li><em>Section 5.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.28">6.7</a></li>
    34753479                        <li><em>Section 5.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.18">4.3</a></li>
    34763480                        <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a></li>
    34773481                        <li><em>Section 6.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.22">5.6</a></li>
    34783482                        <li><em>Section 6.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.24">5.7.2</a></li>
    3479                         <li><em>Section 6.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.28">6.7</a></li>
    3480                         <li><em>Section 6.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.31">9.3</a></li>
    3481                         <li><em>Section 6.5.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.30">9.3</a></li>
     3483                        <li><em>Section 6.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.29">6.7</a></li>
     3484                        <li><em>Section 6.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.32">9.3</a></li>
     3485                        <li><em>Section 6.5.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.31">9.3</a></li>
    34823486                        <li><em>Section 7.1.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">3.2</a></li>
    34833487                        <li><em>Section 8.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">3.2.1</a></li>
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r2406 r2410  
    3535  <!ENTITY header-date            "<xref target='Part2' x:rel='#header.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3636  <!ENTITY header-etag            "<xref target='Part4' x:rel='#header.etag' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     37  <!ENTITY header-expect          "<xref target='Part2' x:rel='#header.expect' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3738  <!ENTITY header-expires         "<xref target='Part6' x:rel='#header.expires' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    3839  <!ENTITY header-last-modified   "<xref target='Part4' x:rel='#header.last-modified' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     
    32863287   the listed protocols.  A server &MUST; ignore an Upgrade header field that
    32873288   is received in an HTTP/1.0 request.
     3289</t>
     3290<t>
     3291   A client cannot begin using an upgraded protocol on the connection until
     3292   it has completely sent the request message (i.e., the client can't change
     3293   the protocol it is sending in the middle of a message).
     3294   If a server receives both Upgrade and an <x:ref>Expect</x:ref> header field
     3295   with the "100-continue" expectation (&header-expect;), the
     3296   server &MUST; send a <x:ref>100 (Continue)</x:ref> response before sending
     3297   a <x:ref>101 (Switching Protocols)</x:ref> response.
    32883298</t>
    32893299<t>
Note: See TracChangeset for help on using the changeset viewer.