Source: https://trac.ietf.org/trac/httpbis/export/1456/draft-ietf-httpbis/01/p1-messaging.html
Timestamp: 2020-04-10 04:02:23
Document Index: 624006566

Matched Legal Cases: ['art3', 'art3', 'art3', 'art3', 'art2', 'art3', 'art3', 'art2', 'art2', 'art3', 'art2', 'art6', 'art6', 'art6', 'art3', 'art2', 'art3', 'art6', 'art 6', 'art2', 'art3', 'art6']

draft-ietf-httpbis-p1-messaging-01
The information transferred as the payload of a request or response. An entity consists of metainformation in the form of entity-header fields and content in the form of an entity-body, as described in Section 3 of [Part3] .
An entity included with a response that is subject to content negotiation, as described in Section 4 of [Part3] . There may exist multiple representations associated with a particular response status.
The mechanism for selecting the appropriate representation when servicing a request, as described in Section 4 of [Part3] . The representation of entities in any response can be negotiated (including error responses).
UPALPHA        = <any US-ASCII uppercase letter "A".."Z">
LOALPHA        = <any US-ASCII lowercase letter "a".."z">
ALPHA          = UPALPHA | LOALPHA
DIGIT          = <any US-ASCII digit "0".."9">
HTAB           = <US-ASCII HT, horizontal-tab (9)>
DQUOTE         = <US-ASCII double-quote mark (34)>
HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body (see Appendix B for tolerant applications). The end-of-line marker within an entity-body is defined by its associated media type, as described in Section 2.3 of [Part3] .
HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT
URIs in HTTP can be represented in absolute form or relative to some known base URI [RFC1808] , depending upon the context of their use. The two forms are differentiated by the fact that absolute URIs always begin with a scheme name followed by a colon. For definitive information on URL syntax and semantics, see "Uniform Resource Identifiers (URI): Generic Syntax and Semantics," [RFC2396] (which replaces [RFC1738] and [RFC1808] ). This specification adopts the definitions of "URI-reference", "absoluteURI", "relativeURI", "port", "host", "abs_path", "rel_path", "query", and "authority" from that specification.
The HTTP protocol does not place any 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] ).
If the port is empty or not given, port 80 is assumed. The semantics are that the identified resource is located at the server listening for TCP connections on that port of that host, and the Request-URI for the resource is abs_path (Section 5.1.2). The use of IP addresses in URLs SHOULD be avoided whenever possible (see [RFC1900] ). If the abs_path is not present in the URL, it MUST be given as "/" when used as a Request-URI for a resource (Section 5.1.2). If a proxy receives a host name which is not a fully qualified domain name, it MAY add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy MUST NOT change the host name.
An empty abs_path is equivalent to an abs_path of "/".
HTTP-date    = rfc1123-date | rfc850-date | asctime-date
The Internet Assigned Numbers Authority (IANA) acts as a registry for transfer-coding value tokens. Initially, the registry contains the following tokens: "chunked" (Section 3.4.1), "gzip", "compress", and "deflate" (Section 2.2 of [Part3] ).
New transfer-coding value tokens SHOULD be registered in the same way as new content-coding value tokens (Section 2.2 of [Part3] ).
trailer        = *(entity-header CRLF)
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 3.1 of [Part3] ) fields, follow the same generic format as that given in Section 2.1 of [RFC2822] . 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.
The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field in the request's message-headers. A message-body MUST NOT be included in a request if the specification of the request method (Section 3 of [Part2] ) does not allow sending an entity-body in requests. A server SHOULD read and forward a message-body on any request; if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request.
general-header = Cache-Control            ; [Part6] , Section 15.2
| Pragma                   ; [Part6] , Section 15.4
| Warning                  ; [Part6] , Section 15.6
| entity-header ) CRLF)  ; [Part3] , Section 3.1
The most common form of Request-URI is that used to identify a resource on an origin server or gateway. In this case the absolute path of the URI MUST be transmitted (see Section 3.2.1, abs_path) as the Request-URI, and the network location of the URI (authority) MUST be transmitted in a Host header field. For example, a client wishing to retrieve the resource above directly from the origin server would create a TCP connection to port 80 of the host "www.example.org" and send the lines:
A transparent proxy MUST NOT rewrite the "abs_path" part of the received Request-URI when forwarding it to the next inbound server, except as noted above to replace a null abs_path with "/".
The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. These codes are fully defined in Section 9 of [Part2] . The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use by automata and the Reason-Phrase is intended for the human user. The client is not required to examine or display the Reason-Phrase.
Host = "Host" ":" host [ ":" port ] ; Section 3.2.2
If the transfer-coding being tested is one of the transfer-codings listed in the TE field, then it is acceptable unless it is accompanied by a qvalue of 0. (As defined in Section 2.4 of [Part3] , a qvalue of 0 means "not acceptable.")
The Via general-header field 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 of [RFC2822] 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.
received-by       = ( host [ ":" port ] ) | pseudonym
HTTP clients are often privy to large amounts of personal information (e.g. the user's name, location, mail address, passwords, encryption keys, etc.), and SHOULD be very careful to prevent unintentional leakage of this information via the HTTP protocol to other sources. We very strongly recommend that a convenient interface be provided for the user to control dissemination of such information, and that designers and implementors be particularly careful in this area. History shows that errors in this area often create serious security and/or privacy problems and generate highly adverse publicity for the implementor's company.
A server is in the position to save personal data about a user's requests which might identify their reading patterns or subjects of interest. This information is clearly confidential in nature and its handling can be constrained by law in certain countries. People using the HTTP protocol to provide data are responsible for ensuring that such material is not distributed without the permission of any individuals that are identifiable by the published results.
The HTTP protocol has evolved considerably over the years. It has benefited from a large and active developer community--the many people who have participated on the www-talk mailing list--and it is that community which has been most responsible for the success of HTTP and of the World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special recognition for their efforts in defining early aspects of the protocol.
[Part6] 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-01 (work in progress), January 2008.
In addition to defining the HTTP/1.1 protocol, this document serves as the specification for the Internet media type "message/http" and "application/http". The following is to be registered with IANA [RFC4288] .
Connection header 4.5, 7.1.2, 7.1.3, 8.1, 8.5, 8.8, D.2, D.4
Date header 4.5, 8.3
http_URL 3.2.2
LOALPHA 2.2
trailer 3.4.1
UPALPHA 2.2
Connection 4.5, 7.1.2, 7.1.3, 8.1, 8.5, 8.8, D.2, D.4
Date 4.5, 8.3
Host 8.4, D.1.1
TE 3.4, 3.4.1, 8.5, D.3
Trailer 3.4.1, 4.5, 8.6
Transfer-Encoding 3.4, 4.3, 4.4, 4.5, 8.7
Upgrade 4.5, 8.8
Via 4.5, 8.9
Host header 8.4, D.1.1
Part2 3.2.1, 4.2, 4.2, 4.3, 5, 5.1.2, 6, 6.1.1, 7.1.2.2, 7.1.4, 7.2.3, 7.2.3, 7.2.3, 7.2.3, 12.1
Section 4 4.2, 5
Section 6 4.2, 6
Part3 1.3, 1.3, 1.3, 1.4, 2.2, 3.4, 3.4, 4.2, 5, 6, 8.5, 12.1, B, D.3
Section 2.2 3.4, 3.4
Section 2.3 2.2
Section 2.4 8.5
Section 3 1.3
Section 3.1 4.2, 5, 6
Section 4 1.3, 1.3
Part6 1.3, 1.4, 4.5, 4.5, 4.5, 12.1, D.3
Section 15.2 4.5
Section 15.4 4.5
Section 15.6 4.5
RFC2396 3.2.1, 3.2.3, 5.1.2, 12.1, D.4
Section 3 D.4
RFC4288 12.1, A
TE header 3.4, 3.4.1, 8.5, D.3
Trailer header 3.4.1, 4.5, 8.6
Transfer-Encoding header 3.4, 4.3, 4.4, 4.5, 8.7
Upgrade header 4.5, 8.8
Via header 4.5, 8.9