0

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.

0

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.Clear();
HttpContext.Current.Response.Status = "303 See Other";
HttpContext.Current.Response.AddHeader("Location", newLocation);
HttpContext.Current.Response.End();

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

0

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.

**200-OK

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.

**201-Created

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.
E.G.
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>
  <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
  <updated>2003-12-13T18:30:02Z</updated>
  <author><name>John Doe</name></author>
  <content>Some text.</content>
</entry>

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.

202-Accepted

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.

207-Multi-Status

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

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>226 IM Used</title>
</head><body>
<h1 id="IM_Used">IM Used <a class="sl" href="#IM_Used"></a></h1>
</body></html>

 

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

0

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.

100-Continue

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

102-Processing

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.

0

What is Base64 Encoding and how it works

Hello Friends, You might have heard about a term called Base64 encoding here and there. This is also one kind of encoding schema which is worth pointing out.

Today we are going to discuss about Base64 and its usage.

Base64 Encoding

In simple terms, Base64 encoding is used in environments where, “perhaps for legacy reasons,” the “storage or transfer” of data is limited to ASCII characters.

According to Wiki:

Base64 is a group of similar binary-to-text encoding schemes that represent binary data in an ASCII string format by translating it into a radix-64 representation.

When you have some binary data that you want to ship across a network, you generally don’t do it by just streaming the bits and bytes over the wire in a raw format. Because some media are made for streaming text. There may be some protocols which may interpret your binary data as control characters (like a modem), or your binary data could be screwed up because the underlying protocol might think that you’ve entered a special character combination (like how FTP translates line endings).

So to get around this, people encode the binary data into characters. Base64 is one of these types of encodings.

Image data\File data is generally transferred into base64 encoding.

How does it works?

Base64 encoding takes minimum three bytes, each consisting of eight bits, and represents them as four printable characters in the ASCII standard.

Each character in Base64 can be multiple of 3 bytes, these bytes are then grouped into 6 bits. Padding is added if data bytes are not multiple of 3 bytes.

Now let’s see with examples, how it works:

Encode “A” with UTF7 (1 Byte)

I’ve written very simple code to show this with example

static void Main(string[] args)
{
    string myData = "A";
    byte[] dataBytes = System.Text.Encoding.UTF7.GetBytes(myData);
    Console.WriteLine(System.Convert.ToBase64String(dataBytes));
    Console.ReadLine();
}

In first example I am trying to convert “A”. Before discussing how it works, let’s discuss about the output. If I run this code then below will be the output.

base64 encoding single byte output

Now let’s see how this is calculated.

If you do not have idea how to encode decode in c# then you can check this.

In first line of code, I am passing character “A” in variable.

In next line I am using UTF7 encoding to get data bytes for “A”.

base64 encoding single byte code

  1. As we can see that in UTF7 we got 1 data byte i.e. “65”

Binary of 65 = 01000001

  1. As we discussed that data bytes should be multiple of 3 bytes. But our data is having one byte so we need to add 2 bytes of padding.

2 bytes of padding = 00000000 00000000

So total data bytes are: 01000001 00000000 00000000

  1. Now convert above bits to multiple of 6

First 6 bits group – 010000

Second group – 010000

Third group – 000000

Forth group – 000000

  1. Now calculate decimal values of these groups each.

First group – 010000 – 16 (Decimal)

Second group – 010000 – 16 (Decimal)

Third group – 000000 – It is padding so padding symbol is “=”

Forth group – 000000 – It is padding so padding symbol is “=”

  1. Now use below chart to get character related to decimal value.

base64 encoding char set

First group – 010000 – 16 (Decimal) – Q

Second group – 010000 – 16 (Decimal) – Q

Third group – 000000 – It is padding so padding symbol is “=”

Forth group – 000000 – It is padding so padding symbol is “=”

So calculated base64 string is “QQ==”

 

UTF7 Multibyte Data

Let’s consider one example where we have multiple bytes. Change code to use below character.

 

 

