I have a server in Azure running two web apps, one on port 443 (IIS), another on 1024 (Apache). Both are https. I have an Azure Application Gateway (WAF v2) in place. I would like to allow requests for subdomain1.domain.com to go through on 443 (which is set-up and working) and requests for subdomain2.domain.com to be re-written to port 1024 internally.
I have tried various combinations of conditions and actions, but cannot get anything to do anything at all, good bad or indifferent!
My current Condition is as follows
Type of variable to check: HTTP Header
Header type: Response Header
Header name: Common Header
Common header: Location
Case-sensitive: No
Operator: =
Pattern to match: (https?):\/\/.*subdomain2.domain.com(.*)$
My current action is:
Re-write type: Response Header
Action type: Set
Header name: Common header
Common header: Location
Header value: https://backendservername.domain.com:1024{http_resp_Location_2}
I can't find a combination that does anything at all, nor any examples that show port updates. I've tried using request headers and the host value, but unfortunately that conflicts with the host rewrite in the HTTP Settings that was necessary to get any end to end SSL working.
Thanks in advance.
Matt.
Related
I want to implement a custom nginx cache control method from my scripts, by using a custom header: "Do-Cache".
I used in http block of nginx:
map $sent_http_do_cache $nocache {
public 0;
default 1;
}
And in the server block of nginx:
fastcgi_cache_bypass $nocache;
fastcgi_no_cache $nocache;
So, for Do-Cache: public, nginx should cache the response. Otherwise not.
But this configuration is not working. By debuging into logs the values of $sent_http_do_cache and $nocache are the right ones, until they are used in server block of nginx. If using them in the server block (fastcgi_cache_bypass $nocache, or a simple set $a $nocache), the $nocache variable got the "1" value, and $sent_http_do_cache - "-".
Is the any other way of managing the cache of nginx based on custom header in response?
Caching based on the response header cannot be done because it implies that Nginx must proxy the request back to the backend and check its response, defeating the purpose of the proxy cache.
I want to develop a Monitoring-WebApp for different things with AngularJS as Frontend. One of the core-elements is showing an overview of Nexus-Artifacts/Repositories.
When I request the REST-API I'm getting following error back:
No 'Access-Control-Allow-Origin' header is present on the requested resource.
Origin 'http://localhost:9090' is therefore not allowed access.
To fix this error, I need to modify the response headers to enable CORS.
It would be great if anyone is familiar with that type of problem and could give me an answer!
The CORS headers are present in the response of the system you are trying to invoke. (Those are checked on the client side [aka browser this case], you can implement a call on your backend to have those calls and there you can ignore those headers, but that could become quite hard to maintain.) To change those you'll need a proxy. So your application will not call the url directly like
fetch("http://localhost:9090/api/sometest")
There are at least two ways: one to add a proxy directly before the sonar server and modify the headers for everyone. I do not really recommend this because of security reasons. :)
The other more maintaneable solution is to go through the local domain of the monitoring web app as follows:
fetch("/proxy/nexus/api/sometest")
To achieve this you need to setup a proxy where your application is running. This could map the different services which you depend on, and modify the headers if necessary.
I do not know which application http server are you going to use, but here are some proxy configuration documentations on the topic:
For Apache HTTPD mod_proxy you could use a configuration similar to this:
ProxyPass "/proxy/nexus/" "http://localhost:9090/"
ProxyPassReverse "/proxy/nexus/" "http://localhost:9090/"
It is maybe necessary to use the cookies as well so you may need to take a look at the following configurations:
ProxyPassReverseCookiePath
ProxyPassReverseCookieDomain
For Nginx location you could employ something as follows
location /proxy/nexus/ {
proxy_pass http://localhost:9090/;
}
For node.js see documentation: https://github.com/nodejitsu/node-http-proxy
module.exports = (req, res, next) => {
proxy.web(req, res, {
target: 'http://localhost:4003/',
buffer: streamify(req.rawBody)
}, next);
};
I'm building my first CouchApp (a simple blogging engine) in order to learn more about it. Now, I have it working to the point that the following URL returns blog posts:
http://127.0.0.1:5984/couchblog/_design/couchblog/_list/index/posts
I have a view called posts that returns my posts, and a list called index that renders the posts. So I figured my next step was to rewrite the URLs to something a bit friendlier. Unfortunately the documentation on URL rewriting seems a tad vague, and I just can't seem to get anything to work.
The rewrite section of my design document looks like this:
rewrites: [{
from: '../../../',
to: '/_list/index/posts',
method: 'GET',
query: ''
}],
I'd like to rewrite it so that it serves the list of blog posts from the web server root, but I just can't seem to get anywhere with it. Can anyone see what I'm doing wrong? I'm using CouchDB 1.6.0 on OS X Snow Leopard via Homebrew.
I'd like to rewrite it so that it serves the list of blog posts from the web server root
I think you need to configure your vhosts settings in the couchdb config for that. This is covered pretty well in the vhosts section so I will just post the relevant part here:-
To add a virtual host, add a CNAME pointer to the DNS for your domain name. For development and testing, it is sufficient to add an entry in the hosts file, typically /etc/hosts` on Unix-like operating systems:
# CouchDB vhost definitions, refer to local.ini for further details
127.0.0.1 couchdb.local
Test that this is working:
$ ping couchdb.local
PING couchdb.local (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_req=1 ttl=64 time=0.025 ms
64 bytes from localhost (127.0.0.1): icmp_req=2 ttl=64 time=0.051 ms
Finally, add an entry to your configuration file in the [vhosts]* section:
[vhosts]
couchdb.local:5984 = /example
*.couchdb.local:5984 = /example
If your CouchDB is listening on the the default HTTP port (80), or is sitting behind a proxy, then you don’t need to specify a port number in the vhost key.
*By the way you can do this from futon as well. Just make sure to restart couchdb after you have configured your vhosts section. Other wise changes will have no effect.
For our case however we need to map the vhosts section to the rewrite handler on our database. So our vhosts will look something like this:-
couchdb.local:5984 = your-db/_design/your-design/_rewrite
Modify your rewirtes handler as well
rewrites: [{
from: 'index',
to: '/_list/index/posts',
method: 'GET',
query: ''
}]
Now if you issue a request to
couchdb.local:5984/index
You should see a list of posts.
I am attempting to configure an owncloud server that rewrites all incoming requests and ships them back out at the exact same domain and request uri but change the scheme from http to https.
This is failed miserably. I tried:
redirect 301 https://$hostname/$request_uri
and
rewrite ^ https://$hostname/$request_uri
Anyway, after removing that just to make sure the basic nginx configuration would work it as it had prior to adding the ssl redirects/rewrites it will NOT stop changing the scheme to https.
Is there a cached list somewhere in nginx's configuration that keeps hold of redirect/rewrite protocols? I cleared my browser cache completely and it will not stop.
AH HA!
in config/config.php there was a line
'forcessl' => true,
Stupid line got switched on when it received a request at the 443 port.
Turned off and standard http owncloud works and neither apache/nginx are redirecting to ssl.
Phew.
I need to redirect anyone with a mobile user agent to a file called mobile.php.
My web hosting provider, Net Registry uses the Zeus web server.
Here's the script I've written from my research
RULE_1_START:
# get the document root
map path into SCRATCH:DOCROOT from /
match IN:User-Agent into $ with iPad|iPod|iPhone|Android|s+Mobile
if matched then
set OUT:Location = /mobile.php
endif
RULE_1_END:
I used the instructions on my host's site.
I pasted that into their console and it has worked to do redirects. Net registry have some odd console thing that you submit and it takes 10 minutes to update the zeus server config (annoying as hell).
Anyway my issue is that it redirects me to the wrong location:
So if you visit the site, with a user agent string that contains ipad|ipod|android|\s+mobile then you will trigger it ()
It takes me here:
http://example.com.au/mobile.php,%20catalog/index.php
I can't work out how to fix that, or why that happens because at the moment this file exists:
http://example.com.au/mobile.php
as does this one:
http://example.com.au/index.php. Contents of this file are:
<?php header("Location: catalog/index.php");
Any ideas on how I can make this work more like an apache .htaccess url Rewrite?
the official Zeus documentation
Fixed it by changing
set OUT:Location = /mobile.php
to
set URL = /mobile.php
From the manual...
Using Request Rewrite Scripts
To use the request rewriting functionality, create a script in the Zeus Request
Rewrite Scripting Language. The script contains instructions telling the
Virtual Server how to change the URL or headers of requests that match specified criteria.
The Virtual Server compiles the script, and (if the rewrite functionality is
enabled) uses it every time it receives a request. It runs the commands in the
script, changing the URL if it matches the specified criteria. Once the script is
finished, the Virtual Server continues processing the resulting URL.Zeus Web Server 4.3 User Guide
142 Configuring URL Handling
When changing the URL, the rewrite functionality can only change the local
part of it, that is, the part of the URL after the host name. For example, if a
user requests http://www.myhost.com/sales/uk.html, the rewrite
functionality can only make changes to /sales/uk.html. This means that
you cannot use the rewrite functionality to change the request to refer to a
file on another Virtual Server.
For example, the following script illustrates how to change requests for any
HTML files in the /sales directory so that the user receives them from the
/newsales directory instead:
match URL into $ with ^/sales/(.).html
if matched set URL=/newsales/$1.html
The rewrite functionality can also change the HTTP headers that were received
with a request, and create new HTTP headers to be returned to the user. For
example, the following script changes the HTTP host header, so that a request
for www.mysite.com/subserver is redirected to the Subserver
www.subserver.mysite.com:
match URL into $ with ^/([^/]+)/(.)$
if matched then
set IN:Host = www.$1.mysite.com
set URL = /$2
endif