Source: https://trac.ietf.org/trac/httpbis/browser/draft-ietf-httpbis/12/draft-ietf-httpbis-p2-semantics-12.xml?rev=1529&order=author&desc=1
Timestamp: 2020-05-29 05:16:57
Document Index: 147928514

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

draft-ietf-httpbis-p2-semantics-12.xml in draft-ietf-httpbis/12 – Hypertext Transfer Protocol Wiki
source: draft-ietf-httpbis/12/draft-ietf-httpbis-p2-semantics-12.xml @ 1529
Last change on this file since 1529 was 1500, checked in by julian.reschke@…, 8 years ago
<rfc obsoletes="2616" updates="2817" category="std" ipr="pre5378Trust200902" docName="draft-ietf-httpbis-p2-semantics-12">
The Method token indicates the method to be performed on the target
resource (Section 4.3 of <xref target="Part1"/>). The method is case-sensitive.
origin server SHOULD respond with the status code 405 (Method Not Allowed)
Due to the parsing rules defined in Section 3.3 of <xref target="Part1"/>, definitions of HTTP
New method definitions need to indicate whether they are safe (<xref target="safe.methods"/>) and whether they are idempotent (<xref target="idempotent.methods"/>). They also need to state whether they can be
cached (<xref target="Part6"/>); in particular what conditions a cache may store the
response, and under what conditions such a stored response may be used to
satisfy a subsequent request.
/ Accept-Charset ; [Part3], Section 6.2
/ Accept-Encoding ; [Part3], Section 6.3
/ Accept-Language ; [Part3], Section 6.4
/ Authorization ; [Part7], Section 4.1
/ Proxy-Authorization ; [Part7], Section 4.3
/ TE ; [Part1], Section 9.5
be request-header fields.
below are defined in <xref target="status.codes"/>, Section 3 of <xref target="Part4"/>,
Section 3 of <xref target="Part5"/>, and Section 3 of <xref target="Part7"/>.
/ "401" ; [Part7], Section 3.1: Unauthorized
/ "407" ; [Part7], Section 3.2: Proxy Authentication Required
/ "416" ; [Part5], Section 3.2: Requested range not satisfiable
cases, user agents SHOULD present to the user the representation enclosed
heuristics to determine their freshness (see <xref target="Part6"/>; by default, it is
carry a representation for (see <xref target="identifying.response.associated.with.representation"/>; by default,
further access to the target resource (Section 4.3 of <xref target="Part1"/>).
/ Proxy-Authenticate ; [Part7], Section 4.2
/ WWW-Authenticate ; [Part7], Section 4.4
be response-header fields.
Request and Response messages MAY transfer a representation if not otherwise
are defined in <xref target="Part3"/>.
present, as described in Section 3.3 of <xref target="Part1"/>. The representation body is obtained
resource (see Section 4.3 of <xref target="Part1"/>). However, this is not always the
(see Section 2.8 of <xref target="Part6"/>).</t>
identified by the effective request URI. This method allows the client to
The GET method means retrieve whatever information (in the form of a
representation) currently corresponds to the target resource.
method requests that the representation be transferred only under the
that only part of the representation be transferred, as described in Section 5.4 of <xref target="Part5"/>.
The response to a GET request is cacheable and MAY be used to satisfy
subsequent GET and HEAD requests (see <xref target="Part6"/>).
in the HTTP header fields in response to a HEAD request SHOULD be identical
The response to a HEAD request is cacheable and MAY be used to satisfy
a subsequent HEAD request; see <xref target="Part6"/>. It also MAY be used to update a previously cached
SHOULD be 201 (Created) and contain a representation which describes the
include explicit freshness information (see Section 2.3.1 of <xref target="Part6"/>). A
(see Section 6.7 of <xref target="Part3"/>) whose value is the effective
Request URI MAY be used to satisfy subsequent GET and HEAD requests.
The PUT method requests that the enclosed representation be stored at the
effective request URI. If the effective request URI refers to an already
existing resource, the enclosed representation SHOULD be considered a
modified version of the one residing on the origin server. Otherwise, if the
effective request URI does not point to an existing resource, and that URI is
agent, the origin server can create the resource with that URI.
If a new resource is created at the effective request URI, the origin
server MUST inform the user agent
to indicate successful completion of the request.
If the target resource could not be created or modified, an appropriate
error response SHOULD be given that reflects the nature of the problem.
The recipient of the representation MUST NOT ignore any Content-*
header fields (headers starting with the prefix "Content-") that it does
If the request passes through a cache that has one or more stored
responses for the effective request URI, those stored responses
SHOULD be marked as stale if the response to the PUT request
has a success status code. Responses to the PUT method are
not cacheable.
reflected in the different meaning of the effective request URI. The URI in a
representation. That resource might be a data-accepting process, a gateway to
some other protocol, or a document that accepts annotations.
In contrast, the URI in a PUT request identifies the resource for
which enclosed representation is a new or replacement value; the
user agent knows what URI is intended and the server MUST NOT attempt
to apply the request to some other resource.
Header fields in a PUT request that are recognized as representation
metadata SHOULD be applied to the resource created or modified by
the PUT. Unrecognized header fields SHOULD be ignored.
resource. This method MAY be overridden by
If the request passes through a cache and the effective request URI
identifies one or more currently cached representations, those entries SHOULD be
treated as stale. Responses to the DELETE method are not cacheable.
A TRACE request MUST NOT include a message-body.
If the request is valid, the response SHOULD have a Content-Type of
"message/http" (see Section 10.3.1 of <xref target="Part1"/>) and contain a message-body
request, via the Upgrade message header field (Section 9.8 of <xref target="Part1"/>), for a
Caches MAY use a heuristic (see Section 2.3.1.1 of <xref target="Part6"/>) to determine
SHOULD include a payload containing a list of resource
just created (see Section 6.1 of <xref target="Part4"/>).
The returned metadata in the header fields is not the
of the metadata known by the origin server. Use of this
The server has successfully fulfilled the request, but there is no
additional content to return in the response payload body. The
resource metadata and representation metadata in the response message's
header fields refer to the target resource
and its current representation, respectively, after the requested action.
and the response contains an ETag header field, then the value of
that field is the current entity-tag for the representation that
was successfully PUT.
any new or updated metadata SHOULD be applied to the document
response MUST NOT include a message-body.
and the enclosed payload is a partial representation as defined in Section 3.1 of <xref target="Part5"/>.
Unless it was a HEAD request, the response SHOULD include a representation
reference for the effective request URI.
The 303 status code is generally applicable to any HTTP method. It is
response SHOULD contain a short hypertext note with a hyperlink
Since the redirection can change over time, the client SHOULD
understand the 307 status code. Therefore, the note SHOULD contain the
the server SHOULD include a representation containing an explanation of the
User agents SHOULD display any included representation to the user.
The request requires user authentication (see Section 3.1 of <xref target="Part7"/>).
resource. The response MUST include an
Allow header field containing a list of valid methods for the requested
according to the accept header fields sent in the request.
client must first authenticate itself with the proxy (see Section 3.2 of <xref target="Part7"/>).
Caches MAY use a heuristic (see Section 2.3.1.1 of <xref target="Part6"/>) to determine freshness
The server is refusing to service the request because the representation of
the request is in a format not supported by the target resource
of the selected resource. See Section 3.2 of <xref target="Part5"/>.
server SHOULD include a representation containing an explanation of the
condition. User agents SHOULD display any included representation to the
Retry-After header field. If no Retry-After is given, the client SHOULD
supported by the target resource. The purpose of
with appropriate error status code. The server MUST respond with a 417
(Expectation Failed) status code if any of the expectations cannot be met
support, it MUST respond with a 417 (Expectation Failed) status code.
return a 417 (Expectation Failed) status code if it receives a request
request-header field itself is end-to-end; it MUST be forwarded if the
Expect header field.
See Section 7.2.3 of <xref target="Part1"/> for the use of the 100 (Continue) status code.
particular, robot agents SHOULD include this header field so that the
of a relative reference (<xref target="RFC3986"/>, Section 4.2),
URI (<xref target="RFC3986"/>, Section 5).
<preamble>Examples are:</preamble><!--DO NOT DARE changing the vertical WSP below, it's necessary this way for xml2rfc-->
]]></artwork></figure><figure><artwork type="example"><![CDATA[ Location: /index.html
would not be appropriate:
<t>With a 201 Created response, because in this usage the Location header
field specifies the URI for the entire created resource.</t>
Note: This specification does not define precedence rules
relative to the effective request URI. The URI MUST NOT include a fragment. See
application MUST NOT modify the Server response-header field. Instead, it
The "User-Agent" request-header field contains information about the user
agent originating the request. User agents SHOULD include this field with
The field can contain multiple product tokens (Section 6.3 of <xref target="Part1"/>)
and comments (Section 3.2 of <xref target="Part1"/>) identifying the agent and its
The User-Agent (<xref target="header.user-agent"/>) or Server (<xref target="header.server"/>) header fields can sometimes be used to determine
Some methods, like TRACE (<xref target="TRACE"/>), expose information
Authorization credentials and other header fields that might be used to
Authors of services SHOULD NOT use GET-based forms for the submission of
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p3-payload-12"/>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p7-auth-12"/>
<reference anchor="RFC3986">
<title abbrev="URI Generic Syntax">Uniform Resource Identifier (URI): Generic Syntax</title>
<organization abbrev="Adobe Systems">Adobe Systems Incorporated</organization>
<date month="January" year="2005"/>
<seriesInfo name="STD" value="66"/>
<seriesInfo name="RFC" value="3986"/>
It used to indicate that the target resource must be accessed through the
Reclassify "Allow" as response header field, removing the option to
Relax the server requirement on the contents of the Allow header field and
remove requirement on clients to always trust the header field value.
Correct syntax of Location header field to allow URI references (including
relative references and fragments), as referred symbol "absoluteURI" wasn't
what was expected, and add some clarifications as to when use of fragments
would not be appropriate.
Allow Referer field value of "about:blank" as alternative to not specifying it.
In the description of the Server header field, the Via field
correctly in the description of the Via header field in Section 9.9 of <xref target="Part1"/>.
in the definition of the Upgrade header field.
<section title="Since draft-ietf-httpbis-p2-semantics-09" anchor="changes.since.09">
<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/43"/>:
"Fragment combination / precedence during redirects"
<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/185"/>:
"Location header payload handling"
<section title="Since draft-ietf-httpbis-p2-semantics-10" anchor="changes.since.10">
<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/139"/>:
"Methods and Caching"
<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/190"/>:
"OPTIONS vs Max-Forwards"
"Status codes and caching"
<section title="Since draft-ietf-httpbis-p2-semantics-11" anchor="changes.since.11">
<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/229"/>:
"Considerations for new status codes"
<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/230"/>:
"Considerations for new methods"
<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/232"/>:
"User-Agent guidelines" (relating to the 'User-Agent' header field)