Http Basic Authentication – Introduction & Implementation

Hello friends, in our previous articles we’ve discussed about Http Authentication. Now we know importance of authentication\Authorization. So this is the time now to discuss about various schema available for authentication and how these are implemented. Let’s discuss about basic authentication.

HTTP provides a general framework for access control and authentication. The most common HTTP authentication is based on “Basic” schema. This page shows an introduction to HTTP Basic authentication.

How Authentication Starts

  • First HTTP client makes a request to the web server.
  • Request method doesn’t has to be GET it can be any method.
  • If web server sees that the requested resource need authentication to access then it sends backs 401 unauthorized status code along with WWW-Authenticate header.
  • Then client displays a dialog box to take username and password as input.
  • Once the credentials has been enter the client sends it using the Authorization header.
  • If the credentials are correct then server responds with 200 status code and Authentication-Info header.
  • If client sends wrong credentials in the Authorization request then server again responds with 401 status code. The client is allowed to try again and again.

Basic Authentication

Basic Authentication

We discussed that when web server sees that the requested resource need authentication to access then it sends backs 401 unauthorized status code along with WWW-Authenticate header.

Below is the response sent by server if user is unauthenticated.

WWW-Authenticate: realm=”Images”

What is Realm? Let’s discuss this.


Servers use realm to group different parts of the server (assigns same realm, username and password other resources on the same and deeper level). Browser saves credentials for all realm’s. Whenever browser receives a WWW-Authenticate response with a realm already saved, it will automatically send the credentials without the knowledge of user. Browser also sends Authorization request directly to the URLs deeper than a level whose realm and credentials are known. This creates a session among the URls with same realm and also URIs deeper to a saved realm.

It is compulsory that this header will contain a realm directive. Realm is displayed in the dialog box.


Client send the request again by putting credentials in the dialog box which is displayed. Browser uses Authorization header to send this information to server. Username and password are joined together with a colon in between and then encoded using base-64 encoding method.

So if the username is “deepak” and the password is “pwd123456” than a string “deepak:pwd123456” is generated and then encoded using base64. Then this encoded result is sent to the server.

Below is the example of Authorization header.

Authorization: Basic S08tyui78ophJKL


Some organizations use proxy servers to authenticate users before allowing them to access the web server resources. The same mechanism is used by proxies to authenticate users but header and status codes are changed. Below are the changes:

  • Response status 407: 407 response status code is sent instead of 401. This code is meant for proxy authentication.
  • Proxy-Authenticate: Proxy-Authenticate is used instead of WWW-Authenticate.
  • Proxy-Authorization: Proxy-Authorization is used instead of Authorization when credentials are sent to server.
  • Proxy-Authentication-Info: Proxy-Authentication-Info is used instead of Authentication-Info.

The Authentication-Info Header Field

Sometime server return with addition information using Authentication-Info header.

HTTP authentication schemes can use the Authentication-Info response header field to return additional information applicable to the authentication currently in use.

The field value is a list of parameters (name/value pairs),

The Authentication-Info header field can be used in any HTTP response, independently of request method and status code. 

Security of Basic Authentication

As the user ID and password are passed over the network as clear text (it is base64 encoded, but base64 is a reversible encoding), the basic authentication scheme is not secure. HTTPS / TLS should be used in conjunction with basic authentication. Without these additional security enhancements, basic authentication should not be used to protect sensitive or valuable information.


Http Authentication – Introduction

Hello friends, we are in discussion about Http and various important aspects related to the same. While discussing this, we cannot ignore vary important aspect of discussion i.e. Http Authentication & Access control.

We live in world of internet where each and every information is available on the network and can be accessed by anyone. With that said, there is some confidential\proprietary information which is available and should be accessed only by authorized people. To access authorized information, we need to prove our identity and we should have access to those resources which we want.

In internet world this is accomplished via Http Authentication\Authorization.

Http also has its own authentication framework to authenticate user and provide authorized information.

HTTP provides a general framework for access control and authentication. The most common HTTP authentication is based on “Basic” schema. This page shows an introduction to HTTP framework for authentication and shows what all type of schemas are there.

HTTP Authentication Framework

RFC 7235 defines the HTTP authentication framework which can be used by a server to challenge a client request and then a client provides authentication information.

The challenge and response flow works like this:

  • Client requests a resource from server.
  • The server responds to a client with a 401(Unauthorized) response status and provides information on how to authorize with a WWW-Authenticate response header containing at least one challenge.
  • A client that wants to authenticate itself with a server, will provide its username and password.
  • Server will match credentials and then will provide resource if authentication succeeded.

Below is the flow:

Http Authentication

Proxy Authentication

The same challenge and response mechanism can be used for proxy authentication. Suppose, there is an intermediate proxy that requires authentication. As both resource authentication and proxy authentication can coexist, a different set of headers and status codes are needed.

In the case of proxies, the challenging status code is 407 (Proxy Authentication Required), the Proxy-Authenticate response header contains at least one challenge applicable to the proxy, and the Proxy-Authorization request header is used for providing the credentials to the proxy server.

Access forbidden

If a (proxy) server receives valid credentials that are not adequate to gain access for a given resource, the server should respond with the 403 Forbidden status code. 

Authentication of cross-origin images

A potential security hole that has recently been fixed by browsers is authentication of cross-site images.

Previously an image from different origin was able to show authentication dialog box to user and user has to put credentials. This way one can steal your data as credential information could be in Base64 encoded and can be cracked easily.

As part of security fix, all image resources loaded from different origins to the current document are no longer able to trigger HTTP authentication dialog, preventing user credentials being stolen if attackers were able to embed an arbitrary image into a third-party page. 

WWW-Authenticate and Proxy-Authenticate headers

The WWW-Authenticate and Proxy-Authenticate response headers define the authentication method that should be used to gain access to a resource. They need to specify which authentication scheme is used, so that the client that wishes to authorize knows how to provide the credentials. The syntax for these headers is the following:

WWW-Authenticate: <type> realm=<realm>

Proxy-Authenticate: <type> realm=<realm>

Here, <type> is the authentication scheme (“Basic” is the most common scheme and introduced below). The realm is used to describe the protected area or to indicate the scope of protection. This could be a message like “Access to the staging site” or similar, so that the user knows to which space they are trying to get access to.

Authorization and Proxy-Authorization headers

The Authorization and Proxy-Authorization request headers contain the credentials to authenticate a user agent with a (proxy) server. Here, the type is needed again followed by the credentials, which can be encoded or encrypted depending on which authentication scheme is used.

