Source: https://trac.ietf.org/trac/httpbis/changeset/1747/draft-ietf-httpbis/latest
Timestamp: 2019-12-10 08:51:03
Document Index: 183245409

Matched Legal Cases: ['art2', 'art2', 'art 2', 'art2', 'art2', 'art2', 'art 2', 'art2', 'art2', 'art2', 'art 2', 'art2', 'art4', 'art4', 'art 4', 'art4']

Changeset 1747 for draft-ietf-httpbis/latest – Hypertext Transfer Protocol Wiki
Changeset 1747 for draft-ietf-httpbis/latest
Jul 9, 2012, 1:35:28 AM (7 years ago)
fix [1682] so that it takes roles into consideration (#361)
<p id="rfc.section.2.5.p.1">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP
<p id="rfc.section.2.5.p.2">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes
<p id="rfc.section.2.5.p.3">Senders <em class="bcp14">MUST NOT</em> generate protocol elements that do not match the grammar defined by the ABNF rules for those protocol elements.
<p id="rfc.section.2.5.p.4">Unless noted otherwise, recipients <em class="bcp14">MUST</em> be able to parse all protocol elements matching the ABNF rules defined for them and <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms
<p id="rfc.section.2.5.p.3">A sender <em class="bcp14">MUST NOT</em> generate protocol elements that do not match the grammar defined by the ABNF rules for those protocol elements that are applicable
<p id="rfc.section.2.5.p.4">Unless noted otherwise, a recipient <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms
<div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.26"></span> <a href="#http.message" class="smpl">start-line</a> = <a href="#request.line" class="smpl">request-line</a> / <a href="#status.line" class="smpl">status-line</a>
</pre><p id="rfc.section.3.1.p.4">Implementations <em class="bcp14">MUST NOT</em> send whitespace between the start-line and the first header field. The presence of such whitespace in a request might be an
</pre><p id="rfc.section.3.1.p.3">Implementations <em class="bcp14">MUST NOT</em> send whitespace between the start-line and the first header field. The presence of such whitespace in a request might be an
<div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.27"></span> <a href="#request.line" class="smpl">request-line</a> = <a href="#method" class="smpl">method</a> <a href="#core.rules" class="smpl">SP</a> <a href="#request-target" class="smpl">request-target</a> <a href="#core.rules" class="smpl">SP</a> <a href="#http.version" class="smpl">HTTP-version</a> <a href="#core.rules" class="smpl">CRLF</a>
</pre><p id="rfc.section.3.1.1.p.3">A server <em class="bcp14">MUST</em> be able to parse any received message that begins with a request-line and matches the ABNF rule for HTTP-message.
<p id="rfc.section.3.1.1.p.4">The method token indicates the request method to be performed on the target resource. The request method is case-sensitive.</p>
</pre><p id="rfc.section.3.1.1.p.6">The methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Methods">Section 2</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods.
<p id="rfc.section.3.1.1.p.6">The request-target identifies the target resource upon which to apply the request, as defined in <a href="#request-target" title="Request Target">Section&nbsp;5.3</a>.
<p id="rfc.section.3.1.1.p.7">No whitespace is allowed inside the method, request-target, and protocol version. Hence, recipients typically parse the request-line
<p id="rfc.section.3.1.1.p.7">The request-target identifies the target resource upon which to apply the request, as defined in <a href="#request-target" title="Request Target">Section&nbsp;5.3</a>.
<h3 id="rfc.section.3.1.2"><a href="#rfc.section.3.1.2">3.1.2</a>&nbsp;<a id="status.line" href="#status.line">Status Line</a></h3>
</pre><p id="rfc.section.3.1.2.p.3">A client <em class="bcp14">MUST</em> be able to parse any received message that begins with a status-line and matches the ABNF rule for HTTP-message.
<div id="status-code">
<p id="rfc.section.3.1.2.p.4">The status-code element is a 3-digit integer result code of the attempt to understand and satisfy the request. See <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> for further information, such as the list of status codes defined by this specification, the IANA registry, and considerations
<div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.30"></span> <a href="#status-code" class="smpl">status-code</a> = 3<a href="#core.rules" class="smpl">DIGIT</a>
</pre><div id="reason-phrase">
<p id="rfc.section.3.1.2.p.5">The reason-phrase element exists for the sole purpose of providing a textual description associated with the numeric status
<p id="rfc.section.3.1.2.p.6">The reason-phrase element exists for the sole purpose of providing a textual description associated with the numeric status
status code (<a href="#status-code">Paragraph&nbsp;4</a>). Responses to the HEAD request method never include a message body because the associated response header fields (e.g., <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, etc.) only indicate what their values would have been if the request method had been GET. <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> responses to CONNECT switch to tunnel mode instead of having a message body. All <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses <em class="bcp14">MUST NOT</em> include a message body. All other responses do include a message body, although the body <em class="bcp14">MAY</em> be of zero length. (See <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> and <a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.)
is being constrained by the requirement.
is being constrained by the requirement. The verb "generate" is used
instead of "send" where a requirement differentiates between creating a
protocol element and merely forwarding a received element downstream.
Senders &MUST-NOT; generate protocol elements that do not match the grammar
defined by the ABNF rules for those protocol elements.
elements matching the ABNF rules defined for them and &MAY; attempt to recover a usable
A sender &MUST-NOT; generate protocol elements that do not match
the grammar defined by the ABNF rules for those protocol elements that
are applicable to the sender's role.
If a received protocol element is processed, the recipient &MUST; be able
to parse any value that would match the ABNF rules for that protocol
Implementations &MUST-NOT; send whitespace between the start-line and
A server &MUST; be able to parse any received message that begins
with a request-line and matches the ABNF rule for HTTP-message.
<iref primary="true" item="method"/>
<t anchor="method">
A client &MUST; be able to parse any received message that begins
with a status-line and matches the ABNF rule for HTTP-message.