Source: https://trac.ietf.org/trac/httpbis/export/1286/draft-ietf-httpbis/latest/p1-messaging.html
Timestamp: 2020-02-18 20:00:59
Document Index: 250352143

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

Expires: November 2, 2011 HP
The changes in this draft are summarized in Appendix D.16.
This Internet-Draft will expire on November 2, 2011.
2.5 Protocol Versioning
B. HTTP Version History
B.1.1 Multi-homed Web Servers
B.1.2 Keep-Alive Connections
D.13 Since draft-ietf-httpbis-p1-messaging-11
D.14 Since draft-ietf-httpbis-p1-messaging-12
D.15 Since draft-ietf-httpbis-p1-messaging-13
D.16 Since draft-ietf-httpbis-p1-messaging-14
The OWS rule is used where zero or more linear whitespace octets might appear. OWS SHOULD either not be produced or be produced as a single SP. Multiple OWS octets that occur within field-content SHOULD be replaced with a single SP before interpreting the field value or forwarding the message downstream.
RWS is used when at least one linear whitespace octet is required to separate field tokens. RWS SHOULD be produced as a single SP. Multiple RWS octets that occur within field-content SHOULD be replaced with a single SP before interpreting the field value or forwarding the message downstream.
Senders SHOULD NOT escape octets that do not require escaping (i.e., other than DQUOTE and the backslash octet).
The specific connection protocols to be used for an interaction are determined by client configuration and the target resource's URI. For example, the "http" URI scheme (Section 2.6.1) indicates a default connection of TCP over IP, with a default TCP port of 80, but the client might be configured to use a proxy via some other connection port or protocol instead of using the defaults.
An HTTP-to-HTTP proxy is called a "transforming proxy" if it is designed or configured to modify request or response messages in a semantically meaningful way (i.e., modifications, beyond those required by normal HTTP processing, that change the message in a way that would be significant to the original sender or potentially significant to downstream recipients). For example, a transforming proxy might be acting as a shared annotation server (modifying responses to include references to a local annotation database), a malware filter, a format transcoder, or an intranet-to-Internet privacy filter. Such transformations are presumed to be desired by the client (or client organization) that selected the proxy and are beyond the scope of this specification. However, when a proxy is not intended to transform a given message, we use the term "non-transforming proxy" to target requirements that preserve HTTP message semantics.
The HTTP version number consists of two non-negative decimal integers separated by a "." (period or decimal point). The first number ("major version") indicates the HTTP messaging syntax, whereas the second number ("minor version") indicates the highest minor version to which the sender is at least conditionally compliant and able to understand for future communication. The minor version advertises the sender's communication capabilities even when the sender is only using a backwards-compatible subset of the protocol, thereby letting the recipient know that more advanced features can be used in response (by servers) or in future requests (by clients).
When comparing HTTP versions, the numbers MUST be compared numerically rather than lexically. For example, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is lower than HTTP/12.3. Leading zeros MUST be ignored by recipients and MUST NOT be sent.
Some old HTTP/1.0 client implementations send an extra CRLF after a POST request as a lame workaround for some early server applications that failed to read message-body content that was not terminated by a line-ending. An HTTP/1.1 client MUST NOT preface or follow a request with an extra CRLF. If terminating the request message-body with a line-ending is desired, then the client MUST include the terminating CRLF octets as part of the message-body length.
HTTP allows the set of defined header fields to be extended without changing the protocol version (see Section 10.1). Unrecognized header fields MUST be forwarded by a proxy unless the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields SHOULD be ignored by other recipients.
Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one space or horizontal tab octet (line folding). This specification deprecates such line folding except within the message/http media type (Section 10.3.1). HTTP/1.1 senders MUST NOT produce messages that include line folding (i.e., that contain any field-content that matches the obs-fold rule) unless the message is intended for packaging within the message/http media type. HTTP/1.1 recipients SHOULD accept line folding and replace any embedded obs-fold whitespace with a single SP prior to interpreting the field value or forwarding the message downstream.
Senders SHOULD NOT escape octets that do not require escaping (i.e., other than the backslash octet "\" and the parentheses "(" and ")").
If a valid Content-Length header field is present without Transfer-Encoding, its decimal value defines the message-body length in octets. If the actual number of octets sent in the message is less than the indicated Content-Length, the recipient MUST consider the message to be incomplete and treat the connection as no longer usable. If the actual number of octets sent in the message is more than the indicated Content-Length, the recipient MUST only process the message-body up to the field value's number of octets; the remainder of the message MUST either be discarded or treated as the next message in a pipeline. For the sake of robustness, a user-agent MAY attempt to detect and correct such an error in message framing if it is parsing the response to the last request on on a connection and the connection has been closed by the server.
The "authority form" is only used by the CONNECT request method (Section 7.9 of [Part2] ).
Clients and servers SHOULD NOT assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See Appendix B.1.2 for more information on backward compatibility with HTTP/1.0 clients.
Clients SHOULD NOT pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see Section 7.1.2 of [Part2] ). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to send a non-idempotent request SHOULD wait to send that request until it has received the response status line for the previous request.
This means that clients, servers, and proxies MUST be able to recover from asynchronous close events. Client software SHOULD reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request sequence is idempotent (see Section 7.1.2 of [Part2] ). Non-idempotent request methods or sequences MUST NOT be automatically retried, although user agents MAY offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding of the application MAY substitute for user confirmation. The automatic retry SHOULD NOT be repeated if the second sequence of requests fails.
The purpose of the 100 (Continue) status code (see Section 8.1.1 of [Part2] ) is to allow a client that is sending a request message with a request body to determine if the origin server is willing to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking at the body.
If a client will wait for a 100 (Continue) response before sending the request body, it MUST send an Expect header field (Section 9.2 of [Part2] ) with the "100-continue" expectation.
A client MUST NOT send an Expect header field (Section 9.2 of [Part2] ) with the "100-continue" expectation if it does not intend to send a request body.
A proxy MUST NOT forward a 100 (Continue) response if the request message was received from an HTTP/1.0 (or earlier) client and did not include an Expect header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of 1xx responses (see Section 8.1 of [Part2] ).
Host = uri-host [ ":" port ] ; Section 2.6.1
A client MUST send a Host header field in all HTTP/1.1 request messages. If the target resource's URI includes an authority component, then the Host field-value MUST be identical to that authority component after excluding any userinfo (Section 2.6.1). If the authority component is missing or undefined for the target resource's URI, then the Host header field MUST be sent with an empty field-value.
The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it is more appropriate to use a 3xx redirection response (Section 8.3 of [Part2] ).
HTTP 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.
[Part2] 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-latest (work in progress), May 2011.
[Part3] 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-latest (work in progress), May 2011.
[Part6] 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-latest (work in progress), May 2011.
The line terminator for header fields is the sequence CRLF. However, we recommend that applications, when parsing such headers fields, recognize a single LF as a line terminator and ignore the leading CR.
The character encoding of a representation SHOULD be labeled as the lowest common denominator of the character codes used within that representation, with the exception that not labeling the representation is preferred over labeling the representation with the labels US-ASCII or ISO-8859-1. See [Part3] .
Rules about implicit linear whitespace between certain grammar productions have been removed; now it's only allowed when specifically pointed out in the ABNF. The NUL octet is no longer allowed in comment and quoted-string text. The quoted-pair rule no longer allows escaping control characters other than HTAB. Non-ASCII content in header fields and reason phrase has been obsoleted and made opaque (the TEXT rule was removed) (Section 1.2.2)
Connection header field 2.3, 2.5, 3.4, 7.1.2, 7.1.3, 7.1.3.1, 9.1, 9.5, 9.8, 10.1, B.1.2, B.2
Date header field 3.4, 9.3, 10.1
Connection 2.3, 2.5, 3.4, 7.1.2, 7.1.3, 7.1.3.1, 9.1, 9.5, 9.8, 10.1, B.1.2, B.2
Transfer-Encoding 3.3, 3.4, 6.2, 9.7, 10.1
Upgrade 3.4, 9.8, 10.1, B.2
Via 2.3, 3.4, 9.9, 10.1
Host header field 4.3, 9.4, 10.1, B.1.1
Part2 4.1.2, 4.1.2, 5.1.1, 7.1.2.2, 7.1.4, 7.2.3, 7.2.3, 7.2.3, 7.2.3, 9.8, 13.1
Section 8.3 9.8
Part3 1, 6.2.3, 6.4, 7.1.3.2, 9.7, 13.1, A
Part6 2.4, 2.6.2, 3.3, 7.1.3.2, 9.1, 13.1
Section 3.2 2.6.2, 9.1
Section 3.6 7.1.3.2
RFC1919 2.3, 13.2
RFC1945 2.5, 13.2, B
RFC2068 2.5, 7.1.3, 7.2.3, 12, 13.1, 13.1, 13.1, 13.2, B.1.2
Section 19.7.1 7.1.3, B.1.2
RFC2145 1, 13.2
RFC2616 1, 2.5, 12, 13.2, D.1
RFC2817 10.5, 13.2, B.2
RFC3040 2.3, 13.2
RFC6265 2.6.2, 3.2, 13.2
Trailer header field 3.4, 6.2.1, 9.6, 10.1
Transfer-Encoding header field 3.3, 3.4, 6.2, 9.7, 10.1
Upgrade header field 3.4, 9.8, 10.1, B.2
Via header field 2.3, 3.4, 9.9, 10.1