Authorization: <type> <credentials>

Proxy-Authorization: <type> <credentials>

Authentication schemes

The general HTTP authentication framework is used by several authentication schemes. Schemes can differ in security strength and in their availability in client or server software.

The most common authentication scheme is the “Basic” authentication scheme which is introduced in more details below. IANA maintains a list of authentication schemes, but there are other schemes offered by host services, such as Amazon AWS.

Common authentication schemes include:

Authentication Scheme



An anonymous request does not contain any authentication information. This is equivalent to granting everyone access to the resource.


Basic authentication sends a Base64-encoded string that contains a user name and password for the client. Base64 is not a form of encryption and should be considered the same as sending the user name and password in clear text. If a resource needs to be protected, strongly consider using an authentication scheme other than basic authentication.


Digest authentication is a challenge-response scheme that is intended to replace Basic authentication. The server sends a string of random data called a nonce to the client as a challenge. The client responds with a hash that includes the user name, password, and nonce, among additional information. The complexity this exchange introduces and the data hashing make it more difficult to steal and reuse the user’s credentials with this authentication scheme.

Digest authentication requires the use of Windows domain accounts. The digest realm is the Windows domain name. Therefore, you cannot use a server running on an operating system that does not support Windows domains, such as Windows XP Home Edition, with Digest authentication. Conversely, when the client runs on an operating system that does not support Windows domains, a domain account must be explicitly specified during the authentication.


NT LAN Manager (NTLM) authentication is a challenge-response scheme that is a securer variation of Digest authentication. NTLM uses Windows credentials to transform the challenge data instead of the unencoded user name and password. NTLM authentication requires multiple exchanges between the client and server. The server and any intervening proxies must support persistent connections to successfully complete the authentication.


This authentication service was developed at Massachusetts Institute of Technology (MIT). It involves the symmetric key encryption practice and a KDC (Key distribution center). It verifies the identities of communication parties on an unprotected network. This is achieved without depending on authentication mechanism by the host OS, without necessitating physical security of the host and without building trust on host address.


Negotiate authentication automatically selects between the Kerberos protocol and NTLM authentication, depending on availability. The Kerberos protocol is used if it is available; otherwise, NTLM is tried. Kerberos authentication significantly improves upon NTLM. Kerberos authentication is both faster than NTLM and allows the use of mutual authentication and delegation of credentials to remote machines.

Windows Live ID

The underlying Windows HTTP service includes authentication using federated protocols. However, the standard HTTP transports in WCF do not support the use of federated authentication schemes, such as Microsoft Windows Live ID. Support for this feature is currently available through the use of message security.


This is only an introduction about Http Authentication framework and schemas. In upcoming articles we’ll discuss each of these schemas in detail.


Http Verbs Details-Meaning & Usage

Hello friends, in our previous discussions, we discussed about What is Http, Usage and Important Terms. Today we are going to discuss about Http verbs details. We’ll see the differences, Implementation and Ideal usage for these.

What are HTTP Verbs?

HTTP defines a set of request methods to indicate the desired action to be performed for a given resource. Although they can also be nouns, these request methods are sometimes referred as HTTP verbs.

Let’s discuss about these http verbs details.


The GET method requests a representation of the specified resource. Requests using GET should only retrieve data and should have no other effect. Requested resource is returned in form of xml or json.

Note: Get should be used only for retrieval. It should not change representation of any resource.

Additionally, GET APIs should be idempotent, which means that making multiple identical requests must produce same result every time until another API (POST or PUT) has changed the state of resource on server.

For any given HTTP GET API, if resource is found on server then it must return HTTP response code 200 (OK) – along with response body which is usually either XML of JSON content (due to their platform independent nature).

In case resource is NOT found on server then it must return HTTP response code 404 (NOT FOUND). Similarly, if it is determined that GET request itself is not correctly formed then server will return HTTP response code 400 (BAD REQUEST).

You can get more information about Http Status Codes here. 

Idempotent Methods:

The term idempotent is used more comprehensively to describe an operation that will produce the same results if executed once or multiple times.

Example request URIs:

HTTP GET http://www.example.com/users
HTTP GET http://www. example.com/users?size=20&page=5


The HEAD method asks for a response identical to that of a GET request, but without the response body. This is useful for retrieving meta-information written in response headers, without having to transport the entire content.

In other words, if GET /users returns a list of users, then HEAD /users will make the same request but will not return the list of users.

HEAD requests are useful for checking what a GET request will return before actually making a GET request – like before downloading a large file or response body.

Example request URIs:

HTTP HEAD http://www.example.com/users


POST is used to send data to a server to create/update a resource. The data sent to the server with POST is stored in the request body of the HTTP request.

Ideally, if a resource has been created on the origin server, the response SHOULD be HTTP response code 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header.

Many times, the action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either HTTP response code 200 (OK) or 204 (No Content) is the appropriate response status.

Some other notes on POST requests:

  • POST requests are never cached
  • POST requests do not remain in the browser history
  • POST requests cannot be bookmarked
  • POST requests have no restrictions on data length


POST /test/myform.php HTTP/1.1
Host: example.com


The PUT method requests that the enclosed entity be stored under the supplied URI. If the URI refers to an already existing resource, it is modified; if the URI does not point to an existing resource, then the server can create the resource with that URI.

The difference between POST and PUT is that PUT requests are idempotent. That is, calling the same PUT request multiple times will always produce the same result. In contrast, calling a POST request repeatedly have side effects of creating the same resource multiple times. In addition to this POST requests are made of resource collections whereas PUT requests are made on individual resource.

If a new resource has been created by the PUT API, the origin server MUST inform the user agent via the HTTP response code 201 (Created) response and if an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request.

Example request URIs:

HTTP PUT http://www.example.com/users/123


The DELETE method deletes the specified resource.

A successful response of DELETE requests SHOULD be HTTP response code

  • 200 (OK) – if the response includes an entity describing the status, 
  • 202 (Accepted) – if the action has been queued, or 
  • 204 (No Content) – if the action has been performed but the response does not include an entity.

DELETE operations are idempotent. If you DELETE a resource, it’s removed from collection of resource. Repeatedly calling DELETE API on that resource will not change the outcome – however calling DELETE on a resource a second time will return a 404 (NOT FOUND) since it was already removed.

Example request URIs:

HTTP DELETE http://www.appdomain.com/users/123


The TRACE method echoes the received request so that a client can see what (if any) changes or additions have been made by intermediate servers.

