Check out a free preview of the full Full Stack for Front-End Engineers, v2 course:
The "HTTP Headers & Cookies" Lesson is part of the full, Full Stack for Front-End Engineers, v2 course featured in this preview video. Here's what you'd learn in this lesson:

Jem defines the different headers that are included in an HTTP request, focuses on the header set-cookie, and explains why cookies are important elements of the web.

Get Unlimited Access Now

Transcript from the "HTTP Headers & Cookies" Lesson

[00:00:00]
>> Jem Young: So let's break it down, let's start with the headers.
>> Jem Young: What is a header? Or what is your take on what a header is and what it does?
>> Speaker 2: Metadata [INAUDIBLE] the request.
>> Jem Young: Sorry?
>> Speaker 2: Give some metadata.
>> Jem Young: Yeah.
>> Speaker 2: [INAUDIBLE] request or the response.
>> Jem Young: Yeah, or we said packets are made up of data and then metadata?

[00:00:24] Part of that meta data is the header, and the header is something really, really interesting that we all probably use at some point but we don't think about what it's doing. And the great thing about this metadata is it can tell a lot about like where the request has come from besides just the IP.

[00:00:40] It tells what kind of encoding it has, what kind of content it has, it actually has so much information that we can pack and unload. And you can understand how that request is formed and where it came from, and we can attach information along the path. In fact, I can attach headers or something that Nginx will read, just for Nginx, it strips it out and then it goes to Express, then Express will read his own headers, maybe pass that data along something else but it strips out another header.

[00:01:05] So along the way we can add information or subtract information, that's what headers are really good for. Do you have a question?
>> Speaker 3: Yeah, I think that like the writing on the outside of the envelope, because the packets or the content, and then the headers are the part that you can inspect without having to look at the contents.

[00:01:22]
>> Jem Young: Exactly, and I love the envelope metaphor, again, who created that? I thought it was me, no, [LAUGH] it's exactly that, it's all this information about where a destination is going, where it's from, what kind of encoding it's using, what kind of encoding it's accepted. And based on if it's a request, so that's something going to the server or the response something coming out of the server, changes what kind of headers we're looking for, what kind of headers we're gonna set.

[00:01:47] So here I highlighted some of the common headers, the host header you probably are familiar with, it tells request where it's going and what's the destination. Host is really interesting because part of it is what Nginx reads to route request to their correct server. Remember earlier how we spoke about virtual hosts, how I can have multiple servers?

[00:02:09] Part of how Nginx determines where it's trying to go is reading the header, here. And I think headers are really, really powerful and underrated, we probably don't think that much about how that data is formed and what it's been used for. But in this case, Nginx is reading it, Express doesn't care anything about it.

[00:02:25] In fact, I can take out the host header, and it would still work, but you'd run into some issues. And funny enough, I can proxy requests, remember what a proxy is? We defined it earlier.
>> Jem Young: Anybody, tell me? Nobody remembered? Yes?
>> Speaker 4: It's when you have a server that represents multiple different endpoints behind it, and it reroutes and redirects based on, in this case, the reverse proxy.

[00:02:56]
>> Jem Young: Exactly, exactly right. Funny enough, there are certain headers that are unmodifiable by the client, and the host header is one of them. I cannot fake where my request came from, browsers don't allow that generally. So if you have a service worker and you're trying to use a service worker as a proxy, I should step back.

[00:03:13] Does anybody know what a service worker is? You've heard the phrase, it's a persistent web worker that runs in a separate thread, and when the tab is closed, it can still run in the background. It's a way of intercepting network requests, essentially, it can do other things, too.

[00:03:28] And there's a good course on FrontEnd Masters on service workers taught by somebody, I forget who.
>> Speaker 5: Kyle Simpson.
>> Jem Young: Kyle Simpson, yeah, and he's brilliant, so take that course. But a service worker, one of the things I tried to do early on was I tried to create out a proxy in the client, so that based on what the request is trying to do it proxy the different servers.

[00:03:46] And I found out you couldn't do it because I can't modify the host header, I can't modify where that packet is supposed to go once the request has gone in flight. Where in fact you might run into if you start messing with headers and service workers, user agent is the next one.

[00:04:00] What does the user agent? I promise you if your web developer you've heard the phrase before, what's the user agent header?
>> Speaker 6: A browser, information general?
>> Jem Young: Yeah.
>> Speaker 7: Yeah, what kind of computer you own, that kind of stuff.
>> Jem Young: Yeah, do you ever wonder why they look like this?

[00:04:19] This weird mishmash of things? I always have, it comes from the early days when there weren't many, there was one browser that's well supported, and that was Internet Explorer, and that was the cutting edge. Do you have a question?
>> Speaker 8: Is it versioning? Is that what the numbers are?

[00:04:35]
>> Jem Young: Part of it is versioning, but the reason why it's this kind of alphabet soup of different types, [INAUDIBLE] HTML, which we haven't used in a long, long time, like Gecko, the old engine. It was because browsers were, hey, I'm a modern engine, but I'm not Internet Explorer, and a lot of sites were only built for Internet Explorer, we're Mozilla, or Safari, or something like that, so they faked it.

[00:04:58] They put Mozilla in the header, even though, in this case, this was a Chrome browser, but it still says Mozilla 5.0 because it's trying to fake itself. And because the web is backwards compatible, they kept it, and it just keeps getting longer and longer, and no one company has ever said, hey, we're gonna fix this today, we're gonna fix this because now there's so many different browsers and no one would agree on what the user agent looks like.

