Category Archives: Web Development

HTTPS Methods and Status Codes

Here’s a curated list of HTTPS methods and status codes for quick reference by web devs:


  • ‘ACL’,
  • ‘BIND’,
  • ‘CONNECT’,
  • ‘COPY’,
  • ‘DELETE’,
  • ‘GET’,
  • ‘HEAD’,
  • ‘LINK’,
  • ‘LOCK’,
  • ‘M-SEARCH’,
  • ‘MERGE’,
  • ‘MKCOL’,
  • ‘MOVE’,
  • ‘NOTIFY’,
  • ‘OPTIONS’,
  • ‘PATCH’,
  • ‘POST’,
  • ‘PRI’,
  • ‘PURGE’,
  • ‘PUT’,
  • ‘REBIND’,
  • ‘REPORT’,
  • ‘SEARCH’,
  • ‘SOURCE’,
  • ‘TRACE’,
  • ‘UNBIND’,
  • ‘UNLINK’,
  • ‘UNLOCK’,


  • ‘100’: ‘Continue’,
  • ‘101’: ‘Switching Protocols’,
  • ‘102’: ‘Processing’,
  • ‘103’: ‘Early Hints’,
  • ‘200’: ‘OK’,
  • ‘201’: ‘Created’,
  • ‘202’: ‘Accepted’,
  • ‘203’: ‘Non-Authoritative Information’,
  • ‘204’: ‘No Content’,
  • ‘205’: ‘Reset Content’,
  • ‘206’: ‘Partial Content’,
  • ‘207’: ‘Multi-Status’,
  • ‘208’: ‘Already Reported’,
  • ‘226’: ‘IM Used’,
  • ‘300’: ‘Multiple Choices’,
  • ‘301’: ‘Moved Permanently’,
  • ‘302’: ‘Found’,
  • ‘303’: ‘See Other’,
  • ‘304’: ‘Not Modified’,
  • ‘305’: ‘Use Proxy’,
  • ‘307’: ‘Temporary Redirect’,
  • ‘308’: ‘Permanent Redirect’,
  • ‘400’: ‘Bad Request’,
  • ‘401’: ‘Unauthorized’,
  • ‘402’: ‘Payment Required’,
  • ‘403’: ‘Forbidden’,
  • ‘404’: ‘Not Found’,
  • ‘405’: ‘Method Not Allowed’,
  • ‘406’: ‘Not Acceptable’,
  • ‘407’: ‘Proxy Authentication Required’,
  • ‘408’: ‘Request Timeout’,
  • ‘409’: ‘Conflict’,
  • ‘410’: ‘Gone’,
  • ‘411’: ‘Length Required’,
  • ‘412’: ‘Precondition Failed’,
  • ‘413’: ‘Payload Too Large’,
  • ‘414’: ‘URI Too Long’,
  • ‘415’: ‘Unsupported Media Type’,
  • ‘416’: ‘Range Not Satisfiable’,
  • ‘417’: ‘Expectation Failed’,
  • ‘418’: “I’m a Teapot”,
  • ‘421’: ‘Misdirected Request’,
  • ‘422’: ‘Unprocessable Entity’,
  • ‘423’: ‘Locked’,
  • ‘424’: ‘Failed Dependency’,
  • ‘425’: ‘Too Early’,
  • ‘426’: ‘Upgrade Required’,
  • ‘428’: ‘Precondition Required’,
  • ‘429’: ‘Too Many Requests’,
  • ‘431’: ‘Request Header Fields Too Large’,
  • ‘451’: ‘Unavailable For Legal Reasons’,
  • ‘500’: ‘Internal Server Error’,
  • ‘501’: ‘Not Implemented’,
  • ‘502’: ‘Bad Gateway’,
  • ‘503’: ‘Service Unavailable’,
  • ‘504’: ‘Gateway Timeout’,
  • ‘505’: ‘HTTP Version Not Supported’,
  • ‘506’: ‘Variant Also Negotiates’,
  • ‘507’: ‘Insufficient Storage’,
  • ‘508’: ‘Loop Detected’,
  • ‘509’: ‘Bandwidth Limit Exceeded’,
  • ‘510’: ‘Not Extended’,
  • ‘511’: ‘Network Authentication Required’

Working around untrusted certificate errors in Express JS

A few very common fatal errors thrown by the request module for express while trying to access data from self-signed web servers are Error: DEPTH_ZERO_SELF_SIGNED_CERT and UNABLE_TO_VERIFY_LEAF_SIGNATURE

This is because of which mandates NodeJS to validate a server’s certificate by default, which needless to say is how things should be in a production environment.