The HTTP TRACE method is designed for diagnostic purposes. If enabled, the web server will respond to requests that use the TRACE method by echoing in its response the exact request that was received.

This behavior is often harmless, but occasionally leads to the disclosure of sensitive information such as internal authentication headers appended by reverse proxies. This functionality could historically be used to bypass the Http Only cookie flag on cookies, but this is no longer possible in modern web browsers.

Example request URIs:

HTTP TRACE /mypage.html HTTP/1.1


The OPTIONS method returns the HTTP methods that the server supports for the specified URL. This can be used to check the functionality of a web server by requesting ‘*’ instead of a specific resource.

To find out which request methods a server supports, one can use curl and issue an OPTIONS request:

curl -X OPTIONS http://example.com -i

The response then contains an Allow header with the allowed methods:

HTTP/1.1 200 OK
Cache-Control: max-age=604800
Date: Thu, 13 Oct 2016 11:45:00 GMT
Expires: Thu, 20 Oct 2016 11:45:00 GMT
Server: EOS (lax004/2813)
x-ec-custom-error: 1
Content-Length: 0


The HTTP CONNECT method method starts two-way communications with the requested resource. It can be used to open a tunnel.

For example, the CONNECT method can be used to access websites that use SSL (HTTPS). The client asks an HTTP Proxy server to tunnel the TCP connection to the desired destination. The server then proceeds to make the connection on behalf of the client. Once the connection has been established by the server, the Proxy server continues to proxy the TCP stream to and from the client.

CONNECT is a hop-by-hop method.

Hop by Hop: 

Indicates the flow the communication follows. Data pass through multiple devices with an IP address, and each is genetically named “hop”. Hop by Hop indicates analyzing the data flow at layer 3, checking all devices in the path.


CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80


The PATCH method applies partial modifications to a resource.

The HTTP PUT method only allows complete replacement of a document. Unlike PUT, PATCH is not idempotent, meaning successive identical patch requests may have different effects. However, it is possible to issue PATCH requests in such a way as to be idempotent.



PATCH /file.txt HTTP/1.1
Host: www.example.com
Content-Type: application/example
If-Match: "e0023aa4e"
Content-Length: 100


A successful response is indicated with a 204 response code, because the response does not carry a message body.

HTTP/1.1 204 No Content
Content-Location: /file.txt
ETag: "e0023aa4f"

All general-purpose HTTP servers are required to implement at least the GET and HEAD methods, and all other methods are considered optional by the specification.

Safe methods

Some of the methods (for example, HEAD, GET) are, by convention, defined as safe, which means they are intended only for information retrieval and should not change the state of the server.

This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested – and they can update/delete the resource on server and so should be used carefully.

Http verbs details



That’s all about Http verbs for this article.


What is Http, Usage and Important Terms

Hello friends, today we are going to discuss about What is Http and details.

Whether you are a user or a website owner, the one word you might come across when browsing is HTTP. It is important to get the basics of HTTP to understand how Internet works and the details sent and received between your browser and the web server. Here is a beginner’s guide to What is Http attempting to explain the basics.

What is Http?

HTTP means Hypertext Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted. How server will recognize these commands and what actions Web servers and browsers should take in response to various commands. HTTP is the set of rules for transferring files (text, graphic images, sound, video, and other multimedia files) on the World Wide Web. 

HTTP functions as a request–response protocol in the client–server computing model. A web browser, for example, may be the client and an application running on a computer hosting a website may be the server. The client submits an HTTP request message to the server. The server, which provides resources such as HTML files and other content, or performs other functions on behalf of the client, returns a response message to the client. The response contains completion status information about the request and may also contain requested content in its message body.

 Let’s first discuss about how website works.

Web Request Life Cycle

 In general below is the flow of any web request. You can get more information about the flow here.



  1. User types any address in any browser e.g. google.com.
  2. Browser sends request to web server.
  3. Web server creates a new process or assign a thread to process this request.
  4. Web server processes the request and generate the response.
  5. This response is sent back to client.
  6. Now assigned process or thread is free to receive another requests.
  7. Browser displays the response to user.

This is very basic and top view of the process.

Request Message

 A simple request message from a client computer consists of the following components:

  • A request line to get a required resource, for example a request GET /content/page1.html is requesting a resource called /content/page1.html from the server.
  • Headers (Example – Accept-Language: EN).
  • An empty line.
  • A message body which is optional.

All the lines should end with a carriage return and line feed. The empty line should only contains carriage return and line feed without any spaces.

Response Message

 A simple response from the server contains the following components:

  • HTTP Status Code (For example HTTP/1.1 301 Moved Permanently, means the requested resource was permanently moved and redirecting to some other resource).
  • Headers (Example – Content-Type: html)
  • An empty line.
  • A message body which is optional.

All the lines in the server response should end with a carriage return and line feed. Similar to request, the empty line in a response also should only have carriage return and line feed without any spaces.

Stateless Protocol

HTTP is called a stateless protocol because each command is executed independently, without any knowledge of the commands that came before it. Server receives the request, process it and create a response for client. Once response is transferred to client then connection drops and next request from same client is treated independently.

User Agent

A web browser is an example of a user agent (UA). Other types of user agent include the indexing software used by search providers (web crawlers), voice browsers, mobile apps, and other software that accesses, consumes, or displays web content.  


A server is the machine which host the resource and can serve client based on the request. All web resources are hosted on any server.  Dedicated computers and appliances may be referred to as Web servers as well.

 Web servers are able to map the path component of a Uniform Resource Locator (URL) into:

  • A local file system resource (for static requests)
  • An internal or external program name (for dynamic requests)

For a static request the URL path specified by the client is relative to the web server’s root directory.

Consider the following URL as it would be requested by a client:


The client’s user agent will translate it into a connection to www.example.com with the following HTTP 1.1 request:

GET /path/file.html HTTP/1.1
Host: www.example.com

The web server on www.example.com will append the given path to the path of its root directory. On an Apache server, this is commonly /home/www (on Unix machines, usually /var/www). The result is the local file system resource:


The web server then reads the file, if it exists, and sends a response to the client’s web browser. The response will describe the content of the file and contain the file itself or an error message will return saying that the file does not exist or is unavailable.


An HTTP session is a sequence of network request-response transactions. An HTTP client initiates a request by establishing a Transmission Control Protocol (TCP) connection to a particular port on a server (typically port 80, occasionally port 8080; see List of TCP and UDP port numbers). An HTTP server listening on that port waits for a client’s request message. Upon receiving the request, the server sends back a status line, such as “HTTP/1.1 200 OK”, and a message of its own. The body of this message is typically the requested resource, although an error message or other information may also be returned.

