Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7230

Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing

Pages: 89
Obsoletes:  21452616
Obsoleted by:  91109112
Updates:  28172818
Updated by:  8615
Part 3 of 4 – Pages 40 to 67
First   Prev   Next

Top   ToC   RFC7230 - Page 40   prevText

5. Message Routing

HTTP request message routing is determined by each client based on the target resource, the client's proxy configuration, and establishment or reuse of an inbound connection. The corresponding response routing follows the same connection chain back to the client.

5.1. Identifying a Target Resource

HTTP is used in a wide variety of applications, ranging from general-purpose computers to home appliances. In some cases, communication options are hard-coded in a client's configuration. However, most HTTP clients rely on the same resource identification mechanism and configuration techniques as general-purpose Web browsers. HTTP communication is initiated by a user agent for some purpose. The purpose is a combination of request semantics, which are defined in [RFC7231], and a target resource upon which to apply those semantics. A URI reference (Section 2.7) is typically used as an
Top   ToC   RFC7230 - Page 41
   identifier for the "target resource", which a user agent would
   resolve to its absolute form in order to obtain the "target URI".
   The target URI excludes the reference's fragment component, if any,
   since fragment identifiers are reserved for client-side processing
   ([RFC3986], Section 3.5).

5.2. Connecting Inbound

Once the target URI is determined, a client needs to decide whether a network request is necessary to accomplish the desired semantics and, if so, where that request is to be directed. If the client has a cache [RFC7234] and the request can be satisfied by it, then the request is usually directed there first. If the request is not satisfied by a cache, then a typical client will check its configuration to determine whether a proxy is to be used to satisfy the request. Proxy configuration is implementation- dependent, but is often based on URI prefix matching, selective authority matching, or both, and the proxy itself is usually identified by an "http" or "https" URI. If a proxy is applicable, the client connects inbound by establishing (or reusing) a connection to that proxy. If no proxy is applicable, a typical client will invoke a handler routine, usually specific to the target URI's scheme, to connect directly to an authority for the target resource. How that is accomplished is dependent on the target URI scheme and defined by its associated specification, similar to how this specification defines origin server access for resolution of the "http" (Section 2.7.1) and "https" (Section 2.7.2) schemes. HTTP requirements regarding connection management are defined in Section 6.

5.3. Request Target

Once an inbound connection is obtained, the client sends an HTTP request message (Section 3) with a request-target derived from the target URI. There are four distinct formats for the request-target, depending on both the method being requested and whether the request is to a proxy. request-target = origin-form / absolute-form / authority-form / asterisk-form
Top   ToC   RFC7230 - Page 42

5.3.1. origin-form

The most common form of request-target is the origin-form. origin-form = absolute-path [ "?" query ] When making a request directly to an origin server, other than a CONNECT or server-wide OPTIONS request (as detailed below), a client MUST send only the absolute path and query components of the target URI as the request-target. If the target URI's path component is empty, the client MUST send "/" as the path within the origin-form of request-target. A Host header field is also sent, as defined in Section 5.4. For example, a client wishing to retrieve a representation of the resource identified as http://www.example.org/where?q=now directly from the origin server would open (or reuse) a TCP connection to port 80 of the host "www.example.org" and send the lines: GET /where?q=now HTTP/1.1 Host: www.example.org followed by the remainder of the request message.

5.3.2. absolute-form

When making a request to a proxy, other than a CONNECT or server-wide OPTIONS request (as detailed below), a client MUST send the target URI in absolute-form as the request-target. absolute-form = absolute-URI The proxy is requested to either service that request from a valid cache, if possible, or make the same request on the client's behalf to either the next inbound proxy server or directly to the origin server indicated by the request-target. Requirements on such "forwarding" of messages are defined in Section 5.7. An example absolute-form of request-line would be: GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
Top   ToC   RFC7230 - Page 43
   To allow for transition to the absolute-form for all requests in some
   future version of HTTP, a server MUST accept the absolute-form in
   requests, even though HTTP/1.1 clients will only send them in
   requests to proxies.

5.3.3. authority-form

The authority-form of request-target is only used for CONNECT requests (Section 4.3.6 of [RFC7231]). authority-form = authority 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 and its "@" delimiter) as the request-target. For example, CONNECT www.example.com:80 HTTP/1.1

5.3.4. asterisk-form

The asterisk-form of request-target is only used for a server-wide OPTIONS request (Section 4.3.7 of [RFC7231]). asterisk-form = "*" When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server, the client MUST send only "*" (%x2A) as the request-target. For example, OPTIONS * HTTP/1.1 If a proxy receives an OPTIONS request with an absolute-form of request-target in which the URI has an empty path and no query component, then the last proxy on the request chain MUST send a request-target of "*" when it forwards the request to the indicated origin server. For example, the request OPTIONS http://www.example.org:8001 HTTP/1.1 would be forwarded by the final proxy as OPTIONS * HTTP/1.1 Host: www.example.org:8001 after connecting to port 8001 of host "www.example.org".
Top   ToC   RFC7230 - Page 44

5.4. Host

