HTTP Requests - What are They?

HTTP was designed for the web. It was created to fetch HTML documents and show the response to the client. HTTP stands for Hypertext Transfer Protocol. Think of HTTP as the messenger of the web.  It is based on a TCP/IP protocol. HTTP requests are used to deliver content to your pages from a server. The server is where content is pulled from. The client, which could be your phone, tablet or computer makes an HTTP request which goes through your ISP (Internet Service Provider) and then goes to the server. Once the response is handled, the client is disconnected from the server, so there is never a permament connection between the client and the server. Multiple HTTP requests can be sent at one time, but each one is independent of each other. There is no relation between them unless some type of stored data is sent such as session ID's cookies.

HTTP is a stateless protocol which means that the connection between the client and the server is lost. The server will have no knowledge of the previous request. If information is needed again, a new HTTP request gets sent with the necessary information. Now this doesn't mean that information can't be stored. There are plenty of websites and web apps where a users progress needs to be tracked or form data needs to be stored. This can be achieved through HTTP cookies, server side session data

How does the web work?

Here is a basic example of the life cycle of an HTTP request.

There are three main aspects to making an HTTP request. The client, the ISP and a web server. You are the client and when you establish a connection with the internet, you get an IP address. Every machine connected to the internet has an IP address. If you don't know what yours is, you can Google 'what's my IP' and it'll show you your IP address. So let's say for example you want to purchase something and you go to You send a request to your ISP which does a DNS lookup. It needs to find what the IP address is of the server which is nothing more than a large data repository, that the website is on so it knows where to direct your request. Once the request is sent to the server, the response is sent back to the browser. The browser will show any kind of content. But how does it determine how to parse the data coming back from the server? In the response is a mime type which describes the media type of content being served. For most web pages coming back, this will be a text/html mime type. Once the browser has that information, it knows how to parse the page. Now it gets your index.html or index.php page and from top to bottom it starts to parse the page until it finds another asset such as a JavaScript file or CSS file. 

For each asset that the browser finds, it sends a request to the server to get that asset. For example, if the browser is requesting a CSS file called styles.css, it'll send that request to the server and the server will send back a response with a content type of text/css. Now we know that will be a CSS file and it will be parsed accordingly. In theory, you want to have the smallest amount of CSS files and JavaScript files possible, as each one is considered an asset and will require a new HTTP request. Remember earlier on about how HTTP is stateless and each request is treated individually. After each asset request, the client to server connection is opened, then closed after the response is received, then once a new asset is requested, the connection is re-opened. Since each of these assets require a new HTTP request, this is why a majority of JavaScript files are put into the footer of web pages. This allows the site to render on screen before JavaScript and JQuery are loaded to give a better and faster user experience.

Another way HTTP responses can be sent is through an XHR or XMLHttpRequest which is a JavaScript Object that allows you to send and receive data to the server after the web page has loaded without reloading the web page. This is also known as an Ajax response. I'll cover this more in depth later on in future posts.

A HTTP request contains two things. Headers and possibly a post body. Here is an example of what request headers could look like. In Chrome, search for any website, then right click > Network and click on a name. You can then view the headers and response from  your most recent request. The two most important responses in the headers are the content-type and status. Status is most useful when running JavaScript. Status codes in the 200's is ok, 300's means you are being re-directed, 400's means there was an error content was not found and 500's means something in the server broke. 


Comments (3)

Rated 5 out of 5 based on 2 voters
This comment was minimized by the moderator on the site

Good material, explained in a step by step fashion that ties the information together cohesively. I found this quite helpful as a beginner. Going to read up on your other topics as well. Thanks!

Greg A
This comment was minimized by the moderator on the site

Thank you for the feedback! I'll be adding new material to the site weekly. If there is anything inpeticular you would like to request information or a tutorial on, you can send me a message and I'll do my best to create it!

Richard H.
This comment was minimized by the moderator on the site

Your helpful tips for losing some special effects. We shared various creating Wiki pages beautiful pictures. I would like to thank you for communicating these tips. I decided to try it at home. Simple Tips to Update ...

Jennie Buchanan
There are no comments posted here yet

Leave your comments

  1. Posting comment as a guest. Sign up or login to your account.
Rate this post:
Attachments (0 / 3)
Share Your Location
© 2019 The Code Crypt. All Rights Reserved.