HTTP sessions are opened by an HTTP Client (i.e. the user’s browser) via a user agent and a connection Request Message is sent to an HTTP Server (i.e. the Web Server). Once the response has been delivered the Web Server closes the connection. This type of connection is known as Stateless in that it exists only for the duration of the data exchange.

Let us take an example that you want to open a page “home.html” from the site “yoursite.com”. Below is how the request from the client browser should look like to get a “home.html” page from “yoursite.com”.

HTTP Request Structure:

GET /home.html HTTP/1.1
Host: www.yoursite.com


The response from the web server should look like below:

HTTP Response Structure:

HTTP/1.1 200 OK
Date: Sun, 28 Jul 2013 15:37:37 GMT
Server: Apache
Last-Modified: Sun, 07 Jul 2013 06:13:43 GMT
Transfer-Encoding: chunked
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8
Webpage Content


Chunked transfer encoding is a method in which the server responds with a data in chunks and this used in place of Content-Length header. The communication is stopped when a zero length of chunk is received and this method is used in HTTP Version 1.1.


Authentication is a process in which the credentials provided are compared to those on file in a database of authorized users’ information on a local operating system or within an authentication server. If the credentials match, the process is completed and the user is granted authorization for access. 

HTTP provides multiple authentication schemes such as basic access authentication and digest access authentication which operate via a challenge-response mechanism whereby the server identifies and issues a challenge before serving the requested content. 

We’ll discuss more about these authentication schemas in detail in upcoming articles.  


HTTP defines methods (sometimes referred to as verbs) to indicate the desired action to be performed on the identified resource. What this resource represents, whether pre-existing data or data that is generated dynamically, depends on the implementation of the server.


The GET method requests a representation of the specified resource. Requests using GET should only retrieve data and should have no other effect.


The HEAD method asks for a response identical to that of a GET request, but without the response body. This is useful for retrieving meta-information written in response headers, without having to transport the entire content.


The POST method requests that the server accept the entity enclosed in the request as a new subordinate of the web resource identified by the URI. The data Posted might be, for example, an annotation for existing resources; a message for a bulletin board, newsgroup, mailing list, or comment thread; a block of data that is the result of submitting a web form to a data-handling process; or an item to add to a database.


The PUT method requests that the enclosed entity be stored under the supplied URI. If the URI refers to an already existing resource, it is modified; if the URI does not point to an existing resource, then the server can create the resource with that URI.


The DELETE method deletes the specified resource.


The TRACE method echoes the received request so that a client can see what (if any) changes or additions have been made by intermediate servers.


The OPTIONS method returns the HTTP methods that the server supports for the specified URL. This can be used to check the functionality of a web server by requesting ‘*’ instead of a specific resource.


The CONNECT method converts the request connection to a transparent TCP/IP tunnel, usually to facilitate SSL-encrypted communication (HTTPS) through an unencrypted HTTP proxy


The PATCH method applies partial modifications to a resource.

All general-purpose HTTP servers are required to implement at least the GET and HEAD methods, and all other methods are considered optional by the specification.

Safe methods

Some of the methods (for example, HEAD, GET, OPTIONS and TRACE) are, by convention, defined as safe, which means they are intended only for information retrieval and should not change the state of the server.

We’ll discuss more about these methods, usage and limitations in detail in upcoming articles.

Status Codes

Depending on the availability or otherwise of the Resource HTTP provides an appropriate status code (also referred to as the ‘Server Response’) determined by the protocol. These are as follows:


Now you understand HTTP then what is that HTTPS? HTTPS is the secured HTTP protocol required to send and receive information securely over internet. Nowadays it is mandatory for all websites to have HTTPS protocol to have secured internet. Browsers like Google Chrome will show an alert with “Not Secure” message in the address bar if the site is not served over HTTPS.

This typically involves the use of an SSL Certificate which creates a secure, encrypted connection between the browser and the web server.

This is typically used for secure areas of websites where sensitive data is transferred such as payment details or login credentials. In recent years though HTTPS has been listed as a Google ranking factor and more and more websites are moving to HTTPS for that reason.

Whereas HTTP uses port 80, HTTPS uses port 443 for communication.

We’ll discuss more about SSL, usage and implementations in detail in upcoming articles.



HTTP Version










Http 2015 is relatively new but still in implementation phase. We can say that 1.1 is the mostly used version as of now.

How to Check HTTP Request and Response on Chrome?

Let us take Google Chrome the popular browser, but the process remains same in all other browsers to view the details.

  • Open a webpage in Google Chrome and go to “View > Developer > Developer Tools” menu.
  • You can also open the developer console by right clicking on the page and choose “Inspect” option.
  • Go to “Network” tab and then reload the page. Now you will see the loading time for each single component on the page.
  • Here you can see request\Response headers.
  • You can check complete response also in highlighted Response tab.

What is Http


That’s all about Http for this session.


Http Response Codes 5xx & Meanings

Hello friends, Today we are going to discuss about http response codes 5xx. In previous articles we have discussed about

Http status code 1xx

Http status code 2xx

Http status code 3xx

Http status code 4xx

In this article we are going to discuss about http response codes 5xx and meaning.

Note: Http response codes 5xx are indication of Server Errors. ** is prefixed for most commonly used status codes.

So let’s start.

**500 Internal Server Error

The server encountered an unexpected condition which prevented it from fulfilling the request. A generic error message, given when no more specific message is suitable.

**501 Not Implemented

The server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource.

**502 Bad Gateway

The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting to fulfill the request.

**503 Service Unavailable

The server is currently unable to handle the request due to a temporary overloading or maintenance of the server.

**504 Gateway Timeout

The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server specified by the URI.

505 HTTP Version Not Supported

The server does not support, or refuses to support, the HTTP protocol version that was used in the request message. The server is indicating that it is unable or unwilling to complete the request.

The response should contain an entity describing why that version is not supported and what other protocols are supported by that server.

506 Variant Also Negotiates (Experimental)

The 506 status code indicates that the server has an internal configuration error: the chosen variant resource is configured to engage in transparent content negotiation itself, and is therefore not a proper end point in the negotiation process.

507 Insufficient Storage (WebDAV)

The 507 (Insufficient Storage) status code means the method could not be performed on the resource because the server is unable to store the representation needed to successfully complete the request. This condition is considered to be temporary