The "Host" header field in a request provides the host and port information from the target URI, enabling the origin server to distinguish among resources while servicing requests for multiple host names on a single IP address. Host = uri-host [ ":" port ] ; Section 2.7.1 A client MUST send a Host header field in all HTTP/1.1 request messages. If the target URI includes an authority component, then a client MUST send a field-value for Host that is identical to that authority component, excluding any userinfo subcomponent and its "@" delimiter (Section 2.7.1). If the authority component is missing or undefined for the target URI, then a client MUST send a Host header field with an empty field-value. Since the Host field-value is critical information for handling a request, a user agent SHOULD generate Host as the first header field following the request-line. For example, a GET request to the origin server for <http://www.example.org/pub/WWW/> would begin with: GET /pub/WWW/ HTTP/1.1 Host: www.example.org A client MUST send a Host header field in an HTTP/1.1 request even if the request-target is in the absolute-form, since this allows the Host information to be forwarded through ancient HTTP/1.0 proxies that might not have implemented Host. When a proxy receives a request with an absolute-form of request-target, the proxy MUST ignore the received Host header field (if any) and instead replace it with the host information of the request-target. A proxy that forwards such a request MUST generate a new Host field-value based on the received request-target rather than forward the received Host field-value. Since the Host header field acts as an application-level routing mechanism, it is a frequent target for malware seeking to poison a shared cache or redirect a request to an unintended server. An interception proxy is particularly vulnerable if it relies on the Host field-value for redirecting requests to internal servers, or for use as a cache key in a shared cache, without first verifying that the intercepted connection is targeting a valid IP address for that host.
Top   ToC   RFC7230 - Page 45
   A server MUST respond with a 400 (Bad Request) status code to any
   HTTP/1.1 request message that lacks a Host header field and to any
   request message that contains more than one Host header field or a
   Host header field with an invalid field-value.

5.5. Effective Request URI

Since the request-target often contains only part of the user agent's target URI, a server reconstructs the intended target as an "effective request URI" to properly service the request. This reconstruction involves both the server's local configuration and information communicated in the request-target, Host header field, and connection context. For a user agent, the effective request URI is the target URI. If the request-target is in absolute-form, the effective request URI is the same as the request-target. Otherwise, the effective request URI is constructed as follows: If the server's configuration (or outbound gateway) provides a fixed URI scheme, that scheme is used for the effective request URI. Otherwise, if the request is received over a TLS-secured TCP connection, the effective request URI's scheme is "https"; if not, the scheme is "http". If the server's configuration (or outbound gateway) provides a fixed URI authority component, that authority is used for the effective request URI. If not, then if the request-target is in authority-form, the effective request URI's authority component is the same as the request-target. If not, then if a Host header field is supplied with a non-empty field-value, the authority component is the same as the Host field-value. Otherwise, the authority component is assigned the default name configured for the server and, if the connection's incoming TCP port number differs from the default port for the effective request URI's scheme, then a colon (":") and the incoming port number (in decimal form) are appended to the authority component. If the request-target is in authority-form or asterisk-form, the effective request URI's combined path and query component is empty. Otherwise, the combined path and query component is the same as the request-target. The components of the effective request URI, once determined as above, can be combined into absolute-URI form by concatenating the scheme, "://", authority, and combined path and query component.
Top   ToC   RFC7230 - Page 46
   Example 1: the following message received over an insecure TCP
   connection

     GET /pub/WWW/TheProject.html HTTP/1.1
     Host: www.example.org:8080

   has an effective request URI of

     http://www.example.org:8080/pub/WWW/TheProject.html

   Example 2: the following message received over a TLS-secured TCP
   connection

     OPTIONS * HTTP/1.1
     Host: www.example.org

   has an effective request URI of

     https://www.example.org

   Recipients of an HTTP/1.0 request that lacks a Host header field
   might need to use heuristics (e.g., examination of the URI path for
   something unique to a particular host) in order to guess the
   effective request URI's authority component.

   Once the effective request URI has been constructed, an origin server
   needs to decide whether or not to provide service for that URI via
   the connection in which the request was received.  For example, the
   request might have been misdirected, deliberately or accidentally,
   such that the information within a received request-target or Host
   header field differs from the host or port upon which the connection
   has been made.  If the connection is from a trusted gateway, that
   inconsistency might be expected; otherwise, it might indicate an
   attempt to bypass security filters, trick the server into delivering
   non-public content, or poison a cache.  See Section 9 for security
   considerations regarding message routing.

5.6. Associating a Response to a Request

HTTP does not include a request identifier for associating a given request message with its corresponding one or more response messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made on the same connection. More than one response message per request only occurs when one or more informational responses (1xx, see Section 6.2 of [RFC7231]) precede a final response to the same request.
Top   ToC   RFC7230 - Page 47
   A client that has more than one outstanding request on a connection
   MUST maintain a list of outstanding requests in the order sent and
   MUST associate each received response message on that connection to
   the highest ordered request that has not yet received a final
   (non-1xx) response.

5.7. Message Forwarding