I’ve written very simple code to show this with example

Let’s discuss about the output. If I run this code then below will be the output.

base64 encoding multibyte output

 

Now let’s see how this is calculated.

In first line of code, I am passing different language character in variable.

In next line I am using UTF7 encoding to get data bytes.

base64 encoding multibyte code

  1. As we can see that in UTF7 we got 5 data bytes i.e. “43”,”65”,”75”,”73”,”45”. Below are calculated bits

43-00101011

65-01000001

75-01001011

73-01001001

45-00101101

  1. As we discussed that data bytes should be multiple of 3 bytes. But our data is having 5 bytes so we need to add 1 byte of padding.

1 bytes of padding = 00000000

So total data bytes are:

00101011 01000001 01001011 01001001 00101101 00000000

  1. Now convert above bits to multiple of 6

First 6 bits group – 001010

Second group – 110100

Third group – 000101

Forth group – 001011

Fifth group – 010010

Sixth group – 010010

Seventh group – 110100

Eighth group – 000000

  1. Now calculate decimal values of these groups each.

First group – 001010 – 10

Second group – 110100 – 52

Third group – 000101 – 5

Forth group – 001011 – 11

Fifth group – 010010 – 18

Sixth group – 010010 – 18

Seventh group – 110100 – 52

Eighth group – 000000 – It is padding so padding symbol is “=”

  1. Now use above chart to get character related to decimal value.

First group – 001010 – 10 – K

Second group – 110100 – 52 – 0

Third group – 000101 – 5 – F

Forth group – 001011 – 11 – L

Fifth group – 010010 – 18 – S

Sixth group – 010010 – 18 – S

Seventh group – 110100 – 52 – 0

Eighth group – 000000 – It is padding so padding symbol is “=”

So calculated base64 string is “K0FLSS0=”

0

Encoding using C#

Hi Friends, as we’ve discussed about encoding decoding in our previous article, so in this article we are going to discuss how we can implement encoding using c#.

Let’s summarize about encoding\decoding:

Computers doesn’t understand these characters. Computers understand only one language i.e. 0\1. These 0 and 1 are electric signal which used to maintain a state in computer memory. This state can be accessed later on and transformed into desired results.

Every character which we type or see in computer are saved somewhere in form of 0 and 1 e.g. If I type my name “Deepak Gera” then this name will be converted into stream of 0\1 by using some algorithm and then this stream will be stored somewhere in computer.

Later on when I try to access my name then this stream will be read from memory location and will be transformed into characters using the same algorithm which was used previously for transformation.

“The process of transforming characters into stream of bytes is called as Encoding”

“The process of transforming encoded bytes into characters is called as Decoding”

Encoding using C#

Create one console application and write following code in Program.cs file.   

class Program
{
    static void Main(string[] args)
    {
        string myData = "A";
        byte[] encodedData = Encode(myData);
        Console.WriteLine($"Encoded Data: {encodedData}");

        string origData = Decode(encodedData);
        Console.WriteLine($"Original Data: {origData}");
        Console.ReadLine();
    }

    public static byte[] Encode(string text)
    {
        byte[] dataBytes = System.Text.Encoding.UTF8.GetBytes(text);
        return dataBytes;
    }

    public static string Decode(byte[] dataBytes)
    {
        string returntext = System.Text.Encoding.UTF8.GetString(dataBytes);
        return returntext;
    }
}

Above code is having 2 methods. One method is for encoding in c# and another method is for decoding.

As you can see that I’ve used UTF8 encoding schema so when I debug this code, I got 1 byte for character “A”. ASCII code for “A” is 65. If I use UTF7, then also I’ll get the same results as UTF7 is also 1 byte.

encoding using c#

Let’s check another character which takes 2 bytes. “¢” symbol takes 2 bytes in code pages so let’s check this with UTF8 schema. We can see below that this character is taking 2 bytes.

If we encode same character using UTF7 schema then it will convert using symbols from ASCII so it will take more bytes so it is considered less efficient for multi byte characters.