508 Loop Detected (WebDAV)

The 508 (Loop Detected) status code indicates that the server terminated an operation because it encountered an infinite loop while processing a request with “Depth: infinity”. This status indicates that the entire operation failed.

509 Bandwidth Limit Exceeded (Apache)

This status code, while used by many servers, is not specified in any RFCs.

510 Not Extended

The policy for accessing the resource has not been met in the request. The server should send back all the information necessary for the client to issue an extended request

If the 510 response contains information about extensions that were not present in the initial request then the client MAY repeat the request if it has reason to believe it can fulfill the extension policy by modifying the request according to the information provided in the 510 response. Otherwise the client MAY present any entity included in the 510 response to the user, since that entity may include relevant diagnostic information.

511 Network Authentication Required

The 511 status code indicates that the client needs to authenticate to gain network access.

The response representation SHOULD contain a link to a resource that allows the user to submit credentials (e.g. with a HTML form).

The 511 status should not be generated by origin servers; it is intended for use by intercepting proxies that are interposed as a means of controlling access to the network.

550 Permission Denied

The server is stating the account you have currently logged in as does not have permission to perform the action you are attempting. You may be trying to upload to the wrong directory or trying to delete a file.

598 Network read timeout error

This status code is not specified in any RFCs, but is used by some HTTP proxies to signal a network read timeout behind the proxy to a client in front of the proxy.

599 Network connect timeout error

This status code is not specified in any RFCs, but is used by some HTTP proxies to signal a network connect timeout behind the proxy to a client in front of the proxy.

That’s it about Http response codes 5xx. There are few more status codes which are unofficial but still used. You can check the list here.


Http Response Codes 4xx & Meanings

Hello friends, Today we are going to discuss about http response codes 4xx. In previous articles we have discussed about

Http status code 1xx

Http status code 2xx

Http status code 3xx

Note: http response codes 4xx are indication of Client Errors. ** is prefixed for most commonly used status codes.

So let’s start.

**400 Bad Request

The request could not be understood by the server due to incorrect syntax.

**401 Unauthorized

The request requires user authentication. The response MUST include a WWW-Authenticate header field containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field. If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials.

402 Payment Required

Reserved for future use. The original intention was that this code might be used as part of some form of digital cash or micro payment scheme, but that has not yet happened, and this code is not usually used. Google Developers API uses this status if a particular developer has exceeded the daily limit on requests.

**403 Forbidden

The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not found) can be used instead.

**404 Not Found

The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent.

405 Method Not Allowed

The method specified in the Request-Line is not allowed for the resource identified by the Request-URI. The response MUST include an Allow header containing a list of valid methods for the requested resource. For example, using GET on a form which requires data to be presented via POST, or using PUT on a read-only resource.

406 Not Acceptable

The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request.

HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept headers sent in the request. In some cases, this may even be preferable to sending a 406 response. User agents are encouraged to inspect the headers of an incoming response to determine if it is acceptable.

407 Proxy Authentication Required

This code is similar to 401 (Unauthorized), but indicates that the client must first authenticate itself with the proxy. The proxy MUST return a Proxy-Authenticate header field containing a challenge applicable to the proxy for the requested resource. The client MAY repeat the request with a suitable Proxy-Authorization header field.

408 Request Timeout

The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time.

**409 Conflict

The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.

Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can’t complete the request. In this case, the response entity would likely contain a list of the differences between the two versions in a format defined by the response Content-Type.

**410 Gone

The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) should be used instead.

The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource is intentionally unavailable.

411 Length Required

The server refuses to accept the request without a defined Content- Length. The client MAY repeat the request if it adds a valid Content-Length header field containing the length of the message-body in the request message.

412 Precondition Failed

The precondition given in one or more of the request-header fields evaluated as false when it was tested on the server.

413 Request Entity Too Large

The server is refusing to process a request because the request entity is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request.

414 Request-URI Too Long

The server is refusing to service the request because the Request-URI is longer than the server is willing to interpret. This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long query information.

415 Unsupported Media Type

The server is refusing to service the request because the entity of the request is in a format not supported by the requested resource for the requested method.

416 Requested Range Not Satisfying

A server SHOULD return a response with this status code if a request included a Range request-header field, and none of the range-specifier values in this field overlap the current extent of the selected resource, and the request did not include an If-Range request-header field

When this status code is returned for a byte-range request, the response SHOULD include a Content-Range entity-header field specifying the current length of the selected resource.

417 Expectation Failed

The expectation given in an Expect request-header field could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could not be met by the next-hop server.

418 I’m a teapot (RFC 2324)

This code was defined in 1998 as one of the traditional IETF April Fools’ jokes, in RFC 2324, Hyper Text Coffee Pot Control Protocol, and is not expected to be implemented by actual HTTP servers. However, known implementations do exist. An Nginx HTTP server uses this code to simulate goto like behavior in its configuration.

Alex explained it pretty well here.

420 Enhance Your Calm (Twitter)

Returned by the Twitter Search and Trends API when the client is being rate limited and is sending too many requests.

422 not process able Entity (WebDAV)

The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity, and the syntax of the request entity is correct but was unable to process the contained instructions.

For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.

423 Locked (WebDAV)

The 423 (Locked) status code means the source or destination resource of a method is locked. This response should contain an appropriate precondition or post condition code, such as ‘lock-token-submitted’ or ‘no-conflicting-lock’.

424 Failed Dependency (WebDAV)

The 424 (Failed Dependency) status code means that the method could not be performed on the resource because the requested action depended on another action and that action failed. 

425 Reserved for WebDAV

Defined in drafts of “WebDAV Advanced Collections Protocol”.

426 Upgrade Required

This is an indication to client that the client should switch to a different protocol such as TLS/1.0. This is required due to interoperability negotiation.

428 Precondition Required

The 428 status code indicates that the origin server requires the request to be conditional.

Its typical use is to avoid the “lost update” problem, where a client GETs a resource’s state, modifies it, and PUTs it back to the server, when meanwhile a third party has modified the state on the server, leading to a conflict. By requiring requests to be conditional, the server can assure that clients are working with the correct copies.

429 Too Many Requests

The 429 status code indicates that the user has sent too many requests in a given amount of time (“rate limiting”).

The response representations SHOULD include details explaining the condition, and MAY include a Retry-After header indicating how long to wait before making a new request.

When a server is under attack or just receiving a very large number of requests from a single party, responding to each with a 429 status code will consume resources.

