Source: https://trac.ietf.org/trac/httpbis/export/1650/draft-ietf-httpbis/latest/p2-semantics.html
Timestamp: 2019-12-08 18:31:46
Document Index: 39350408

Matched Legal Cases: ['art 2', 'art6', 'art1', 'art1', 'art4', 'art5']

Expires: October 1, 2012 greenbytes
Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields. Furthermore, it defines HTTP message content, metadata, and content negotiation. [rfc.comment.1: #351]
This Internet-Draft will expire on October 1, 2012.
E.40 Since draft-ietf-httpbis-p2-semantics-19
E.41 Since draft-ietf-httpbis-p3-payload-19
Furthermore, it defines HTTP/1.1 message payloads (a.k.a., content), the associated metadata header fields that define how the payload is intended to be interpreted by a recipient, the request header fields that might influence content selection, and the various selection algorithms that are collectively referred to as HTTP content negotiation. [rfc.comment.2: #351]
New method definitions need to indicate whether they are safe (Section 2.1.1), what semantics (if any) the request body has, and whether they are idempotent (Section 2.1.2). They also need to state whether they can be cached ( [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.
The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header field (Section 9.16). If no Retry-After is given, the client SHOULD handle the response as it would for a 500 response.
Request and Response messages MAY transfer a representation if not otherwise restricted by the request method or response status code. A representation consists of metadata (representation header fields) and data (representation body). When a complete or partial representation is enclosed in an HTTP message, it is referred to as the payload of the message. [rfc.comment.3: #351]
A representation body is only present in a message when a message body is present, as described in Section 3.3 of [Part1] . The representation body is obtained from the message body by decoding any Transfer-Encoding that might have been applied to ensure safe and proper transfer of the message. [rfc.comment.4: #351]
CONNECT no Section 2.3.8
DELETE no Section 2.3.6
GET yes Section 2.3.2
HEAD yes Section 2.3.3
OPTIONS yes Section 2.3.1
POST no Section 2.3.4
PUT no Section 2.3.5
TRACE yes Section 2.3.7
Deprecate 305 Use Proxy status code, because user agents did not implement it. It used to indicate that the target resource needs to be accessed through the proxy given by the Location field. The Location field gave the URI of the proxy. The recipient was expected to repeat this single request via the proxy. (Section 4.5.5)
Remove the default character encoding for text media types; the default now is whatever the media type definition says. (Section 5.5.1)
; qvalue UNDEFINED
Part1 1, 1.2, 1.3, 1.3.1, 1.3.1, 1.3.1, 1.3.1, 1.3.1, 1.3.1, 1.3.1, 1.3.1, 1.3.2, 1.3.2, 1.3.2, 1.3.2, 2, 2.2.1, 2.3.1, 2.3.7, 2.3.7, 2.3.8, 3, 3.1, 3.1, 3.1, 3.1, 3.1, 3.2, 3.2, 3.3, 4.3.1, 4.3.2, 4.4.4, 4.4.6, 4.6.15, 4.7.6, 5.4, 5.4, 5.4, 5.4.1, 5.4.1, 6.1, 6.2, 7, 7.1, 8.1, 9.1, 9.3, 9.8, 9.11, 9.17, 9.17, 9.18, 10.4, 10.4, 10.4, 12, 13.1, A.6, C
Section 4.3.1 8.1, 9.1, 9.3
Part4 3.2, 3.2, 3.2, 3.2, 3.3, 4.1, 4.1, 4.1, 4.4.2, 4.5, 7.2, 7.2, 13.1, E.2
Part5 2.3.2, 3.2, 3.2, 3.3, 4.1, 4.1, 4.1, 6.1, 13.1