Source: https://trac.ietf.org/trac/httpbis/export/2096/draft-ietf-httpbis/latest/p1-messaging.html
Timestamp: 2019-09-21 17:59:06
Document Index: 421271383

Matched Legal Cases: ['art2', 'art6', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art6', 'art6', 'art2', 'art2', 'art2', 'art2', 'art2', 'art2', 'art4', 'art5', 'art6', 'art7', 'art2', 'art4', 'art5', 'art6']

Intended status: Standards Track January 5, 2013
Expires: July 9, 2013
This Internet-Draft will expire on July 9, 2013.
6.3.1 Pipelining
6.3.2 Retrying Requests
7.3 Internet Media Type Registration
7.5 Transfer Coding Registration
8.1 DNS-related Attacks
8.2 Intermediaries and Caching
8.3 Buffer Overflows
8.4 Message Integrity
8.5 Server Log Information
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. See Section 6.3.4 of [Part2] and Section 7.5 of [Part6] for status and warning codes related to transformations.
A gateway behaves as an origin server on its outbound connection and as a user agent on its inbound connection. All HTTP requirements applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification. However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers MUST conform to HTTP user agent requirements on the gateway's inbound connection and MUST implement the Connection (Section 6.1) and Via (Section 5.7.1) header fields for both connections.
The URI generic syntax for authority also includes a deprecated userinfo subcomponent ( [RFC3986] , Section 3.2.1) for including user authentication information in the URI. Some implementations make use of the userinfo component for internal configuration of authentication information, such as within command invocation options, configuration files, or bookmark lists, even though such usage might expose a user identifier or password. Senders MUST exclude the userinfo subcomponent (and its "@" delimiter) when an "http" URI is transmitted within a message as a request target or header field value. Recipients of an "http" URI reference SHOULD parse for userinfo and treat its presence as an error, since it is likely being used to obscure the authority for the sake of phishing attacks.
If the port is equal to the default port for a scheme, the normal form is to elide the port subcomponent. When not being used in absolute form as the request target of an OPTIONS request, an empty path component is equivalent to an absolute path of "/", so the normal form is to provide a path of "/" instead. The scheme and host are case-insensitive and normally provided in lowercase; all other components are compared in a case-sensitive manner. Characters other than those in the "reserved" set are equivalent to their percent-encoded octets (see [RFC3986] , Section 2.1): the normal form is to not encode them.
The methods defined by this specification can be found in Section 4 of [Part2] , along with information regarding the HTTP method registry and considerations for defining new methods.
HTTP does not place a pre-defined limit on the length of a request-line. A server that receives a method longer than any that it implements SHOULD respond with a 501 (Not Implemented) status code. A server MUST be prepared to receive URIs of unbounded length and respond with the 414 (URI Too Long) status code if the received request-target would be longer than the server wishes to handle (see Section 6.5.12 of [Part2] ).
HTTP header fields are fully extensible: there is no limit on the introduction of new field names, each presumably defining new semantics, nor on the number of header fields used in a given message. Existing fields are defined in each part of this specification and in many other specifications outside the core standard. New header fields can be introduced without changing the protocol version if their defined semantics allow them to be safely ignored by recipients that do not recognize them.
New HTTP header fields ought to be be registered with IANA in the Message Header Field Registry, as described in Section 8.3 of [Part2] . A proxy MUST forward unrecognized header fields unless the field-name is listed in the Connection header field (Section 6.1) or the proxy is specifically configured to block, or otherwise transform, such fields. Other recipients SHOULD ignore unrecognized header fields.
Multiple header fields with the same field name can be combined into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field value to the combined field value in order, separated by a comma. The order in which header fields with the same field name are received is therefore significant to the interpretation of the combined field value; a proxy MUST NOT change the order of these field values when forwarding a message.
The OWS rule is used where zero or more linear whitespace octets might appear. OWS SHOULD either not be generated or be generated as a single SP. Multiple OWS octets that occur within field-content SHOULD either be replaced with a single SP or transformed to all SP octets (each octet other than SP replaced with 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 generated as a single SP. Multiple RWS octets that occur within field-content SHOULD either be replaced with a single SP or transformed to all SP octets before interpreting the field value or forwarding the message downstream.
BWS is used where the grammar allows optional whitespace, for historical reasons, but senders SHOULD NOT generate it in messages; recipients MUST accept such bad optional whitespace and remove it before interpreting the field value or forwarding the message downstream.
Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one space or horizontal tab (obs-fold). This specification deprecates such line folding except within the message/http media type (Section 7.3.1). Senders MUST NOT generate messages that include line folding (i.e., that contain any field-value that matches the obs-fold rule) unless the message is intended for packaging within the message/http media type. Recipients MUST accept line folding and replace any embedded obs-fold whitespace with either a single SP or a matching number of SP octets (to avoid buffer copying) prior to interpreting the field value or forwarding the message downstream.
HTTP does not place a pre-defined limit on the length of each header field or on the length of the header block as a whole. Various ad-hoc limitations on individual header field length are found in practice, often depending on the specific field semantics.
A server MUST be prepared to receive request header fields of unbounded length and respond with an appropriate 4xx (Client Error) status code if the received header field(s) are larger than the server wishes to process.
A client MUST be prepared to receive response header fields of unbounded length. A client MAY discard or truncate received header fields that are larger than the client wishes to process if the field semantics are such that the dropped value(s) can be safely ignored without changing the response semantics.
Senders SHOULD NOT generate a quoted-pair in a quoted-string except where necessary to quote DQUOTE and backslash octets occurring within that string.
All HTTP/1.1 recipients MUST implement the chunked transfer coding (Section 4.1) because it plays a crucial role in framing messages when the payload body size is not known in advance. If chunked is applied to a payload body, the sender MUST NOT apply chunked more than once (i.e., chunking an already chunked message is not allowed). If any transfer coding is applied to a request payload body, the sender MUST apply chunked as the final transfer coding to ensure that the message is properly framed. If any transfer coding is applied to a response payload body, the sender MUST either apply chunked as the final transfer coding or terminate the message by closing the connection.
Unlike Content-Encoding (Section 3.1.2.1 of [Part2] ), Transfer-Encoding is a property of the message, not of the payload, and any recipient along the request/response chain MAY decode the received transfer coding(s) or apply additional transfer coding(s) to the message body, assuming that corresponding changes are made to the Transfer-Encoding field-value. Additional information about the encoding parameters MAY be provided by other header fields not defined by this specification.
When a message does not have a Transfer-Encoding header field, a Content-Length header field can provide the anticipated size, as a decimal number of octets, for a potential payload body. For messages that do include a payload body, the Content-Length field-value provides the framing information necessary for determining where the body (and message) ends. For messages that do not include a payload body, the Content-Length indicates the size of the selected representation (Section 7.2 of [Part2] ).
A server MUST NOT send a Content-Length header field in any response with a status code of 1xx (Informational) or 204 (No Content). A server SHOULD NOT send a Content-Length header field in any 2xx (Successful) response to a CONNECT request (Section 4.3.6 of [Part2] ).
Aside from the cases defined above, in the absence of Transfer-Encoding, an origin server SHOULD send a Content-Length header field when the payload body size is known prior to sending the complete header block. This will allow downstream recipients to measure transfer progress, know when a received message is complete, and potentially reuse the connection for additional requests.
Any Content-Length field value greater than or equal to zero is valid. Since there is no predefined limit to the length of an HTTP payload, recipients SHOULD anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows (Section 8.3).
If a response terminates in the middle of the header block (before the empty line is received) and the status code might rely on header fields to convey the full meaning of the response, then the client cannot assume that meaning has been conveyed; the client might need to repeat the request in order to determine what action to take next.
A message body that uses the chunked transfer coding is incomplete if the zero-sized chunk that terminates the encoding has not been received. A message that uses a valid Content-Length is incomplete if the size of the message body received (in octets) is less than the value given by Content-Length. A response that has neither chunked transfer coding nor Content-Length is terminated by closure of the connection, and thus is considered complete regardless of the number of message body octets received, provided that the header block was received intact.
Older HTTP/1.0 user agent implementations might 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 user agent 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 user agent MUST count the terminating CRLF octets as part of the message body length.
In the interest of robustness, servers SHOULD ignore at least one empty line received where a request-line is expected. In other words, if a server is reading the protocol stream at the beginning of a message and receives a CRLF first, the server SHOULD ignore the CRLF.
All transfer-coding names are case-insensitive and ought to be registered within the HTTP Transfer Coding registry, as defined in Section 7.4. They are used in the TE (Section 4.3) and Transfer-Encoding (Section 3.3.1) header fields.
The chunked transfer coding modifies the body of a message in order to transfer it as a series of chunks, each with its own size indicator, followed by an OPTIONAL trailer containing header fields. This allows dynamically generated content to be transferred along with the information necessary for the recipient to verify that it has received the full message.
Chunk extensions within the chunked transfer coding are deprecated. Senders SHOULD NOT send chunk-ext. Definition of new chunk extensions is discouraged.
When a message includes a message body encoded with the chunked transfer coding and the sender desires to send metadata in the form of trailer fields at the end of the message, the sender SHOULD send a Trailer header field before the message body to indicate which fields will be present in the trailers. This allows the recipient to prepare for receipt of that metadata before it starts processing the body, which is useful if the message is being streamed and the recipient wishes to confirm an integrity check on the fly.
A server MUST send an empty trailer with the chunked transfer coding unless at least one of the following is true:
All recipients MUST be able to receive and decode the chunked transfer coding and MUST ignore chunk-ext extensions they do not understand.
The TE field-value consists of a comma-separated list of transfer coding names, each allowing for optional parameters (as described in Section 4), and/or the keyword "trailers". Clients MUST NOT send the chunked transfer coding name in TE; chunked is always acceptable for HTTP/1.1 recipients.
The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer coding, as defined in Section 4.1, on behalf of itself and any downstream clients. For chained requests, this implies that either: (a) all downstream clients are willing to accept trailer fields in the forwarded response; or, (b) the client will attempt to buffer the response on behalf of downstream recipients. Note that HTTP/1.1 does not define any means to limit the size of a chunked response such that a client can be assured of buffering the entire response.
The authority-form of request-target is only used for CONNECT requests (Section 4.3.6 of [Part2] ). When making a CONNECT request to establish a tunnel through one or more proxies, a client MUST send only the target URI's authority component (excluding any userinfo) as the request-target. For example,
Senders SHOULD NOT combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced by pseudonyms. Senders MUST NOT combine entries that have different received-protocol values.
A proxy MUST NOT modify the "path-absolute" and "query" parts of the received request-target when forwarding it to the next inbound server, except as noted above to replace an empty path with "/" or "*".
A non-transforming proxy MUST preserve the message payload (Section 3.3 of [Part2] ). A transforming proxy MUST preserve the payload of a message that contains the no-transform cache-control directive.
A transforming proxy MAY transform the payload of a message that does not contain the no-transform cache-control directive; if the payload is transformed, the transforming proxy MUST add a Warning 214 (Transformation applied) header field if one does not already appear in the message (see Section 7.5 of [Part6] ).
A sender MUST NOT send a connection option corresponding to a header field that is intended for all recipients of the payload. For example, Cache-Control is never appropriate as a connection option (Section 7.2 of [Part6] ).
in either the request or the response header fields indicates that the connection MUST be closed after the current request/response is complete (Section 6.6).
In order to remain persistent, all messages on a connection MUST have a self-defined message length (i.e., one not defined by closure of the connection), as described in Section 3.3. A server MUST read the entire request message body or close the connection after sending its response, since otherwise the remaining data on a persistent connection would be misinterpreted as the next request. Likewise, a client MUST read the entire response message body if it intends to reuse the same connection for a subsequent request.
Clients that assume persistent connections and pipeline immediately after connection establishment SHOULD be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it MUST NOT pipeline before it knows the connection is persistent. Clients MUST also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.
Clients SHOULD NOT pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see Section 4.2.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.
Connections can be closed at any time, with or without intention. Implementations ought to anticipate the need to recover from asynchronous close events. A client MAY open a new connection and retransmit an aborted sequence of requests without user interaction so long as the request sequence is idempotent (see Section 4.2.2 of [Part2] ). A client MUST NOT automatically retry non-idempotent request sequences, 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. An automatic retry SHOULD NOT be repeated if a second sequence of requests fails.
A server that receives a close connection option MUST initiate a lingering close (see below) of the connection after it sends the final response to the request that contained close. The server SHOULD send a close connection option in its final response on that connection. The server MUST NOT process any further requests received on that connection.
The Upgrade header field only applies to switching application-level protocols on the existing connection; it cannot be used to switch to a protocol on a different connection. For that purpose, it is more appropriate to use a 3xx (Redirection) response (Section 6.4 of [Part2] ).
This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined by the HTTP version rules of Section 2.6 and future updates to this specification. Additional tokens ought to be registered with IANA using the registration procedure defined in Section 7.6.
HTTP header fields are registered within the Message Header Field Registry [BCP90] maintained by IANA at <http://www.iana.org/assignments/message-headers/message-header-index.html>.
This specification also provides a way for servers to reject messages that have request-targets that are too long (Section 6.5.12 of [Part2] ) or request entities that are too large (Section 6.5 of [Part2] ).
Adam Barth, Adam Roach, Addison Phillips, Adrian Chadd, Adrien W. de Croy, Alan Ford, Alan Ruttenberg, Albert Lunde, Alek Storm, Alex Rousskov, Alexandre Morgaut, Alexey Melnikov, Alisha Smith, Amichai Rothman, Amit Klein, Amos Jeffries, Andreas Maier, Andreas Petersson, Anil Sharma, Anne van Kesteren, Anthony Bryan, Asbjorn Ulsberg, Ashok Kumar, Balachander Krishnamurthy, Barry Leiba, Ben Laurie, Benjamin Niven-Jenkins, Bil Corry, Bill Burke, Bjoern Hoehrmann, Bob Scheifler, Boris Zbarsky, Brett Slatkin, Brian Kell, Brian McBarron, Brian Pane, Brian Smith, Bryce Nesbitt, Cameron Heavon-Jones, Carl Kugler, Carsten Bormann, Charles Fry, Chris Newman, Chris Weber, Cyrus Daboo, Dale Robert Anderson, Dan Wing, Dan Winship, Daniel Stenberg, Darrel Miller, Dave Cridland, Dave Crocker, Dave Kristol, David Booth, David Singer, David W. Morris, Diwakar Shetty, Dmitry Kurochkin, Drummond Reed, Duane Wessels, Duncan Cragg, Edward Lee, Eliot Lear, Eran Hammer-Lahav, Eric D. Williams, Eric J. Bowman, Eric Lawrence, Eric Rescorla, Erik Aronesty, Evan Prodromou, Florian Weimer, Frank Ellermann, Fred Bohle, Gabriel Montenegro, Geoffrey Sneddon, Gervase Markham, Grahame Grieve, Greg Wilkins, Harald Tveit Alvestrand, Harry Halpin, Helge Hess, Henrik Nordstrom, Henry S. Thompson, Henry Story, Herbert van de Sompel, Howard Melman, Hugo Haas, Ian Fette, Ian Hickson, Ido Safruti, Ilya Grigorik, Ingo Struck, J. Ross Nicoll, James H. Manger, James Lacey, James M. Snell, Jamie Lokier, Jan Algermissen, Jeff Hodges (who came up with the term 'effective Request-URI'), Jeff Walden, Jeroen de Borst, Jim Luther, Joe D. Williams, Joe Gregorio, Joe Orton, John C. Klensin, John C. Mallery, John Cowan, John Kemp, John Panzer, John Schneider, John Stracke, John Sullivan, Jonas Sicking, Jonathan A. Rees, Jonathan Billington, Jonathan Moore, Jonathan Rees, Jonathan Silvera, Jordi Ros, Joris Dobbelsteen, Josh Cohen, Julien Pierre, Jungshik Shin, Justin Chapweske, Justin Erenkrantz, Justin James, Kalvinder Singh, Karl Dubost, Keith Hoffman, Keith Moore, Ken Murchison, Koen Holtman, Konstantin Voronkov, Kris Zyp, Lisa Dusseault, Maciej Stachowiak, Marc Schneider, Marc Slemko, Mark Baker, Mark Pauley, Mark Watson, Markus Isomaki, Markus Lanthaler, Martin J. Duerst, Martin Musatov, Martin Nilsson, Martin Thomson, Matt Lynch, Matthew Cox, Max Clark, Michael Burrows, Michael Hausenblas, Mike Amundsen, Mike Belshe, Mike Kelly, Mike Schinkel, Miles Sabin, Murray S. Kucherawy, Mykyta Yevstifeyev, Nathan Rixham, Nicholas Shanks, Nico Williams, Nicolas Alvarez, Nicolas Mailhot, Noah Slater, Pablo Castro, Pat Hayes, Patrick R. McManus, Patrik Faltstrom, Paul E. Jones, Paul Hoffman, Paul Marquess, Peter Lepeska, Peter Saint-Andre, Peter Watkins, Phil Archer, Philippe Mougin, Phillip Hallam-Baker, Poul-Henning Kamp, Preethi Natarajan, Rajeev Bector, Ray Polk, Reto Bachmann-Gmuer, Richard Cyganiak, Robert Brewer, Robert Collins, Robert O'Callahan, Robert Olofsson, Robert Sayre, Robert Siemer, Robert de Wilde, Roberto Javier Godoy, Roberto Peon, Roland Zink, Ronny Widjaja, S. Mike Dierken, Salvatore Loreto, Sam Johnston, Sam Ruby, Scott Lawrence (who maintained the original issues list), Sean B. Palmer, Shane McCarron, Stefan Eissing, Stefan Tilkov, Stefanos Harhalakis, Stephane Bortzmeyer, Stephen Farrell, Stephen Ludin, Stuart Williams, Subbu Allamaraju, Subramanian Moonesamy, Sylvain Hellegouarch, Tapan Divekar, Tatsuya Hayashi, Ted Hardie, Thomas Broyer, Thomas Fossati, Thomas Nordin, Thomas Roessler, Tim Bray, Tim Morgan, Tim Olsen, Tobias Oberstein, Tom Zhou, Travis Snoozy, Tyler Close, Vincent Murphy, Wenbo Zhu, Werner Baumann, Wilbur Streett, Wilfredo Sanchez Vega, William A. Rowe Jr., William Chan, Willy Tarreau, Xiaoshu Wang, Yaron Goland, Yngve Nysaeter Pettersen, Yoav Nir, Yogesh Bang, Yutaka Oiwa, Yves Lafon (long-time member of the editor team), Zed A. Shaw, and Zhong Yu.
[Part2] Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content”, Internet-Draft draft-ietf-httpbis-p2-semantics-latest (work in progress), January 2013.
[Part4] Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests”, Internet-Draft draft-ietf-httpbis-p4-conditional-latest (work in progress), January 2013.
[Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Range Requests”, Internet-Draft draft-ietf-httpbis-p5-range-latest (work in progress), January 2013.
[Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Caching”, Internet-Draft draft-ietf-httpbis-p6-cache-latest (work in progress), January 2013.
[Part7] Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Authentication”, Internet-Draft draft-ietf-httpbis-p7-auth-latest (work in progress), January 2013.
[BCP13] Freed, N. and J. Klensin, “Media Type Specifications and Registration Procedures”, BCP 13, RFC 4288, December 2005.
The NUL octet is no longer allowed in comment and quoted-string text, and handling of backslash-escaping in them has been clarified. (Section 3.2.6)
The quoted-pair rule no longer allows escaping control characters other than HTAB. (Section 3.2.6)
Non-ASCII content in header fields and the reason phrase has been obsoleted and made opaque (the TEXT rule was removed). (Section 3.2.6)
The limit of two connections per server has been removed. (Section 6.3)
An idempotent sequence of requests is no longer required to be retried. (Section 6.3)
The requirement to retry requests under certain circumstances when the server prematurely closes the connection has been removed. (Section 6.3)
Some extraneous requirements about when servers are allowed to close connections prematurely have been removed. (Section 6.3)
The semantics of the Upgrade header field is now defined in responses other than 101 (this was incorporated from [RFC2817] ). (Section 6.7)
BCP115 7.2, 10.2
BCP13 7.3, 10.2
BCP90 7.1, 10.2
close 2.3, 2.6, 3.2.1, 4.3, 5.7, 6.1, 6.1, 6.6, 6.6, 6.7, 7.1, 7.1, A.2, A.2
Connection header field 2.3, 2.6, 3.2.1, 4.3, 5.7, 6.1, 6.1, 6.6, 6.6, 6.7, 7.1, 7.1, A.2, A.2
ISO-8859-1 3.2.4, 10.2
Kri2001 3.2.2, 10.2
Part2 1, 2.1, 2.3, 2.7, 2.7.1, 3.1.1, 3.1.1, 3.1.2, 3.2, 3.2.1, 3.3, 3.3, 3.3.1, 3.3.2, 3.3.2, 3.3.2, 4.3, 5.1, 5.3, 5.3, 5.6, 5.7.2, 6.3.1, 6.3.2, 6.7, 7.4, 8.3, 8.3, 10.1
Section 4.3.6 3.3, 3.3.2, 5.3
Section 6.3.4 2.3
Section 6.5 8.3
Section 6.5.12 3.1.1, 8.3
Section 7.2 3.3.2
Part4 1, 3.3.1, 3.3.2, 10.1
Part5 1, 10.1
Part6 1, 2.3, 2.4, 3.4, 5.2, 5.7.2, 6.1, 10.1
Section 7.2 6.1
Section 7.5 2.3, 5.7.2
RFC2047 3.2.4, 10.2
RFC2068 1, 2.6, 6.3, 9, 10.2, A.1.2
RFC2616 1, 2.6, 9, 9, 10.2
RFC4033 8.1, 10.2
RFC5322 2.1, 3, 5.7.1, 10.2
RFC6265 2.7.2, 3.2.2, 10.2
Upgrade header field 5.7.1, 6.7, 7.1, A.2
USASCII 1.2, 3, 3.2.4, 10.1
Via header field 2.3, 5.7.1, 7.1