However, more often than none we tend to use self-signed SSL certificates in our development environments or even within internal networks.

Thankfully for such brain-wracking moments, two particular flags come to our rescue. Enter strictSSL and rejectUnauthorized. The way I personally like to use these flags, is to set defaults within my development environments as follows to bypass SSL validation hence, saving the day! 🙂

var request = require('request').defaults({
    strictSSL: false,
    rejectUnauthorized: false

Please do note, that I do not recommend that you ever try this on your production systems without understanding the true implications of what disabling strictSSL and rejectUnauthorized means for you node server. By disabling these, you are essentially telling your server to skip validation of the requested server’s identity, which leaves your application in quite a vulnerable position.

Creating scrollable Charts using Angular-Kendo

Creating Scrollable Charts:

Horizontal scrolling of Charts is not supported out of the box in Kendo UI, however it can be achieved using a bit of custom styling.

Basic steps:

  • Set overflow: auto of the <div class="chart-wrapper">;
  • Set width of the aforementioned div;
  • Set width of the <div id="chart"> to a value higher than it’s parent div width size.

Example piece of code:


<div class="parent-container">
  <div kendo-chart k-options="line" class="chart-container">


.parent-container {
    overflow-y: scroll; 
    width: 1000px;

.chart-container {
    overflow: auto; 
    width: 2000px;

Coding Best Practices – With a tinge of CSS!

For the curious: What made me write this post:

A very good friend of mine called me up today and asked me to go through a web portal that their company is developing to gather some feedback about it. When I opened the page I was quite impressed at first site and everything about the visual styling to the page layout frankly looked quite awesome.

Being a web developer myself, I somehow couldn’t resist the urge of opening up the browser’s developer tools to check out code behind it, and this is where the problems started showing up. As soon as the developer tools window pane opened up eating up half of my screen estate, I noticed the page layout completely fall apart. There was a mess of overlapping texts, visual elements, and what not all over the page rendering the site completely useless.

By instinct I ended up opening the style editor of developer tools to check the CSS to find out where things where breaking, however what I saw was nothing but plain horror for any front-end developer . It had to be one of the most messed up style-sheets I have ever seen! Basically it was nothing but a garbled up mess of style definitions for classes, ids, media queries, etc. What made it even more insane was that there was no homogeneity to the way the document was written, no indentations and to top it all the whole site had the most generically confusing class names that one could ever have nightmares of.

So, I called up my friend to congratulate him about having such a gem of a front end guy work on his team, when I came to know about the most sorry part of the whole story. The person who wrote this code was apparently a man who had quite a large number of years worth of “industry experience” and has been doing front end work since before even I knew what HTML/CSS was!

This is what convinced me to go ahead and post a few simple things about things that one should keep in mind while writing code with a bit of an inclination towards CSS.

For the Restless, Here’s what I want to say:

Here are a few best practices that I personally follow that I’d like to share with everyone:-

  • Always remember that any code that you write has a high probability of being extended or needing maintenance in the long term. 70% of most maintenance woes can be avoided by keeping this simple fact in mind while writing code.
  • As a direct consequence of this, make sure that whatever code that you write is readable even to the most novice coders out there.
  • Adopt good variable naming practices [eg. a variable name “count” is always more desirable than a variable name “i” for a counter variable since it’s name gives a good idea about it’s functionality.]
  • Try and write self documenting code, with enough [read: not too less, yet not too much] comments describing what a certain block of code does, and how it does that. The best way to make sure that the comments are of the perfect length would be to make sure that the comments for a block of around 5-10 lines of code is never longer than 2 lines [of 80 characters each].
  • One of the places which very often make the biggest mistakes in documenting stuff are the CSS files. A CSS file with a spaghetti mixture of ids, classes, etc. is never a good idea.
  • Always try to have a proper document structure for the CSS with logical grouping of style definitions, preferably with an index comment at the very beginning. This helps make the code more readable and thus much more easy to maintain and extend in the long run.
  • Indentation is your biggest friend – It helps make the code more easily readable as well as create a well-structured document format. Indentation makes it dead simple to understand the flow of logic within the program and separated different logical groups from each other by creating well nested content for the document.
  • Lastly, and more importantly before signing off a piece of code as ready for production, be honest to yourself and ask yourself: “Is this the kind of code that I would like to read through and work upon in a few years time when I have forgotten the minutes of the implimentation?”

I sincerely this helps atleast a few people to understand what it is like to write beautiful code and give them a brief idea about how to do so themselves.

%d bloggers like this: