finishes chapter 06.4 headers

Author: ishtms

chapters/ch01-what-is-a-web-server-anyway.md

@@ -1,6 +1,6 @@
 [![Read Prev](/assets/imgs/prev.png)](/Readme.md)
 
-# What the hell is a web server any way?
+# What the heck is a web server any way?
 
 > Note: This chapter gives you a brief overview of the basics of web servers and HTTP. We'll learn about HTTP in more details in an [upcoming chapter](/chapters/ch06.0-http-deep-dive.md).
 

chapters/ch06.4-headers.md

@@ -210,7 +210,7 @@ Here's an example of the `Host` header in a request:
 Host: www.eaxmple.com
 ```
 
-### Content-Type
+### Content-Type (request)
 
 We talked about `Content-Type` in the previous section. This is another example of headers that are used both in a Request and the Response.
 
@@ -228,6 +228,129 @@ Content-Type: application/json
 
 ## Response Headers
 
+When a client sends a request to a server, it is the server's responsibility to send back a response with the appropriate headers. These headers contain information such as the type of content that is being sent, the status of the response, and any caching instructions that the client should follow.
+
+For example, the `Content-Type` header, like we just discussed, indicates the format of the data being sent back to the client, such as HTML, JSON, or XML. The `Cache-Control` header specifies how long the client should cache the response before requesting it again from the server.
+
+In addition to these standard headers, servers can also send custom headers that provide additional information specific to the application or service. For instance, an API might include a custom header containing a unique authentication token that the client can use to make subsequent requests. We'll use this technique while building our backend library, in the upcoming chapters.
+
+### Content-Type (response)
+
+This header specifically deals with indicating the format or MIME type of the content being sent or received. It plays a pivotal role in ensuring that the client and server understand how to process the exchanged data accurately.
+
+In response headers, the `Content-Type` header informs the client about the format of the content being sent by the server. For example, if a server is sending an HTML page as the response, it includes the `Content-Type` header to specify that the content is in HTML format:
+
+```bash
+> HTTP/1.1 200 OK
+> Content-Type: text/html; charset=UTF-8
+```
+
+Here, the `Content-Type` header indicates that the content is HTML, and the `charset` attribute is an extra parameter which specifies the character encoding used. We talked about the extra parameters in the previous chapter (MIME Type and Content-Type)
+
+### Cache-Control
+
+The Cache-Control header is a really important aspect of the HTTP protocol that web developers should not overlook. This header provides directives to both client and intermediary caches on how to handle the response from the server. It is highly recommended to use this header in every HTTP response because it plays a crucial role in optimizing performance and content freshness by controlling caching behavior. 
+
+> An intermediary cache, is a special server that sits between the client and the original server, serving as a middleman for requests and responses. The main job of an intermediary cache is to keep copies of often requested resources, like web pages, images, and other content, to decrease waiting time and network traffic.
+> 
+> There are two main types of intermediary caches:
+> 
+> 1. **Proxy Cache:** A proxy cache is like a middleman between employees' devices and the internet. When someone requests a web page, the proxy cache checks if it has a copy of that page and sends it straight to the person if it does. This saves time and internet data because the page doesn't have to be downloaded from the internet multiple times.
+> 2. **CDN (Content Delivery Network):** A CDN is a network of distributed intermediary caches placed in various locations around the world. One of the examples is AWS Cloudfront. CDNs are primarily used to deliver web content (like images, stylesheets, scripts) to end-users more efficiently. When a user requests content from a website using a CDN, the request is routed to the nearest CDN server. If the requested content is cached on that server, it's delivered quickly. 
+
+#### How Caches Work:
+
+When someone requests a web page, the cache checks if it already has a copy of that web page. If it does, and the copy is still fresh (based on the expiration time and the `Cache-Control` header), the cache sends that copy to the person right away. This saves time and internet data. If the cache doesn't have a copy of the web page, it asks the origin server for the page. Once the origin server responds, the cache stores a copy of the page so it can send it to someone else who requests it in the future without asking the origin server again.
+
+By specifying directives such as `max-age` and `public`, the server can communicate with the cache to determine how long the response should be cached and whether it can be cached by public caches or not. This way, the server can ensure that visitors get the latest version of the content, while avoiding unnecessary requests and thereby, improving the overall performance of the website. 
+
+#### Cache-Control Directives:
+
+The Cache-Control header is used to provide directives to caching systems, instructing them on how to handle a response. It can specify whether a response should be cached, for how long, and whether it can be reused for subsequent requests. There are several common directives that can be used with this header.
+
+- `public`: Indicates that the response can be cached by both the client and intermediary caches. This is typically suitable for content that is meant to be shared publicly.
+
+- `private`: Specifies that the response can be cached by the client but not by intermediary caches. This is useful for content that is specific to the individual user.
+
+- `max-age`: Sets the maximum time (in seconds) for which the response can be cached. After this time elapses, the cached response becomes stale and should be revalidated with the server.
+
+- `no-cache`: Instructs caches to revalidate the response with the server before using a cached copy, even if it appears to be fresh.
+
+- `no-store`: Requires caches to not store the response at all. Each request/response cycle must involve contacting the origin server.
+
+Let's see some of the examples on how we can use these directives with the `Cache-Control` header:
+
+##### Always Cache (infrequent updates)
+
+Suppose a website has static assets like images, stylesheets, and JavaScript files that rarely change. To improve performance, the server can allow public caching of these assets by specifying the `Cache-Control` header:
+
+```bash
+Content-Type: image/webp
+Cache-Control: public, max-age=604800
+```
+
+If the `max-age` is set, and has the `public` directive, this means that the image is marked as publicly cacheable for up to 7 days (`max-age=604800`).
+
+##### Always Cache (private only)
+
+Consider a website that displays recommendations for each user based on their browsing history. These recommendations are relatively stable and can be cached on the user's device for a limited time to improve performance, and we do not wish the intermediate servers to cache this info. The `private` cache directive with the `max-age` directive can be used in this scenario.
+
+```bash
+Content-Type: application/json
+Cache-Control: private, max-age=3600
+```
+
+The `max-age=3600` directive specifies that the cached response can be used for up to 3600 seconds (1 hour). This means that the user's device will display the cached recommendations for subsequent interactions within the next hour.
+
+##### Never Cache (realtime data)
+
+For content that can change frequently, like social feed or your messages feed, the server might use the `no-cache` directive to ensure that clients revalidate the content on each request:
+
+```bash
+Content-Type: text/html
+Cache-Control: no-cache, no-store, must-revalidate, max-age=0
+```
+
+When all these directives are combined as `'no-cache, no-store, must-revalidate, max-age=0'`, the goal is to prevent caching entirely and ensure that each request to the resource results in a revalidation with the origin server. This combination is useful for scenarios where content should always be dynamically generated and where no cached copy, regardless of freshness, is considered acceptable.
+
+For example, if a web application displays real-time data, like stock prices or live news updates, this cache-control combination ensures that users always receive the most current information by fetching it directly from the origin server. It minimizes the risk of outdated data being displayed to users due to cached copies.
+
+We looked at `no-cache`, `no-store` and `max-age` in the **Cache-Control directives** section. Let's take a look at the `must-revalidate` directive:
+
+The **`must-revalidate`** directive emphasizes that the cached response must be revalidated with the origin server before being used, even if it's marked as fresh. If the cached response has expired, it must not be used without revalidation. It's an extra level of security to ensure up-to-date content.
+
+### Set-Cookie
+
+The `Set-Cookie` header plays a key role in maintaining the state of a user's session. When a server sends a response to a client's browser, it can include instructions to store cookies, which are small pieces of data that are stored locally on the client's machine. These cookies can then be sent back to the server with subsequent requests, allowing the server to identify the client and maintain a record of their activity.
+
+Cookies are widely used on the web for a variety of purposes, including tracking user sessions, personalizing user experiences, and more. For example, a website might use cookies to remember a user's login credentials so that they don't have to enter them every time they visit the site. Cookies can also be used to store user preferences, such as language, font size or theme (dark or light) for a more personalized browsing experience.
+
+> We looked at the `Cookie` header earlier, which is sent as request header, on the contrary the `Set-Cookie` is sent as a response header.
+
+Some of the most important components of the `Set-Cookie` header include expiration date (`expires`), the `path` attribute, the `domain` attribute, the `secure` attribute, and the `HttpOnly` attribute. These elements work together to ensure that cookies are delivered to the correct domain, are only accessible via secure connections, and cannot be accessed by malicious scripts or third-party applications.
+
+- **`expires`**: attribute allows you to specify the exact date and time when the cookie will expire. Once expired, the cookie will be considered invalid and will no longer be sent back by the client. By setting an expiration date, you can control how long the cookie will remain active on the user's computer.
+  
+  > Note: If the `expires` attribute is not specified, the cookie becomes a **session cookie**. A session finishes when the client shuts down, after which the session cookie is removed.  Many web browsers have a *session restore* feature that will save all tabs and restore them the next time the browser is used. Session cookies will also be restored, as if the browser was never closed.
+- **`domain`**: This attribute allows you to specify the domain for which the cookie is valid. You can set it to a specific domain or a subdomain.
+- **`path`**: This attribute allows you to specify the URL path for which the cookie is valid. The cookie will only be sent to the server if the requested path matches the specified path. This means that you can control which pages on your website can access the cookie.
+  
+  Let's say you set the `path` attribute as `/blog`:
+  - If you type `/blog`, `/blog/`, `/blog/post`, or `/blog/post/1` as the request path, it will work.
+  - But if you type `/`, `/docs`, `/blogpost`, or `/v1/blog` as the request path, it won't work.
+- **`Secure`**: This attribute instructs the client to send the cookie only over secure (HTTPS) connections. This ensures that the cookie is transmitted securely and cannot be intercepted by attackers. By using this attribute, you can protect sensitive information stored in the cookie.
+- **`HttpOnly`**: This attribute prevents client-side scripts from accessing the cookie through JavaScript. This enhances security by protecting sensitive information from being accessed by malicious scripts. By using this attribute, you can ensure that the cookie is only accessible through the server-side code. This mitigates attacks against cross-site scripting ([XSS](https://developer.mozilla.org/en-US/docs/Glossary/Cross-site_scripting)).
+
+An example response using `Set-Cookie`:
+
+```bash
+Set-Cookie: userprefs=language=en; currency=INR; expires=Thu, 31 Dec 2023 23:59:59 GMT; Path=/; Secure; HttpOnly
+```
+
+
+
+
+
 [![Read Prev](/assets/imgs/prev.png)](/chapters/ch06.5-the-response.md)
 
 ![](https://uddrapi.com/api/img?page=ch6.4)

chapters/ch06.5-the-response.md

@@ -1,4 +1,3 @@
 ## Status Codes and the Response
 
-
 ![](https://uddrapi.com/api/img?page=ch6.5)