Probably best to make distinct files so that bucks.benco's header_rewrite file is different from gertrude.benco's. You can have it all in the same file, but, as you point out, you'd need to have an extra conditional line in each to match the host/path/whatever. Like:

cond %{CLIENT-URL:HOST} =""
  set-redirect 301 "http://..."

cond %{CLIENT-URL:HOST} =""
  set-redirect 301 "http://..."

Depending on what you need to do, you may end up with both -- like if you needed to have different rules for different file extensions, you probably can't get away with writing specific remap rules, and would need to have the above sort of pattern.

On Sun, Mar 28, 2021 at 10:42 AM Patrick Andrews <> wrote:
As an aside, let's say I had to do multiple of those. Would you recommend creating a config file for each instance? Or is it better to utilize that one as a kind of list? If so, how would I designate between different entries? I'll consult the documents but figured I'd ask.

On Sun, Mar 28, 2021 at 1:39 PM Patrick Andrews <> wrote:
That was it! Holy cow what a journey. Thanks for your assistance, Miles! Do you have anything setup like a "buymeacoffee" or something? I'd love to throw you a token of my appreciation. This has been a real speed bump in getting this finished!

On Sun, Mar 28, 2021 at 1:35 PM Miles Libbey <> wrote:
That's what I get for not actually testing before recommending it :) The url apparently needs to be quoted:
set-redirect 301 ""
keeps the "=":
turns it into a space:


On Sun, Mar 28, 2021 at 10:23 AM Patrick Andrews <> wrote:
Hey Miles,

Thanks again for as your help. I did not have any luck with the regex remap, I was getting errors in my diags.log after traffic_ctl reloading it. 

I did have more luck with the rewrite plugin, however, I am unfortunately seeing this url now:

That "%20" in my url should be an "="

When I wireshark the actual HTTP redirect packet, I'm seeing the following:

You'll notice the space between Rp and https

So I'm not entirely sure why that's happening either. Here is my config setup per your instructions:



On Sun, Mar 28, 2021 at 12:15 PM Miles Libbey <> wrote:
FWIW, that dynamic cache setting should not be in play, as the response is generated directly, not coming from an origin server.

But, your redirect mapping looks reasonable, and it's not apparent why it isn't working for you.

There are other ways to do this that you could try:
- regex remap plugin:
map @pparam=redirect.config
(the origin doesn't matter here, as long as it exists in DNS -- it isn't used)
then in redirect.config
(if you want to put the original path in the location, append $0 to the second field ... and I was too lazy to transpose the screenshot to text -- so replace the "."s :)

- header_rewrite plugin
map @pparam=hdr_rewrite.config
then in hdr_rewrite.config
(and here, you could also set a more appropriate Cache-Control: setting for a permanent redirect. -- like 
  set-header Cache-Control "max-age=8640000, public"
(and frequently when I'm troubleshooting with header_rewrite, I throw in a temporary header to "prove" I got there -- like
  set-header Patrick "debugging"

If these don't work, then there is some other interaction going on... like another remap being too greedy etc.

On Sun, Mar 28, 2021 at 5:29 AM Patrick Andrews <> wrote:
Hey Miles,

Yes, the white background is a wireshark capture of the redirect packet sent to my client machine. So basically what I'm seeing is that the client machine, through DNS, hits the proxy. The proxy then serves the client machine that white screenshot. What you'll notice in the red underline is that the packet is showing a path that does not contain the full URL in the redirect instructions. This originally led me down a rabbithole to find that my redirect configuration contains a dynamic url that requires that additional config as per the documentation. The issue, however, is that I have that configuration set and it still isn't redirecting. 

My apologies for the first screenshot. I did a curl on the host box accurately this time:

And it looks like it is serving that incorrectly. Here is the redirect config:


So my question is - How do I get everything past the .aspx?... onward to be shown? I've already taken steps in the documentation to enable dynamic url caching (proxy.config.http.cache.cache_urls_that_look_dynamic)

And I'm at a loss at what else I can do. Thanks for your help.

On Sat, Mar 27, 2021 at 9:54 PM Miles Libbey <> wrote:
Ah -- the redirect remap rule-- had forgotten that existed! So that doesn't need or talk to any other machine. I'm a bit confused about what the 2 curls are -- one has Server: ats 5, and the other Server ATS 9.

Just threw a redirect on one of ours:


[18:49:02]$ curl -sIXGET --resolve "" | grep -i Location
[18:49:13]$ curl -sIXGET --resolve "" | grep -i Location
[18:49:22]$ curl -sIXGET --resolve "" | grep -i Location

Is the second machine (the white background screeny) proxying to the first (black background)?


On Sat, Mar 27, 2021 at 2:21 PM Patrick Andrews <> wrote:
Everything on the server is mostly default. It just seems as, from what I can gather, the redirect reply isn't sending the fully configured url despite having that configuration as instructed. I'm not quite sure where else to look or tweak. 

Let me know if the details I sent weren't sufficient.

On Sat, Mar 27, 2021 at 5:00 PM Patrick Andrews <> wrote:
Hey Miles,

Curl from the server:

and the response I'm getting on my service box is as follows:


You'll notice that the redirect gets cut off via the .aspx. I am aware of the Dynamic Content Caching configuration required in records.config and do have it on:

CONFIG proxy.config.httpcache.cache_urls_that_look_dynamic INT 1

On Sat, Mar 27, 2021 at 4:52 PM Patrick Andrews <> wrote:
Standby I did not finish my reply. That is simply the remap rule. Apologies.

On Sat, Mar 27, 2021 at 4:51 PM Patrick Andrews <> wrote:
Hey Miles,

Thrilled I got a response so quickly. If you can imagine a beleaguered sysadmin who's been trying to get this to work for too many hours now then you've got a good image where I'm at. Here's what I've got:

a) remap rule is as follows:

On Sat, Mar 27, 2021 at 4:47 PM Miles Libbey <> wrote:
When you say "redirecting" do you mean returning a 301/302/303/307/308
status code?

Can you share
a) the remap rule
b) a curl with response headers through your ATS instance -- like curl
-s -IXGET --resolve
c) a curl with response headers to the origin used (like ATS would send to it
and d) what headers/response you were expecting?


On Sat, Mar 27, 2021 at 1:27 PM Patrick Andrews <> wrote:
> I'm having some issues with getting ATS to redirect to a link containing .aspx. I am aware of the config setting in records.config and dynamic caching and have made the configuration changes as per the documentation. When I analyze the redirect via wireshark, however, I am still seeing that it's not redirecting properly the entire URL. I have an older box running version 6 so I know that at one point it was capable of doing so. Is there somewhere else I'm missing or have to configure?
> Thanks.