Emails / Email Course (4) Powerful Tools for Delivering Content to Users

Email Course (4) Powerful Tools for Delivering Content to Users
Hello, {{ subscriber.first_name | default: "friend" }}! 👋
The response has completed its long journey back to the browser! 🛬
We should have everything we need to show the user what they asked for.
Behind the scenes, response headers tell the browser how to handle the response before the content is passed on to the user.
A response might be an HTML page, but it might also be a JSON object or some other type of content.
The response header can tell the browser how to properly render the result with the Content-Type header.
 
response.writeHead(200, {
  "Content-Type": "text/html; charset=UTF-8",
});
Consider that response might include data that has been compressed and encoded to maximize its delivery speed to the user.
Perhaps you've heard someone say that a JavaScript bundle is "X kilobytes Gzipped."
Well, Gzip is an encoding mechanism that does just that, so if the browser receives a "Gzipped" response body, it needs to know how to decode it first.
The response Content-Encoding header can help with that.
 
response.writeHead(200, {
  "Content-Type": "text/html; charset=UTF-8",
  "Content-Encoding": "gzip",
});
What if the response is rarely updated?
Browsers can use caching to more quickly show the user a page without going through another request cycle.
The Cache-Control header tells the browser whether or not it's safe to cache the response, for how long, and what to do if the server needs to revalidate the request.
 
response.writeHead(200, {
  "Content-Type": "text/html; charset=UTF-8",
  "Content-Encoding": "gzip",
  "Cache-Control": "max-age=604800, stale-while-revalidate=86400",
});
In the end, headers are just little messages that web browsers and servers can pass back and forth to one another.
The recipient can do something with those messages or choose to ignore them, but they are powerful tools in the process of delivering content to your users.
Challenge
The request/response cycle is complete!
Our long journey across cyberspace is complete... until the user interacts with the page. Many interactions will trigger another journey that follows the same basic path from the browser to our server and back again.
But what if instead of simply requesting to receive some data we want to request our server to change some data?
What do you think the request should do differently if it wants the server to do more than send a response.
Respond here with your answer in just a few sentences or bullet points:
Respond here!