Empty `http.response.header.X-Accel-Redirect`

Help
1

1. Caddy version (caddy version): 2.4.0

2. How I run Caddy: Irrelevant

3. The problem I’m having:

Using the new handle_response, the http.response.header.X-Accel-Redirect has leftover ?token=... which interfere with file_server directive: It seems that the response header is empty. I’ve added a custom mytest header to copy the value there, but it is empty

reverse_proxy localhost:8000 {
      @accel header X-Accel-Redirect *
      handle_response @accel {
               root * /path/to/protected/files
               header Content-Disposition "attachment"
               header mytest "{http.response.header.X-Accel-Redirect}"
               rewrite {http.response.header.X-Accel-Redirect}
               file_server
      }
}
2

It’s always relevant. Please don’t assume that it’s not. Not filling in parts of the topic template makes us have to make assumptions, which is not helpful.

I’m reading the code for rewrite and this should work as expected. I’ll need more detail to better understand what’s going on.

Turn on debug mode to better see what’s going on in Caddy with rewrite and file_server operations.

{
	debug
}

Then check your logs (this depends on how you run it; like I said, it’s always relevant).

3

Yes, I’m sorry about that. Just figured this issue is more on the config/CaddyFile part and service rather than a setup issue.

I have done a bit more debugging and it seems the issue is that http.response.header.X-Accel-Redirect is empty. I manually tested with curl and the response header is set correctly: X-Accel-Redirect: /_protected/attachments/8/3/a/3/c31a7aca09a18164f29f388b0167043abfcd57f45720301961938ed4f6bc/image1.png

4

Here’s the full line for it:

"http.handlers.rewrite","msg":"rewrote request","request":{"remote_addr":"x.x.x.x:62472","proto":"HTTP/2.0","method":"GET","host":"taiga.xxx.xxx","uri":"/attachments/8/3/a/3/c31a7aca09a18164f29f388b0167043abfcd57f45720301961938ed4f6bc/image1.png?token=YJtTtA%3AnJR4kPCVWzSJJkguaCctHlcj9eE57WlEWfPVwnWm8aWzbKCh0mnz_wCNgVYMUe9ek4RWis1UgJEh9cxof9rs7A","headers":{"User-Agent":["Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:88.0) Gecko/20100101 Firefox/88.0"],"Accept":["image/webp,*/*"],"Accept-Language":["en,en-US;q=0.5"],"Accept-Encoding":["gzip, deflate, br"],"Referer":["https://taiga.xxx.xxx/project/lecris-test/issue/1"],"Te":["trailers"],"X-Forwarded-For":["x.x.x.x"],"X-Forwarded-Proto":["https"]},"tls":{"resumed":true,"version":772,"cipher_suite":4865,"proto":"h2","proto_mutual":true,"server_name":"taiga.xxx.xxx"}},"method":"GET","uri":"/?token=YJtTtA%3AnJR4kPCVWzSJJkguaCctHlcj9eE57WlEWfPVwnWm8aWzbKCh0mnz_wCNgVYMUe9ek4RWis1UgJEh9cxof9rs7A"}
5

Okay… I think I see the bug :man_facepalming:

This is somewhat complicated, so bear with me.

The http.response.header.* placeholders grab from the “response writer” which is used to write the response back to the client. The problem is that in the handle_response flow, the headers actually aren’t being written to the response writer before running the handler, because it’s expected that the handler will write whatever headers actually need to end up on the final response. In the “normal case”, when the request doesn’t get handled by handle_response, then the headers from the proxy response are copied onto the response writer.

So I’m working on quick patch to actually set the header values from the upstream response at http.reverse_proxy.header.* instead. This should probably fix it for you. It won’t be on http.response.header.* because that should continue to be the actual headers being written to the client, instead of the ones from the proxy.

I’d appreciate if you could download the build from CI once I have the PR up to confirm that it does work (gimme like 15-20 min tops).

1 Like
6

Certainly, this indeed would make sense, I’ll keep an eye out for the PR

7

The goal is to simply strip the query string right? So wouldn’t another rewrite do the trick?

rewrite {path}

Something like that…

8

PR is here, the CI job is running.

You’ll find the CI artifacts at the bottom of this page, once all the tests are done running.

https://github.com/caddyserver/caddy/actions/runs/834103109

The problem is actually that the placeholder is empty.

9

@matt Sorry for the confusion the actual problem was that the response was empty. But on that note, how could we edit the variables after rewrite {variable}, e.g. chaining the rewrites

10

Oh. Did the last new example on reverse_proxy (Caddyfile directive) — Caddy Documentation never get tested then? :thinking:

11

Nope! :smiley:

Nobody tested it because you implemented it (JSON only at first) and it was assumed to work, I just set up the Caddyfile part. I was testing the adapter.

1 Like
12

Oops – my bad.

13

The CI job is all done, you can grab one of the build artifacts from here

1 Like
14

Downloaded and tested. Indeed everything works as intended. Thank you for the fast fix

2 Likes
15

Excellent! :tada:

We’ll probably make a v2.4.1 release in a little while (we’re not going to rush into it, timeline TBD)

16

This topic was automatically closed after 30 days. New replies are no longer allowed.