As described in Section 2.3, intermediaries can serve a variety of roles in the processing of HTTP requests and responses. Some intermediaries are used to improve performance or availability. Others are used for access control or to filter content. Since an HTTP stream has characteristics similar to a pipe-and-filter architecture, there are no inherent limits to the extent an intermediary can enhance (or interfere) with either direction of the stream. An intermediary not acting as a tunnel MUST implement the Connection header field, as specified in Section 6.1, and exclude fields from being forwarded that are only intended for the incoming connection. An intermediary MUST NOT forward a message to itself unless it is protected from an infinite request loop. In general, an intermediary ought to recognize its own server names, including any aliases, local variations, or literal IP addresses, and respond to such requests directly.

5.7.1. Via

The "Via" header field indicates the presence of intermediate protocols and recipients between the user agent and the server (on requests) or between the origin server and the client (on responses), similar to the "Received" header field in email (Section 3.6.7 of [RFC5322]). Via can be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities of senders along the request/response chain. Via = 1#( received-protocol RWS received-by [ RWS comment ] ) received-protocol = [ protocol-name "/" ] protocol-version ; see Section 6.7 received-by = ( uri-host [ ":" port ] ) / pseudonym pseudonym = token Multiple Via field values represent each proxy or gateway that has forwarded the message. Each intermediary appends its own information about how the message was received, such that the end result is ordered according to the sequence of forwarding recipients.
Top   ToC   RFC7230 - Page 48
   A proxy MUST send an appropriate Via header field, as described
   below, in each message that it forwards.  An HTTP-to-HTTP gateway
   MUST send an appropriate Via header field in each inbound request
   message and MAY send a Via header field in forwarded response
   messages.

   For each intermediary, the received-protocol indicates the protocol
   and protocol version used by the upstream sender of the message.
   Hence, the Via field value records the advertised protocol
   capabilities of the request/response chain such that they remain
   visible to downstream recipients; this can be useful for determining
   what backwards-incompatible features might be safe to use in
   response, or within a later request, as described in Section 2.6.
   For brevity, the protocol-name is omitted when the received protocol
   is HTTP.

   The received-by portion of the field value is normally the host and
   optional port number of a recipient server or client that
   subsequently forwarded the message.  However, if the real host is
   considered to be sensitive information, a sender MAY replace it with
   a pseudonym.  If a port is not provided, a recipient MAY interpret
   that as meaning it was received on the default TCP port, if any, for
   the received-protocol.

   A sender MAY generate comments in the Via header field to identify
   the software of each recipient, analogous to the User-Agent and
   Server header fields.  However, all comments in the Via field are
   optional, and a recipient MAY remove them prior to forwarding the
   message.

   For example, a request message could be sent from an HTTP/1.0 user
   agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
   forward the request to a public proxy at p.example.net, which
   completes the request by forwarding it to the origin server at
   www.example.com.  The request received by www.example.com would then
   have the following Via header field:

     Via: 1.0 fred, 1.1 p.example.net

   An intermediary used as a portal through a network firewall SHOULD
   NOT forward the names and ports of hosts within the firewall region
   unless it is explicitly enabled to do so.  If not enabled, such an
   intermediary SHOULD replace each received-by host of any host behind
   the firewall by an appropriate pseudonym for that host.
Top   ToC   RFC7230 - Page 49
   An intermediary MAY combine an ordered subsequence of Via header
   field entries into a single such entry if the entries have identical
   received-protocol values.  For example,

     Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy

   could be collapsed to

     Via: 1.0 ricky, 1.1 mertz, 1.0 lucy

   A sender SHOULD NOT combine multiple entries unless they are all
   under the same organizational control and the hosts have already been
   replaced by pseudonyms.  A sender MUST NOT combine entries that have
   different received-protocol values.

5.7.2. Transformations

Some intermediaries include features for transforming messages and their payloads. A proxy might, for example, convert between image formats in order to save cache space or to reduce the amount of traffic on a slow link. However, operational problems might occur when these transformations are applied to payloads intended for critical applications, such as medical imaging or scientific data analysis, particularly when integrity checks or digital signatures are used to ensure that the payload received is identical to the original. An HTTP-to-HTTP proxy is called a "transforming proxy" if it is designed or configured to modify 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 a privacy filter. Such transformations are presumed to be desired by whichever client (or client organization) selected the proxy. If a proxy receives a request-target with a host name that is not a fully qualified domain name, it MAY add its own domain to the host name it received when forwarding the request. A proxy MUST NOT change the host name if the request-target contains a fully qualified domain name.
Top   ToC   RFC7230 - Page 50
   A proxy MUST NOT modify the "absolute-path" 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 proxy MAY modify the message body through application or removal of
   a transfer coding (Section 4).

   A proxy MUST NOT transform the payload (Section 3.3 of [RFC7231]) of
   a message that contains a no-transform cache-control directive
   (Section 5.2 of [RFC7234]).

   A proxy MAY transform the payload of a message that does not contain
   a no-transform cache-control directive.  A proxy that transforms a
   payload MUST add a Warning header field with the warn-code of 214
   ("Transformation Applied") if one is not already in the message (see
   Section 5.5 of [RFC7234]).  A proxy that transforms the payload of a
   200 (OK) response can further inform downstream recipients that a
   transformation has been applied by changing the response status code
   to 203 (Non-Authoritative Information) (Section 6.3.4 of [RFC7231]).

   A proxy SHOULD NOT modify header fields that provide information
   about the endpoints of the communication chain, the resource state,
   or the selected representation (other than the payload) unless the
   field's definition specifically allows such modification or the
   modification is deemed necessary for privacy or security.

