I am looking to try and get haproxy to rewrite a url on the backend. For example if the end user navigates to bitechomp.domain.com they should only see this URL but the request to the backend server needs to have the request re-written to include a path. e.g. bitechomp.domain.com/bitechomp
I believe I have the regex to match it, but struggling to find the syntax to then just have it add the folder path at the end.
^([a-zA-Z0-9]/)?(bitechomp).$
I believe I have resolved this.
http-request set-path /bitechomp/ if { path_reg ^([a-zA-Z0-9]/)?(bitechomp).$ }
This works for any domain so both bitechomp.domain1.com and bitechomp.domain2.com would be re-written to bitechomp.domain1.com/bitechomp and bitechomp.domain2.com/bitechomp
Only answers I can find for this have specific parameters and don't work if the parameters change.
I have a URL coming in such as:
/logs.php?user_id=10032&account_id=10099&message=0&interval=1&online=1&rsid=65374826&action=update&ids=827,9210,82930&session_id=1211546313-1602275138
I need to redirect this url to a completely different domain and file but keep the get params.
So it ends up redirecting to:
https://example.com/the_logger.php?REPEAT_ALL_GET_PARAMETERS_HERE
Here is what I have unsuccessfully tried so far:
location logs.php
{
rewrite https://example.com/the_logger.php?$args last;
}
But it doesn't seem to match the url or redirect. I think I'm misunderstanding the logic of nginx confs. If it were .htaccess I think I'd be okay. I can put a few more examples here if need be of what I'm trying to achieve.
As you state this is a redirect and not reverse proxying a request, I would use the return directive to tell the client to do a 301 or 302. Using the return directive is the simpler and more recommend approach to redirecting a client.
Something like should do what you want:
location /logs {
return 302 https://example.com/the_logger.php$is_args$args;
}
Where $is_args would output a ? if and only if the query string is not empty, and $args is the query string itself
Welcome essence of the problem.
We have a path
site.com/seveniry-dlya-turistov/...
(Where ... is the character code specific record (of goods), and in front of it, as you might guess - section of this article)
Those show on site.com website under "souvenirs for tourists" page of a souvenir.
I need to redirect this type:
If there is a request to .../eveniry-dlya-turistov/.. substitute the section title in the name of .../seveniry/..., see if there is a request for
site.com/seveniry-dlya-turistov/elemnet1/
we have to do a 301 redirect to
site.com/seveniry/elemnet1/
Please tell me how to do it, and why does not work like that ...
location /catalog {
rewrite ^/catalog/souvernirs-for-tourists/(.*)$ http://SITE-NAME/suveniry/$1 permanent;
}
Thanks in advance for your help!
Should be something like
rewrite ^/seveniry-dlya-turistov/(.*)$ /seveniry/$1 last;
But you need to test the exact regex since it's hard to do by head without testing. nginx will look for another location block matching /seveniry/$1 to serve content.
I need to place a Mojolicious app behind an Apache reverse proxy. I've been unable to get Mojolicious to generate working URLs when behind the proxy.
I'm using Mojolicious 6.14 with Perl 5.18.1.
Here's my Apache reverse proxy configuration which I set based on https://github.com/kraih/mojo/wiki/Apache-deployment (in the path section).
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyRequests Off
ProxyPreserveHost On
ProxyPass /app1 http://localhost:3000/ keepalive=On
ProxyPassReverse /app1 http://localhost:3000/
RequestHeader set X-Forwarded-HTTPS "0"
Here's my test case.
use 5.014;
use Mojolicious::Lite;
app->hook('before_dispatch' => sub {
my $self = shift;
if ($self->req->headers->header('X-Forwarded-Host')) {
#Proxy Path setting
my $path = shift #{$self->req->url->path->parts};
push #{$self->req->url->base->path->parts}, $path;
}
});
any '/' => sub {
my $c = shift;
$c->render('index');
};
any '/test' => sub {
my $c = shift;
$c->render('test');
};
app->start;
__DATA__
## index.html.ep
<!DOCTYPE html>
<html>
<head><title>Index Page</title></head>
<body>
<p>Index page</p>
<p>
%= link_to 'Go to Test Page' => '/test'
</p>
</body>
</html>
## test.html.ep
<!DOCTYPE html>
<html>
<head><title>Test Page</title></head>
<body>
<p>Test page</p>
<p>
%= link_to 'Return to home page' => '/'
</p>
</body>
</html>
I can see the index page when I access http://www.example.com/app1, but the link to the test page is incorrect. The link is //test when I expected it to be http://www.example.com/app1/test.
Here's the HTML output from the test case.
<!DOCTYPE html>
<html>
<head><title>Index Page</title></head>
<body>
<p>Index page</p>
<p>
Go to Test Page
</p>
</body>
</html>
How can I tell Mojolicious what the base URL is for my app so it generates the correct links?
Maybe need to replace server proxy pass on http://localhost:3000/app1 in apache config:
ProxyPass /app1 http://localhost:3000/app1 keepalive=On
ProxyPassReverse /app1 http://localhost:3000/app1
That's a good question! Judging by some of the answers here and elsewhere, there seems to be a general lack of understanding of how the Apache reverse proxy settings affect the Mojolicious application and what the hook is supposed to do.
You've received an answer that's basically correct, but it begins with "Maybe [need to replace server proxy pass..." and it doesn't provide any explanation. A trial-and-error approach may or may not work for you. If your hook works differently, it probably won't.
Apache reverse proxy
This is your reverse proxy configuration (trailing slash removed, see below):
ProxyPass /app1 http://localhost:3000 keepalive=On
Quoting from the Apache documentation:
Suppose the local server has address http://example.com/; then
| ProxyPass /mirror/foo/ http://backend.example.com/
will cause a local request for http://example.com/mirror/foo/bar to be internally converted into a proxy request to http://backend.example.com/bar.
Now, assuming your Apache is listening on localhost:80 and your (Morbo) application server is listening on port 3000, a request to http://localhost/app1 is received by the Apache and forwarded to your application as /. The app1 prefix has been lost, which is why it's missing from the base url, i.e., it's missing in all the links. To fix urls generated by the application, this prefix must be added to the base url, which leads us to the hook.
Hook
This is your hook function:
if ($self->req->headers->header('X-Forwarded-Host')) { # 1. if
my $path = shift #{$self->req->url->path->parts}; # 2. shift
push #{$self->req->url->base->path->parts}, $path; # 3. push
}
This hook is supposed to fix the base url. As explained above, the app1 prefix needs to be added to the base url, which is prepended to all generated urls. If one of your templates links to /test, the base url should look like /app1 to get the final url /app1/test.
This is what your hook does:
By checking for the X-Forwarded-Host, you make sure to only modify the base url if the request came through the reverse proxy. This works because the mod_proxy_http module (documentation) automatically sets that header. Without that check, you wouldn't be able to access your application server directly under localhost:3000, all urls would be broken.
In fact, I asked the question on how this distinction should be made in a reliable way to fix the url prefix when using a reverse proxy without breaking requests going to the application server. Unfortunately, most of the answers I have received are wrong. But I believe checking for X-Forwarded-Host is good enough as it's set by Apache and not by Morbo or Hypnotoad. In fact, it's set by reverse proxies, which is precisely what you're looking for.
This shift is supposed to extract the prefix from the request url.
This is necessary because, strictly speaking, appending the application prefix to the ProxyPass directive manipulates the final request url, so your application receives a request for /app1/. Of course, there's no route for that address because the router in your application doesn't know that /app1 is the prefix of that instance rather than a relative application url.
Clearly, adding the hard-coded prefix /app1 to all templates (as some might be tempted to do) would not work if you deployed another copy of the same application under /app2. Even if you didn't, you'd still have to change all the links if your provider forces you to change the app1 prefix to app_one. This is why the prefix is picked up in that hook, stored to make links work (see #3) and then removed from the request url to make the router happy.
This is where the /app1 prefix, a single path token, is appended to the base url. The base url is prepended to urls generated in your templates. This is what turns /test into /app1/test (if the request came through the reverse proxy).
In your case, /test is turned into //test because you're missing the prefix. I've explained that at the end of this answer.
Fix reverse proxy
That being said, your reverse proxy needs to manipulate the request url to include the prefix in order to make the hook work:
ProxyPass /app1 http://localhost:3000/app1
After this modification, your hook works:
It modifies the base url only if a reverse proxy header is set because the modification is only necessary when a reverse proxy is used.
All requests going to the Mojolicious application will have the /app1 prefix, e.g., /app1/test. In this step, the prefix is removed to turn the url into /test.
The prefix removed in step 2 is appended to the base url, which is later used to generate links.
This should explain why you need to add the application prefix to the ProxyPass line. Without that explanation, someone else might try to do just that without success because they might have a different hook function.
Slashes
A single slash can break everything and cause most requests to fail with error 404.
Note that the local target url in your ProxyPass line (second argument) has a trailing slash but the path argument doesn't. If those don't match, you might end up with double slashes in the request url and some requests could fail.
From the Apache documentation:
If the first argument ends with a trailing /, the second argument should also end with a trailing /, and vice versa. Otherwise, the resulting requests to the backend may miss some needed slashes and do not deliver the expected results.
Now, if you remove the trailing slash but forget the prefix...
ProxyPass /app1 http://localhost:3000
... generated urls will still have two leading slashes: url_for '/test' = //test
That's because you're appending undef to the base url where you want to append the application prefix.
What happens is that in step 2 (see above), you extract the prefix, assuming the application is running exactly one level below the document root, i.e., your prefix is something like app1 and not apps/app1 (in which case the shift/push routine has to be run twice). But there's no prefix in the ProxyPass directive, so your application sees something like /, in other words, there's nothing to extract from parts. And there's no safeguard in the code either, so you end up pushing undef to the parts array of the base url. If you then generate a url, Mojolicious is adding an extra slash for that undef element, which is why you get //test. The parts array looks like this:
"parts" => [
undef,
"test"
],
To fix this double slash error, you can add a safeguard to your hook:
my $path = shift #{$self->req->url->path->parts};
if ($path) { # safeguard
push #{$self->req->url->base->path->parts}, $path;
}
Of course, as long as your reverse proxy configuration has the prefix in it, $path should always be defined.
One could certainly argue that this approach is a hack because it manipulates the url. Hacks tend to fail under certain circumstances. In this case, it would fail if you were to manually set the X-Forwarded-Host while accessing the application server directly. I mentioned that in my question. But as developer, you're probably the only person who has direct access to that application server, as the firewall would only allow external requests to the reverse proxy in a typical production environment. I'll leave it at that.
Somehow a workaround, but this is how I solved this problem:
In the configuration-file (.conf) I define the the base-url:
base_url => 'https://booking.business-apartments.wien',
This allows me to write templates like this:
%= link_to 'Payment Information' => ( config('base_url') . url_for('intern/invoice/list_payments/') );
May you should try to update your Mojolicious to a newer version? I remember I had a similar problem and I solved it with a code where I explicitly defined the url for the proxy and appended it to every request (similar to lanti's answer). After some mojolicious update the code was not necessary anymore.
Moreover, I think I use the same config as proposed by Logioniz.
When you mount your app into some point (not root / ) it is curious to get working it. Look at Mojolicious::Controller::url_for
# Make path absolute
my $base_path = $base->path;
unshift #{$path->parts}, #{$base_path->parts};
$base_path->parts([])->trailing_slash(0);
Here you can control what is generated.
I would like to use Nginx as my CDN for a file hosting system. I saw a great module for nginx that allows postgres connection (https://github.com/FRiCKLE/ngx_postgres) it works really well, however when I try to use it while having alias directive it seems to ignore the alias or file download and rather give me an empty file.
My idea is, to use the UUID from the URL and find the correct file doing a query and then using the found details to change the filename header so that the user's client will download automatically set the name to the original filename instead of a uuid.
Here is the code.
location /dl{
postgres_output none;
postgres_pass database;
postgres_query "SELECT * FROM \"Files\" WHERE uuid = '$args'";
postgres_set $filename 0 name;
alias /home/ubuntu/fileStorage;
add_header Content-Disposition "attachment; filename=$filename";
}
I think somehow the postgres directive is locking up this block. Is there a way I can run the postgres query without effecting the download block?
It seem that you expect that the line
add_header Content-Disposition "attachment; filename=$filename";
will cause the browser to download the file given by $filename. This is not how the Content-Disposition header works, it simply tells the browser to interpret the response body as a file. You're going to have to do something additional to get the proper content to the client. Perhaps what you really want is to issue a redirect?