Ignore:
Timestamp:
Jul 4, 2012, 1:15:19 PM (7 years ago)
Author:
julian.reschke@…
Message:

Work-in-progress: hyperlink status codes definitions (1xx range)

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

Legend:

Unmodified
Added
Removed

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

    r1715 r1716  
    21662166      </p>
    21672167      <h3 id="rfc.section.6.4.3"><a href="#rfc.section.6.4.3">6.4.3</a>&nbsp;<a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3>
    2168       <p id="rfc.section.6.4.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 4.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
     2168      <p id="rfc.section.6.4.3.p.1">The purpose of the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 4.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
    21692169         to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might
    21702170         either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without
    … …  
    21732173      <p id="rfc.section.6.4.3.p.2">Requirements for HTTP/1.1 clients: </p>
    21742174      <ul>
    2175          <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.11</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.
     2175         <li>If a client will wait for a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response before sending the request body, it <em class="bcp14">MUST</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.11</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.
    21762176         </li>
    21772177         <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.11</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body.
    … …  
    21792179      </ul>
    21802180      <p id="rfc.section.6.4.3.p.3">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client might send "Expect:
    2181          100-continue" without receiving either a <a href="p2-semantics.html#status.417" class="smpl">417 (Expectation Failed)</a> or a 100 (Continue) status code. Therefore, when a client sends this header field to an origin server (possibly via a proxy)
    2182          from which it has never seen a 100 (Continue) status code, the client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the request body.
     2181         100-continue" without receiving either a <a href="p2-semantics.html#status.417" class="smpl">417 (Expectation Failed)</a> or a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code. Therefore, when a client sends this header field to an origin server (possibly via a proxy) from which it has
     2182         never seen a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code, the client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the request body.
    21832183      </p>
    21842184      <p id="rfc.section.6.4.3.p.4">Requirements for HTTP/1.1 origin servers: </p>
    21852185      <ul>
    2186          <li>Upon receiving a request which includes an Expect header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with 100 (Continue) status code and continue to read from the input stream, or respond with a final status
    2187             code. The origin server <em class="bcp14">MUST NOT</em> wait for the request body before sending the 100 (Continue) response. If it responds with a final status code, it <em class="bcp14">MAY</em> close the transport connection or it <em class="bcp14">MAY</em> continue to read and discard the rest of the request. It <em class="bcp14">MUST NOT</em> perform the request method if it returns a final status code.
    2188          </li>
    2189          <li>An origin server <em class="bcp14">SHOULD NOT</em> send a 100 (Continue) response if the request message does not include an Expect header field with the "100-continue" expectation,
    2190             and <em class="bcp14">MUST NOT</em> send a 100 (Continue) response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this
    2191             rule: for compatibility with <a href="#RFC2068" id="rfc.xref.RFC2068.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, a server <em class="bcp14">MAY</em> send a 100 (Continue) status code in response to an HTTP/1.1 PUT or POST request that does not include an Expect header field
    2192             with the "100-continue" expectation. This exception, the purpose of which is to minimize any client processing delays associated
    2193             with an undeclared wait for 100 (Continue) status code, applies only to HTTP/1.1 requests, and not to requests with any other
    2194             HTTP-version value.
    2195          </li>
    2196          <li>An origin server <em class="bcp14">MAY</em> omit a 100 (Continue) response if it has already received some or all of the request body for the corresponding request.
    2197          </li>
    2198          <li>An origin server that sends a 100 (Continue) response <em class="bcp14">MUST</em> ultimately send a final status code, once the request body is received and processed, unless it terminates the transport connection
     2186         <li>Upon receiving a request which includes an Expect header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code and continue to read from the input stream, or respond with a final status code. The origin server <em class="bcp14">MUST NOT</em> wait for the request body before sending the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response. If it responds with a final status code, it <em class="bcp14">MAY</em> close the transport connection or it <em class="bcp14">MAY</em> continue to read and discard the rest of the request. It <em class="bcp14">MUST NOT</em> perform the request method if it returns a final status code.
     2187         </li>
     2188         <li>An origin server <em class="bcp14">SHOULD NOT</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if the request message does not include an Expect header field with the "100-continue" expectation, and <em class="bcp14">MUST NOT</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this rule: for compatibility
     2189            with <a href="#RFC2068" id="rfc.xref.RFC2068.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, a server <em class="bcp14">MAY</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code in response to an HTTP/1.1 PUT or POST request that does not include an Expect header field with the "100-continue"
     2190            expectation. This exception, the purpose of which is to minimize any client processing delays associated with an undeclared
     2191            wait for <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code, applies only to HTTP/1.1 requests, and not to requests with any other HTTP-version value.
     2192         </li>
     2193         <li>An origin server <em class="bcp14">MAY</em> omit a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if it has already received some or all of the request body for the corresponding request.
     2194         </li>
     2195         <li>An origin server that sends a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response <em class="bcp14">MUST</em> ultimately send a final status code, once the request body is received and processed, unless it terminates the transport connection
    21992196            prematurely.
    22002197         </li>
    … …  
    22162213         <li>Proxies <em class="bcp14">SHOULD</em> maintain a record of the HTTP version numbers received from recently-referenced next-hop servers.
    22172214         </li>
    2218          <li>A proxy <em class="bcp14">MUST NOT</em> forward a 100 (Continue) response if the request message was received from an HTTP/1.0 (or earlier) client and did not include
    2219             an Expect header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of
    2220             1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     2215         <li>A proxy <em class="bcp14">MUST NOT</em> forward a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if the request message was received from an HTTP/1.0 (or earlier) client and did not include an Expect header field
     2216            with the "100-continue" expectation. This requirement overrides the general rule for forwarding of 1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    22212217         </li>
    22222218      </ul>
    … …  
    22572253         is more appropriate to use a 3xx redirection response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 4.5</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    22582254      </p>
    2259       <p id="rfc.section.6.5.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in 101 (Switching Protocols) responses to indicate which protocol(s) are being switched
    2260          to, and <em class="bcp14">MUST</em> include it in <a href="p2-semantics.html#status.426" class="smpl">426 (Upgrade Required)</a> responses to indicate acceptable protocols to upgrade to. Servers <em class="bcp14">MAY</em> include it in any other response to indicate that they are willing to upgrade to one of the specified protocols.
     2255      <p id="rfc.section.6.5.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in <a href="p2-semantics.html#status.101" class="smpl">101 (Switching
     2256            Protocols)</a> responses to indicate which protocol(s) are being switched to, and <em class="bcp14">MUST</em> include it in <a href="p2-semantics.html#status.426" class="smpl">426 (Upgrade Required)</a> responses to indicate acceptable protocols to upgrade to. Servers <em class="bcp14">MAY</em> include it in any other response to indicate that they are willing to upgrade to one of the specified protocols.
    22612257      </p>
    22622258      <p id="rfc.section.6.5.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined

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

    r1715 r1716  
    30913091<section title="Use of the 100 (Continue) Status" anchor="use.of.the.100.status">
    30923092<t>
    3093    The purpose of the 100 (Continue) status code (see &status-100;) is to
    3094    allow a client that is sending a request message with a request body
     3093   The purpose of the <x:ref>100 (Continue)</x:ref> status code (see &status-100;)
     3094   is to allow a client that is sending a request message with a request body
    30953095   to determine if the origin server is willing to accept the request
    30963096   (based on the request header fields) before the client sends the request
    … …  
    31033103  <list style="symbols">
    31043104    <t>
    3105         If a client will wait for a 100 (Continue) response before
     3105        If a client will wait for a <x:ref>100 (Continue)</x:ref> response before
    31063106        sending the request body, it &MUST; send an Expect header
    31073107        field (&header-expect;) with the "100-continue" expectation.
    … …  
    31183118   ambiguous situations in which a client might send "Expect: 100-continue"
    31193119   without receiving either a <x:ref>417 (Expectation Failed)</x:ref>
    3120    or a 100 (Continue) status code. Therefore, when a client sends this
     3120   or a <x:ref>100 (Continue)</x:ref> status code. Therefore, when a client sends this
    31213121   header field to an origin server (possibly via a proxy) from which it
    3122    has never seen a 100 (Continue) status code, the client &SHOULD-NOT; 
     3122   has never seen a <x:ref>100 (Continue)</x:ref> status code, the client &SHOULD-NOT; 
    31233123   wait for an indefinite period before sending the request body.
    31243124</t>
    … …  
    31283128    <t> Upon receiving a request which includes an Expect header
    31293129        field with the "100-continue" expectation, an origin server &MUST;
    3130         either respond with 100 (Continue) status code and continue to read
     3130        either respond with <x:ref>100 (Continue)</x:ref> status code and continue to read
    31313131        from the input stream, or respond with a final status code. The
    31323132        origin server &MUST-NOT; wait for the request body before sending
    3133         the 100 (Continue) response. If it responds with a final status
     3133        the <x:ref>100 (Continue)</x:ref> response. If it responds with a final status
    31343134        code, it &MAY; close the transport connection or it &MAY; continue
    31353135        to read and discard the rest of the request.  It &MUST-NOT;
    31363136        perform the request method if it returns a final status code.
    31373137    </t>
    3138     <t> An origin server &SHOULD-NOT;  send a 100 (Continue) response if
     3138    <t> An origin server &SHOULD-NOT;  send a <x:ref>100 (Continue)</x:ref> response if
    31393139        the request message does not include an Expect header
    31403140        field with the "100-continue" expectation, and &MUST-NOT; send a
    3141         100 (Continue) response if such a request comes from an HTTP/1.0
     3141        <x:ref>100 (Continue)</x:ref> response if such a request comes from an HTTP/1.0
    31423142        (or earlier) client. There is an exception to this rule: for
    3143         compatibility with <xref target="RFC2068"/>, a server &MAY; send a 100 (Continue)
     3143        compatibility with <xref target="RFC2068"/>, a server &MAY; send a <x:ref>100 (Continue)</x:ref>
    31443144        status code in response to an HTTP/1.1 PUT or POST request that does
    31453145        not include an Expect header field with the "100-continue"
    31463146        expectation. This exception, the purpose of which is
    31473147        to minimize any client processing delays associated with an
    3148         undeclared wait for 100 (Continue) status code, applies only to
     3148        undeclared wait for <x:ref>100 (Continue)</x:ref> status code, applies only to
    31493149        HTTP/1.1 requests, and not to requests with any other HTTP-version
    31503150        value.
    31513151    </t>
    3152     <t> An origin server &MAY; omit a 100 (Continue) response if it has
     3152    <t> An origin server &MAY; omit a <x:ref>100 (Continue)</x:ref> response if it has
    31533153        already received some or all of the request body for the
    31543154        corresponding request.
    31553155    </t>
    3156     <t> An origin server that sends a 100 (Continue) response &MUST;
     3156    <t> An origin server that sends a <x:ref>100 (Continue)</x:ref> response &MUST;
    31573157        ultimately send a final status code, once the request body is
    31583158        received and processed, unless it terminates the transport
    … …  
    31903190        numbers received from recently-referenced next-hop servers.
    31913191    </t>
    3192     <t> A proxy &MUST-NOT; forward a 100 (Continue) response if the
     3192    <t> A proxy &MUST-NOT; forward a <x:ref>100 (Continue)</x:ref> response if the
    31933193        request message was received from an HTTP/1.0 (or earlier)
    31943194        client and did not include an Expect header field with
    … …  
    32753275</t>
    32763276<t>
    3277    Servers &MUST; include the "Upgrade" header field in 101 (Switching
    3278    Protocols) responses to indicate which protocol(s) are being switched to,
     3277   Servers &MUST; include the "Upgrade" header field in <x:ref>101 (Switching
     3278   Protocols)</x:ref> responses to indicate which protocol(s) are being switched to,
    32793279   and &MUST; include it in <x:ref>426 (Upgrade Required)</x:ref> responses to indicate
    32803280   acceptable protocols to upgrade to. Servers &MAY; include it in any other
    … …  
    41094109  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;"/>
    41104110  <x:source href="p2-semantics.xml" basename="p2-semantics">
     4111    <x:defines>100 (Continue)</x:defines>
     4112    <x:defines>101 (Switching Protocols)</x:defines>
    41114113    <x:defines>200 (OK)</x:defines>
    41124114    <x:defines>204 (No Content)</x:defines>

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

    r1715 r1716  
    16511651         not define any 1xx status codes, servers <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client except under experimental conditions.
    16521652      </p>
    1653       <p id="rfc.section.4.3.p.2">A client <em class="bcp14">MUST</em> be prepared to accept one or more 1xx status responses prior to a regular response, even if the client does not expect a 100
    1654          (Continue) status message. Unexpected 1xx status responses <em class="bcp14">MAY</em> be ignored by a user agent.
     1653      <p id="rfc.section.4.3.p.2">A client <em class="bcp14">MUST</em> be prepared to accept one or more 1xx status responses prior to a regular response, even if the client does not expect a <a href="#status.100" class="smpl">100
     1654            (Continue)</a> status message. Unexpected 1xx status responses <em class="bcp14">MAY</em> be ignored by a user agent.
    16551655      </p>
    16561656      <p id="rfc.section.4.3.p.3">Proxies <em class="bcp14">MUST</em> forward 1xx responses, unless the connection between the proxy and its client has been closed, or unless the proxy itself
    16571657         requested the generation of the 1xx response. (For example, if a proxy adds a "Expect: 100-continue" field when it forwards
    1658          a request, then it need not forward the corresponding 100 (Continue) response(s).)
     1658         a request, then it need not forward the corresponding <a href="#status.100" class="smpl">100 (Continue)</a> response(s).)
    16591659      </p>
    16601660      <div id="rfc.iref.21"></div>
    … …  
    28972897      </p>
    28982898      <ol>
    2899          <li>If the response status code is 100 (Continue) or 101 (Switching Protocols), the response <em class="bcp14">MAY</em> include a Date header field, at the server's option.
    2900          </li>
    2901          <li>If the response status code conveys a server error, e.g., 500 (Internal Server Error) or <a href="#status.503" class="smpl">503 (Service Unavailable)</a>, and it is inconvenient or impossible to generate a valid Date.
     2899         <li>If the response status code is <a href="#status.100" class="smpl">100 (Continue)</a> or <a href="#status.101" class="smpl">101 (Switching Protocols)</a>, the response <em class="bcp14">MAY</em> include a Date header field, at the server's option.
     2900         </li>
     2901         <li>If the response status code conveys a server error, e.g., <a href="#status.500" class="smpl">500
     2902               (Internal Server Error)</a> or <a href="#status.503" class="smpl">503 (Service Unavailable)</a>, and it is inconvenient or impossible to generate a valid Date.
    29022903         </li>
    29032904         <li>If the server does not have a clock that can provide a reasonable approximation of the current time, its responses <em class="bcp14">MUST NOT</em> include a Date header field.

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

    r1715 r1716  
    12911291<t>
    12921292   A client &MUST; be prepared to accept one or more 1xx status responses
    1293    prior to a regular response, even if the client does not expect a 100
    1294    (Continue) status message. Unexpected 1xx status responses &MAY; be
     1293   prior to a regular response, even if the client does not expect a <x:ref>100
     1294   (Continue)</x:ref> status message. Unexpected 1xx status responses &MAY; be
    12951295   ignored by a user agent.
    12961296</t>
    … …  
    13001300   requested the generation of the 1xx response. (For example, if a
    13011301   proxy adds a "Expect: 100-continue" field when it forwards a request,
    1302    then it need not forward the corresponding 100 (Continue)
     1302   then it need not forward the corresponding <x:ref>100 (Continue)</x:ref>
    13031303   response(s).)
    13041304</t>
    … …  
    13071307  <iref primary="true" item="100 Continue (status code)" x:for-anchor=""/>
    13081308  <iref primary="true" item="Status Codes" subitem="100 Continue" x:for-anchor=""/>
     1309  <x:anchor-alias value="100 (Continue)"/>
    13091310<t>
    13101311   The client &SHOULD; continue with its request. This interim response is
    … …  
    13221323  <iref primary="true" item="101 Switching Protocols (status code)" x:for-anchor=""/>
    13231324  <iref primary="true" item="Status Codes" subitem="101 Switching Protocols" x:for-anchor=""/>
     1325  <x:anchor-alias value="101 (Switching Protocols)"/>
    13241326<t>
    13251327   The server understands and is willing to comply with the client's
    … …  
    20472049  <iref primary="true" item="500 Internal Server Error (status code)" x:for-anchor=""/>
    20482050  <iref primary="true" item="Status Codes" subitem="500 Internal Server Error" x:for-anchor=""/>
     2051  <x:anchor-alias value="500 (Internal Server Error)"/>
    20492052<t>
    20502053   The server encountered an unexpected condition which prevented it
    … …  
    35423545   except in these cases:
    35433546  <list style="numbers">
    3544       <t>If the response status code is 100 (Continue) or 101 (Switching
    3545          Protocols), the response &MAY; include a Date header field, at
    3546          the server's option.</t>
    3547 
    3548       <t>If the response status code conveys a server error, e.g., 500
    3549          (Internal Server Error) or <x:ref>503 (Service Unavailable)</x:ref>,
     3547      <t>If the response status code is <x:ref>100 (Continue)</x:ref> or
     3548         <x:ref>101 (Switching Protocols)</x:ref>, the response &MAY; include a
     3549         Date header field, at the server's option.</t>
     3550
     3551      <t>If the response status code conveys a server error, e.g., <x:ref>500
     3552         (Internal Server Error)</x:ref> or <x:ref>503 (Service Unavailable)</x:ref>,
    35503553         and it is inconvenient or impossible to generate a valid Date.</t>
    35513554
Note: See TracChangeset for help on using the changeset viewer.