Ignore:
Timestamp:
14/01/13 02:39:35 (7 years ago)
Author:
fielding@…
Message:

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

File:
1 edited

Legend:

Unmodified
Added
Removed
  • 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.