I don't know how to send header again as part of redirect handling

[milanaleksic]

I have a request

POST /entry/48861/read HTTP/1.1
HX-Current-URL: https://localhost:8002/entry/48861
HX-Request: true
HX-Target: tttoolbar
Host: localhost:8002
...
X-My-Custom-Header: true

that responds with a 302:

HTTP/1.1 302 Found
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://localhost:8002
Content-Length: 0
Date: Sat, 01 Mar 2025 08:04:54 GMT
Location: https://localhost:8002/entry/48861?segment=toolbar
X-My-Custom-Header: true

This is all fine. But, the HTMX follows on this redirect without letting me send again the header. In other words, htmx adds its own Hx-* headers, but doesn't trigger my htmx:configRequest header so that I can add my X-My-Custom-Header again.

GET /entry/48861?segment=toolbar HTTP/1.1
HX-Current-URL: https://localhost:8002/entry/48861
HX-Request: true
HX-Target: tttoolbar
...

How can I add my custom headers as part of the 302 handling, just as I can do in the normal htmx initial request?

[milanaleksic]

I have read this part from the page https://htmx.org/docs/#response-headers:

Also the response headers above are not provided to htmx for processing with 3xx Redirect response codes like HTTP 302 (Redirect). Instead, the browser will intercept the redirection internally and return the headers and response from the redirected URL. Where possible use alternative response codes like 200 to allow returning of these response headers.

So it's more clear (if I understood it correctly) that there is an explicit design choice here, but I am asking myself how can then htmx add the HX-* requests. Just wanted to make sure I am not missing something because it... feels like... it should be possible.

[Telroshan]

there is an explicit design choice here

Not really! At least, not our choice ; the browser simply doesn't let us know about this standard redirection happening, so just as you don't receive a htmx:configRequest event for the "new" request, htmx itself cannot either catch it. The browser will follow the redirection and eventually pass its response to htmx, which won't even know about the first response that was redirected.
So, to answer your question in that part, htmx doesn't add its hx-* headers to the redirected request, the browser is doing that automatically.

As for your issue itself, I just tried with a local setup, if I set a custom header in a htmx:configRequest event listener, then do a standard 302 redirection in my backend's reponse, I properly see the custom header in the redirected request, as you would expect.

Just to make sure, could you clarify whether the issue you're facing is A) the custom header not being present at all in the redirected request, or B) you wanted to be able to set a value for that same header in the redirected request, different than the initial request's one?
If A), please make sure you're using the latest htmx version first to see if the issue persists, then provide a reproducible example as I personally got the behavior you would expect
If B), you'll likely want to use another mechanism (such as responding with a HX-Trigger header in the first request's response, instead of redirecting)

Hope this helps!

[milanaleksic]

Perfect, thank you for the analysis. My assumption was not clearly stated, sorry about that. Indeed, I actually wanted to use a response header from the initial request and forward it as a request header of the 302, but as you said yourself it's browser that I am fighting against.
I have solved this problem with business logic migration to the backend, so that there's no need for 302 since the redirect is done on the backend side, so frontend doesn't have to change on the fly the secondary 302 request at all.