Source: https://trac.ietf.org/trac/httpbis/browser/draft-ietf-httpbis/19/draft-ietf-httpbis-p2-semantics-19.xml?rev=2653&desc=1
Timestamp: 2020-08-08 01:02:03
Document Index: 165943043

Matched Legal Cases: ['art1', 'art6', 'art1', 'art1', 'art1', 'art3', 'art3', 'art1', 'art1', 'art6', 'art1', 'art3', 'art3', 'art3', 'art3', 'art7', 'art1', 'art4', 'art4', 'art4', 'art5', 'art4', 'art7', 'art5', 'art1', 'art1', 'art5', 'art6', 'art7', 'art6', 'art7', 'art4', 'art5', 'art7', 'art5', 'art4', 'art7', 'art7', 'art4', 'art5', 'art1', 'art1', 'art6', 'art6', 'art1', 'art1', 'art1', 'art3', 'art1', 'art1', 'art4', 'art1', 'art6', 'art6', 'art1', 'art3', 'art4', 'art3', 'art1', 'art1', 'art1', 'art1', 'art1']

draft-ietf-httpbis-p2-semantics-19.xml in draft-ietf-httpbis/19 – Hypertext Transfer Protocol Wiki
source: draft-ietf-httpbis/19/draft-ietf-httpbis-p2-semantics-19.xml @ 2653
Last change on this file since 2653 was 1592, checked in by julian.reschke@…, 8 years ago
<rfc obsoletes="2616" updates="2817" category="std" ipr="pre5378Trust200902" docName="draft-ietf-httpbis-p2-semantics-19">
resource (Section 5.5 of <xref target="Part1"/>). The method is case-sensitive.
<figure><iref primary="true" item="Grammar" subitem="method"/><artwork type="abnf2616"><![CDATA[
Note that this list is not exhaustive — it does not include request methods defined
methods cannot prohibit the presence of a message body on either the request
New method definitions need to indicate whether they are safe (<xref target="safe.methods"/>), what semantics (if any) the request body has,
They also need to state whether they can be cached (<xref target="Part6"/>); in
itself (i.e., control data). See Section 3.2 of <xref target="Part1"/> for a general definition
Section 4.1 of <xref target="RFC3864"/>. Authors of specifications
(<xref target="RFC5234"/>), using the extension defined in Section 3.2.5 of <xref target="Part1"/>
double-quotes using the quoted-string ABNF production (Section 3.2.4 of <xref target="Part1"/>).
parameters (for instance, Content-Type, defined in Section 6.8 of <xref target="Part3"/>).
parameter handling for media types in Section 2.3 of <xref target="Part3"/>).
(delimited by commas; see Section 3.2 of <xref target="Part1"/>).<vspace blankLines="1"/>If it does not use the list syntax, document how to treat messages
choice).<vspace blankLines="1"/>Note that intermediaries and software libraries might combine
<t>Under what conditions the header field can be used; e.g., only in
request method.</t>
<t>Whether it is appropriate to list the field-name in the Connection header
(i.e., if the header is to be hop-by-hop, see Section 6.1 of <xref target="Part1"/>).</t>
<t>Under what conditions intermediaries are allowed to modify the header
field's value, insert or delete it.</t>
<t>How the header might interact with caching (see <xref target="Part6"/>).</t>
<t>Whether the header field is useful or allowable in trailers (see
Section 4.1 of <xref target="Part1"/>).</t>
<t>Whether the header field should be preserved across redirects.</t>
<c>Accept</c> <c>Section 6.1 of <xref target="Part3"/></c>
<c>Accept-Charset</c> <c>Section 6.2 of <xref target="Part3"/></c>
<c>Accept-Encoding</c> <c>Section 6.3 of <xref target="Part3"/></c>
<c>Accept-Language</c> <c>Section 6.4 of <xref target="Part3"/></c>
<c>Authorization</c> <c>Section 4.1 of <xref target="Part7"/></c>
<c>Host</c> <c>Section 5.4 of <xref target="Part1"/></c>
<c>If-Match</c> <c>Section 3.1 of <xref target="Part4"/></c>
<c>If-Modified-Since</c> <c>Section 3.3 of <xref target="Part4"/></c>
<c>If-None-Match</c> <c>Section 3.2 of <xref target="Part4"/></c>
<c>If-Range</c> <c>Section 5.3 of <xref target="Part5"/></c>
<c>If-Unmodified-Since</c> <c>Section 3.4 of <xref target="Part4"/></c>
<c>Proxy-Authorization</c> <c>Section 4.3 of <xref target="Part7"/></c>
<c>Range</c> <c>Section 5.4 of <xref target="Part5"/></c>
<c>TE</c> <c>Section 4.3 of <xref target="Part1"/></c>
further access to the target resource (Section 5.5 of <xref target="Part1"/>).
<c>Accept-Ranges</c> <c>Section 5.1 of <xref target="Part5"/></c>
<c>Age</c> <c>Section 3.1 of <xref target="Part6"/></c>
<c>Proxy-Authenticate</c> <c>Section 4.2 of <xref target="Part7"/></c>
<c>Vary</c> <c>Section 3.5 of <xref target="Part6"/></c>
<c>WWW-Authenticate</c> <c>Section 4.4 of <xref target="Part7"/></c>
of this specification, Section 4 of <xref target="Part4"/>, Section 3 of <xref target="Part5"/>, and Section 3 of <xref target="Part7"/>.
The reason phrases listed here are only recommendations — they can be
<c>206</c> <c>Partial Content</c> <c>Section 3.1 of <xref target="Part5"/></c>
<c>304</c> <c>Not Modified</c> <c>Section 4.1 of <xref target="Part4"/></c>
<c>401</c> <c>Unauthorized</c> <c>Section 3.1 of <xref target="Part7"/></c>
<c>407</c> <c>Proxy Authentication Required</c> <c>Section 3.2 of <xref target="Part7"/></c>
<c>412</c> <c>Precondition Failed</c> <c>Section 4.2 of <xref target="Part4"/></c>
<c>416</c> <c>Requested range not satisfiable</c> <c>Section 3.2 of <xref target="Part5"/></c>
Note that this list is not exhaustive — it does not include
A representation body is only present in a message when a message body is
resource (see Section 5.5 of <xref target="Part1"/>). However, this is not always the
OPTIONS, and TRACE request methods SHOULD NOT have the significance
to be considered "safe".
If the OPTIONS request includes a message body (as indicated by the
If the request-target (Section 5.3 of <xref target="Part1"/>) is an asterisk ("*"),
the OPTIONS request is
The Max-Forwards header field MAY be used to target a
return a message body in the response. The metadata contained
previously stored responses to GET; see Section 2.5 of <xref target="Part6"/>.
the PUT successfully creates one, then the origin server MUST inform
SHOULD be sent to indicate successful completion of the request.
Unrecognized header fields SHOULD be ignored (i.e., not saved
An origin server SHOULD verify that the PUT representation is
server SHOULD either make them consistent, by transforming the
a state-changing request, SHOULD be implemented using the POST
MUST send a 301 (Moved Permanently) response; the user agent MAY
A PUT request applied to the target resource MAY have side-effects
An origin server SHOULD reject any PUT request that contains a
Section 2.6 of <xref target="Part6"/>).
message body of a 200 (OK) response. The final recipient is either the
A TRACE request MUST NOT include a message body.
information. The value of the Via header field (Section 6.2 of <xref target="Part1"/>) is of
"message/http" (see Section 7.3.1 of <xref target="Part1"/>) and contain a message body
to the request-target and, if successful, thereafter restrict its behavior
to blind forwarding of packets until the connection is closed.
When using CONNECT, the request-target MUST use the authority form
(Section 5.3 of <xref target="Part1"/>); i.e., the request-target consists of only the
<figure><artwork type="message/http; msgtype=&#34;request&#34;"><![CDATA[
The tunneled data from the server begins immediately after the blank line
that concludes the successful response's header block.
A server SHOULD NOT send any Transfer-Encoding or Content-Length
header fields in a successful response.
A client MUST ignore any Content-Length or Transfer-Encoding header
fields received in a successful response.
Any response other than a successful response indicates that the tunnel
has not yet been formed and that the connection remains governed by HTTP.
Proxy authentication might be used to establish the
A message body on a CONNECT request has no defined semantics. Sending a
body on a CONNECT request might cause existing implementations to reject
Similar to a pipelined HTTP/1.1 request, data to be tunneled from client
to server MAY be sent immediately after the request (before a response
is received). The usual caveats also apply:
SHOULD make a CONNECT request of that next proxy, requesting a tunnel
to the authority. A proxy MUST NOT respond with any 2xx status code
An origin server which receives a CONNECT request for itself MAY
For most status codes the response can carry a payload, in which case a
(Section 6.8 of <xref target="Part3"/>).
Section 6.4.3 of <xref target="Part1"/> for detailed discussion of the use and handling of this
request, via the Upgrade message header field (Section 6.5 of <xref target="Part1"/>), for a
The newly created resource is typically linked to from the response payload,
with the most relevant URI also being carried in the Location header field.
If the newly created resource's URI is the same as the Effective Request URI,
this information can be omitted (e.g., in the case of a response to a PUT
The origin server MUST create the resource before returning the 201 status
code. If the action cannot be carried out immediately, the server SHOULD
just created (see Section 2.3 of <xref target="Part4"/>).
modified by a transforming proxy (Section 2.3 of <xref target="Part1"/>). Note that the
behavior of transforming intermediaries is controlled by the no-transform
Cache-Control directive (Section 3.2 of <xref target="Part6"/>).
(Section 3.6 of <xref target="Part6"/>) is appropriate.
user agent SHOULD NOT traverse away from its current "document view"
The 204 response MUST NOT include a message body, and thus is always
The message body included with the response MUST be empty. Note that
in Section 3.3 of <xref target="Part1"/>.
action involves a subsequent HTTP request, it MAY be carried out by the
agent-driven content negotiation (Section 5.2 of <xref target="Part3"/>). This
(Not Modified), see Section 4.1 of <xref target="Part4"/>).
Note: In HTTP/1.0, only the status codes 301 (Moved Permanently)
type did not exist at all (<xref target="RFC1945"/>, Section 9.3).
code 303 (See Other) (<xref target="RFC2068"/>, Section 10.3.4).
not apply (<xref target="RFC2616"/>, Section 10.3.8).
A Location header field on a 3xx response indicates that a client MAY
automatically redirect to the URI provided; see <xref target="header.location"/>.
Note that for methods not known to be "safe", as defined in <xref target="safe.methods"/>,
automatic redirection needs to done with care, since the redirect might
Clients SHOULD detect and intervene in cyclical redirections (i.e.,
which the user or user agent can choose the one most appropriate. Depending
upon the format and the capabilities of
Note: For historic reasons, user agents MAY change the
request, a user agent SHOULD perform a retrieval request using the
Note: This status code is similar to 302 Found, except that
malformed syntax).
SHOULD NOT be repeated with the same credentials.
(Not Found) MAY be used instead.
resource. The response MUST include an Allow header field containing a
(see Section 6 of <xref target="Part3"/>).
appropriate. Depending upon the format and the
to keep the mark for any length of time — that is left to the
<iref primary="true" item="413 Request Representation Too Large (status code)"/>
<iref primary="true" item="Status Codes" subitem="413 Request Representation Too Large"/>
<iref primary="true" item="426 Upgrade Required (status code)"/>
<iref primary="true" item="Status Codes" subitem="426 Upgrade Required"/>
response MUST include an Upgrade header field (Section 6.5 of <xref target="Part1"/>)
The server SHOULD include a message body in the 426 response which
alleviated after some delay. If known, the length of the delay MAY be
If no Retry-After is given, the client SHOULD handle the response as it
using the same major version as the client, as described in Section 2.6 of <xref target="Part1"/>,
HTTP/1.1 clients and servers that parse a date value MUST accept
<figure><iref primary="true" item="Grammar" subitem="HTTP-date"/><artwork type="abnf2616"><![CDATA[
<figure><iref primary="true" item="Grammar" subitem="rfc1123-date"/><iref primary="true" item="Grammar" subitem="date1"/><iref primary="true" item="Grammar" subitem="time-of-day"/><iref primary="true" item="Grammar" subitem="hour"/><iref primary="true" item="Grammar" subitem="minute"/><iref primary="true" item="Grammar" subitem="second"/><iref primary="true" item="Grammar" subitem="day-name"/><iref primary="true" item="Grammar" subitem="day-name-l"/><iref primary="true" item="Grammar" subitem="day"/><iref primary="true" item="Grammar" subitem="month"/><iref primary="true" item="Grammar" subitem="year"/><iref primary="true" item="Grammar" subitem="GMT"/><artwork type="abnf2616"><![CDATA[
month = %x4A.61.6E ; "Jan", case-sensitive
The semantics of <xref target="preferred.date.format" format="none">day-name</xref>, <xref target="preferred.date.format" format="none">day</xref>,
<xref target="preferred.date.format" format="none">month</xref>, <xref target="preferred.date.format" format="none">year</xref>, and <xref target="preferred.date.format" format="none">time-of-day</xref> are the
with the corresponding name (<xref target="RFC5322"/>, Section 3.3).
<figure><iref primary="true" item="Grammar" subitem="obs-date"/><artwork type="abnf2616"><![CDATA[
<figure><iref primary="true" item="Grammar" subitem="rfc850-date"/><artwork type="abnf2616"><![CDATA[
day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive
<figure><iref primary="true" item="Grammar" subitem="asctime-date"/><artwork type="abnf2616"><![CDATA[
date3 = month SP ( 2DIGIT / ( SP 1DIGIT ))
token octet MAY appear in a product-version, this token SHOULD
<iref primary="true" item="Allow header field"/>
<iref primary="true" item="Header Fields" subitem="Allow"/>
A proxy MUST NOT modify the Allow header field — it does not need to
<iref primary="true" item="Date header field"/>
<iref primary="true" item="Header Fields" subitem="Date"/>
Date Field (orig-date) defined in Section 3.6.1 of <xref target="RFC5322"/>.
MUST NOT include a Date header field.</t>
any useful information (as is usually the case for requests that do not
The HTTP-date sent in a Date header field SHOULD NOT represent a date and
<iref primary="true" item="Expect header field"/>
<iref primary="true" item="Header Fields" subitem="Expect"/>
<figure><iref primary="true" item="Grammar" subitem="Expect"/><iref primary="true" item="Grammar" subitem="expectation"/><iref primary="true" item="Grammar" subitem="expect-param"/><iref primary="true" item="Grammar" subitem="expect-value"/><iref primary="true" item="Grammar" subitem="expect-name"/><artwork type="abnf2616"><![CDATA[
Expect = 1#expectation
expectation = expect-name [ BWS "=" BWS expect-value ]
the recipient MUST respond with a 417 (Expectation Failed) status code. A
recipient of a syntactically invalid Expectation header field MUST respond
The "100-continue" expectation is defined Section 6.4.3 of <xref target="Part1"/>. It does not support
end-to-end; it MUST be forwarded if the request is forwarded.
<iref primary="true" item="From header field"/>
<iref primary="true" item="Header Fields" subitem="From"/>
The "From" header field, if given, SHOULD contain an Internet
<iref primary="true" item="Location header field"/>
<iref primary="true" item="Header Fields" subitem="Location"/>
The "Location" header field MAY be sent in responses to refer to
URI (<xref target="RFC3986"/>, Section 5). If the original URI, as
Note: Some recipients attempt to recover from Location fields
<iref primary="true" item="Max-Forwards header field"/>
<iref primary="true" item="Header Fields" subitem="Max-Forwards"/>
trace a request which appears to be failing or looping mid-chain.
The Max-Forwards header field MAY be ignored for all other request
<iref primary="true" item="Referer header field"/>
<iref primary="true" item="Header Fields" subitem="Referer"/>
<iref primary="true" item="Retry-After header field"/>
<iref primary="true" item="Header Fields" subitem="Retry-After"/>
<iref primary="true" item="Server header field"/>
<iref primary="true" item="Header Fields" subitem="Server"/>
The field can contain multiple
product tokens (<xref target="product.tokens"/>) and
application MUST NOT modify the Server header field. Instead, it
MUST include a Via field (as described in Section 6.2 of <xref target="Part1"/>).
<iref primary="true" item="User-Agent header field"/>
<iref primary="true" item="Header Fields" subitem="User-Agent"/>
product tokens (<xref target="product.tokens"/>)
The registration procedure for HTTP Status Codes — previously defined
in Section 7.1 of <xref target="RFC2817"/> — is now defined
that a specific client or server has a particular security hole which might
information to the target server — although the fragment identifier is
via SMTP, for example. As such, proxies SHOULD restrict CONNECT
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p3-payload-19"/>
<title>PATCH Method for HTTP</title>
<author initials="L." surname="Dusseault" fullname="L. Dusseault">
<organization>Linden Lab</organization>
<author initials="J." surname="Snell" fullname="J. Snell"/>
<reference anchor="RFC5987">
<title>Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters</title>
Take over definition of CONNECT method from <xref target="RFC2817"/>.
Broadened the definition of 203 (Non-Authoritative Information) to include
cases of payload transformations as well.
(<xref target="status.203"/>)
Status codes 301, 302, and 307: removed the normative requirements on both
response payloads and user interaction.
Define status 426 (Upgrade Required) (this was incorporated from
<xref target="RFC2817"/>).
The ABNF for the Expect header field has been both fixed (allowing parameters
for value-less expectations as well) and simplified (allowing trailing
semicolons after "100-continue" when they were invalid before).
(<xref target="header.expect"/>)
Restrict Max-Forwards header field to OPTIONS and TRACE (previously,
extension methods could have used it as well).
(<xref target="header.max-forwards"/>)
correctly in the description of the Via header field in Section 6.2 of <xref target="Part1"/>.
<section title="Since draft-ietf-httpbis-p2-semantics-12" anchor="changes.since.12">
<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/79"/>:
"Content-* vs. PUT"
"205 Bodies"
<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/102"/>:
"Understanding Content-* on non-PUT requests"
<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/225"/>:
"PUT side effect: invalidation or just stale?"
<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/226"/>:
"proxies not supporting certain methods"
<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/239"/>:
"Migrate CONNECT from RFC2817 to p2"
<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/240"/>:
"Migrate Upgrade details from RFC2817"
<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/267"/>:
"clarify PUT semantics'"
<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/275"/>:
"duplicate ABNF for 'Method'"
<section title="Since draft-ietf-httpbis-p2-semantics-13" anchor="changes.since.13">
<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/251"/>:
"message body in CONNECT request"
<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/255"/>:
"Clarify status code for rate limiting"
<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/296"/>:
"Clarify 203 Non-Authoritative Information"
<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/298"/>:
"update default reason phrase for 413"
<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/303"/>:
"400 response isn't generic"
<section title="Since draft-ietf-httpbis-p2-semantics-16" anchor="changes.since.16">
<section title="Since draft-ietf-httpbis-p2-semantics-17" anchor="changes.since.17">
"Clarify status code for rate limiting" (change backed out because
a new status code is being defined for this purpose)
<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/312"/>:
"should there be a permanent variant of 307"
<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/325"/>:
"When are Location's semantics triggered?"
<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/327"/>:
"'expect' grammar missing OWS"
<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/329"/>:
"header field considerations: quoted-string vs use of double quotes"
<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/238"/>:
"Requirements for user intervention during redirects"
<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/250"/>:
"message-body in CONNECT response"
<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/331"/>:
"clarify that 201 doesn't require Location header fields"
<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/336"/>:
"drop indirection entries for status codes"