hx-pod

Every request has secret hidden headers. But what if you wanted to make your own?

https://htmx.org/attributes/hx-headers/

What is hx-pod?

Join me while I learn HTMX and talk at you about it
Twitter: @htmxlabs

Lazarus:

So the next one we're gonna do here is h x headers. And h x headers, this these are the headers that are gonna go along with your request. So your h x get, your h x post, etcetera, you're put in patch. And some of these headers are already on the request. So you don't you don't need to do HX headers by default, whatever headers you need, including the HTMX one that just mentions, you know, to the server that this is an HTMX request.

Lazarus:

Those are already on there. And you can check what headers are already on your requests. Same way as you would for any other, Ajax request, inspect the page. If you're using something like Chrome, you you right click, go to inspect element, go to the network tab within your inspector. And when a request happens, click on that and then you can see there's a headers section.

Lazarus:

So you can see all the headers that are currently being passed back and forth with the request and the response. But this is if HX headers is if you want to have a little bit of control over what those headers are and you want to pass an extra header. So why would you do this? There's a couple different reasons. I will say the reason it's in the advanced, section of these attributes is that it's not exactly that common, that you would need to do this, but we've already talked about.

Lazarus:

One example would be a CSRF token. When you're making a post, put, patch, or delete request, your server is expecting to see a matching CSRF token, cross site request forgery token, and you need to provide that along with your request. And there's different ways to do that. You can include it as a hidden input if you're submitting a form, but when you're making just a regular post request, you don't necessarily have a form. So setting h x headers equals and then putting in the, the CSRF token into that into those headers, is is kind of a good way to sort of handle that, in a in a one off situation.

Lazarus:

But you could also do an API token. So you have to be sure that, you know, it's okay that you're exposing that API token, in the code. So that's not gonna work for every API token, but that's the sort of thing that is a header. If you're making a request to somewhere, maybe even to your own thing, you may want to put that sort of sort of token into it. You could also add a custom header that you that you're going to check on the server side.

Lazarus:

So you might have logic where you want to, depending on what's happening with the request, you might just want to send a custom header and you can check-in your on your server side very early on in your request life cycle and say, okay, you know, this has this custom header in it. So here's how I'm gonna handle that. I'm gonna handle that with some other bit of code. I can branch off based on that header, so custom header. All this to say, this the uses for headers are advanced.

Lazarus:

You just don't necessarily need to think about it that much under normal circumstances. But when you do need to, h x headers is there. It should be valid JSON. So you pass it, you that means you need to put it in single quotes for the attribute. H x headers equals and then single quotes, which usually you don't need the single quotes.

Lazarus:

Usually, it could be double quotes for an attribute, but to make sure that the JSON can have the proper double quote format, it's much more strict about that. So use single quotes for the hx headers attribute. You can also not just use valid JSON, but if you want to have it dynamically, if you want to include dynamic JSON or dynamic JavaScript, anything that's not static you can use JS colon in front of it or j or Java script colon in front of the value. So h x headers equals j s colon, and then you can put the JSON array, but it can have custom evaluated expressions included in it. You do need to be careful allowing for the custom JavaScript because you could open yourself up to cross site scripting vulnerabilities.

Lazarus:

That's a little bit beyond the scope of, you know, just talking about HX headers, but it is something to look out for. So this is why this is in the advanced. You probably don't need it, and also there are some gotchas. If you are putting if you're allowing user input in that dynamic, you know, JavaScript, that's being that's being put put in there. The users can do tricky stuff.

Lazarus:

You know, that's something to look out for. So the most common is probably the CSRF token, but when you need to send an extra bit of header info, you can break out HX headers.