Therefore, servers are not required to use the 429 status code; when limiting resource usage, it may be more appropriate to just drop connections, or take other steps.

431 Request Header Fields Too Large

The 431 status code indicates that the server is unwilling to process the request because its header fields are too large. The request MAY be resubmitted after reducing the size of the request header fields.

It can be used both when the set of request header fields in total are too large, and when a single header field is at fault. In the latter case, the response representation SHOULD specify which header field was too large.

Servers are not required to use the 431 status code; when under attack, it may be more appropriate to just drop connections, or take other steps.

444 No Response (Nginx)

An Nginx HTTP server extension. The server returns no information to the client and closes the connection (useful as a deterrent for malware).

449 Retry with (Microsoft)

A Microsoft extension. The request should be retried after performing the appropriate action.

450 Blocked by Windows Parental Controls (Microsoft)

A Microsoft extension. This error is given when Windows Parental Controls are turned on and are blocking access to the given webpage.

451 Unavailable For Legal Reasons

Intended to be used when resource access is denied for legal reasons, e.g. censorship or government-mandated blocked access.

499 Client Closed Request (Nginx)

An Nginx HTTP server extension. This code is introduced to log the case when the connection is closed by client while HTTP server is processing its request, making server unable to send the HTTP header back.


That’s it about http response codes 4xx. In upcoming articles we’ll discuss about next set of codes.


Http Response Codes 3xx & Meanings

Hello friends, in previous articles we have discussed about Http status code 1xx and Http status code 2xxIn this article we are going to discuss about http response codes 3xx and meaning.

Note: http response codes 3xx status codes are indication of Redirection. ** is prefixed for most commonly used status codes.

So let’s start.

**300 Multiple Choices

The HTTP 300 Multiple Choices redirect status response code indicates that the request has more than one possible responses. The user-agent or the user should choose one of them. As there is no standardized way of choosing one of the responses, this response code is very rarely used.

If the server has a preferred choice, it should generate a Location header.

This is typically the case where the URL represents a high level grouping of which lower level selections need to be made e.g. a directory within which the user must select a particular file to access.

**301 Moved Permanently

The requested resource has been assigned a new permanent URI and any future references to this resource should use one of the returned URIs

The new permanent URI should be given by the Location field in the response. Unless the request method was HEAD, the entity of the response should contain a short hypertext note with a hyperlink to the new URI(s).

We should use Response.RedirectPermanent in ASP.Net, which send 301 status code.

**302 Found

The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client should continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.

The temporary URI should be given by the Location field in the response. Unless the request method was HEAD, the entity of the response should contain a short hypertext note with a hyperlink to the new URI(s).

A 301 redirect means that the page has permanently moved to a new location. A 302 redirect means that the move is only temporary.

If you use Response.Redirect to direct users to a new location, you should be aware that it issues a status code of 302, which means that “the resource resides temporarily under a different URI.” If you intend to communicate that the resource has permanently changed locations, you should not use Response.Redirect. In case of permanent, we should use Response.RedirectPermanent which send 301 status code.

303 See Other

The response to the request can be found under a different URI and should be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested resource. The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable.

In ASP.Net we can achieve this

HttpContext.Current.Response.Status = "303 See Other";
HttpContext.Current.Response.AddHeader("Location", newLocation);

**304 Not Modified

If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server SHOULD respond with this status code. The 304 response MUST NOT contain a message-body, and thus is always terminated by the first empty line after the header fields.

305 Use Proxy

The requested resource MUST be accessed through the proxy given by the Location field. The Location field gives the URI of the proxy. The recipient is expected to repeat this single request via the proxy. 305 responses MUST only be generated by origin servers.

306 (Unused)

The 306 status code was used in a previous version of the specification, is no longer used, and the code is reserved.

**307 Temporary Redirect

A 307 is the actual Temporary Redirect. It really means temporary, as in the very next request should also be made to the old URL, and the new one should not even be cached. This is usually only used for emergency redirects (like when a primary server is down) and the like.

How it is different than 302?

If the URL is really, really temporary please do use a 307. Only use a 302 if you want the URL that you are redirecting to show up in the search results with the content of the page that you are redirecting to.

So you have page A with a URL and you have page B with content. You want the URL of page A to show up with the content of page B in the index. If that’s what you want, use a 302. If that’s not what you want, use a 307. And if something is not temporary but permanent use a 301 redirect and not anything else.

308 Permanent Redirect (experimental)

The request, and all future requests should be repeated using another URI. 307 and 308 (as proposed) parallel the behaviors of 302 and 301, but do not require the HTTP method to change. 

Note: 301 and 302 allow change of request method from POST to GET (i.e. “your submission is received but you should get response elsewhere”); 307 and 308 forbid such behavior.

Below is a flow from which you can get more understanding about status code behavior.

http response codes 3xx chart



That’s it about Http 3xx status codes. In upcoming articles we’ll discuss about next set of codes.


Http Response Codes 2xx & Meanings

Hello friends, in previous articles we have discussed about Http status code 1xx. In this article we are going to discuss about status http response codes 2xx and meaning.

Note: http response codes 2xx are indication of Success. ** is prefixed for most commonly used status codes.


So let’s start.


The request has succeeded. The information returned with the response is dependent on the method used in the request, for example:
If you sent GET request then relevant data will be returned in response.
If you sent POST request then data containing the result of the action will be returned in response.
In each succeeded response, 200 status code will be returned to inform client that request is successfully completed.


Following a POST command, this indicates success, but the textual part of the response line indicates the URI by which the newly created document should be known.
Client sent a new request to server:

POST /edit/ HTTP/1.1
Host: example.org
User-Agent: Thingio/1.0
Authorization: Basic ZGFmZnk6c2VjZXJldA==
Content-Type: application/atom+xml;type=entry
Content-Length: nnn
Slug: First Post

<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom">
  <title>Atom-Powered Robots Run Amok</title>
  <author><name>John Doe</name></author>
  <content>Some text.</content>

The server signals a successful creation with a status code of 201. The response includes a Location header indicating the Member Entry URI of the Atom Entry, and a representation of that Entry in the body of the response.

HTTP/1.1 201 Created
Date: Fri, 7 Oct 2005 17:17:11 GMT
Content-Length: nnn
Content-Type: application/atom+xml;type=entry;charset="utf-8"
Location: http://example.org/edit/first-post.atom
ETag: "c180de84f991g8"

The origin server MUST create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server SHOULD respond with 202 (Accepted) response instead.
A 201 response MAY contain an ETag response header field indicating the current value of the entity tag for the requested entity just created.