[00:05:21] But really the user agent is we use it to inspect what version of browser we're on, so what features are supported and what type of browser it is basically. Generally, you're gonna use some sort of library parts of your user agent because these are generally unreadable, like I pulled this from Google Chrome browser.

[00:05:39] But like it'd be very difficult to tell which browser it was, is it Chrome, is it Safari, is it Mozilla? No one knows, so use a library if you're trying to sniff user agents. But again, it's good for a feature support, so if I wanna turn on like top level async await which V8 now supports but it's not supporting other browsers.

[00:05:57] I already use some sort of user agent sniffing or other methods. Accept is just saying, as a browser, what sort of things can I receive back from the server? Because not all web browsers support all the same protocols, but the accept header is usually generated by the browser itself.

[00:06:16] And it just says, hey, you know what I'll take HTML in that text format, and we use that for different types, we use that for different types of supportive formats, we move down to the accepting coding. That just means this browser accepts these gzip encoding so Nginx will say, hey, I've got a request here and it'll actually take gzips on the way out, I'm gonna gzip that up because I know Azure can handle that.

[00:06:40] Whereas back in the day not every browser support the gzip, in this case, because I'm using Chrome as this user agent, it also accepts probably, which we talked about earlier as a alternative compression format invented, I wanna say in Switzerland, yes, invented in Switzerland. Why do I know that?

[00:06:57] Cuz I was in Switzerland, and I was like probably, and actually means little bread. Good, you learn all sorts of things not just Fast and Furious trivia, but it's a different encoding format, but it's just saying, hey, if Nginx, or Apache, or whatever web server using, supports probably, my browser will accept it too.

[00:07:14] And it's really nice, cuz it's a way of like falling back to different things. And again, all this is contained in the header, like all this metadata about the request itself. And of course, except languages, what sort of languages am I expecting to get back? These are generally auto populated by the browser, and whatever language you've said in the browser or your operating system

[00:07:38]
>> Jem Young: And I'm just going over some of the common headers you'll run into, the one I didn't talk about was Set-cookie which sets cookies. Why are cookies kind of important to the web?
>> Jem Young: Or should I say what is a cookie? Yeah?
>> Speaker 7: It's a piece of metadata, but it goes on every subsequent request.

[00:07:59] And it can be inspected and kinda managed on the server side too.
>> Jem Young: Exactly, it's a persistent bit of text data that persists on the browser, depending on if it's a session cookie, meaning the minute you close a tab or the browser, it's gonna be erased, or a regular cookie, which will persist over time.

[00:08:16] And it will expire whenever you set the expire on the cookie tool. But why is the cookie important? In fact, it's crucial to the web, like we couldn't we couldn't operate a web without cookies. Anybody, [INAUDIBLE], Tanner?
>> Speaker 8: [INAUDIBLE] let's you bring data between sessions and like let's you extend the user experience across different sessions.

[00:08:42]
>> Jem Young: Exactly, there's something we don't think about as what developers, is that the internet is stateless, every request and response is a brand new request and response the server doesn't remember that you've been here or not. Versus say other programming paradigms, where there's a state and then whenever the user goes away that state is gone.

[00:09:03] The web is stateless, it's something we don't think about that it exists, so we need cookies versus this data over time so that we know that a request, say the person is logged in or they're logged out, or I accept cookie banner that we all have to do now because of regulations or things like that.

[00:09:23] The danger with cookies and I'm glad you brought that up, Kayla, is that cookies persist over every single request unless you expire them. And the bad thing about that is you can make a really simple request, like I want a 2 kilobyte HTML page, 10 kilobytes, if you put a lot of cookies in there, because they're sent on every single request.

[00:09:44] So if I to tip is web developers and full stack engineers, be careful the amount of cookies you send, and don't add too much data in there, because it's gonna get sent on every single request and you're just adding overhead, and you're making your connection slower. The final type of common header I wanna talk about, there are lots and lots of headers, I'm just touching on a few of them, is the X header.

[00:10:03] X is a general guideline on how to set custom headers, so if you're like I wanna set a Jem is the best header, I would use X dot Jem Is the best header and put whatever sort of data you want. And using custom headers is a good way of sending one-time custom data that we don't necessarily want a payload but we wanna be decrypted by the browser.

[00:10:28] It's something you've probably seen, if you probably seen X something header, it just means it's a custom header, the browser probably doesn't know what to do with it. The Nginx probably doesn't know what to do with it, the one you'll see most commonly, and let's pull up our web page and see if we can see a custom header in there.

[00:10:43] So I'm on my web page, we can pull up your own, and I'm gonna refresh this page, I'm gonna look at the Network tab, and let's check out the request headers. Given the host, the user agents, and we have under the response headers, we this X powered by, cuz powered by is not an official HP header that browser know to deal with.

[00:11:07] Express just tag this on to let you know that, hey, the application of a serving is using Express. So if you need to send custom one-time data using an X header is a good way of doing it.
>> Jem Young: The response looks a little different, and the headers will be a little different.

[00:11:31] The request header is all about, who I am as a browser? Where am I going? Where am I trying to get to? What sort of technology incentives I support? The response headers is what the server is sending you so that let's say the content is gzip encoded, the browser wouldn't know that unless we set a header that says the content type is encoded as gzip, it wouldn't know how to unpack that.

[00:11:55] So the response headers are just as important as the request headers.