6. Connection Management

HTTP messaging is independent of the underlying transport- or session-layer connection protocol(s). HTTP only presumes a reliable transport with in-order delivery of requests and the corresponding in-order delivery of responses. The mapping of HTTP request and response structures onto the data units of an underlying transport protocol is outside the scope of this specification. As described in Section 5.2, the specific connection protocols to be used for an HTTP interaction are determined by client configuration and the target URI. For example, the "http" URI scheme (Section 2.7.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.
Top   ToC   RFC7230 - Page 51
   HTTP implementations are expected to engage in connection management,
   which includes maintaining the state of current connections,
   establishing a new connection or reusing an existing connection,
   processing messages received on a connection, detecting connection
   failures, and closing each connection.  Most clients maintain
   multiple connections in parallel, including more than one connection
   per server endpoint.  Most servers are designed to maintain thousands
   of concurrent connections, while controlling request queues to enable
   fair use and detect denial-of-service attacks.

6.1. Connection

The "Connection" header field allows the sender to indicate desired control options for the current connection. In order to avoid confusing downstream recipients, a proxy or gateway MUST remove or replace any received connection options before forwarding the message. When a header field aside from Connection is used to supply control information for or about the current connection, the sender MUST list the corresponding field-name within the Connection header field. A proxy or gateway MUST parse a received Connection header field before a message is forwarded and, for each connection-option in this field, remove any header field(s) from the message with the same name as the connection-option, and then remove the Connection header field itself (or replace it with the intermediary's own connection options for the forwarded message). Hence, the Connection header field provides a declarative way of distinguishing header fields that are only intended for the immediate recipient ("hop-by-hop") from those fields that are intended for all recipients on the chain ("end-to-end"), enabling the message to be self-descriptive and allowing future connection-specific extensions to be deployed without fear that they will be blindly forwarded by older intermediaries. The Connection header field's value has the following grammar: Connection = 1#connection-option connection-option = token Connection options are case-insensitive. 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 5.2 of [RFC7234]).
Top   ToC   RFC7230 - Page 52
   The connection options do not always correspond to a header field
   present in the message, since a connection-specific header field
   might not be needed if there are no parameters associated with a
   connection option.  In contrast, a connection-specific header field
   that is received without a corresponding connection option usually
   indicates that the field has been improperly forwarded by an
   intermediary and ought to be ignored by the recipient.

   When defining new connection options, specification authors ought to
   survey existing header field names and ensure that the new connection
   option does not share the same name as an already deployed header
   field.  Defining a new connection option essentially reserves that
   potential field-name for carrying additional information related to
   the connection option, since it would be unwise for senders to use
   that field-name for anything else.

   The "close" connection option is defined for a sender to signal that
   this connection will be closed after completion of the response.  For
   example,

     Connection: close

   in either the request or the response header fields indicates that
   the sender is going to close the connection after the current
   request/response is complete (Section 6.6).

   A client that does not support persistent connections MUST send the
   "close" connection option in every request message.

   A server that does not support persistent connections MUST send the
   "close" connection option in every response message that does not
   have a 1xx (Informational) status code.

6.2. Establishment

It is beyond the scope of this specification to describe how connections are established via various transport- or session-layer protocols. Each connection applies to only one transport link.

6.3. Persistence

HTTP/1.1 defaults to the use of "persistent connections", allowing multiple requests and responses to be carried over a single connection. The "close" connection option is used to signal that a connection will not persist after the current request/response. HTTP implementations SHOULD support persistent connections.
Top   ToC   RFC7230 - Page 53
   A recipient determines whether a connection is persistent or not
   based on the most recently received message's protocol version and
   Connection header field (if any):

   o  If the "close" connection option is present, the connection will
      not persist after the current response; else,

   o  If the received protocol is HTTP/1.1 (or later), the connection
      will persist after the current response; else,

   o  If the received protocol is HTTP/1.0, the "keep-alive" connection
      option is present, the recipient is not a proxy, and the recipient
      wishes to honor the HTTP/1.0 "keep-alive" mechanism, the
      connection will persist after the current response; otherwise,

   o  The connection will close after the current response.

   A client MAY send additional requests on a persistent connection
   until it sends or receives a "close" connection option or receives an
   HTTP/1.0 response without a "keep-alive" connection option.

   In order to remain persistent, all messages on a connection need to
   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.

   A proxy server MUST NOT maintain a persistent connection with an
   HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and
   discussion of the problems with the Keep-Alive header field
   implemented by many HTTP/1.0 clients).

   See Appendix A.1.2 for more information on backwards compatibility
   with HTTP/1.0 clients.

6.3.1. Retrying Requests

Connections can be closed at any time, with or without intention. Implementations ought to anticipate the need to recover from asynchronous close events.
Top   ToC   RFC7230 - Page 54
   When an inbound connection is closed prematurely, a client MAY open a
   new connection and automatically retransmit an aborted sequence of
   requests if all of those requests have idempotent methods (Section
   4.2.2 of [RFC7231]).  A proxy MUST NOT automatically retry
   non-idempotent requests.

   A user agent MUST NOT automatically retry a request with a non-
   idempotent method unless it has some means to know that the request
   semantics are actually idempotent, regardless of the method, or some
   means to detect that the original request was never applied.  For
   example, a user agent that knows (through design or configuration)
   that a POST request to a given resource is safe can repeat that
   request automatically.  Likewise, a user agent designed specifically
   to operate on a version control repository might be able to recover
   from partial failure conditions by checking the target resource
   revision(s) after a failed connection, reverting or fixing any
   changes that were partially applied, and then automatically retrying
   the requests that failed.

   A client SHOULD NOT automatically retry a failed automatic retry.

6.3.2. Pipelining

A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server MAY process a sequence of pipelined requests in parallel if they all have safe methods (Section 4.2.1 of [RFC7231]), but it MUST send the corresponding responses in the same order that the requests were received. A client that pipelines requests SHOULD retry unanswered requests if the connection closes before it receives all of the corresponding responses. When retrying pipelined requests after a failed connection (a connection not explicitly closed by the server in its last complete response), a client MUST NOT pipeline immediately after connection establishment, since the first remaining request in the prior pipeline might have caused an error response that can be lost again if multiple requests are sent on a prematurely closed connection (see the TCP reset problem described in Section 6.6). Idempotent methods (Section 4.2.2 of [RFC7231]) are significant to pipelining because they can be automatically retried after a connection failure. A user agent SHOULD NOT pipeline requests after a non-idempotent method, until the final response status code for that method has been received, unless the user agent has a means to detect and recover from partial failure conditions involving the pipelined sequence.
Top   ToC   RFC7230 - Page 55
   An intermediary that receives pipelined requests MAY pipeline those
   requests when forwarding them inbound, since it can rely on the
   outbound user agent(s) to determine what requests can be safely
   pipelined.  If the inbound connection fails before receiving a
   response, the pipelining intermediary MAY attempt to retry a sequence
   of requests that have yet to receive a response if the requests all
   have idempotent methods; otherwise, the pipelining intermediary
   SHOULD forward any received responses and then close the
   corresponding outbound connection(s) so that the outbound user
   agent(s) can recover accordingly.

6.4. Concurrency

A client ought to limit the number of simultaneous open connections that it maintains to a given server. Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many applications. As a result, this specification does not mandate a particular maximum number of connections but, instead, encourages clients to be conservative when opening multiple connections. Multiple connections are typically used to avoid the "head-of-line blocking" problem, wherein a request that takes significant server-side processing and/or has a large payload blocks subsequent requests on the same connection. However, each connection consumes server resources. Furthermore, using multiple connections can cause undesirable side effects in congested networks. Note that a server might reject traffic that it deems abusive or characteristic of a denial-of-service attack, such as an excessive number of open connections from a single client.

6.5. Failures and Timeouts

Servers will usually have some timeout value beyond which they will no longer maintain an inactive connection. Proxy servers might make this a higher value since it is likely that the client will be making more connections through the same proxy server. The use of persistent connections places no requirements on the length (or existence) of this timeout for either the client or the server. A client or server that wishes to time out SHOULD issue a graceful close on the connection. Implementations SHOULD constantly monitor open connections for a received closure signal and respond to it as appropriate, since prompt closure of both sides of a connection enables allocated system resources to be reclaimed.
Top   ToC   RFC7230 - Page 56
   A client, server, or proxy MAY close the transport connection at any
   time.  For example, a client might have started to send a new request
   at the same time that the server has decided to close the "idle"
   connection.  From the server's point of view, the connection is being
   closed while it was idle, but from the client's point of view, a
   request is in progress.

   A server SHOULD sustain persistent connections, when possible, and
   allow the underlying transport's flow-control mechanisms to resolve
   temporary overloads, rather than terminate connections with the
   expectation that clients will retry.  The latter technique can
   exacerbate network congestion.

   A client sending a message body SHOULD monitor the network connection
   for an error response while it is transmitting the request.  If the
   client sees a response that indicates the server does not wish to
   receive the message body and is closing the connection, the client
   SHOULD immediately cease transmitting the body and close its side of
   the connection.

6.6. Tear-down

The Connection header field (Section 6.1) provides a "close" connection option that a sender SHOULD send when it wishes to close the connection after the current request/response pair. A client that sends a "close" connection option MUST NOT send further requests on that connection (after the one containing "close") and MUST close the connection after reading the final response message corresponding to this request. A server that receives a "close" connection option MUST initiate a close of the connection (see below) 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. A server that sends a "close" connection option MUST initiate a close of the connection (see below) after it sends the response containing "close". The server MUST NOT process any further requests received on that connection. A client that receives a "close" connection option MUST cease sending requests on that connection and close the connection after reading the response message containing the "close"; if additional pipelined requests had been sent on the connection, the client SHOULD NOT assume that they will be processed by the server.
Top   ToC   RFC7230 - Page 57
   If a server performs an immediate close of a TCP connection, there is
   a significant risk that the client will not be able to read the last
   HTTP response.  If the server receives additional data from the
   client on a fully closed connection, such as another request that was
   sent by the client before receiving the server's response, the
   server's TCP stack will send a reset packet to the client;
   unfortunately, the reset packet might erase the client's
   unacknowledged input buffers before they can be read and interpreted
   by the client's HTTP parser.

   To avoid the TCP reset problem, servers typically close a connection
   in stages.  First, the server performs a half-close by closing only
   the write side of the read/write connection.  The server then
   continues to read from the connection until it receives a
   corresponding close by the client, or until the server is reasonably
   certain that its own TCP stack has received the client's
   acknowledgement of the packet(s) containing the server's last
   response.  Finally, the server fully closes the connection.

   It is unknown whether the reset problem is exclusive to TCP or might
   also be found in other transport connection protocols.

6.7. Upgrade

The "Upgrade" header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other protocol on the same connection. A client MAY send a list of protocols in the Upgrade header field of a request to invite the server to switch to one or more of those protocols, in order of descending preference, before sending the final response. A server MAY ignore a received Upgrade header field if it wishes to continue using the current protocol on that connection. Upgrade cannot be used to insist on a protocol change. Upgrade = 1#protocol protocol = protocol-name ["/" protocol-version] protocol-name = token protocol-version = token A server that sends a 101 (Switching Protocols) response MUST send an Upgrade header field to indicate the new protocol(s) to which the connection is being switched; if multiple protocol layers are being switched, the sender MUST list the protocols in layer-ascending order. A server MUST NOT switch to a protocol that was not indicated by the client in the corresponding request's Upgrade header field. A
Top   ToC   RFC7230 - Page 58
   server MAY choose to ignore the order of preference indicated by the
   client and select the new protocol(s) based on other factors, such as
   the nature of the request or the current load on the server.

   A server that sends a 426 (Upgrade Required) response MUST send an
   Upgrade header field to indicate the acceptable protocols, in order
   of descending preference.

   A server MAY send an Upgrade header field in any other response to
   advertise that it implements support for upgrading to the listed
   protocols, in order of descending preference, when appropriate for a
   future request.

   The following is a hypothetical example sent by a client:

     GET /hello.txt HTTP/1.1
     Host: www.example.com
     Connection: upgrade
     Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11


   The capabilities and nature of the application-level communication
   after the protocol change is entirely dependent upon the new
   protocol(s) chosen.  However, immediately after sending the 101
   (Switching Protocols) response, the server is expected to continue
   responding to the original request as if it had received its
   equivalent within the new protocol (i.e., the server still has an
   outstanding request to satisfy after the protocol has been changed,
   and is expected to do so without requiring the request to be
   repeated).

   For example, if the Upgrade header field is received in a GET request
   and the server decides to switch protocols, it first responds with a
   101 (Switching Protocols) message in HTTP/1.1 and then immediately
   follows that with the new protocol's equivalent of a response to a
   GET on the target resource.  This allows a connection to be upgraded
   to protocols with the same semantics as HTTP without the latency cost
   of an additional round trip.  A server MUST NOT switch protocols
   unless the received message semantics can be honored by the new
   protocol; an OPTIONS request can be honored by any protocol.
Top   ToC   RFC7230 - Page 59
   The following is an example response to the above hypothetical
   request:

     HTTP/1.1 101 Switching Protocols
     Connection: upgrade
     Upgrade: HTTP/2.0

     [... data stream switches to HTTP/2.0 with an appropriate response
     (as defined by new protocol) to the "GET /hello.txt" request ...]

   When Upgrade is sent, the sender MUST also send a Connection header
   field (Section 6.1) that contains an "upgrade" connection option, in
   order to prevent Upgrade from being accidentally forwarded by
   intermediaries that might not implement the listed protocols.  A
   server MUST ignore an Upgrade header field that is received in an
   HTTP/1.0 request.

   A client cannot begin using an upgraded protocol on the connection
   until it has completely sent the request message (i.e., the client
   can't change the protocol it is sending in the middle of a message).
   If a server receives both an Upgrade and an Expect header field with
   the "100-continue" expectation (Section 5.1.1 of [RFC7231]), the
   server MUST send a 100 (Continue) response before sending a 101
   (Switching Protocols) response.

   The Upgrade header field only applies to switching protocols on top
   of the existing connection; it cannot be used to switch the
   underlying connection (transport) protocol, nor to switch the
   existing communication to a different connection.  For those
   purposes, it is more appropriate to use a 3xx (Redirection) response
   (Section 6.4 of [RFC7231]).

   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 8.6.

7. ABNF List Extension: #rule

A #rule extension to the ABNF rules of [RFC5234] is used to improve readability in the definitions of some header field values. A construct "#" is defined, similar to "*", for defining comma-delimited lists of elements. The full form is "<n>#<m>element" indicating at least <n> and at most <m> elements, each separated by a single comma (",") and optional whitespace (OWS).
Top   ToC   RFC7230 - Page 60
   In any production that uses the list construct, a sender MUST NOT
   generate empty list elements.  In other words, a sender MUST generate
   lists that satisfy the following syntax:

     1#element => element *( OWS "," OWS element )

   and:

     #element => [ 1#element ]

   and for n >= 1 and m > 1:

     <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element )

   For compatibility with legacy list rules, a recipient MUST parse and
   ignore a reasonable number of empty list elements: enough to handle
   common mistakes by senders that merge values, but not so much that
   they could be used as a denial-of-service mechanism.  In other words,
   a recipient MUST accept lists that satisfy the following syntax:

     #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]

     1#element => *( "," OWS ) element *( OWS "," [ OWS element ] )

   Empty elements do not contribute to the count of elements present.
   For example, given these ABNF productions:

     example-list      = 1#example-list-elmt
     example-list-elmt = token ; see Section 3.2.6

   Then the following are valid values for example-list (not including
   the double quotes, which are present for delimitation only):

     "foo,bar"
     "foo ,bar,"
     "foo , ,bar,charlie   "

   In contrast, the following values would be invalid, since at least
   one non-empty element is required by the example-list production:

     ""
     ","
     ",   ,"

   Appendix B shows the collected ABNF for recipients after the list
   constructs have been expanded.
Top   ToC   RFC7230 - Page 61

8. IANA Considerations

8.1. Header Field Registration

HTTP header fields are registered within the "Message Headers" registry maintained at <http://www.iana.org/assignments/message-headers/>. This document defines the following HTTP header fields, so the "Permanent Message Header Field Names" registry has been updated accordingly (see [BCP90]). +-------------------+----------+----------+---------------+ | Header Field Name | Protocol | Status | Reference | +-------------------+----------+----------+---------------+ | Connection | http | standard | Section 6.1 | | Content-Length | http | standard | Section 3.3.2 | | Host | http | standard | Section 5.4 | | TE | http | standard | Section 4.3 | | Trailer | http | standard | Section 4.4 | | Transfer-Encoding | http | standard | Section 3.3.1 | | Upgrade | http | standard | Section 6.7 | | Via | http | standard | Section 5.7.1 | +-------------------+----------+----------+---------------+ Furthermore, the header field-name "Close" has been registered as "reserved", since using that name as an HTTP header field might conflict with the "close" connection option of the Connection header field (Section 6.1). +-------------------+----------+----------+-------------+ | Header Field Name | Protocol | Status | Reference | +-------------------+----------+----------+-------------+ | Close | http | reserved | Section 8.1 | +-------------------+----------+----------+-------------+ The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
Top   ToC   RFC7230 - Page 62

8.2. URI Scheme Registration

IANA maintains the registry of URI Schemes [BCP115] at <http://www.iana.org/assignments/uri-schemes/>. This document defines the following URI schemes, so the "Permanent URI Schemes" registry has been updated accordingly. +------------+------------------------------------+---------------+ | URI Scheme | Description | Reference | +------------+------------------------------------+---------------+ | http | Hypertext Transfer Protocol | Section 2.7.1 | | https | Hypertext Transfer Protocol Secure | Section 2.7.2 | +------------+------------------------------------+---------------+

8.3. Internet Media Type Registration

IANA maintains the registry of Internet media types [BCP13] at <http://www.iana.org/assignments/media-types>. This document serves as the specification for the Internet media types "message/http" and "application/http". The following has been registered with IANA.

8.3.1. Internet Media Type message/http

The message/http type can be used to enclose a single HTTP request or response message, provided that it obeys the MIME restrictions for all "message" types regarding line length and encodings. Type name: message Subtype name: http Required parameters: N/A Optional parameters: version, msgtype version: The HTTP-version number of the enclosed message (e.g., "1.1"). If not present, the version can be determined from the first line of the body. msgtype: The message type -- "request" or "response". If not present, the type can be determined from the first line of the body. Encoding considerations: only "7bit", "8bit", or "binary" are permitted
Top   ToC   RFC7230 - Page 63
   Security considerations:  see Section 9

   Interoperability considerations:  N/A

   Published specification:  This specification (see Section 8.3.1).

   Applications that use this media type:  N/A

   Fragment identifier considerations:  N/A

   Additional information:

      Magic number(s):  N/A

      Deprecated alias names for this type:  N/A

      File extension(s):  N/A

      Macintosh file type code(s):  N/A

   Person and email address to contact for further information:
      See Authors' Addresses section.

   Intended usage:  COMMON

   Restrictions on usage:  N/A

   Author:  See Authors' Addresses section.

   Change controller:  IESG

8.3.2. Internet Media Type application/http

The application/http type can be used to enclose a pipeline of one or more HTTP request or response messages (not intermixed). Type name: application Subtype name: http Required parameters: N/A Optional parameters: version, msgtype version: The HTTP-version number of the enclosed messages (e.g., "1.1"). If not present, the version can be determined from the first line of the body.
Top   ToC   RFC7230 - Page 64
      msgtype:  The message type -- "request" or "response".  If not
         present, the type can be determined from the first line of the
         body.

   Encoding considerations:  HTTP messages enclosed by this type are in
      "binary" format; use of an appropriate Content-Transfer-Encoding
      is required when transmitted via email.

   Security considerations:  see Section 9

   Interoperability considerations:  N/A

   Published specification:  This specification (see Section 8.3.2).

   Applications that use this media type:  N/A

   Fragment identifier considerations:  N/A

   Additional information:

      Deprecated alias names for this type:  N/A

      Magic number(s):  N/A

      File extension(s):  N/A

      Macintosh file type code(s):  N/A

   Person and email address to contact for further information:
      See Authors' Addresses section.

   Intended usage:  COMMON

   Restrictions on usage:  N/A

   Author:  See Authors' Addresses section.

   Change controller:  IESG

8.4. Transfer Coding Registry

The "HTTP Transfer Coding Registry" defines the namespace for transfer coding names. It is maintained at <http://www.iana.org/assignments/http-parameters>.
Top   ToC   RFC7230 - Page 65

8.4.1. Procedure

Registrations MUST include the following fields: o Name o Description o Pointer to specification text Names of transfer codings MUST NOT overlap with names of content codings (Section 3.1.2.1 of [RFC7231]) unless the encoding transformation is identical, as is the case for the compression codings defined in Section 4.2. Values to be added to this namespace require IETF Review (see Section 4.1 of [RFC5226]), and MUST conform to the purpose of transfer coding defined in this specification. Use of program names for the identification of encoding formats is not desirable and is discouraged for future encodings.

8.4.2. Registration

The "HTTP Transfer Coding Registry" has been updated with the registrations below: +------------+--------------------------------------+---------------+ | Name | Description | Reference | +------------+--------------------------------------+---------------+ | chunked | Transfer in a series of chunks | Section 4.1 | | compress | UNIX "compress" data format [Welch] | Section 4.2.1 | | deflate | "deflate" compressed data | Section 4.2.2 | | | ([RFC1951]) inside the "zlib" data | | | | format ([RFC1950]) | | | gzip | GZIP file format [RFC1952] | Section 4.2.3 | | x-compress | Deprecated (alias for compress) | Section 4.2.1 | | x-gzip | Deprecated (alias for gzip) | Section 4.2.3 | +------------+--------------------------------------+---------------+
Top   ToC   RFC7230 - Page 66

8.5. Content Coding Registration

IANA maintains the "HTTP Content Coding Registry" at <http://www.iana.org/assignments/http-parameters>. The "HTTP Content Coding Registry" has been updated with the registrations below: +------------+--------------------------------------+---------------+ | Name | Description | Reference | +------------+--------------------------------------+---------------+ | compress | UNIX "compress" data format [Welch] | Section 4.2.1 | | deflate | "deflate" compressed data | Section 4.2.2 | | | ([RFC1951]) inside the "zlib" data | | | | format ([RFC1950]) | | | gzip | GZIP file format [RFC1952] | Section 4.2.3 | | x-compress | Deprecated (alias for compress) | Section 4.2.1 | | x-gzip | Deprecated (alias for gzip) | Section 4.2.3 | +------------+--------------------------------------+---------------+

8.6. Upgrade Token Registry

The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" defines the namespace for protocol-name tokens used to identify protocols in the Upgrade header field. The registry is maintained at <http://www.iana.org/assignments/http-upgrade-tokens>.

8.6.1. Procedure

Each registered protocol name is associated with contact information and an optional set of specifications that details how the connection will be processed after it has been upgraded. Registrations happen on a "First Come First Served" basis (see Section 4.1 of [RFC5226]) and are subject to the following rules: 1. A protocol-name token, once registered, stays registered forever. 2. The registration MUST name a responsible party for the registration. 3. The registration MUST name a point of contact. 4. The registration MAY name a set of specifications associated with that token. Such specifications need not be publicly available. 5. The registration SHOULD name a set of expected "protocol-version" tokens associated with that token at the time of registration.
Top   ToC   RFC7230 - Page 67
   6.  The responsible party MAY change the registration at any time.
       The IANA will keep a record of all such changes, and make them
       available upon request.

   7.  The IESG MAY reassign responsibility for a protocol token.  This
       will normally only be used in the case when a responsible party
       cannot be contacted.

   This registration procedure for HTTP Upgrade Tokens replaces that
   previously defined in Section 7.2 of [RFC2817].

8.6.2. Upgrade Token Registration

The "HTTP" entry in the upgrade token registry has been updated with the registration below: +-------+----------------------+----------------------+-------------+ | Value | Description | Expected Version | Reference | | | | Tokens | | +-------+----------------------+----------------------+-------------+ | HTTP | Hypertext Transfer | any DIGIT.DIGIT | Section 2.6 | | | Protocol | (e.g, "2.0") | | +-------+----------------------+----------------------+-------------+ The responsible party is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".


(page 67 continued on part 4)

Next Section