Source: https://greenbytes.com/tech/webdav/draft-ietf-httpbis-p2-semantics-14.html
Timestamp: 2020-01-21 03:45:00
Document Index: 740240268

Matched Legal Cases: ['art 2', 'art 2', 'art6', 'art4', 'art5', 'art7', 'art1', 'art4', 'art1', 'art1', 'art 1', 'art 3', 'art 4', 'art 5', 'art 6', 'art 7']

The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields.¶
This Internet-Draft will expire on October 20, 2011.¶
The changes in this draft are summarized in Appendix C.15.¶
7.9.1. Establishing a Tunnel with CONNECT
8.4.19. 426 Upgrade Required
The methods listed below are defined in Section 7.¶
New method definitions need to indicate whether they are safe (Section 7.1.1), what semantics (if any) the request body has, and whether they are idempotent (Section 7.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 status codes listed below are defined in Section 8 of this specification, Section 4 of [Part4] , Section 3 of [Part5] , and Section 3 of [Part7] . The reason phrases listed here are only recommendations — they can be replaced by local equivalents without affecting the protocol.¶
The Max-Forwards header field MAY be used to target a specific proxy in the request chain (see Section 9.5). If no Max-Forwards field is present in the request, then the forwarded request MUST NOT include a Max-Forwards field.¶
The TRACE method requests a remote, application-layer loop-back of the request message. The final recipient of the request SHOULD reflect the message received back to the client as the message-body of a 200 (OK) response. The final recipient is either the origin server or the first proxy to receive a Max-Forwards value of zero (0) in the request (see Section 9.5). A TRACE request MUST NOT include a message-body.¶
When using CONNECT, the request-target MUST use the authority form (Section 4.1.2 of [Part1] ); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon. For example,¶
A 201 response MAY contain an ETag response header field indicating the current value of the entity-tag for the representation of the resource just created (see Section 2.2 of [Part4] ).¶
The 204 response allows a server to indicate that the action has been successfully applied to the target resource while implying that the user agent SHOULD NOT traverse away from its current "document view" (if any). The server assumes that the user agent will provide some indication of the success to its user, in accord with its own interface, and apply any new or updated metadata in the response to the active representation. For example, a 204 status code is commonly used with document editing interfaces corresponding to a "save" action, such that the document being saved remains available to the user for editing. It is also frequently used with interfaces that expect automated data transfers to be prevalent, such as within distributed version control systems.¶
The expectation given in an Expect header field (see Section 9.2) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could not be met by the next-hop server.¶
The request can not be completed without a prior protocol upgrade. This response MUST include an Upgrade header field (Section 9.8 of [Part1] ) specifying the required protocols.¶
The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST return a 417 (Expectation Failed) status code if it receives a request with an expectation that it cannot meet. However, the Expect header field itself is end-to-end; it MUST be forwarded if the request is forwarded.¶
The "Max-Forwards" header field provides a mechanism with the TRACE (Section 7.8) and OPTIONS (Section 7.2) methods to limit the number of times that the request is forwarded by proxies. This can be useful when the client is attempting to trace a request which appears to be failing or looping in mid-chain.¶
If the response is being forwarded through a proxy, the proxy application MUST NOT modify the Server header field. Instead, it MUST include a Via field (as described in Section 9.9 of [Part1] ).¶
Some request methods, like TRACE (Section 7.8), expose information that was sent in request header fields within the body of their response. Clients SHOULD be careful with sensitive information, like Cookies, Authorization credentials, and other header fields that might be used to collect data from the client.¶
Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., and J. Reschke, Ed., “HTTP/1.1, part 1: URIs, Connections, and Message Parsing”, Internet-Draft draft-ietf-httpbis-p1-messaging-14 (work in progress), April 2011.
Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., and J. Reschke, Ed., “HTTP/1.1, part 3: Message Payload and Content Negotiation”, Internet-Draft draft-ietf-httpbis-p3-payload-14 (work in progress), April 2011.
Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., and J. Reschke, Ed., “HTTP/1.1, part 4: Conditional Requests”, Internet-Draft draft-ietf-httpbis-p4-conditional-14 (work in progress), April 2011.
Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., and J. Reschke, Ed., “HTTP/1.1, part 5: Range Requests and Partial Responses”, Internet-Draft draft-ietf-httpbis-p5-range-14 (work in progress), April 2011.
Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “HTTP/1.1, part 6: Caching”, Internet-Draft draft-ietf-httpbis-p6-cache-14 (work in progress), April 2011.
Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., and J. Reschke, Ed., “HTTP/1.1, part 7: Authentication”, Internet-Draft draft-ietf-httpbis-p7-auth-14 (work in progress), April 2011.
Remove requirement to handle all Content-* header fields; ban use of Content-Range with PUT. (Section 7.6)¶
Take over definition of CONNECT method from [RFC2817] . (Section 7.9)¶
Define status 426 (Upgrade Required) (this was incorporated from [RFC2817] ). (Section 8.4.19)¶
Restrict Max-Forwards header field to OPTIONS and TRACE (previously, extension methods could have used it as well). (Section 9.5)¶