Hypertext Transfer Protocol (HTTP) uses a client-request/server-response model. HTTP is a stateless protocol, which means it does not require the server to retain information or status about each user for the duration of multiple requests. However, for performance reasons and to avoid TCP' connection-latency issues, techniques like Persistent, Parallel or Pipelined connections may be used.

HTTP/1.1 defines a number of numeric HTTP status codes that appear in the status line - the first line of an HTTP response - to summarise what the client should do with the response.

The first digit of a status codes defines the response’s class:

• 1xx Informational
• 2xx Client request successful
• 3xx Request redirected - further action necessary, such as a new request
• 4xx Client error - do not repeat the same request
• 5xx Server error - maybe try again

In practice, it is not always easy to choose the most appropriate status code.

The CONNECT method is reserved by the method definitions specification for use with proxies that are able to switch between proxying and tunneling modes (such as for SSL tunneling).

Basic Authentication is defined in RFC2617. It can be used to authenticate against the origin server after receiving a 401 Unauthorized as well as against a proxy server after a 407 (Proxy Authentication Required). In the (decoded) credentials, the password starts after the first colon. Therefore the username cannot contain a colon, but the password can.

Responses are cached separately for each URL and each HTTP method.

HTTP caching is defined in RFC 7234.

Glossary

• fresh — state of a cached response, which hasn't expired yet. Typically, a fresh response can satisfy requests without a need to contact the server the response originated from.
• stale — state of a cached response, which is past its expiration date. Typically, stale responses can't be used to satisfy a request without checking with the server whether it's still valid.
• satisfy — cached response satisfies a request when all conditions in the request match the cached response, e.g. they have the same HTTP method and URL, the response is fresh or the request allows stale responses, request headers match headers listed in response's Vary header, etc.
• revalidation — checking whether a cached response is fresh. This is usually done with a conditional request containing If-Modified-Since or If-None-Match and response status 304.
• private cache — cache for a single user, e.g. in a web browser. Private caches can store personalized responses.
• public cache — cache shared between many users, e.g. in a proxy server. Such cache can send the same response to multiple users.

Cross-origin resource sharing is designed to allow dynamic requests between domains, often using techniques such as AJAX. While the scripting does most of the work, the HTTP server must support the request using the correct headers.