04/07/12 17:59:15 (10 years ago)

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

1 edited


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

    r1710 r1713  
    10601060   directly instead of properly percent-encoding the disallowed characters.
    10611061   Recipients of an invalid request-line &SHOULD; respond with either a
    1062    400 (Bad Request) error or a 301 (Moved Permanently) redirect with the
     1062   <x:ref>400 (Bad Request)</x:ref> error or a 301 (Moved Permanently) redirect with the
    10631063   request-target properly encoded.  Recipients &SHOULD-NOT; attempt to
    10641064   autocorrect and then process the request without a redirect, since the
    10691069   HTTP does not place a pre-defined limit on the length of a request-line.
    10701070   A server that receives a method longer than any that it implements
    1071    &SHOULD; respond with either a 405 (Not Allowed), if it is an origin
     1071   &SHOULD; respond with either a <x:ref>405 (Method Not Allowed)</x:ref>, if it is an origin
    10721072   server, or a <x:ref>501 (Not Implemented)</x:ref> status code.
    10731073   A server &MUST; be prepared to receive URIs of unbounded length and
    1074    respond with the 414 (URI Too Long) status code if the received
     1074   respond with the <x:ref>414 (URI Too Long)</x:ref> status code if the received
    10751075   request-target would be longer than the server wishes to handle
    10761076   (see &status-414;).
    16691669     "chunked" transfer-coding is not the final encoding, the message body
    16701670     length cannot be determined reliably; the server &MUST; respond with
    1671      the 400 (Bad Request) status code and then close the connection.
     1671     the <x:ref>400 (Bad Request)</x:ref> status code and then close the connection.
    16721672    </t>
    16731673    <t>
    16881688     prevent request or response smuggling.
    16891689     If this is a request message, the server &MUST; respond with
    1690      a 400 (Bad Request) status code and then close the connection.
     1690     a <x:ref>400 (Bad Request)</x:ref> status code and then close the connection.
    16911691     If this is a response message received by a proxy, the proxy
    16921692     &MUST; discard the received response, send a <x:ref>502 (Bad Gateway)</x:ref>
    17311731   A server &MAY; reject a request that contains a message body but
    1732    not a Content-Length by responding with 411 (Length Required).
     1732   not a Content-Length by responding with <x:ref>411 (Length Required)</x:ref>.
    17371737   use a valid Content-Length header field if the message body length
    17381738   is known in advance, rather than the "chunked" encoding, since some
    1739    existing services respond to "chunked" with a 411 (Length Required)
     1739   existing services respond to "chunked" with a <x:ref>411 (Length Required)</x:ref>
    17401740   status code even though they understand the chunked encoding.  This
    17411741   is typically because such services are implemented via a gateway that
    18211821   receives a sequence of octets that does not match the HTTP-message
    18221822   grammar aside from the robustness exceptions listed above, the
    1823    server &MUST; respond with an HTTP/1.1 400 (Bad Request) response. 
     1823   server &MUST; respond with an HTTP/1.1 <x:ref>400 (Bad Request)</x:ref> response. 
    2412    A server &MUST; respond with a 400 (Bad Request) status code to
    2413    any HTTP/1.1 request message that lacks a Host header field and
     2412   A server &MUST; respond with a <x:ref>400 (Bad Request)</x:ref> status code
     2413   to any HTTP/1.1 request message that lacks a Host header field and
    24142414   to any request message that contains more than one Host header field
    24152415   or a Host header field with an invalid field-value.
    31173117   Because of the presence of older implementations, the protocol allows
    31183118   ambiguous situations in which a client might send "Expect: 100-continue"
    3119    without receiving either a 417 (Expectation Failed)
     3119   without receiving either a <x:ref>417 (Expectation Failed)</x:ref>
    31203120   or a 100 (Continue) status code. Therefore, when a client sends this
    31213121   header field to an origin server (possibly via a proxy) from which it
    31853185    <t> If the proxy knows that the version of the next-hop server is
    31863186        HTTP/1.0 or lower, it &MUST-NOT; forward the request, and it &MUST;
    3187         respond with a 417 (Expectation Failed) status code.
     3187        respond with a <x:ref>417 (Expectation Failed)</x:ref> status code.
    31883188    </t>
    31893189    <t> Proxies &SHOULD; maintain a record of the HTTP version
    32773277   Servers &MUST; include the "Upgrade" header field in 101 (Switching
    32783278   Protocols) responses to indicate which protocol(s) are being switched to,
    3279    and &MUST; include it in 426 (Upgrade Required) responses to indicate
     3279   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
    32813281   response to indicate that they are willing to upgrade to one of the
    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>400 (Bad Request)</x:defines>
     4112    <x:defines>405 (Method Not Allowed)</x:defines>
     4113    <x:defines>411 (Length Required)</x:defines>
     4114    <x:defines>414 (URI Too Long)</x:defines>
     4115    <x:defines>417 (Expectation Failed)</x:defines>
     4116    <x:defines>426 (Upgrade Required)</x:defines>
    41114117    <x:defines>501 (Not Implemented)</x:defines>
    41124118    <x:defines>502 (Bad Gateway)</x:defines>
Note: See TracChangeset for help on using the changeset viewer.