1.3 Overall Operation [page 5-6]

    The HTTP protocol is based on a request/response paradigm. A client
    establishes a connection with a server and sends a request to the
    server in the form of a request method, URI, and protocol version,
    followed by a MIME-like message containing request modifiers, client
    information, and possible body content. The server responds with a
    status line, including the message‘s protocol version and a success
    or error code, followed by a MIME-like message containing server
    information, entity metainformation, and possible body content.

[page 7]
    On the Internet, HTTP communication generally takes place over TCP/IP
    connections. The default port is TCP 80 [15], but other ports can be
    used. This does not preclude HTTP from being implemented on top of
    any other protocol on the Internet, or on other networks. HTTP only
    presumes a reliable transport; any protocol that provides such
    guarantees can be used, and the mapping of the HTTP/1.0 request and
    response structures onto the transport data units of the protocol in
    question is outside the scope of this specification.

[page 7]
    Except for experimental applications, current practice requires that
    the connection be established by the client prior to each request and
    closed by the server after sending the response. Both clients and
    servers should be aware that either party may close the connection
    prematurely, due to user action, automated time-out, or program
    failure, and should handle such closing in a predictable fashion. In
    any case, the closing of the connection by either or both parties
    always terminates the current request, regardless of its status.    

7.2.2 Length [Page 29]

    When an Entity-Body is included with a message, the length of that
    body may be determined in one of two ways. If a Content-Length header
    field is present, its value in bytes represents the length of the
    Entity-Body. Otherwise, the body length is determined by the closing
    of the connection by the server.

    Closing the connection cannot be used to indicate the end of a
    request body, since it leaves no possibility for the server to send
    back a response. Therefore, HTTP/1.0 requests containing an entity
    body must include a valid Content-Length header field. If a request
    contains an entity body and Content-Length is not specified, and the
    server does not recognize or cannot calculate the length from other
    fields, then the server should send a 400 (bad request) response.

8.1 GET [Page 30]

    The GET method means retrieve whatever information (in the form of an
    entity) is identified by the Request-URI. If the Request-URI refers
    to a data-producing process, it is the produced data which shall be
    returned as the entity in the response and not the source text of the
    process, unless that text happens to be the output of the process.

14.10 Connection

    The Connection general-header field allows the sender to specify
    options that are desired for that particular connection and MUST NOT
    be communicated by proxies over further connections.

    The Connection header has the following grammar:

    Connection = "Connection" ":" 1#(connection-token)
    connection-token = token

8.1 Persistent Connections

8.1.1 Purpose
　　Persistent HTTP connections have a number of advantages:

　　- HTTP requests and responses can be pipelined on a connection.
　　Pipelining allows a client to make multiple requests without
　　waiting for each response, allowing a single TCP connection to
　　be used much more efficiently, with much lower elapsed time.

8.1.2.1 Negotiation
　　An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
　　maintain a persistent connection unless a Connection header including
　　the connection-token "close" was sent in the request. If the server
　　chooses to close the connection immediately after sending the
　　response, it SHOULD send a Connection header including the
　　connection-token close.

10.1.2 101 Switching Protocols

　　The server understands and is willing to comply with the client‘s
　　request, via the Upgrade message header field (section 14.42), for a
　　change in the application protocol being used on this connection. The
　　server will switch protocols to those defined by the response‘s
　　Upgrade header field immediately after the empty line which
　　terminates the 101 response.

　　The protocol SHOULD be switched only when it is advantageous to do
　　so. For example, switching to a newer version of HTTP is advantageous
　　over older versions, and switching to a real-time, synchronous
　　protocol might be advantageous when delivering resources that use
　　such features.

3. Client Requested Upgrade to HTTP over TLS

　　When the client sends an HTTP/1.1 request with an Upgrade header
　　field containing the token "TLS/1.0", it is requesting the server to
　　complete the current HTTP/1.1 request after switching to TLS/1.0.

3.1 Optional Upgrade

　　A client MAY offer to switch to secured operation during any clear
　　HTTP request when an unsecured response would be acceptable:

　　GET http://example.bank.com/acct_stat.html?749394889300 HTTP/1.1
　　Host: example.bank.com
　　Upgrade: TLS/1.0
　　Connection: Upgrade