encoding using c#

Same way you can perform encoding using c# using different schemas

ASCII

byte[] dataBytes = System.Text.Encoding.ASCII.GetBytes(text);

UTF-16 (Little Endian)

byte[] dataBytes = System.Text.Encoding.Unicode.GetBytes(text);

UTF-16 (Big Endian)

byte[] dataBytes = System.Text.Encoding.BigEndianUnicode.GetBytes(text);

In little endian machines, least significant byte of binary representation of the multi-byte datatype is stored first. On the other hand, in big endian machines, most significant byte of binary representation of the multi-byte datatype is stored first. You can see more about Big Endian\Little Endian

UTF-32

byte[] dataBytes = System.Text.Encoding.UTF32.GetBytes(text);

 

 

You can check yourself and see how these schema results are differ.

0

Little and Big Endian Mystery

Hello friends, as we’ve already discussed about Encoding and types so let’s now discuss little bit about “Little and Big Endian Mystery”.

Small topic but play important role whenever we talk about data transfer and storage.

What are these Little and Big Endian?

Both are ways to store multi-byte data types e.g. int, float etc.

In little endian machines, least significant byte of binary representation of the multi-byte datatype is stored first. On the other hand, in big endian machines, most significant byte of binary representation of the multi-byte datatype is stored first.

Their difference is similar to the difference between English and Arabic.

English is written and read from left to right, while Arabic from right to left.

Suppose integer is stored as 4 bytes then a variable x with value 0x01234567 will be stored as following.

Big Endian’s Advantages

Easier for (most) human to read:

When examining memory values. This sometimes also applies to serializing/deserializing values when communicating with networks.

Easier sign checking:

By checking the byte at offset 0 we can easily check sign.

Easier comparison:

Useful in arbitrary-precision math, as numbers are compared from the most significant digit.

No need for endianness conversion:

No conversion needed when sending/receiving data to/from the network. This is less useful because network adapters can already swap bytes and copy them to memory in the correct order without the help of the CPU, and most modern CPUs have the ability to swap bytes themselves.

Little Endian’s Advantages

Easier parity checking:

Parity check is easy by checking the byte at offset 0 we can see that it’s odd or even.

Easier for some people to read:

Arabic, Hebrew and many other languages write from right to left so they read numbers in little-endian order. Some languages also read number values in little-endian order (like 134 as 4 units, 3 tens and 1 hundred), so it’s easier to know how big the current digit is and the thousand separator will be less useful.

Natural in computation:

  • Mathematics operations mostly work from least to most significant digit, so it’s much easier to work in little endian.
  • This is extremely useful in Arbitrary-precision arithmetic (or any operations that are longer than the architecture’s natural word size like doing 64-bit maths on 32-bit computers) because it would be much more painful to read the digits backwards and do operations.
  • It’s also useful in situations like in case a computer with limited memory bandwidth (like some 32-bit ARM microcontrollers with 16-bit bus, or the Intel 8088 with 16-bit register but 8-bit data bus). Now the 32-bit CPU can do math 16 bits at a time by reading a half word at address A, add it while still reading the remaining half word at A+2 then do the final add instead of waiting for the two reads to be finished then adding from the LSB.

Always reads as the same value:

It always read same value if reading in the size less than or equal to the written value.

For example 20 = 0x14 if writing as a 64-bit value into memory at address A will be 14 00 00 00 00 00 00 00, and will always be read as 20 regardless of using 8, 16, 32, 64-bit reads (or actually any reads with length <= 64 at the address A like 24, 48 or 40 bits). This can be extended to arbitrarily longer types.

In big-endian system you have to know in which size you have written the value, in order to read it correctly. For example to get the least significant byte you need to read at byte A+n-1 (with n is the length in bytes of the write) instead of A.

This property also makes it easy to cast the value to a smaller type like int32 to int16 because the int16 value will always lie at the beginning of int32.

How to check Endianness?