The status code 202 indicates that server has received and understood the request, and that it has been accepted for processing, although it may not be processed immediately.

The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process without requiring that the user agent’s connection to the server persist until the process is completed. The entity returned with this response should include an indication of the request’s current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled.

203-Non-Authoritative Information (since HTTP/1.1)

When received in the response to a GET command, this indicates that the returned meta information is not a definitive set of the object from a server. It is from a private overlaid web. This may include annotation information about the object. The set presented MAY be a subset or superset of the original version. We say it partial because this is not from origin server. This is from third party web.

This is virtually identical in meaning to a 200 status code.

**204-No Content

There are several requests for which we do not expect any response message body. In those cases the 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields.

This is just a notification for client that server has received the request but there is no information to send back, and the client should stay in the same document view.

205-Reset Content

The server has fulfilled the request and the user agent should reset the document view which caused the request to be sent. A value of 205 (SC_RESET_CONTENT) means that there is no new document, but the browser should reset the document view. This status code instructs browsers to clear form fields.

Once browser has clear all form fields, user can initiate another input action.

206-Partial Content

We’ve discussed about range requests in bandwidth optimization as part of Http 1.1.

Range Requests:

By using this way a client can send a request and in the request it can mention a range to get. Once server processes this requests and if server supports range requests then server will transfer the range of bytes requested by client.
Following is the example of one range request.

http response codes 2xx

In above example we can see that range from 0 to 1023 bytes is requested from server.

If a response contains a range, rather than the entire resource, it carries the 206 (Partial Content) status code.


The 207 (Multi-Status) status code provides status for multiple independent operations. The message body that follows is an XML message and can contain a number of separate response codes, depending on how many sub-requests were made.

E.g. if you perform an operation like POST, PUT, DELETE against more than one resource and the operations against each individual resource did not share a common outcome then this is ideal scenario to use status code 207.

208-Already Reported

The 208 (Already Reported) status code can be used inside a DAV: propstat response element to avoid enumerating the internal members of multiple bindings of the same collection repeatedly. For each binding of a collection inside the request’s scope, only one will be reported with a 200 status, while subsequent DAV: response elements for all other bindings will use the 208 status, and no DAV: response elements for their descendants are included.

This is for server performance improvement as well as bandwidth optimization.

226-IM Used

A 226 IM Used response means that the server has fulfilled a request for the resource; however, the response is a demonstration of the result of at least one or more instance-manipulations assigned to the current instance.

The actual current instance might not be available except by combining this response with other previous or future responses, as appropriate for the specific instance-manipulation(s).

HTTP/1.1 226 IM Used
Date: Sat, 06 Apr 2013 21:10:40 GMT
Server: Apache/2.4.4 (Unix)
Content-Length: 500
Content-Type: text/html; charset=iso-8859-1

<title>226 IM Used</title>
<h1 id="IM_Used">IM Used <a class="sl" href="#IM_Used"></a></h1>


That’s it about Http 2xx status codes. In upcoming articles we’ll discuss about next set of codes.


Http Response Codes 1xx & Meanings

Hello friends, as we know that we are in the world of internet where each and every information is accessible from various servers upon requests. This communication mechanism is a complete picture where multiple components are involved to send request to server and get the response to you. You can have a look into the complete flow here.

In this complete flow, Http is one of the most important part which we need to focus upon. Http is meant for hypertext transfer protocol. HTTP is the foundation of data communication for the World Wide Web.

HTTP functions as a request–response protocol in the client–server computing model. A web browser, for example, may be the client and an application running on a computer hosting a website may be the server. The client submits an HTTP request message to the server. The server, which provides resources such as HTML files and other content, or performs other functions on behalf of the client, returns a response message to the client. The response contains completion status information about the request and may also contain requested content in its message body.

There are many type of responses which server can return. As developers we need to have information about meaning of each response code returned from server. Based on these response codes, you can narrow down troubleshooting to get the actual root cause of any issue.

I’ve divided this discussion into multiple parts based on the type of response codes.

So let’s start with the part – 1 where we are going to discuss about all those responses which are like 1xx e.g. 100,101 etc.

Note: http response codes 1xx status codes are only Informative.


This response is just to inform client that it can continue to send remaining request. Server notifies client that it has not rejected its request. Once client receives this response code then client can send remaining request based on this response.

Let’s consider one example:

Assume that we have a client which want to transmit a video file to server. This file length may be high and server may not be able to process. To check if this file length is acceptable by server or not, client sends a request with expect header (Read more about Expect header here ).

Client sends a request with Expect header and waits for the server to respond before sending the message body.

PUT /somewhere/fun HTTP/1.1
Host: origin.example.com
Content-Type: video/h264
Content-Length: 1234567890987
Expect: 100-continue

The server now checks the request headers and may respond with a 100 (Continue) response to instruct the client to go ahead and send the message body, else server will send some error code to reject the request.

If server approves the request and send 100 response code then server must send a final response after the request has been completed.

101-Switching Protocols

In order to ease the deployment of incompatible future protocols, HTTP/1.1 includes the new Upgrade request-header. This feature is part of compatibility. By sending the Upgrade header, a client can inform a server of the set of protocols it supports as an alternate means of communication. The server may choose to switch protocols, but this is not mandatory.

If server choose to switch protocol then it send 101 response header which notifies client that server is ready to switch protocol.

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


The 102 (Processing) status code is an interim response used to inform the client that the server has accepted the complete request, but has not yet completed it. This status code SHOULD only be sent when the server has a reasonable expectation that the request will take significant time to complete. As guidance, if a method is taking longer than 20 seconds (a reasonable, but arbitrary value) to process the server SHOULD return a 102 (Processing) response. The server MUST send a final response after the request has been completed.

Methods can potentially take a long period of time to process, especially methods that support the Depth header. In such cases the client may time-out the connection while waiting for a response. To prevent this the server may return a 102 (Processing) status code to indicate to the client that the server is still processing the method.

103-Early Hints

It is common for HTTP responses to contain links to external resources that need to be fetched prior to their use; for example, rendering HTML by a Web browser. Having such links available to the client as early as possible helps to minimize perceived latency. So there is a new status code i.e. 103 that lets the server send headers early, before the main headers. This helps with optimizations like preloading.

Example from the document:

HTTP/1.1 103 Early Hints
Link: ; rel=preload; as=style

HTTP/1.1 103 Early Hints
Link: ; rel=preload; as=style
Link: ; rel=preload; as=script

