Source: https://greenbytes.com/tech/webdav/draft-ietf-httpbis-p1-messaging-05.html
Timestamp: 2020-01-28 23:41:43
Document Index: 114132626

Matched Legal Cases: ['art3', 'art 1', 'art 1', 'art2', 'art2', 'art2', 'art3', 'art 2', 'art 3', 'art 5', 'art 6']

This Internet-Draft will expire on May 20, 2009.¶
The changes in this draft are summarized in Appendix E.6.¶
1.2. Overall Operation
2.1. ABNF Extension: #rule
3.2.1. http URI scheme
3.2.2. URI Comparison
Appendix D. Terminology
E.5. Since draft-ietf-httpbis-p1-messaging-03
E.6. Since draft-ietf-httpbis-p1-messaging-04
The Hypertext Transfer Protocol (HTTP) is an application-level request/response protocol that uses extensible semantics and MIME-like message payloads for flexible interaction with network-based hypermedia information systems. HTTP relies upon the Uniform Resource Identifier (URI) standard [RFC3986] to indicate resource targets for interaction and to identify other resources. Messages are passed in a format similar to that used by Internet mail [RFC5322] and the Multipurpose Internet Mail Extensions (MIME) [RFC2045] (see Appendix A of [Part3] for the differences between HTTP and MIME messages).¶
HTTP is also designed for use as a generic protocol for translating communication to and from other Internet information systems, such as USENET news services via NNTP [RFC3977] , file services via FTP [RFC959] , Gopher [RFC1436] , and WAIS [WAIS] . HTTP proxies and gateways provide access to alternative information services by translating their diverse protocols into a hypermedia format that can be viewed and manipulated by clients in the same way as HTTP services.¶
This document is Part 1 of the seven-part specification of HTTP, defining the protocol referred to as "HTTP/1.1" and obsoleting [RFC2616] . Part 1 defines how clients determine when to use HTTP, the URI schemes specific to HTTP-based resources, overall network operation with transport protocol connection management, and HTTP message framing. Our goal is to define all of the mechanisms necessary for HTTP message handling that are independent of message semantics, thereby defining the complete set of requirements for an HTTP message relay or generic message parser.¶
One extension to the ABNF rules of [RFC5234] is used to improve readability.¶
A construct "#" is defined, similar to "*", for defining lists of elements. The full form is "<n>#<m>element" indicating at least <n> and at most <m> elements, each separated by one or more commas (",") and OPTIONAL linear white space (OWS). This makes the usual form of lists very easy; a rule such as ¶
can be shown as ¶
Wherever this construct is used, null elements are allowed, but do not contribute to the count of elements present. That is, "(element), , (element) " is permitted, but counts as only two elements. Therefore, where at least one element is required, at least one non-null element MUST be present. Default values are 0 and infinity so that "#element" allows any number, including zero; "1#element" requires at least one; and "1#2element" allows one or two.¶
[abnf.list: At a later point of time, we may want to add an appendix containing the whole ABNF, with the list rules expanded to strict RFC 5234 notation.] ¶
This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] . The following core rules are included by reference, as defined in [RFC5234] , Appendix B.1: ALPHA (letters), CHAR (any [USASCII] character, excluding NUL), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed), OCTET (any 8-bit sequence of data), SP (space) and WSP (white space).¶
All linear white space (LWS) in header field-values has the same semantics as SP. A recipient MAY replace any such linear white space with a single SP before interpreting the field value or forwarding the message downstream.¶
Historically, HTTP/1.1 header field values allow linear white space folding across multiple lines. However, this specification deprecates its use; senders MUST NOT produce messages that include LWS folding (i.e., use the obs-fold rule), except within the message/http media type (Section 9.3.1). Receivers SHOULD still parse folded linear white space.¶
This specification uses three rules to denote the use of linear white space; BWS ("Bad" White Space), OWS (Optional White Space), and RWS (Required White Space).¶
"Bad" white space is allowed by the BNF, but senders SHOULD NOT produce it in messages. Receivers MUST accept it in incoming messages.¶
Required white space is used when at least one linear white space character is required to separate field tokens. In all such cases, a single SP character SHOULD be used.¶
Uniform Resource Identifiers (URIs) [RFC3986] are used in HTTP to indicate the target of a request and to identify additional resources related to that resource, the request, or the response. Each protocol element in HTTP that allows a URI reference will indicate in its ABNF whether the element allows only a URI in absolute form, any relative reference, or some limited subset of the URI-reference grammar. Unless otherwise indicated, relative URI references are to be parsed relative to the URI corresponding to the request target (the base URI).¶
This specification adopts the definitions of "URI-reference", "absolute-URI", "fragment", "port", "host", "path-abempty", "path-absolute", "query", and "authority" from [RFC3986] :¶
HTTP does not place an a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see Section 9.4.15 of [Part2] ).¶
The "http" scheme is used to locate network resources via the HTTP protocol. This section defines the syntax and semantics for identifiers using the http or https URI schemes.¶
Characters other than those in the "reserved" set (see [RFC3986] , Section 2.2) are equivalent to their ""%" HEXDIG HEXDIG" encoding.¶
Request (Section 5) and Response (Section 6) messages use the generic message format of [RFC5322] for transferring entities (the payload of the message). Both types of message consist of a start-line, zero or more header fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields, and possibly a message-body.¶
HTTP header fields, which include general-header (Section 4.5), request-header (Section 4 of [Part2] ), response-header (Section 6 of [Part2] ), and entity-header (Section 4.1 of [Part3] ) fields, follow the same generic format as that given in Section 2.1 of [RFC5322] . Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive. The field value MAY be preceded by any amount of LWS, though a single SP is preferred. Header fields can be extended over multiple lines by preceding each extra line with at least one SP or HTAB. Applications ought to follow "common form", where one is known or indicated, when generating HTTP constructs, since there might exist some implementations that fail to accept anything beyond the common forms.¶
[rfc.comment.1: whitespace between field-name and colon is an error and MUST NOT be accepted] ¶
/ Connection               ; Section 8.1
/ Date                     ; Section 8.3
/ Trailer                  ; Section 8.6
/ Transfer-Encoding        ; Section 8.7
/ Upgrade                  ; Section 8.8
/ Via                      ; Section 8.9
The Request-URI is transmitted in the format specified in Section 3.2.1. If the Request-URI is encoded using the "% HEXDIG HEXDIG" encoding ( [RFC3986] , Section 2.4), the origin server MUST decode the Request-URI in order to properly interpret the request. Servers SHOULD respond to invalid Request-URIs with an appropriate status code.¶
The general-header field "Connection" allows the sender to specify options that are desired for that particular connection and MUST NOT be communicated by proxies over further connections.¶
The entity-header field "Content-Length" indicates the size of the entity-body, in decimal number of OCTETs, sent to the recipient or, in the case of the HEAD method, the size of the entity-body that would have been sent had the request been a GET.¶
The general-header field "Date" represents the date and time at which the message was originated, having the same semantics as orig-date in Section 3.6.1 of [RFC5322] . The field value is an HTTP-date, as described in Section 3.3.1; it MUST be sent in rfc1123-date format.¶
The request-header field "Host" specifies the Internet host and port number of the resource being requested, as obtained from the original URI given by the user or referring resource (generally an HTTP URL, as described in Section 3.2.1). The Host field value MUST represent the naming authority of the origin server or gateway given by the original URL. This allows the origin server or gateway to differentiate between internally-ambiguous URLs, such as the root "/" URL of a server for multiple host names on a single IP address.¶
Host-v = uri-host [ ":" port ] ; Section 3.2.1
The request-header field "TE" indicates what extension transfer-codings it is willing to accept in the response and whether or not it is willing to accept trailer fields in a chunked transfer-coding. Its value may consist of the keyword "trailers" and/or a comma-separated list of extension transfer-coding names with optional accept parameters (as described in Section 3.4).¶
The general field "Trailer" indicates that the given set of header fields is present in the trailer of a message encoded with chunked transfer-coding.¶
The general-header "Transfer-Encoding" field indicates what (if any) type of transformation has been applied to the message body in order to safely transfer it between the sender and the recipient. This differs from the content-coding in that the transfer-coding is a property of the message, not of the entity.¶
The general-header "Upgrade" allows the client to specify what additional communication protocols it supports and would like to use if the server finds it appropriate to switch protocols. The server MUST use the Upgrade header field within a 101 (Switching Protocols) response to indicate which protocol(s) are being switched.¶
The general-header field "Via" MUST be used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server on requests, and between the origin server and the client on responses. It is analogous to the "Received" field defined in Section 3.6.7 of [RFC5322] and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities of all senders along the request/response chain.¶
The entry for the "http" URI Scheme in the registry located at <http://www.iana.org/assignments/uri-schemes.html> should be updated to point to Section 3.2.1 of this document (see [RFC4395] ).¶
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 2: Message Semantics”, Internet-Draft draft-ietf-httpbis-p2-semantics-05 (work in progress), November 2008.
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-05 (work in progress), November 2008.
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-05 (work in progress), November 2008.
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 6: Caching”, Internet-Draft draft-ietf-httpbis-p6-cache-05 (work in progress), November 2008.
Rules about implicit linear white space between certain grammar productions have been removed; now it's only allowed when specifically pointed out in the ABNF. The CHAR rule does not allow the NUL character anymore (this affects the comment and quoted-string rules). Furthermore, the quoted-pair rule does not allow escaping NUL, CR or LF anymore. (Section 2.2)¶
Update use of abs_path production from RFC1808 to the path-absolute + query components of RFC3986. (Section 5.1.2)¶