Execute below program on your machine and you’ll be able to check.

#include<stdio.h>
void byte_order(char *start, int num)
{
    int i;
    for(i=0 ; i<n ; i++)
        printf("%.2x",start[i]);

    printf("\n");
}

void main()
{
    int n = 0x01234567;
    byte_order((char*)&n,n);
}

The above program when run on a Big Endian Machine produces ’01 23 45 67′ as output, while on a Little Endian Machine produces ’67 45 23 01′.

Final Note

Both big and little endian have their advantages and disadvantages. Even if one were clearly superior (which is not the case), there is no way that any legacy architecture would ever be able to switch endianness. You can have a look into more details about Endianness on Wiki.

 

0

What are Encoding Schemas, Types & Differences

Hello friends, Today we are going to discuss about Encoding Schemas, Usage, and Differences. However this is a simple topic but still there are many ways, one can get confused easily with types and pros\cons of various encoding schemas.

We’ll cover basic information about this topic. So let’s move step by step.

What is Encoding\Decoding

We all in this world communicate with each other using some language e.g. English, Spanish, and German etc. Each language has some set of characters which we used to write, read and understand.

Do you think that computer also able to understand these characters in its simple form?

The answer is No.

Computers doesn’t understand these characters. Computers understand only one language i.e. 0\1. These 0 and 1 are signals which used to maintain a state in computer memory. This state can be accessed later on and transformed into desired results.

Every character which we type or see in computer are saved somewhere in form of 0 and 1 e.g. If I type my name “Deepak Gera” then this name will be converted into stream of 0\1 by using some algorithm and then this stream will be stored somewhere in computer.

Later on when I try to access my name then this stream will be read from memory location and will be transformed into characters using the same algorithm which was used previously for transformation.

“The process of transforming characters into stream of bytes is called as Encoding”

“The process of transforming encoded bytes into characters is called as Decoding”

Microsoft says “Encoding is the process of transforming a set of Unicode characters into a sequence of bytes. In contrast, decoding is the process of transforming a sequence of encoded bytes into a set of Unicode characters.

Most popular types of Encoding Schemas

There are many encoding schemas which discovered\evolved time to time based on the requirements and shortcomings of previous ones. Let’s discuss most popular schemas and see how these evolved.

ASCII

ASCII stands for American standard code for Information Interchange. This code is basically used for identifying characters and numerals in a keyboard. These are 8 bit sequence code and are used for identifying letters, numbers and special characters.

ASCII uses 7 bits to represent a character. By using 7 bits, we can have a maximum of 2^7 i.e. 128 distinct characters. The last bit (8th) is used for avoiding errors as parity bit.

Below is the ASCII chart shows mapping of character and its corresponding numeric value. This numeric value is then converted into 7 bit binary value and stored\transferred.

encoding schemas ascii

But 127 characters are not enough to capture complete language so ASCII started using 8th bit also to encode more characters to support language (to support “é”, in French, for example). Just using one extra bit doubled the size of the original ASCII table to map up to 256 characters (2^8 = 256 characters).

Below is the list of extended characters which are now supported by ASCII.

encoding schemas ex ascii

UTF

ASCII Extended solves the problem for languages that are based on the Latin alphabet. But what about the others languages which have completely different character set. How those languages will be encoded.

That’s the reason behind Unicode. Unicode doesn’t contain every character from every language, but it sure contains a gigantic amount of characters.

You can check entire Unicode character set here.

In the Unicode standard, a character is called as “Code Point”. Unicode character set is divided into 17 blocks. Each block is a continuous group of 65,536 (2^16) code points. Each block is called as “Plane”.

There are 17 planes, identified by the numbers 0 to 16.

Plane-0 is called as BMP (Basic Multilingual Plane)

Basic Multilingual Plane:

The first plane, plane 0, the Basic Multilingual Plane (BMP) contains characters for almost all modern languages, and a large number of symbols. A primary objective for the BMP is to support the unification of prior character sets as well as characters for writing. Most of the assigned code points in the BMP are used to encode Chinese, Japanese, and Korean (CJK) characters.

