Changeset 2122


Ignore:
Timestamp:
Jan 13, 2013, 6:39:35 PM (7 years ago)
Author:
fielding@…
Message:

(editorial) explain empty Allow field for 405; misc typos; partly addresses #426

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

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p2-semantics.html

    r2121 r2122  
    23822382               <tr>
    23832383                  <td class="left">505</td>
    2384                   <td class="left">HTTP Version not supported</td>
     2384                  <td class="left">HTTP Version Not Supported</td>
    23852385                  <td class="left"><a href="#status.505" id="rfc.xref.status.505.1" title="505 HTTP Version Not Supported">Section&nbsp;6.6.6</a></td>
    23862386               </tr>
     
    23942394      <p id="rfc.section.6.2.p.1">The <dfn>1xx (Informational)</dfn> class of status code indicates an interim response for communicating connection status or request progress prior to completing
    23952395         the requested action and sending a final response. All 1xx responses consist of only the status-line and optional header fields,
    2396          and thus are terminated by the empty line at the end of the header block. There are no required header fields for this class
    2397          of status code. Since HTTP/1.0 did 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.
    2398       </p>
    2399       <p id="rfc.section.6.2.p.2">A client <em class="bcp14">MUST</em> be prepared to accept one or more 1xx status responses prior to a final response, even if the client does not expect a <a href="#status.100" class="smpl">100 (Continue)</a> status message. A user agent <em class="bcp14">MAY</em> ignore unexpected 1xx status responses.
     2396         and thus are terminated by the empty line at the end of the header block. Since HTTP/1.0 did not define any 1xx status codes,
     2397         servers <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client except under experimental conditions.
     2398      </p>
     2399      <p id="rfc.section.6.2.p.2">A client <em class="bcp14">MUST</em> be prepared to accept one or more 1xx status responses prior to a final response, even if the client does not expect one.
     2400         A user agent <em class="bcp14">MAY</em> ignore unexpected 1xx status responses.
    24002401      </p>
    24012402      <p id="rfc.section.6.2.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
     
    24142415      <div id="rfc.iref.72"></div>
    24152416      <h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a>&nbsp;<a id="status.101" href="#status.101">101 Switching Protocols</a></h3>
    2416       <p id="rfc.section.6.2.2.p.1">The <dfn>101 (Switching Protocols)</dfn> status code indicates that the server understands and is willing to comply with the client's request, via the <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.7</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch to the protocol(s) indicated
    2417          within the response's Upgrade header field immediately after the empty line that terminates the 101 response.
     2417      <p id="rfc.section.6.2.2.p.1">The <dfn>101 (Switching Protocols)</dfn> status code indicates that the server understands and is willing to comply with the client's request, via the <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.7</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server <em class="bcp14">MUST</em> generate an Upgrade header field in the response that indicates which protocol(s) will be switched to immediately after the
     2418         empty line that terminates the 101 response.
    24182419      </p>
    24192420      <p id="rfc.section.6.2.2.p.2">It is assumed that the server will only agree to switch protocols when it is advantageous to do so. For example, switching
     
    31373138</pre><p id="rfc.section.7.4.1.p.3">Example of use:</p>
    31383139      <div id="rfc.figure.u.60"></div><pre class="text">  Allow: GET, HEAD, PUT
    3139 </pre><p id="rfc.section.7.4.1.p.5">The actual set of allowed methods is defined by the origin server at the time of each request.</p>
    3140       <p id="rfc.section.7.4.1.p.6">A proxy <em class="bcp14">MUST NOT</em> modify the Allow header field — it does not need to understand all the methods specified in order to handle them according
     3140</pre><p id="rfc.section.7.4.1.p.5">The actual set of allowed methods is defined by the origin server at the time of each request. An origin server <em class="bcp14">MUST</em> generate an Allow field in a <a href="#status.405" class="smpl">405 (Method Not Allowed)</a> response and <em class="bcp14">MAY</em> do so in any other response. An empty Allow field value indicates that the resource allows no methods, which might occur in
     3141         a 405 response if the resource has been temporarily disabled by configuration.
     3142      </p>
     3143      <p id="rfc.section.7.4.1.p.6">A proxy <em class="bcp14">MUST NOT</em> modify the Allow header field — it does not need to understand all of the indicated methods in order to handle them according
    31413144         to the generic message handling rules.
    31423145      </p>
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2121 r2122  
    26552655  <c>503</c> <c>Service Unavailable</c> <c><xref target="status.503"/></c>
    26562656  <c>504</c> <c>Gateway Time-out</c> <c><xref target="status.504"/></c>
    2657   <c>505</c> <c>HTTP Version not supported</c> <c><xref target="status.505"/></c>
     2657  <c>505</c> <c>HTTP Version Not Supported</c> <c><xref target="status.505"/></c>
    26582658</texttable>
    26592659<t>
     
    26742674   All 1xx responses consist of only the status-line and optional header
    26752675   fields, and thus are terminated by the empty line at the end of the header
    2676    block. There are no required header fields for this class of status code.
     2676   block.
    26772677   Since HTTP/1.0 did not define any 1xx status codes, servers &MUST-NOT; send
    26782678   a 1xx response to an HTTP/1.0 client except under experimental conditions.
     
    26802680<t>
    26812681   A client &MUST; be prepared to accept one or more 1xx status responses
    2682    prior to a final response, even if the client does not expect a
    2683    <x:ref>100 (Continue)</x:ref> status message.
     2682   prior to a final response, even if the client does not expect one.
    26842683   A user agent &MAY; ignore unexpected 1xx status responses.
    26852684</t>
     
    27232722   server understands and is willing to comply with the client's request,
    27242723   via the <x:ref>Upgrade</x:ref> header field (&header-upgrade;), for
    2725    a change in the application protocol being used on this connection. The
    2726    server will switch to the protocol(s) indicated within the response's
    2727    Upgrade header field immediately after the empty line that terminates the
    2728    101 response.
     2724   a change in the application protocol being used on this connection.
     2725   The server &MUST; generate an Upgrade header field in the response that
     2726   indicates which protocol(s) will be switched to immediately after the empty
     2727   line that terminates the 101 response.
    27292728</t>
    27302729<t>
     
    40424041<t>
    40434042   The "Allow" header field lists the set of methods advertised as
    4044    supported by the <x:ref>target resource</x:ref>. The purpose of this field is strictly to
    4045    inform the recipient of valid request methods associated with the resource.
     4043   supported by the <x:ref>target resource</x:ref>. The purpose of this field
     4044   is strictly to inform the recipient of valid request methods associated
     4045   with the resource.
    40464046</t>
    40474047<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Allow"/>
     
    40564056<t>
    40574057   The actual set of allowed methods is defined by the origin server at the
    4058    time of each request.
    4059 </t>
    4060 <t>
    4061    A proxy &MUST-NOT; modify the Allow header field &mdash; it does not need to
    4062    understand all the methods specified in order to handle them according to
    4063    the generic message handling rules.
     4058   time of each request. An origin server &MUST; generate an Allow field in a
     4059   <x:ref>405 (Method Not Allowed)</x:ref> response and &MAY; do so in any
     4060   other response. An empty Allow field value indicates that the resource
     4061   allows no methods, which might occur in a 405 response if the resource has
     4062   been temporarily disabled by configuration.
     4063</t>
     4064<t>
     4065   A proxy &MUST-NOT; modify the Allow header field &mdash; it does not need
     4066   to understand all of the indicated methods in order to handle them
     4067   according to the generic message handling rules.
    40644068</t>
    40654069</section>
Note: See TracChangeset for help on using the changeset viewer.