3.5 Beyond the RequestResponse Model

3.5 Beyond the Request/Response Model

HTTP/1.1 defines a few mechanisms that extend the basic model in which a single request triggers a single response and then the TCP connection is closed again. Most of these mechanisms involve keeping TCP connections alive for a number of message roundtrips. There are some startup costs to establishing a TCP connection, so these mechanisms can improve performance.

WebDAV defines another mechanism that extends the request/response model. The 102 Processing response is defined for WebDAV servers to use when the final response is delayed due to lengthy processing. This mechanism is defined in Section 5.2.

3.5.1 Keeping Connections Alive

The client uses the Connection request header (see Section 3.7.7) to indicate whether it prefers to maintain the TCP connection after the server's response. If the client sends the Keep-Alive header value, then the server can choose not to drop the connection when it has sent the response.

Keeping connections alive offers a couple of benefits:

• An ordinary TCP connection has some startup costs. Many books cover TCP performance considerations quite effectively, including books on HTTP ([Gourley02] and [Krishnamurthy01]) and, naturally, TCP references [Stevens98].

• A secure connection, such as a SSL or TLS connection, incurs even more startup costs. The first connection includes expensive key generation and certificate verification, and subsequent connections must at least restore the encryption context [Rescorla00].

3.5.2 Pipelining

When the connection is kept alive, the client can pipeline requests for improved performance. In pipelining, the client does not have to wait for the server's first response before sending a second request, so in theory the second response should arrive faster. The server must respond to each request in the order in which it is received. Note that pipelining doesn't have to be used all the time when a connection is kept alive. At any point, the client may decide to wait for a server's response before sending another request.

The HTTP/1.1 specification requires that only idempotent requests should be pipelined together. In theory, an idempotent request is one in which multiple instances of the same request have the same effect as one instance of the request. In practice, a client implementer cannot tell when requests are going to be idempotent. For example, the client implementer could believe that using PUT to upload the same body over and over again is no different than uploading it once, and thus PUT is an idempotent request (and Section 9.6 of RFC2616 encourages this belief). However, if the server supports versioning and each PUT request creates a new version, the request is not strictly idempotent. Since in practice the client can't tell, the client might as well pipeline any set of requests for which the failure of one request won't affect whether or not the client attempts another request.

For example, the client might use pipelining with PUT requests to upload all the contents of a local directory to the server without waiting for intermediate success responses.

3.5.3 Predicting Success for Lengthy Requests

The latest specification for HTTP/1.1 [RFC2616] defines the Expect header so that a client can make sure that a lengthy request will be successful before sending the entire request. The client includes the Expect header in a normal request but pauses when it reaches the request body. The server sees the Expect header and responds to the request headers before waiting for the request body. This allows the server to say that it may allow the request (with a 100 Continue response), in which case the client can send the entire request body. If the request must fail, the server responds with an appropriate error response immediately. For example, if a lock would prevent the request from succeeding, the server responds with 423 Locked.

This mechanism is particularly useful with PUT requests because the client may send a large body with PUT. If the client is operating over a slow upload link, it can save a lot of time that would be wasted uploading a large file in a request doomed to fail.

Any WebDAV server should be prepared to receive the Expect header and send 100 Continue responses or a specific error. This applies not only to the PUT method but to any method that can take a body.

However, WebDAV clients cannot currently rely on using the Expect header. The client can't verify whether the server will support the Expect header before sending it. There's no way to tell the difference between a server supporting HTTP/1.1 as defined in RFC2068, which is obsolete, and a server supporting HTTP/1.1 as defined in RFC2616. Only RFC2616 defines the Expect header.

An HTTP/1.1 server compliant with RFC2068 may respond to one of these requests as if the Expect header is not present. For example, the server could wait for the request body to appear and eventually time out the response. To work around this problem, the client could attempt the request with the Expect header, but if it doesn't receive a 100 Continue or an error response quickly, it would have to drop the TCP connection and try the request again without the Expect header and with the full request body present.

If the server notices but does not understand the entire Expect header, it responds with the 417 Expectation Failed error.