UTF is a super set of ASCII symbols. We need schemas which can transform set of characters into relevant Unicode code points. Below are few popular schemas which are used here.

UTF-7, UTF-8, UTF-16, UTF-32

Let’s discuss these

UTF-7

UTF-7 is an encoding that is used to encode Unicode characters by using only the ASCII characters. This encoding has the advantage that even in environments or operating systems that understand only 7-bit ASCII, Unicode characters can be represented and transferred.

For example, some Internet protocols such as SMTP for email, only allow the 128 ASCII characters and all other major bytes are not allowed. All of the other UTF encodings use at least 8 bits, so that they cannot be used for such purposes.

All those characters which are there in ASCII are converted to its normal ASCII codes. All other characters are encoded and also converted to ASCII characters. The + marks the beginning of such an encoding, the – (or any other character which cannot occur in the encoding) marks the end.

The German word for cheese “Käse”, for instance, would be coded as K+AOQ-se. The ASCII characters K, s and e will be the same, while the ä will be converted to AOQ (other ASCII characters). The beginning and the end of this coding are marked with + and -. Same way decoding happens.

Pros:

Compatibility with ASCII character set.

Cons:

Because of issues with robustness and security, you should not use UTF-7 encoding in 8-bit environments where UTF-8 encoding can be used instead.

UTF-8\UTF-16\UTF-32

Main difference between UTF-8, UTF-16 and UTF-32 character encoding is how many bytes it require to represent a character in memory.

UTF-8 uses minimum one byte, while UTF-16 uses minimum 2 bytes. BTW, if character’s code point is greater than 127, maximum value of byte then UTF-8 may take 2, 3 or 4 bytes but UTF-16 will only take either two or four bytes. On the other hand, UTF-32 is fixed width encoding scheme and always uses 4 bytes to encode a Unicode code point. 

Fundamental difference between UTF-32 and UTF-8, UTF-16 is that former is fixed width encoding scheme, while later duo is variable length encoding.

UTF-8 pros:

  • Basic ASCII characters like digits, Latin characters with no accents, etc. occupy one byte which is identical to US-ASCII representation. This way all US-ASCII strings become valid UTF-8, which provides decent backwards compatibility in many cases.
  • No null bytes, which allows to use null-terminated strings, this introduces a great deal of backwards compatibility too.
  • UTF-8 is independent of byte order, so you don’t have to worry about Big Endian / Little Endian issue.

UTF-8 cons:

  • Many common characters have different length, which slows indexing by codepoint and calculating a codepoint count terribly.
  • Even though byte order doesn’t matter, sometimes UTF-8 still has BOM (byte order mark) which serves to notify that the text is encoded in UTF-8, and also breaks compatibility with ASCII software even if the text only contains ASCII characters. Microsoft software (like Notepad) especially likes to add BOM to UTF-8.

UTF-16 pros:

  • BMP (basic multilingual plane) characters, including Latin, Cyrillic, most Chinese, and Japanese can be represented with 2 bytes. This speeds up indexing and calculating codepoint count in case the text does not contain supplementary characters.
  • Even if the text has supplementary characters, they are still represented by pairs of 16-bit values, which means that the total length is still divisible by two and allows to use 16-bit chars the primitive component of the string.

Note: .NET strings are UTF-16 because that’s an excellent fit with the operating system encoding, no conversion is required.

But why UTF-16?

This is because of history. Windows became a Unicode operating system at its core in 1993. Back then, Unicode still only had a code space of 65535 codepoints, these days called UCS. At that time to cover all these characters two bytes were enough. So at that time UCS-16 was adopted as standard.

To maintain compatibility with windows UCS-2 encoding, UTF-16 was adopted as new standard for in-memory transformations.