HTTP/1.1 200 OK
Date: Fri, 26 May 2017 10:02:11 GMT
Content-Length: 1234
Content-Type: text/html; charset=utf-8
Link: ; rel=preload; as=style
Link: ; rel=preload; as=style
Link: ; rel=preload; as=script

The client can start preloading the CSS and JavaScript before the main headers arrive. This is a nice optimization.
There are various security risks with sending multiple headers to non-conforming clients hence a server might refrain from sending Early Hints over HTTP/1.1 unless the client is known to handle informational responses correctly.


That’s it about http response codes 1xx. In upcoming articles we’ll discuss about next set of codes.


HTTP 1.0 vs HTTP 1.1 – Caching

Hi Friends, as we are discussing about differences between HTTP 1.0 vs HTTP 1.1, I am trying to cover one difference in one article so that it will be easy for us to grasp these. Http 1.1 caching is an important aspect to learn which impacts web behavior.

Previously we discussed about compatibility changes which were done as part of HTTP 1.1.

In this article we are going to discuss about http 1.1 caching changes.


Caching is a technique through which you can preserve few most required resources on the server\client. Once these resources are preserved, whenever any new client request the same resource from the server then rather than process again, server returns with the preserved resource.

This technique gives few benefits.

  1. As server do not need to process again for the same resource, so server performance improves.
  2. As this is preserved resource so there is no need to add network packets in the response. Due to which response size decreases a bit and network latency improved for other requests.
  3. Due to less network congestion, server is able to handle more and more requests which is cost effective solution.

Caching was there in HTTP 1.0 also but it was not at that much mature level so it causes couple of issues.

Caching in HTTP 1.0

The HTTP 1.0 caching mechanism worked well, but it had many shortcomings. It did not allow either servers or clients to give full and explicit instructions to caches. Therefore, this caching was not well-specified. Because of which we had following issues.

  1. Incorrect caching of some responses that should not have been cached. Due to this responses were unexpected.
  2. Failure to cache some responses that could have been cached. This causes performance problems.

Expires Header:

HTTP/1.0 provided a simple caching mechanism. An origin server may mark a response, using the Expires header, with a time until which a cache could return the response.

After above mentioned date time, cache will expire and will not be served to client. It should be validated with origin server.

If-Modified-Since, Last-Modified headers:

A cache may check the current validity of a response using what is known as a conditional request: it may include an If-Modified-Since header in a request for the resource, specifying the value given in the cached response’s Last-Modified header.

Below is the syntax for this header


The If-Modified-Since request HTTP header makes the request conditional: the server will send back the requested resource, with a 200 status, only if it has been last modified after the given date. If the resource has not been modified since, the response will be a 304 (Not modified) without any body; the Last-Modified header will contain the date of last modification. 

Pragma: no-cache header:

The Pragma: no-cache header, for the client to indicate that a request should not be satisfied from a cache.

Every time response will be processed fresh from origin server.

Caching in HTTP/1.1

HTTP 1.1 caching attempts to clarify the concepts behind caching, and to provide more mature mechanisms for caching. It retains the basic HTTP 1.0 caching plus it provide a design with new features and with more careful specifications of the existing features.

In HTTP 1.1, a cache entry is fresh until it reaches its expiration time. Once it expires, it should not be provided in the response but it should not be deleted from the cache also. But it normally must revalidate it with the origin server before returning it in response to a subsequent request. However, the protocol allows both origin servers and end-user clients to override this basic rule.

ETag, If-None-Match Headers:


The ETag or entity tag is part of HTTP caching, which allows a client to make conditional requests. This allows caches to be more efficient, and saves bandwidth, as a web server does not need to send a full response if the content has not changed. 

When a URL is retrieved, the web server will return the resource’s current representation along with its corresponding ETag value, which is placed in an HTTP response header “ETag” field:

ETag: “686897696a7c8745rt5”

The client may then decide to cache the representation, along with its ETag. Later, if the client wants to retrieve the same URL resource again, it will first determine whether the local cached version of the URL has expired (through the Cache-Control and the Expire headers). If the cache has not expired, it will retrieve the local cached resource. If it determined that the cache has expired (is stale), then the client will contact the server and send its previously saved copy of the ETag along with the request in an “If-None-Match” field.

If-None-Match: “686897696a7c8745rt5”

On this subsequent request, the server may now compare the client’s ETag with the ETag for the current version of the resource. If the ETag values match, meaning that the resource has not changed, then the server may send back a very short response with a HTTP 304 Not Modified status. The 304 status tells the client that its cached version is still good and that it should use that.

However, if the ETag values do not match, meaning the resource has likely changed, then a full response including the resource’s content is returned, just as if ETags were not being used. In this case the client may decide to replace its previously cached version with the newly returned representation of the resource and the new ETag.

The Cache-Control Header:

Standard Cache-Control directives that can be used by the client in an HTTP request. There are many variations for using this directive. Below is directives list for request.

  • Cache-Control: max-age=<seconds>
  • Cache-Control: max-stale [=<seconds>]
  • Cache-Control: min-fresh=<seconds>
  • Cache-Control: no-cache
  • Cache-Control: no-store
  • Cache-Control: no-transform
  • Cache-Control: only-if-cached

Below is directives list for response.

  • Cache-Control: must-revalidate
  • Cache-Control: no-cache
  • Cache-Control: no-store
  • Cache-Control: no-transform
  • Cache-Control: public
  • Cache-Control: private
  • Cache-Control: proxy-revalidate
  • Cache-Control: max-age=<seconds>
  • Cache-Control: s-maxage=<seconds>

In upcoming sessions, we’ll discuss about all these directives in details.

The Vary header:

A cache finds a cache entry by using a key value in a lookup algorithm. HTTP/1.0 uses just the requested URL as the cache key. But this is not a perfect model as sometimes response may vary not only based on the URL, but also based on one or more request-headers (such as Accept-Language and Accept-Charset).

To support this type of caching, HTTP/1.1 includes the Vary response-header. This header field carries a list of the relevant selecting request-header fields that participated in the selection of the response variant. If new request exactly matches with the cached version of request, then only cached resource is returned else server does it normal processing to return the resource.

In addition to above headers, there are few more important headers but those are generally used in more complex scenarios. We’ll cover those headers separately e.g. If-Unmodified-Since and If-Match etc.

That’s all about caching. Please note that this is very simple and basic overview about caching changes in http 1.1. There is a long list of changes which are complex. We’ll cover those in another articles.