Getting started with HTTP

1. Welcome to this class!: Hello guys and welcome to this course on the HTTP protocol. My name is Alex and I'm a software engineer that has been writing code used within this protocol for the last three years. When I heard of the possibility of creating a course to explain how this works, I was quite eager to develop one. This class will be structured in ten lessons that contain practical steps for you to take in order to understand what the HTTP protocol is and how you can take advantage of this knowledge with coding. A T-wave own pace, I will show you how you can see all the requests made to and from your machine, but not before. I will explain what our HTTP methods return codes handled out of other things. If you are interested in how the Internet works, consider this course for you. There are no other requirements then an Internet connection for the project of this class, it will be extremely practical and it will involve you to follow the steps presented in the course. So you can start on your journey of writing code with a huge block of knowledge under your belt. That is the HTTP protocol. We thought the set, I think we are rarely see you in the first lesson. 2. HTTP Status Codes: Hello guys, and welcome back to discourse. In this lecture, we are going to take a look at the HTTP status codes, also called return codes. These are a fundamental part of web communication. The reason why these data codes are so important is because they are issued by a server in response to a client's request made to that specific server and are the most relevant and short pieces of information about how the request went. The first digit of the status code specifies one of the five standard classes of responses. The message phrases shown are typical, but any human readable alternative may be provided. As I was saying, HTTP return codes have three digits. If these three digits are starting with one, the status you are receiving is informational, meaning that the request was received. If it starts with two, it means that the request was a successful operation, meaning it was successfully received, understood, and accepted. With three, it means a redirection, as in further action, needs to be taken in order to complete the request. If it starts with four, it means that your request had a client error. Something went wrong on the client side and the request contains bad syntax or it just cannot be fulfilled. Lastly, if your three digit code starts with the digit five, it means that your request had a server error. Something went wrong on the server side, as in, the server may be failed to fulfill an apparently valid request. Now let's make our way through the different categories of responses and list some examples for each of them. For informational responses, we have the code 100 with the keyword continue. This means the server has received the request headers and the client should proceed to send the request body. This code is used in situations where the server needs to confirm that it is willing to accept the request. For example, a user may submit a large file for upload to a file sharing service. Think about we transfer, the server responds with 100 continuum to indicate that it is ready to receive this big file and the user can proceed with the actual upload At informational responses. We also have 11 with the keywords of switching protocols. The server is indicating here a change in protocol such as switching from HTTP to web socket. The client should follow this new protocol for further communication. For the next category, we have successful responses, and here we have a very well known code, which is 200, followed by the keyword of okay. This is the most common success code, indicating that the request was successful, the server has fulfilled the request, and the response contains the requested data or information. For example, think about a user accessing a blog post, and the server responds with a 2000 K status code delivering the requested blog content successfully. We also have 21, which means created. This status code indicates that the request resulted in the creation of a new resource. It's often used with post or put requests. You can think about a user that submits a registration form on a website and the server responds with 21 created, hopefully to indicate that a new user account has been successfully created. Also at success messages, we have 24 for no content while the server successfully processed the request. In this case, it has no response body to send back to the client. This is often used for delete requests. If a user deletes a comment on a social media platform and the server responds with 24 no content, it confirms the removal without returning any additional redundant data. Moving on to redirection messages, we have 31 with the keywords of moved permanently. The requested resource has been permanently moved to a new URL. The client should update its bookmarks or links accordingly. You can think about an e commerce website that changes its URL structure and the user attempts to access an old. Product page. The server responds with 31 moved, permanently redirecting the user to the new URL for the product. We also have here the code of 34 not modified. This status is used to indicate that the client's cached version of the resource is still valid and there is no need to download it again. If a user accesses a frequently visited Us website, the server, recognizing that the user's browser cache is up to date, responds with this three or four not modified, indicating that the cached version is still valid and no new data is required. For client error responses, We have 400 which is bad request. The server could not understand the request here due to invalid syntax, missing parameters, or maybe other client site issues. Think about a user that submits a search query with invalid parameters on a travel booking site, and the server responds back with 400 bad requests to indicate that the request lacks essential information. Also, we have 41 for unauthorized. The request requires user authentication. The client that sends this request should provide valid credentials, for example, a user name and password or a token. All of this in order to access the resource. For example, a user attempts to access a private document on a cloud storage service without proper authentication, the server will naturally respond back with 41 unauthorized prompting the user to provide valid logging credentials before getting back the whole response. Lastly, we have 43 forbidden. The server understood the request but refuses to fulfill it. The client's request is valid, but the server has decided not to serve the resource. If a user tries to access an admin only section of a web application, and the server responds with 43 forbidden, it indicates that the user does not have the necessary permissions for that action. You can see that 41 unauthorized is received when you do not provide any credentials and 43 forbidden is received when you provide credentials, but they do not have the necessary permissions attached. We also have 44 not found here. The requested resource could not be found on the server. It indicates that the URL is invalid or that the resource no longer exists. If a user clicks on a broken link that led to a deleted product page on an e commerce website, the server will respond with 44 not found, in order to notify the user that the requested resource no longer exists. For server error responses, we have 500, which stands for Internal Server Error. This is a generic error message and it indicates an unexpected condition prevented the server from fulfilling the request. It's a catch all for server side errors. You can think here about a user that attempts to submit an order on an online store, but due to an unexpected issue on the server, this request results in a 500 internal server error. The user is advised to try again later. Also, we have 52 for bad gateway. This status code indicates that a server acting as a gateway or proxy received an invalid response from an upstream server, often indicates network issues. You can think about a user that accesses a web server or an API that acts as a gateway or another service. The gateway server encounters a problem when forwarding the request to the upstream server, leading to a 52 bed gateway response. Of course, there are a lot more return codes than the ones I enumerated, but in case you encounter one that is not mentioned here, you can Google it and you will be safe to understand exactly what happened with your request. When it comes to the distinction between safe and unsafe HTTP methods, this is not directly related to HTTP status code. Safe methods such as get and hand are designed to have no significant impact on the resources. They are generally associated with successful or informational responses. While unsafe methods like put or post can have a range of responses depending on the specific situation, including success, client, and server errors. As a conclusion for this lesson, HTTP return codes are essential for understanding the results of HTTP requests. They provide information about the success, redirection, client errors, and even server errors associated with a given request. These codes are a fundamental part of web development and troubleshooting, aiding both developers like you and users in diagnosing issues and interpreting the outcomes of their interactions with web services. With all of this being said, I thank you guys for sticking with me up to the end of this lecture, and I look forward to seeing you in the next one. 3. HTTP Request Methods: Hello guys, and welcome back to this course. In this lecture, we will look at a very important concept and that is the HTTP methods. They are often referred to as HTVP verbs, and they are the foundation of communication between clients and servers on the worldwide web. They define the actions that a client can request from a server, ranging from retrieving data to modifying resources. In this lesson, we will explore the various HTTP methods, their practical examples, and their role in web communication, as well as their classification as safe or unsafe, and the key fundamental concept of item potency. To get started, let's firstly get into the C RD acronym. It represents the four fundamental operations for managing data in a database or data storage system. It is commonly used in the context of API's databases and software development to describe the basic actions that can be performed on data. Each letter in the acronym corresponds to a specific operation is for create. The create operation involves adding new data, records, or resources to a database or a data store. It is the action of inserting a new piece of information or a new entity. In the context of an API, this typically means sending a request to create a new resource. The R letter is for read. This operation entails retrieving or accessing data from a database or data store. This operation does not modify the data. It is all about fetching and viewing existing information in API's. This often corresponds to sending a request to retrieve data from a resource. U stands for update. This involves modifying existing data in a database. It is the action of making changes to an existing record, such as updating it, attributes or content. In an API, updating typically requires sending a request to modify a resource. D stands for deletion, and this operation is the action of removing data, records, or resources from a database or a data store. It results in the permanent removal of the specified information in the context of API's. This corresponds to sending a request to remove a resource. The CRUD operations are fundamental in data management and data manipulation. They serve as the foundation for building and interacting with databases, web services, and applications that to perform these essential tasks. When designing API's or working with databases, CRUD operations are a crucial concept for developers like you, as they provide a standardized way to manage data efficiently and accurately. We talked about the CRUD operations first as they intertwined with the HTTP verbs of post, from create, get from read, put from update, and delete, as we will see next. Let's get back now to the HTTP methods. Firstly, we have Get It is used to retrieve the data of a resource that is probably identified by an ID parameter or a general list that contains all the elements of that resource. A few notes on the get requests are that they can be cached and bookmarked. They remain in the browser history and should never be used when dealing with sensitive data. Also, they have some restrictions regarding the length, as I've said when defining them. They are used to only retrieve data and not modify it in any shape or form. Imagine you are using a web browser to access an online news website. When you click on a news article, your browser sends a get request to the websites server asking for the content of the article. The server responds by sending back the requested article, allowing you, the client, to read it. Next we have post. This HTTP method creates a new resource and sends it to be processed by the server. It is not safe and can have side effects on the server or the resource. Some observations when it comes to post methods are that unlike get methods, they cannot be cached, bookmarked, or even in the browser history. And also they do not have any restrictions on the length. Also, the back button, if hit on post request, will resubmit data. Unlike on a Get request where it will do no harm for a real life scenario. Here imagine you're using a social media app and you decide to create a new post. When you click the actual post button, the application sends a post request to the server, including the text and any attached media. The server processes your request, saves the post, and Visible to your followers. Next we have the HTTP method put. This updates a specified resource, meaning that it replaces all current representations of the target resource with the request payload. The main difference when it comes to the post and put methods are the results that you get when repeatedly doing them over and over again. While the put method will always produce the same result as it updates a resource over and over again, the post method will have side effects if trying to double enter the same entity into a system. Imagine you have a personal blog and you notice a typo in one of your published articles. You use a content management system and make corrections to the articles content. When you save the changes, the CMS sends a put request to update the article on the server, ensuring that the corrected version is now displayed. Next, we have delete. This method requests the removal of a resource at the specified URL. It should delete the resource if it exists. Let's say you have an e mail application open, like mail, and you want clutter your inbox by removing an outdated e mail. When you select that specific e mail and click delete, the application sends a deleted request to the e mail server, which removes the e mail from your inbox. As far as the HTTP method patch goes, it is used to apply partial modifications to a resource. It is often used when you want to update only a subset of the resources data. Imagine you are using a task management application to keep track of your work. You realize that due date or a task has changed, so you open the app and update only the due date without altering any other task details. The application will send a patch request to the server which modifies only the due date of the task. Next we have head. Head is similar to Get, but it only requests the headers of the resource. Without the actual data, it is used to check the resources made to data or existence without transferring the entire actual content. This could be used for example, if you would be browsing a shopping website and want to buy product from it. Before viewing the product details, you click on the Check Availability button. The website sends ahead request to the server asking formated data such as product availability, price, and stock information, without loading the entire product page and all of its corresponding details. Lastly, we have the HTTP method of options. This method retrieves information about the communication options available for a resource. It allows a client to discover which HTTP methods are supported by the server. If you're building a web application and you need to determine which actions are supported by a web service, then this HTTP method is crucial for you. The application sends an options request to the service asking what methods are available for specific resources. This helps your application adapt to the services capabilities and know what kind of request it can send to it. These were all the HTTP methods, but there are more key concepts to be understood here. Next, let's look at how we can classify an HTTP method. When it comes to these HTTP verbs, they can be broadly categorized in two. Firstly, safe methods are those HTTP methods that are designed to have no significant impact on the resources they target. In other words, when a safe method is used, it should not cause any changes or side effects on the server or the resource itself. The following HTTP methods are considered safe, et it should not alter the state of the resource or server. It is solely for data retrieval. Also, head it retrieves metadata without transferring the entire content, making it again safe. We also have unsafe HTTP methods. These, in contrast, are HTTP methods that can potentially lead to changes in the state of the resource or the server. They are not safe in the sense that they may have side effects such as resource creation, modification, or deletion. The following HTTP methods are considered unsafe. Post it is not considered safe because it often leads to the creation of a new resource or the modification of an existing one. Put it directly, modifies or creates resources, and therefore it is not a safe method. Delete, it leads to the removal of the specified resource, making it inherently unsafe. Lastly, patch, although it is more targeted than post or put, it can still alter resource data, making it an unsafe method. Let's get now into the very important term of idempotency in the context of HTTP methods, idempotency refers to the property of an operation where performing the same action multiple times has the same effect as performing once. This means that if you send an idempotent request multiple times, the state of the system and the resource it interacts with should remain unchanged after the first request. Let's take a look at some examples of idempotent HTTP methods. The get method, it is idempotent when you retrieve information with a get request. Making the same request again and again should not change the state of the server or the resource you are fetching. The put method as well is item potent. If you use put to update a resource with certain data, sending the same put request multiple times will result in the resource containing the same data each time. Lastly, we have delete here. It is an idempotent method because if you request the deletion of a resource using delete, sending the request repeatedly won't change the fact that the resource has been deleted. In contrast to idempotent methods, non idempotent methods and have different outcomes when repeated. For example, the post method is non idempotent, and repeated post requests for creating a resource can lead to the creation of multiple identical resources. Each request results in a new resource being added. The patch request is typically non item potent as well. Repeating a patch request may update a different resource each time if the changes are incremental or depend on the current state of the resource. Let's get now into why item potency matters. First of all, item potent methods contribute to system resilience. In scenarios where network issues, timeouts, or communication failures occur, item potent operations can be safely retried without causing unintended side effects or data corruption. Item potency is closely related to caching as well. When a response to an item potent request is cached, subsequent requests can be satisfied from the cache, reducing the load on the server and improving performance. Item potent methods ensure predictable behavior. Developers and users can rely on the fact that repeating a request will not result in different outcomes or unexpected changes in the system's state. Lastly, item potency simplifies error handling. When a request fails or is interrupted, retrying doesn't introduce inconsistency or unexpected results. In general, when designing API's, it's essential to choose the appropriate HTTP methods for different operations and document their item potent behavior. This helps clients and developers like you, understand how requests should be handled and what to expect when they interact with the API. With all of this said, I really hope some of the concept presented in this lecture will help you out in the future. And I look forward to seeing you in next lectures. 4. Debugging HTTP Requests: Hello guys and welcome back to this HTTP course. In this lecture, we are going to discuss troubleshooting and debugging HTTP requests. Because in my opinion, at least as a developer, it is very important to understand how to troubleshoot and debug HTTP requests effectively. This skill is essential for ensuring that web applications run smoothly, diagnosing and fixing issues, and delivering a seamless user experience. Http requests are at the heart of every web interaction, whether it's loading a web page, submitting a form, fetching data from an AP I, or even streaming multimedia content. It all starts with an HTTP request. However, these requests are not always error free. Various factors can lead to issues such as server misconfigurations, network problems, client site bugs, or conflict between different components. And this is exactly where this lecture comes in to help you understanding first the common issues that can arise in HTTP requests is the first ineffective troubleshooting. Here we have things like server errors because servers can encounter various errors such as 44, which is the code for not found, 500 for internal server error, or 53, which is service unavailable. These errors may result from misconfigured servers or application issues. We also have errors on the client side. Clients such as web browsers can also generate these errors, like 400 for bad request or 43 for forbidden. These often occur due to issues with the client's request or permissions. Network issues are another factor that can disrupt communication between the client and server. This includes problems like DNS, resolution failures, slow connections, or even complete network outages. Cross origin resource sharing violations can also block requests to a different domain. If not configured correctly, this can lead to security and functionality problems. Lastly, we have SSL and TLS errors. These two layers of security can cause errors. They can occur when HTTP connections are not properly established. These errors can disrupt secure data transfer. Now the most important part of the lesson, debugging HTTP requests. This can be a systematic process to identify and resolve issues effectively. Here are the steps to follow. First, check the browser developer tools. Most modern web browsers offer developer tools that allow you to inspect network requests. You can view requests and response headers, payloads, and error messages. This will happen in Google Chrome, for example, if you press control F 12 or function F 12 if you are on a Mac and then go to the network. Next, you should review the HTTP status codes. These codes in the response provide valuable information about the outcome of the request. Familiarize yourself with common status codes to identify the issue quickly. You can also inspect request and response headers. Pay close attention to request and response headers. They may reveal critical details about the problem, such as missing authentication tokens, incorrect content types, or course issues. Next you can examine the payload data is the request involves data transfer. Inspect the payload anomalies or issues. Mismatched data formats, corrupted data, or missing parameters can cause problems. You should check the server logs as well. Server logs can offer insights into what's happening on the server side. They might reveal errors, performance issues, or, again, misconfigurations. Next, you can verify network connectivity, Ensure that your network connection on the machine from which you are sending requests is stable. Sometimes intermittent connectivity issues can lead to request failures. Lastly, you can use online debugging tools. Several online tools are available for testing and debugging HTTP requests. These tools can help simulate requests, check headers, and validate responses. Here something worthy of mentioning is that if you are developing the web application where the HTTP error is happening, you can again press function F 12 to go into the browser developer tools and then press command P and search for the script where you think that the error is happening, put a break point there, and then go on with the debugging, which you can do by refreshing the page. When it comes to common debugging tools, there are several that can aid in debugging HTTP requests. First, we have of course, Postman. This popular API testing tool allows you to send and receive HTTP requests, inspect headers, and view responses. Next we have Curl. The command line tool is excellent for sending HTTP requests and viewing responses in a terminal. We also have Hitler, which is a web debugging proxy that logs and inspects HTTP and HTTPS traffic between the computer it is installed on and the Internet. Lastly, we have Wireshark, which is a network protocol analyzer and can help you troubleshoot network level issues affecting HTTP requests. When it comes to troubleshooting and debugging, effective collaboration with your team is vital for resolving complex HTTP request issues. Keep thorough documentation of your findings, including error messages, logs, and debugging steps. Share this information with colleagues who may assist in diagnosing and fixing the problem. In conclusion, troubleshooting and debugging HTTP requests is a fundamental skill for web developers, as HTTP is the fundamental protocol of web interactions. Being able to identify and resolve issues quickly and effectively is essential for delivering reliable web applications and seamless user experience. By using developer tools, examining status codes, inspecting headers and payloads, checking server logs, and utilizing debugging tools. Developers like you can diagnose and fix HTTP request issues while keeping their applications running smoothly. With all of this being said, I thank you guys very much for sticking with me up to the end of this lecture. I hope this got you an advantage on troubleshooting and debugging HTTP requests that will come hand in the future. I was X and I look forward to seeing you in the next one. 5. What is HTTP?: Hello guys and welcome again to this HTTP course. In this first lecture, we are going to take a look at the protocol HTTP and discuss what it is and have a basic overview also on how it works getting started, HTTP is a protocol that is mainly used to transfer information in the form of data over the World Wide Web. It takes part of the Internet Protocol suit. It defines commands and services used for transmitting web page data. You can think of HTTP as the foundation of data communication or the worldwide Web. Of course here, hypertext documents include hyperlinks to other resources that the user that sees them can easily access. For example, by a mouse click or by tapping the screen in a web browser. The HTTP protocol is working by a server. Client model. A client here can be a home computer, a laptop, or even a mobile device. The HTTP server is typically a web host running web server software such as IIS. For example, when you access a website, your browser sends a request to the corresponding webserver, and it responds with an HTTP status code. If the URL is valid and the connection is created, the server will send your browser the web page in the standard HTML format, and also along with it, other related files. Another note, worthy of observation here, would be that the HTTP is a stateless request response system. The connection is maintained between the client and the server only for the immediate request. Then after that request is fulfilled, the connection is closed. After the HTTP client establishes a TCP connection with the server and sends it a request command, the server sends back its response and closes the connection. Now, the most common HTTP return codes are amongst those of 200. That means successful request, also known as the web page that you are trying to access, exists. Then we have the 31 status code, which stands for moved permanently, and that's often forwarded to a new URL when receiving this code. Then we have 41, which stands for the unauthorized request, and you basically need authorization to get past this point. If you are trying to access that URL, you can also have a four oh three which is forbidden, meaning that the access is not allowed to the page or directory you are trying to access through URL. And lastly, there is also 500 standing for Internal Server error, and that is often used by an incorrect server configuration. Http also defines commands, and this can be along the lines of get and post, which are used to handle form submission on websites. Encrypted HTTP connections take place over HTTPS, an extension of HTTP designed for secure data transmission. This secure connection is made available by encryption using the SSL certificate. The SSL comes from secure sockets layer and also has a successor nowadays, which is called LS, also known as the transport layer security. These are protocols for establishing authenticated and encrypted links between networks and computers. Although the SSL protocol was deprecated with the release of the first version of LS, it is still common to refer to this related technology as SSL or SSL TLS. Nowadays, the most current version is TLS 13. Don't worry about SSL and HTTPS for now, as this lecture is just an overview and in a later lecture, we are going to take a more detailed approach to the whole HTTPS protocol. The differences between the HTTP and HTTPS and so on, for you to understand in depth these notions. For now, let's just iterate through the notions one more time. In the protocol of HTTP, there are two entities. The client, which is your home web browser, and the actual web server. These two can communicate, more specifically by the client making requests to the web server and the server sending back responses. This communication is structured in chunks, named messages as opposed to a continuous stream of data. In the next lecture, we are going to take a look at HTTP, key components and the structure of it. So if that sounds interesting, I look forward to seeing you guys there. And thank you very much for sticking with me up to the end of this lecture. 6. HTTP Components: Hello guys, and welcome back to the HTTP course. In this lecture, we are going to take a closer look at what exactly are the main key components in the HTTP protocol. I consider this is a key factor in order for us to understand exactly how this whole protocol is working. Now, there are of course, more entities than just the client and the server. In this lecture, we are going to take a look at them either if there are other authorization servers as it is the case in the 00 to that O protocol, or if there are other routers or modems and so on. As a collective, these entities in between the client and the web server that are after all, the main two actors in this HTTP protocol. All the other entities are called proxies. Now, the most important entity of the HTTP protocol is the user, also called the client. This user accesses a website on the Internet and does so by using a tool that is acting on behalf of him and is called a web browser, as you may already know. Or a user agent in specific terms. At this user you can think of as yourself at home operating on your own machine. When you open Google Chrome and you type any URL of Facebook or some social media platform that you are trying to access, you are the user the most important part of this HTTP protocol. Now, in this whole process, each time the browser is the one that initiating the request and never the web server that you make the request to. Now, you may observe that you are the one that made the social media account and you are the one that is checking it. The whole process comes from you, the client, and also the tool that you are using. That is, as I've mentioned before, the web browser from your machine. Now, when given the task to show you the page of the Internet that you requested with your browser. Your browser is given the task to retrieve the HTML document representing this website that you requested from the server. It may even make additional requests if that page has references of other resources that need to be retrieved. For example, you can think of images, PNGs and so on, but the response has all the information and the browser will put it all together in a document of HTML that will be shown to you. Looking now at the other side of this information exchange that takes place in this protocol, we have the web server, an entity which provides the documents requested by the client as a response to its request. What we need to understand here that even though in our lecture we depict this web server as a single entity, in most of the cases nowadays, given the large amounts of data stored by companies in their servers, it will most definitely not be the case. It will not be a single entity behind the web server. You can think about the social media companies data data from all the users that have an account with them. And if the users are in the millions, you can think that it would be pretty impossible for all the data to be kept on a single machine. The server that we are talking about that hosts all the information from the users is actually made up of an abundance of server machines. So if you ever saw company warehouses where they store their servers, may be in movies or you can just search on the web for servers, it will show you those huge rooms full of web servers. So then you will know what I'm talking about. They share in between them the information they store. So they share and balance all the load that they have in between them. This multitude of servers can furthermore make requests to databases that are remote in order to provide the final document that is being requested by the client. And in that database, that might be some other information that they can interrogate regarding either users or some other related field to them. The last actor in this protocol are the actual proxies which are, as I have mentioned before, numerous other machines that transmit along the messages sent by these two main actors, the client and the server. These proxies can be either non transparent or transparent. Non transparent means that they can alter it, and transparent means that they are just forwarding and they are not altering it in any shape or form if they alter it, So they are not transparent. They can do a lot of things like filter it, cache it into your browser. Or even balance the request the client made by allowing different servers to start to serve different parts of the request. So these are the key components and the main actors that are available in the HTTP protocol. In the next lecture, we are going to take a closer look at the whole HTTP flows, how this protocol is exactly working step by step. Thank you guys for sticking with me to the end of this lecture, and I really look forward to see you in the next one. 7. The HTTP Workflow: Hello guys, and welcome back to this HTTP course. In this lecture, we are going to take a closer look at the HTTP workflow to understand exactly how this protocol works. We can talk about the workflow that takes place when a client is making a request towards the web server in order to better understand the HTTP protocol. Firstly, as I've said, the client would open a new connection or maybe re, use an opened one to the webserver. This connection can be of type TCP and will be used, as you may have guessed, to make the actual request to the server. As you can see here, again, the client is the one that initiates the whole workflow as we discussed in a previous lecture. The next step is to send the HTTP message, which specifies the resource you want to retrieve as the client, meaning the web page that you are trying to get access to. Once you get a response from the web server, your browser will read it and parse it into an HTML document that will be human readable and aesthetic for you to look at. Lastly, the connection can be closed or used. Furthermore, for other such flows as the one just mentioned, of course. Now when thinking about it, an observation here can be that this flow can be slightly different if we are familiar with the concept of HTTP pipelining and what HTTP pipelining means. And thus it's that it permits the client to make multiple requests to different servers without actually having to wait first for the previous responses. Because this process was taught as linear before. But HTTP pipelining finds a workaround for that whole thing. This was a broad overview of the HTTP workflow. In the next lecture, we are going to discuss what is a URL and later what its exact structure is. If that sounds interesting, I look forward to seeing you guys there. Thank you very much for sticking with me to the end of this lecture. 8. Caching: Hello guys, and welcome back to discourse on the HTTP protocol. In this lecture, we are going to talk about a fundamental strategy for optimizing the performance of a web application, and that is caching. This involves storing frequently accessed data and resources to reduce the need for redundant data retrieval. Resulting in faster load times, improved user experiences, and reduced server load. When it comes to web performance optimization, caching plays a key role. And it's a concept that every web developer should understand. But before understanding it, let's talk about the need and importance of caching. Web applications rely on the transfer of data between clients that are usually web browsers and servers. We already talked about this whole flow in a previous lesson. Each request for a resource such as an HTML page, a Javascript file, or an image, necessitates a trip from the client to the server and back. The time it takes. This round trip can significantly impact the user's perception of a website's speed and responsiveness. Caching addresses this challenge by storing copies of resources in various locations, reducing the need to fetch the same data repeatedly. It accelerates the delivery of content to the user and minimizes the load on servers. Caching can occur at different levels within the web architecture. From the client side to intermediary servers and content delivery networks, also called CDNs. Let's take a look now at the types of caching that are out there. First and foremost, we have browser caching. Web browsers maintain their local caches, where they store resources like style sheets, images, and scripts. When a user revisits a website, the browser can retrieve these resources from its cache, saving time and also bandwidth. You can think of an image of a webpage and it is cached by the user's browser. When the user navigates to another page on the same site, the image is loaded from the local cache, reducing the need for a server request. The second type of cache is called CDN caching, or content delivery network. Cdns are distributed networks of servers strategically placed in various geographical locations. They cache and serve content from locations close to the user. By storing and delivering content from H servers, CDNs can significantly reduce latency and improve the load times that the user will experience. A website uses a CDN to distribute its images. Let's say when a user in Europe accesses the site, the images are delivered from a nearby CDN server rather than the origin server reducing the load time. Third, we have proxy server caching in corporate networks. Proxy servers are often employed to cache frequently accessed external websites. This not only improves performance, but also conserves bandwidth by reducing the amount of data fetched repeatedly from external servers. As an example, a company's proxy server caches frequently accessed external websites, enhancing performance and for more than that, saving bandwidth. In HTTP, there are cache headers, SCTP, the protocol underpinning. The worldwide web includes several caching headers that instruct clients and intermediaries on how to cache and validate resources. These headers are crucial for controlling and optimizing the caching of web resources. These headers are just like the other headers that we talked about, authorization headers and so on, but they are called Cache control tag and last modified, The Cache control header defines directives for caching. Such as max H to set the maximum time a resource is considered fresh. An entity tag, represented by the tag header, is a unique identifier for a resource. When a resource changes, the tag changes, allowing clients to check if the resource is still valid. The last modified header indicates the last modification time of a resource. This helps clients validate whether their cached copy is still current and relevant. When it comes to caching, there are several strategies that developers might apply. The first is called cache busting, And it is employed when resources change frequently. Developers can Bund version numbers or unique query parameters to resource URLs, forcing browsers to fetch the latest content. Next, you can leverage browser caches. Developers can optimize resource URLs and set appropriate cache control headers to maximize the benefits of browser caching. Lastly, you can use CDNs. Content delivery networks are highly effective for uploading server resources and delivering content for nearby servers, thereby improving performance. There are quite a few benefits of caching and performance optimization. They include reduced latency because caching significantly reduces the time it takes to load resources, resulting in faster user experience. Also, they minimize server load by serving caching resources. Servers are relieved of the burden of handling repeated requests for the same client. You also will have bandwidth savings. Caching conserves bandwidth by reducing the amount of data transferred between servers and clients. We also have here improved user experience because faster load times and more responsive applications enhance the user experience and satisfaction. While caching and performance optimizations are highly advantageous, there are challenges and considerations to keep in mind while implementing it. First, you need to pay attention to user experience. Striking a balance between security and user convenience is essential here. Complex caching strategies can sometimes deter users. You also need to keep in mind the implementation complexity properly. Implementing caching, optimizing resource URLs and configuring headers require careful planning and consideration. In summary, caching is a predominant technique for optimizing performance with HTTP. It reduces latency, conserves bandwidth, and enhances the user experience by leveraging various types of caching, caching headers and cache control strategies. Web developers can create fast and responsive web applications that meet the demands of modern web users. In a world where web performance is a critical factor in the success of applications like the one we live in nowadays, mastering the art of caching is indispensable. It's a skill that can transform a sluggish website into a lightning fast, responsive platform, satisfying users and reducing the load down servers. You might find that on your website and I look forward to hearing your guy's experiences as the Internet continues to grow and evolve. The role of this catching in performance optimizations remains as major as ever. But with that being said, I thank you guys for sticking with me up to the end of this lecture. I really hope you got something out of it, and I look forward to seeing you in the next one. 9. Cross Origin Resource Sharing: Hello guys and welcome back to this HTTP course. In this lecture, we are going to talk about cross origin resource sharing. This is a very important security feature of modern web applications, allowing for controlled access to resources from different domains. In an era where web applications interact with various services and API's across the Internet course plays a pivotal role in maintaining security while enabling cross origin data sharing. In the early days of the web, browsers enforced a strict same origin policy. This meant that web pages could only make requests to the same domain from which they were loaded. While this policy was essential for security, it became a significant limitation as web applications evolved. Modern web applications, on the other hand, often require access to resources hosted on different domains. This includes loading funds from Google Images scripts and data from third party servers and API's to address this limitation and enable controlled cross origin requests. Course was introduced as a security feature. Course allows web servers to specify who can access the resources and under what conditions. It is part of the HTTP protocol and it works by adding HTTP headers to responses sent by web servers. These headers convey the servers policies regarding cross origin requests. Let's take a look now at the key components. Of course, first we have origin. Which term refers to the combination of protocol domain and Port that a web page was loaded from. For example, Htp, example.com is an origin, while Http example.com and Http sub example.com are different origins. Next we have HTTP headers. Course uses these to communicate permissions for cross origin requests. The most critical headers are the origin header which is sent by the client to indicate the origin of the requesting page. Access control allow origin header set by the server to specify which origins are allowed to access its resources. Access control allow methods. Header specifies the HTTP methods get post, put, delete permitted for cross origin request. And access control allow headers which lists the HTTP headers that can be used in the actual request. Now that the headers are out of the way, let's take a closer look at the course process and what steps it actually involves. The first step is the preflight request. When a web page makes a cross origin request with certain conditions, for example, custom headers or credentials, the browser sends a preflight request, meaning an HTTP options request, to the target server. This preflight request asks for permission to make the actual cross origin request. Next, the target server responds to the preflight request with appropriate course headers. If the server approves the request, it includes headers like access control allow origin access control allow methods, and access control allow headers. Lastly, if the server's response to the preflight request is positive, the browser sends the actual request to the target server. The server may include course headers in the response to indicate whether the cross origin request is allowed. I chose to talk about course in this lecture because it is essential in various real world scenarios. You can think about third party API's here. Web applications often integrate third party services and API's for various functionalities such as social media sharing, payment processing or mapping services. Course allows these integrations to occur securely. Websites may need to load resources like fonts or scripts from content delivery networks or serve data from remote servers. Course ensures that cross origin data sharing is safe and control. Single sign on and authentication. Many identity providers implement course four, single sign on solutions. It enables a seamless and secure logging experience even if the identity provider resides on a different domain. Lastly, course is also a fundamental part of web security. By allowing servers to define which origins access their request, it helps prevent unauthorized cross origin requests. While Course enhances websecurity, its implementation should be approached with care because firstly, misconfigured course policies can inadvertently open security vulnerabilities. So it is very important to validate and test course configurations thoroughly. Also, not all browsers fully support course. Some older browsers may not handle it correctly or have limitations. Developers must be aware of these limitations when using course. Preflight requests add an extra round trip to cross origin requests, potentially impacting performance. Minimizing preflight requests is crucial for efficient applications. With all of this being said, cross origin resource sharing is an integral part of the modern web security and functionality. It allows web applications to access resources and services from different domains while maintaining controlled and secure interactions. Developers and server administrators need a solid understanding, of course, to ensure that their web applications can leverage the full potential of cross origin requests while protecting against security threats. Thank you guys very much for sticking with me up to the end of this lecture. I hope you got something out of it and you will be using cross origin resource sharing in your future HTTP requests. I was Ox and I look forward to seeing you in the next lecture. 10. What is an URL?: Hello guys, and welcome back to this HDDP tutorial. In this lecture, we are going to discuss URLs and what are they exactly? A URL acronym comes from the Uniform resource locator. A URL is nothing more than the address of a resource on the World Wide Web. Of course, this resource can be an actual Web page, an image, or any other type of data that put together can be found on the Internet. An observation here is that each value of the URL points on the worldwide web to a unique resource. Such resources can be an HTML page, a CSS document, an image, and so on. They can even be a Json aggregate that when you open, just contains data in between braces. Some of these might be moved or removed. Hence, the Internet is moving so fast nowadays. If that is the case, it might point you straight to a four or four not found HTTP return code, don't worry about return codes. We will have a future section that will be entirely about them and we will discuss them in detail. The way we would access a URL would be to type it into our browser bar and hit Enter. What would happen in the back end of this process that the basic user doesn't know about and doesn't know, basically how it works would be that UR browser, so the user's browser would make a request at the server specified in the URL to retrieve exactly the information specified in the path of that URL. We can see that these URLs are a tool that makes the request to the server possible to us from our local browsers. Thus, they are very useful. Now, depending on the context we are in, there exists only two types of URLs that are classified as absolute URLs and relative URLs. The difference is pretty subtle between these two, but it deserves to be known as, it is a pretty basic concept that you might run into If you get into web development or just enter an F 12 on Google Chrome and try to read the resource of a web page, You might run into this concept. And it is better to have it covered in order for you to understand it deeply when you run into it. An absolute URL is best used when having no context. For example, in the home page of our browser. Absolute means that you need to specify the full path to the request you are making. Now, on the other end of the spectrum when it comes to relative URLs, if an URL is used inside of an HTML document, for example, you can just specify the relative path from where you are and it will now have to get you there. This can happen because the browser at that point has the documents URL that you are at and can use that to fill in the void of the relative path that you are entering. It can use that as an intermediate point to get you where you want to go relative to that point. If you see a path that starts with slash, the browser will put the remaining path after the slash relative to the path are at at that point, meaning after it. And we'll get you to the chosen destination if it is a valid one. That is why the relative URL naming was picked. When thinking about it, URLs are a very straightforward, human readable way in which we can fastly and also simply navigate the Internet without too much technological knowledge. Furthermore, given the lack of experience of most users of the Internet, the semantic property of the URL's should be kept as a good practice in order to maybe maintain this clarity in manipulating the paths of requests by the average users. In the next lectures, we will take a closer look at the exact key elements in the structure of a URL and decompose it to see what each of them do in detail. If that sounds interesting, I look forward to see you guys there. Thank you very much for sticking with me up to the end of this lecture. 11. The structure of an URL: Hello guys, and welcome back to this HTTP tutorville. In this lecture, we are going to take a closer look when it comes to the structure of an URL. Something you may be never thought about as you just wrote it in your home browser bar. But these URLs actually have a structure, and each part of them means something. As for when you put them together, they can take us exactly to where we want to go, maybe a specific part in an HTML document from the web that the server hosts. A URL is composed, as I've said, from different parts, and some of them are mandatory, whereas others are optional. The first part of a URL is the scheme of it. This indicates the protocol that the browser must use, request the resource, usually for websites, the protocol is HTTPS or HTTP. Addressing web pages requires one of the two. This is basically pretty straightforward, and you might have seen the scheme into some URLs that you have wrote, or maybe if you have clicked on the URL of the web page that you are now on, you can see that starts with HTTP or HTTPS. I don't think that is strange to you at all now, you just know more about the naming of it. Next after the scheme, we have the authority part which is separated from the scheme by a character pattern, which is the column and then two slashes. In this authority, we have the domain name, for example. That might be www.thenameofyoursite.com This is the domain, the actual address that you are on right now. It might include even the port, even though this is not very usual as we will see why in a moment. And these two are separated again by a column. So it would go like so site.com column. And then the Port 88 maybe. Now the domain indicates which web server is being requested, as you see on your day to day life when you write W and then the website that you are trying to access, that web server is being requested. Now the Port indicates the technical gate as to speak, used to access the resource on the web server. It is usually omitted if the web server uses the standard ports of the HTTP protocol. That's why we almost never see it. The web server almost always use the standard ports of the HTTP protocol. As for myself, I rarely saw any port after the domain. Now after the authority part in the structure of a URL, it comes the path of the resource on the web server. Now, in the early days of the web, a path like this represented a physical location on the web server. But now it is mostly an abstraction handled by web servers without any physical reality whatsoever. This path that we are talking about here might be some slashes that indicates, for example, the user, then the ID of a specified user, and then again, some fact about that user may be its information page. So each of these keywords are separated, as I've said, by slashes after the authority, and they point to a very specific location on that webserver. So it comes with additional information. Even though these are the main parts, we can also have parameters. They are a list of key value pairs separated with the end symbol. This might come up in URLs pretty often as well, and the web server can use those parameters to add extra staff between returning the resource. Lastly, we might have an anchor. And this represents a sort of bookmark inside the resource, giving the browser the directions to show the content located at that bookmark spot on an HDML document. For example, what an anchor would do is that the browser would scroll down automatically to the point where the anchor is defined. And on a video or audio document in the browser, it will try to go to the time that the anchor represents. It is worth noting that the part after the H t is also known as the fragment identifier, and that's basically the syntax of an anchor. This was pretty much the structure of a URL in detail. I hope you guys got something out of it. And from now on, each time you enter URL, you are going to very well be able to separate each of its parts in your head and understand the naming of each one, and more importantly than that, what each of them does. Now in the next section, we are going to talk about a process that is called URL encoding, which is pretty interesting and useful when it comes to the Internet. So if that sounds interesting, I look forward to seeing you guys there. Thank you very much for sticking with me up to the end of this lecture. 12. URL Encoding: Hello guys, and welcome back to this HTTB course. In this lecture, we are going to discuss the URL encoding process. What it is, why, and when it is useful when it comes to URL encoding, also known as percent encoding. What this whole process does is that it converts characters into a format that can be transmitted in URLs over the World Wide Web. How it does this is by basically processing the G character set. At this point, you might ask, what's the point of having this encoding? Well, it is necessary because more often than not, the URLs have inside them characters that are not inside the G set and need to be converted to that format in order for that specific URL to work when entering into a web browser. The whole way this encoding works is pretty simple and straightforward. For each character that is not an SG character, it is being replaced by a percent sign followed by two hexadecimal digits. This means that for each character that is not an Asch character. It basically maps that character to a three character structure out of which the first one is always the percent, and the next two are hexadecimal digits. Now for the spaces in particular, if you thought of that, they are also not permitted either inside of a URL. And they are replaced in the URL with the plus sign if you ever tried to represent them. There are on the Internet entire tables where you can see what each character is mapped to when it comes to the URL encoding. Or you have an even simpler approach than that. If you fall into the situation of wanting to encode a URL out of your non Asch text. There are websites like URL Encoder.org and if you paste UR text there, it can automatically encode it as URL encoded for you. So this is a pretty basic and straightforward process that is very simple to understand, but it's key for you to know that it is used in order to write pretty much anything in a new RL that might not otherwise have been permitted to be there. Thank you guys for staying with me up to the end of this lecture. In the next one, we are going to look at the HTTP session and also cookies in order to furthermore better understand this protocol. So if that sounds interesting to you, I look forward to see you guys there. 13. Sessions and Cookies: Hello guys, and welcome back to the HTTP tutorial. In this lecture, we are going to discuss the HTTP session and also the cookies that are available here in order to better understand this protocol and how it works. The way HTTP sessions work is by using these things called cookies and also cryptographic techniques in order to maintain date without storing as much data on the server. When presenting a dynamic web page, the server sends the current state data to the client, meaning the web browser, in the form of a cookie. This what a cookie is, the client saves this cookie in memory that he received or on disk. This way the web server doesn't need to. With each successive request, the client sets the cookie back to the server. The server uses the data to remember the state of the application for that specific client and also generate an appropriate response. This mechanism can work well in almost all contexts, but there are a few exceptions you may have seen when entering a new website that it requires you to accept all cookies. This is what it means. It will send you parts of the information so they don't have to store it on their web servers. Information regarding the session that you are on. And information about it though, if you click on that website later, it will know where to take you from. However, data stored on a client, meaning on you, is vulnerable to use client side sessions where confidentiality and integrity are required. The following must guaranteed. We need to have confidentiality. Data, integrity and authenticity. Confidentiality comes from the fact that nothing apart from the server should be able to interpret the session data, meaning no third party or hacker. The integrity means that nothing apart from the server should manipulate the data accidentally or maliciously. And the authenticity means that nothing apart from the server should be able to initiate valid sessions. Now to accomplish these three properties and to make sure that they are respected, the server needs to encrypt the session data before sending it to the client. And modification of such information by any other party should be prevented via this cryptographic means. Transmitting the state back and forth with every request is only practical if the size of the Coke is small. In essence, client side sessions trade server disc space or the extra bandwidth that each web request will require. Moreover, web browser limit the number and size of cookies that may be stored by a website to improve efficiency and allow for more cessation data. The server may compress the data before creating the cookie, decompressing it later when the cookie is returned by the client. This can work with compressions tools such as Win Sip or Seven P programs that you guys might be familiar with. By making the cookies too large in size, the tradeoff would no longer be worth it, as the bandwidth to send it would be obviously huge. This is about the HTTP session, how it is improven by cookies. I hope you guys got something out of this lecture. In the next one, we are going to look in detail at all the HTTP request methods, See what they are, what they do, and how they can be useful on our journey to better understand the HTTP protocol. If that sounds interesting, I look forward to seeing you guys there. Thank you for staying with me to the end of this lecture. 14. Web Sockets: Hello guys and welcome back to this course on the HTTP protocol. In this lecture, we are going to take a look at web sockets. They are very important in the real time communication when it comes to the HTTP protocol. In the modern landscape of web technology, user expectations for real time communication have reached new heights. As you can see, all around you weather is chatting with friends on Whatsapp, monitoring life data, or collaborating with colleagues at work. The demand for instant and seamless interaction on the web has never been greater. To meet this demand, web developers in general turn to Web Sockets, a technology that facilitates real time communication over the HTTP protocol. In this lesson, we will delve into the world of web sockets. And how they enable real time communication without the need for constant HTTP requests. They really are an essential part of this protocol. But before that, let's take another look at the HTTP request response model that we already talked about. Just refresh on it. Before we explore web sockets, it is essential to understand the foundation upon which they operate. The hypertext transfer protocol or foreshort. Http has long been the backbone of the world wide Web, serving as the mechanism for exchanging data between clients, typically web browsers and servers. In the traditional HTTP request response model, the client sends a request to the server which processes the request and sends back a response. While this model works well for many web interactions, it has limitations when it comes to real time communication. In the traditional HTTP model, a new request is required for each interaction between the client and the server. This means that to retrieve new data or messages, the client must repeatedly send requests, resulting in a series of back and forth exchanges. This approach is not well suited. Real time applications where data needs to flow continuously and instantaneously enter web sockets. They were introduced as a solution to the limitation of traditional HTTP. They provide a full plex bidirectional communication channel over a single long lived connection with web sockets. Both the client and the server can initiate communication independently. This means that data can be pushed from the server to the client, or vice versa, without the need for a new HTTP request each time as it was the case before. Now let's look at the key features of web sockets and also the main reasons why you should consider implementing it in your own applications. First, we have persistent connection. Web sockets maintain a persistent connection between the client and the server. Once the connection is established, it remains open, allowing data to flow continuously without the overhead of opening and closing connections for each interaction. Secondly, we have low latency, real time communication demands. Low latency, and web sockets deliver on this front. Since the connection is always open, data can be transmitted with minimal delay, making web sockets ideal for applications where instant updates are essential. The third key feature of web socket is the lightweight protocol. The Web socket protocol is designed to be lightweight, reducing the overhead of data transfer. This efficiency contributes to the speed and responsiveness of real time applications. Lastly, we have cross origin communication, which is supported by web sockets, meaning that clients can connect to web socket servers on different domains. This makes it suitable for various use cases, including chat applications and live data feeds. Now we are going to take a look at some real world use cases just in order for you to better understand the entire websocket concept. The advantages of web sockets are evident in various real world applications. For the first scenario, let's consider chat applications. These benefit from the instant messaging capabilities of web sockets. Users can exchange messages in real time without the need to refresh the page continuously. Here you can think about your favorite chatting application, whether it's on mobile or on web. Next we have online gaming. These often require real time updates such as player movements and game state changes. Web sockets enable the seamless synchronization of game data among players. Also, if you are investing. You might think about the stock market and financial platforms. In financial services, real time data is critical. Stock market platforms use web sockets to provide live stock prices, market trends, and trade executions to traders. Lastly, collaboration tools like shared whiteboards and document editors rely on real time updates to ensure that all participants see the latest changes instantly. When it comes to implementing web sockets, both the client and server need web socket support. Java Script through the web socket API is commonly used on the client side. Server side frameworks and libraries like no JS with the YS library or pattern with web socket enable this websocket support on the server side. This is a very good starting point of libraries to take a look at if you already have a client server situation that you want to implement web sockets at. While web sockets offer a powerful solution for real time communication, there are some challenges and considerations. First, we have scalability. Handling a large number of web socket connections can be challenging. Load balancing and efficient connection management are crucial for scalable web socket applications. Next, we have firewall and proxy issues. Some networks and security setups may restrict web socket traffic. In such cases, web socket connections might need to be tunneled through HTTP or other protocols. Or you might even implement a fallback solution just in case your implementation of web socket will fail. Third, we have security enable the security of web socket connections is vital. Implementing secure web socket connections, which are double YSS, and validating data to prevent security vulnerabilities is essential. In summary, web sockets have revolutionized real time communication on the web by overcoming the limitations of traditional HDDP. They provide a low latency by directional connection that serves as the backbone of numerous real time applications from chat platforms to online games and collaborative tools. Web developers equipped with web socket knowledge are royal position to create the next generation of real time web applications that meet the growing demands of users for instant and seamless interaction. Thank you guys for sticking with me up to the end of this lecture. I really hope you've got something out of it. And websockets will be from now on a concept that you will thoroughly understand. I look forward to seeing you in the next lesson. 15. HTTPs: Hello guys, and welcome back to the HTTP course. In this lecture, we are going to discuss the HTTPS protocol, what it does better than the HTTP, if we should use it and also understand at a basic and even more than that on a more advanced level, how it works. Getting started with it, the HTTPS protocol and acronym stands for the hypertext transfer protocol that comes from secured. It's pretty much the same thing as HTTP, but this one has the S and the secured keyword attached to it. And going over the main security problem with the HTTP protocol that we talked about up to this point is that the information that flows from server to client is not encrypted at all. Furthermore, the problem with this lack of encryption is that it can be seen by anybody exactly in the shape that it has. Which means that, of course, it can be easily stolen, but also replaced by a hacker or a third party that is assisting to this exchange, he can intervene in it. The HTTPS protocol remedy this by using an SSL certificate. The SSL acronym comes from Security Sockets Layer, and this certificate helps create a secure encrypted connection between the web server and the client browser. Thereby, it furthermore protects sensitive information from being stolen as it is transferred between the server and the browser. Encrypting this information means that it is mapped to some other shape that a third party or attacker cannot understand, and furthermore, even see it, access it, or steal it. The most important difference between the protocols of HTTP and HTTPS is obviously the SSL certificate. In fact, HTTPS is basically an HTTP simple protocol that we talked about up to this point with just some additional security layer, which is very important. However, this additional security can be extremely important, especially for websites that store sensitive information for their users, such as credit card information. For example, if you bought something on a website, you might have seen that or just your password. So if you do not see a lock in the left of the URL and you're trying to access your account by entering your password or trying to buy something which your credit card details. You should just stop because it is not safe and your data might be stolen from an attacker that is seeing this process. Now, the SSL certificate encrypts the information, as I've said, that users supply to the site, which basically means that it translates the data into a code. Even if someone manages to steal the data being communicated in between the server and the recipient, they would not be able to understand it thanks to this encryption that the S cell certificate applies to it. Furthermore, in addition to applying this extra layer, HTTPS is also secured via the TLS protocol. Now the TLS protocol and acronym comes from the transport layer security. And what it does, it helps provide data integrity which helps prevent the transfer of data to being modified or even corrupted. Also another thing that it does, it provides authentication that proves to the users that they are actually communicating with the actual websites. This means at the end of the day, that the third party cannot come and change the content that is transmitted in between the client and the server. That is very important, users can identify whether a site is using the HTTPS protocol by the web address, the very first part of the web address, or the URL as we saw in prior lecture, that is called the authority before the start of the main name. That part right there indicates whether the site is using HTTP or the HTTPS protocol. You should just look at your URL and see that. Or you can also check the lock that is present in the left part of the URL. That will also tell you if you are accessing a page that is secured with the HTTPS or not. Now, to make a quick recap, the main difference between the HTTP and the HTTPS protocol is simply the presence of the unnecess certificate. Http does not have the SSL certificate and the HTTPS has it. That assessor certificate encrypts your information so your connection are secured and the information that you're transmitting cannot be stolen or modified by a third party or hacker. This was about it with the HTTPS protocol. Dps is obviously a protocol that is preferred nowadays and is almost always implemented on web pages. Furthermore, if you are into web development and you are trying to create a website, I highly suggest that you use this more secure protocol, especially if you are trying to get any sensitive data from the users. So this protocol is going to make you less susceptible to a text from eventual hackers. Thank you guys very much for sticking with me up to the end of this lecture. In the next one, we are going to take a look at some very useful tools with which we can see the actual HTTP requests that are made from our machine to other web servers and capture them to see what information is sent or received and so on. So that's going to be the more concrete and actionable part of our tutorial here. So if that sounds interesting, I look forward to seeing you guys there. 16. IP Addresses: Hello guys, and welcome back to the HTTP course. In this lecture, we are going to learn more about what an AP address is and how we can use it in our endeavors with the HTTP protocol. The AP address stands for an Internet Protocol address. That's where the NP comes from, Internet Protocol. What it is, it is a numerical label such as 1902121. This label represents your connection to a computer network that uses the Internet Protocol for communication, that's why it's an Internet Protocol address. An AP address serves two main functions. The network interface identification function and the location addressing function. In just a moment, we'll talk more broadly on these two functions in more easy to understand terms. But as long as the versions of the Internet Protocol goes, there were two main versions of Internet Protocol. The first one, when it was first started, is called the version four, also known as IPV four, and defines an AP address as a 32 bit number. However, because of the growth of the Internet happened and the depletion of available IPV four addresses, a new version of IP were made. Because you can't think that a 32 bit number can only store so much addresses. Out of this need, we created the IPV six, which is the version six of the Internet protocol. These IP addresses are using 128 bits instead of just 32. Now, another notable mention here is that the IP address space is managed globally by the Internet assigned numbers authority. These IP addresses are written and displayed in human readable notations. As the example that I gave you, a valid IP address is 1902120. The network administrators from the Internet assigned numbers, authority, or just in general, assign an IP address to each device connected to a network. Such assignments may be on a static or dynamic basis. What this means is that they may be fixed or they may be permanent. It all depends on the network practices that you're on and the software features of the machine you're working from. Now getting into the purpose of the AP address and why exactly, it's important for you to know things about it. It is because an IP address identifies the host. And you can see that if you type on Google IP address. Some sites are willing to show your own IP address and will also show exactly where you are on a global map. That of course, if you are not using a VPN or something like that, that will reroute your access to Internet to some other distinct place. The IP address identifies the host or more specifically its network interface with it. As I said, it provides the location of the host in the network. And this way it has the capability of establishing a path to that host. It row has been characterized as a name that indicates what we see. An address indicates where it is and the route indicates how to get there. The header of each IP packet contains the AP address of the sending host and that of the destination host, which we are going to see in just a moment when we are going to look at some HDTP requests being made in either Fiddler or Wireshark. As a conclusion, in essence, IP addresses are the identifier that allows information to be sent between devices on a network. They contain location information and also make devices accessible for communication. The Internet needs a way to differentiate between different computers, routers, and websites. This is exactly what IP address provides, a way of doing so and form an essential part of how the Internet works nowadays. I really hope you guys got something useful out of this lecture. Thank you very much for sticking with me up to the end of it, and I look forward to see you in the next one. 17. HTTP Requests in practice: Help guys and welcome back to the HTTP tutorial. In this first lecture of the section where we have more hands on experience with actual tools that will help us not only just better understand the whole HTTP protocol and its requests, but also maybe even do some stuff about them. Not only just understanding them as to see exactly how a request is made, the information about it in practice, and even see if anything is wrong with it or something like that. For this first lecture, we are going to take a look at a piece of software developed by a company called Alaric. It is called Fiddler. You may ask yourself now, what is this Fiddler tool used for? Well, this is a proxy entity, which if you remember, we talked about in previous lecture. The proxy entity was an entity that was in between the server entity and the client entity. And it ran the actual request in between these two main entities through it. And it was either transparent or non transparent based on whether it manipulated the data of the request or not. This what fiddler is, it's a proxy server that will show you, of course, all web traffic on your local machine that you have it installed with to various web servers. For example, if you enter a social media website from your computer, it will show you that request that you made as yet, and you will be able to see it in much more detail. Now, the reason why this tool is used is to debug web traffic for applications in browsers. And what that means is, for example, let's say you created the website and you wanted to see exactly how your request to the website is made. If something goes wrong with it, you would want to look at that specific request to see what goes wrong with it. And the two will actually help you to do that by showing you a lot of information about each specific request that was made from your local machines or from your client machine to web server. Now, in order to download the Fiddler piece of software, you can go on Google, just right Fiddler, of course, the bare version is an even more basic version and you can choose that as well. But when you get it you should type in your e mail and then also select the country that you are in and some stuff like that. Straight up download it. Also if you are on the Apple environment or Linux, you should use one of these download buttons. But we are on Windows. On the machines, I chose the standard download, it will just download an executable for you. That would be pretty straightforward, and once you open it, you can see that it just shows you a license agreement. Then once you click Agree, it will start installing it on your local machine. Once the install is done, we are going to get an overview of this tool to see exactly how the requests are shown and how we can get ahead in understanding this protocol by using this tool. Once you open it, you can sign in with your account. I will do that in just a moment and I'll get back to you once I'm in the application. Okay? So, I'm back after creating my account with Fiddler. Once we open up the app, you are going to see that this is going to run you through a quick tutorial. First of all, basically tell you that it will not track your HTTPS traffic as that is encrypted and not tracked. But you can click on deterate icon in order to change that. Then it will show you all the left part of the tool where traffic will appear and each of these rows means something. Of course the result as in the status code of the request that we talked about. The, the method as in get post and so on. The process, the remote IP and then the URL next here, once you click on a request from the left part here, you are going to see the actual response and actual content of the response in either HTML, Json, and some other ways that it can be shown here, you can capture the live traffic or not. Then we can of course have some safe sessions. After you're done with the tutorial, you can click on the Me button and then click on that exclamation red sign after the URL symbol. And once you click on that, it will start to also track the actual requests and responses that are going through HTTPS. Because you are going by granting that certificate to it to enable it to see those requests that are made securely. For example, I opened up my chrome here and I opened up my Instagram account. You can see that once I did that, I got a lot of pictures here that I got from my Instagram feed and of course, some other to access tokens that I was given through authenticating through Facebook, on Instagram and so on. So you can see also in the first part, not just the number of the request that was made based on the type but also the type of the response that you got. For example, this is images you saw. This is a Jason response. These are post methods that are used to create stuff and so on and so forth. Of course, you can group them by results. First of all, if you want to have the okay result requests, you can do that and then they will actually increase. For example, here is the last one that had a 43 response. Then we have the method if you want first to get types of requests and so on. Then the IP's processes and also the body sizes or comments. You can order them by that as well. Now, when receiving this request, you can see a few things. Here we have a preview. We can see it in the raw format. You can see the body of the request and also the headers that came with it. Here we, of course, have some pretty general information about it, like last day that it was modified, the type of connection, the content length, and so on and so forth. Again, the response is also shown here. You can save the session. So a session is once you start to see some requests, then you can start the session and you have a few requests the end it and then save it. Under the session thing here, you can also remove all of them if you want to have a clean slate. As I said, safety session can share the session. You can actually do some advanced filters like the response headers and request headers in order to just see some of the requests that take place. Here you have some notifications, your profile, the settings. This is pretty much just basic stuff, but this can be very useful as I've said, if you want to make a website or maybe you just expose some API's to your web service and you want to see how the requests that are made to get endpoints API is going to look like. This is the tool you would want to use. Of course, there is also another tool called Wireshark, and we're going to go through that tool next and take a deeper look at that as well, but for now, this was about it with the Fiddler tool. I thank you guys very much for sticking with me up to the end of this lecture. 18. Wireshark: Hello guys and welcome back to this HTTP tutorial. In this last lecture, we are going to take a deeper look at another tool that will improve our knowledge about the HTTP protocol and the requests that are made more exactly. This too is called Wireshark, as you can see on the screen. And it's another application very similar to the last application that was in this area, and we talked about it in the previous lecture, which was Fiddler. This application as well allows you to capture and investigate in detail the network traffic that you have, meaning the requests that are made, and the responses that are received in between the client, meaning the web browser that you have on the local machine where you installed this too, and the web server that you make requests to. And that can vary based on the website that you enter and what you received from it. Again, here we can just search on Google Wireshark. It's free tool, and once you are on Wireshark.org you can basically get started by downloading it. I'm on Windows, I will install this 64 bit too. But again, they also have the cos, if you are on Apple product, you can choose that in order for you to install. And once you click on it, as you can see, it will download the executable as well. Then I will run you through the set up as well. As it is pretty straightforward, you can just install it with the whole things that Caes with. We'll also ask you to associate all these extensions of different files with Wireshark. We are going to install it in C drive. I'm not going to use this MP 1102, neither the USB, I'm just going to not click on that. You don't really need those tools in order for to just observe these requests that are made and see exactly what are the details about them. As you can see here, the wireshark is installing. And I will get back to you guys once the tool is installed and opened on my machine in order for us to see what's going on and how we can use it guys. Once you open up the wireshark, you can select the connection that you have. I chose the Internet to then, as you can see on the screen, I just stopped it for now. So you'll get a better look at what exactly is going on here. But of course, sign of shark here is used to start the actual capturing of the request. And this is the stop button in the first upper part here. Unlike fire that it had these parts vertically, this one has them horizontally. But here you can see the actual request that took place, the protocol, the source in the destination IPs. Which can be very useful if you just want to, for example, see a request that went out from your computer on the network. You can sort from the source and it will show the IPs in sorted order. Then of course the length of the response, the number of them. If you want to go into further detail on actual request, you need to click on it. And then it will show you in the second and third actual windows more information about that specific request. In the third window, it will show you the actual response in decimal language. In the second one, it will show you as the request is body and an actual response in XML or whatever format it has. Also the responses and all that good stuff will appear in the second kind of window. This is about Wireshark as well. It's not that much of a difference between these two. I usually work with Wireshark as I found it, more simple and straightforward than fiddler. But both of them are good enough at this job. So you can choose which one you feel more comfortable with based on what you saw in these two lectures. This was about it with the HTTP tutorial guys. I hope you got something out of it and you understand now better the HTTP protocol, what requests are, what are the entities in a client server workflow and all the other stuff we talked about, status codes and HTP request methods. If you have any questions whatsoever about the HTTP protocol, you can reach me and message me. And I will make sure to reply to you guys in the shortest amount possible. But once again, thank you very much for sticking with me up to the end of the tutorial and watching it, and I look forward to seeing you in further tutorials that I will create.