UTF-16 cons:

  • Lots of null bytes in US-ASCII strings, which means no null-terminated strings and a lot of wasted memory.
  • Using it as a fixed-length encoding “mostly works” in many common scenarios (especially in US / EU / countries with Cyrillic alphabets / Israel / Arab countries / Iran and many others), often leading to broken support where it doesn’t. This means the programmers have to be aware of surrogate pairs and handle them properly in cases where it matters!
  • Its variable length, so counting or indexing codepoints is costly, though less than UTF-8.

UTF-32 pros:

  • This has fixed length i.e. 4 bytes, which fastens indexing by codepoint.

UTF-32 pros:

  • Takes most memory (4 bytes for all code points) compared to UTF-8/16.

 

UTF-8 is the default for text storage and transfer because it is a relatively compact form for most languages (some languages are more compact in UTF-16 than in UTF-8). Each specific language has a more efficient encoding.

UTF-16 is used for in-memory strings because it is faster per character to parse and maps directly to Unicode character class and other tables. All string functions in Windows use UTF-16 and have for years.

That’s all about encoding now. In upcoming articles we’ll discuss more about encoding implementation.

0

HTTP 1.0 vs HTTP 1.1 – Bandwidth Optimization

Hi Friends, as part of “differences between HTTP 1.0 vs HTTP 1.1”, we are now trying to cover another important difference about HTTP 1.1 – bandwidth optimization.

Let’s discuss about http 1.1 – bandwidth optimization changes.

Bandwidth Optimization

As we know that bandwidth is precious to serve client better and efficiently. If we are not utilizing bandwidth in effective way then it may cause issues while transferring data. Inefficient use of bandwidth increases network latency which decreases site performance.

So we should be very careful to decide mechanism through which we can preserve bandwidth and can use in effective way.

Bandwidth improvement is also part of those key changes which were done in HTTP 1.1.

What was in HTTP 1.0

We were having few issues in HTTP 1.0 due to which there are higher chances to get bandwidth wastage.

Sending large requests to server:

Every server is restricted to accept requests up to specific sizes. If request is having size more than specification then server returns error code. But server returns error code after bandwidth is consumed by this large request. So this entire consumed bandwidth is a waste. There is no way in HTTP 1.0 so that client server can negotiate before sending large request.

Sending large responses to client:

There could be cases where client needs only a part of any big document or image but in HTTP 1.0 there is no way so that server can send only partial data. Server sends the entire data to client. This is another example of bandwidth wastage which could be saved.

Optimizations in HTTP 1.1

As we discussed about cases where client needs only a part of any big document or image. In HTTP 1.0 there was no way to achieve this but in HTTP 1.1 this is possible. Let’s discuss, how we can achieve this.

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.

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. This code prevents HTTP/1.0 proxy caches from accidentally treating the response as a full one, and then using it as a cached response to a subsequent request. In a range response, the Content- Range header indicates the offset and length of the returned range, and the new multipart/byteranges MIME type allows the transmission of multiple ranges in one message.

Range requests can be used in a variety of ways, such as:

  1. To read the initial part of an image, to determine its geometry and therefore do page layout without loading the entire image.
  2. To complete a response transfer that was interrupted (either by the user or by a network failure); in other words, to convert a partial cache entry into a complete response.
  3. To read the tail of a growing object.

Expect and 100 (Continue):

Whenever client sends request to server, it includes Expect header with 100 status code. This request is just to get an approval about if client can continue or not. If server is fine with the expectations of client then it returns 100-continue response and client can continue. But if server does not meet the expectation then it can send any 4xx status code due to which client cannot continue with requests.

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.

A 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, or it will send a 417 (Expectation Failed) status if any of the expectations cannot be met.

This way server is able to save its bandwidth. If this would have been http 1.0 then this request would have transferred to server with entire body. Bandwidth is consumed and then server would have rejected the request which is complete waste of bandwidth.

 

In next articles we’ll discuss about few more differences between http 1.0 and 1.1.

0

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

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:

https://www.slideshare.net/RakeshChaudhary4/advanced-caching-concepts-velocity-ny-2015

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.