Currently, I'm making a website and I would like this site to redirect (via .htaccess) to another domain WITHOUT reloading the page. Because in all the tutorials I saw, it loaded the page of the new domain. Outside what I want is that it keeps the page of the base domain while displaying the URL of the new domain.
Example:
redirect this site
https://DOMAIN1.US/folder1/folder2/page.html?param=1¶m=2
to this site
https://DOMAIN2.US/folder1/folder2/page.html?param=1¶m=2
i dont have the access to the main server config. Htaccess cannot "fake redirect" ??
What you are asking for is not a simple "redirect" (which is managed by the browser). You need to configure the server that hosts domain1.com as a "reverse proxy" - since this needs to be managed entirely server-side.
The user sends a request to domain1.com. The server at domain1.com then constructs an internal HTTP request (reverse proxy) to domain2.com. The response from domain2.com is then sent back to the server at domain1.com which then forwards the (possibly "rewritten") response back to the client.
This requires additional modules enabled on the server at domain1.com, ie. mod_proxy, mod_proxy_http and additional (optional) modules such as mod_proxy_html, etc. depending on your requirements.
Ideally, you would then configure this in the server config (or VirtualHost container). Notably, you would need to set ProxyPassReverse (in the server config) to cover the scenario of domain2.com issuing an external redirect to itself. The proxy server needs to rewrite the response headers so that the redirect goes to domain1.com, not domain2.com. ProxyPassReverse cannot be set in .htaccess.
You can then use mod_rewrite with mod_proxy by using the P flag. This part you can do in .htaccess. For example, to proxy the request from https://DOMAIN1.US/folder1/folder2/page.html?param=1¶m=2 to https://DOMAIN2.US/folder1/folder2/page.html?param=1¶m=2.
RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?domain1\.us [NC]
RewriteRule ^ https://domain2.us%{REQUEST_URI} [P]
If you have access to the server config then you can do this more simply with the ProxyPass directive (no need for mod_rewrite in this instance since the source and target URLs are the same).
Reference:
https://httpd.apache.org/docs/2.4/mod/mod_proxy.html
Related
I registered a expired domain to forward all incoming links to another domain. The problem is: many inlinks are placed on subdomains, for example: axa-art.cdn.contento-v41.eu/axa-art/0eee9cec-58cb-45b2-a4e2-b5f73920068e_091216_axa+art_classic+car+study_de_rz.pdf
I am looking for a 301 redirect rule in htaccess that forward any url (no matter on main domain or subdomain) to "new-url.tld"
axa-art.cdn.contento-v41.eu
axa-art.cdn.contento-v41.eu/slug
any-subdomain.contento-v41.eu
any-subdomain.contento-v41.eu/slug
all of this example above should
forward to this exact URL: new-domain.tld
Question 1:
Is it possible to create a "general" rule and place it into htaccess of the main directory?
Question 2:
Or do i have to write a specific rule for each subdomain?
Question 3:
Do I have to create a sub-directory and create a separate htaccess in every sub-directory for each subdomain I want to add redirection-rules?
Help or suggestions are highly appreciated. Thank you very much for your help in advance.
This isn't just a .htaccess question. In order for your server to receive requests to <any-subdomain>.example.com the necessary DNS and server config directives need to be in place. If the request doesn't reach your server then you can't implement a redirect in .htaccess.
So, I suspect that these subdomains are not even resolving?
You either need to create the necessary DNS A records and ServerAlias directives one by one for each hostname (ie. subdomain) or create a "wildcard" DNS A record (and ServerAlias *.example.com directive in the vHost). But then you still have an issue with these hostnames being covered by an SSL cert if you need to redirect from HTTPS.
You can then create the necessary redirect in .htaccess. Although, since you need access to the server config (or a using a control panel that does this for you) to implement the directives above, you should also implement this redirect in the server config also.
For example, at the top of your .htaccess file, before the existing directives (or in your vHost):
RewriteEngine On
RewriteCond %{HTTP_HOST} !^new\.example$
RewriteRule ^ https://new.example%{REQUEST_URI} [R=301,L]
The above states... for any request that is not for new.example then 301 redirect to https://new.example/<same-url>.
However, if you have access to the server config and this other domain is configured in its own vHost container then the redirect can be simplified:
Redirect 301 / https://new.example/
UPDATE#1:
this rule does forward any URL form the main domain to the new domain.
# Permanent URL redirect- by netgrade
RewriteEngine on
RewriteCond %{REQUEST_URI} !https://www.marco-mahling.de/$
RewriteRule $ https://www.marco-mahling.de/ [R=302,L]
The rule I posted above should probably replace your existing rule entirely.
Yes, your rule does redirect every URL to the root of the new domain, but it is arguably incorrect. The RewriteCond directive is superflous and isn't actually doing anything. The REQUEST_URI server variable contains the URL-path, it never contains the scheme + hostname. So, the RewriteCond directive you've posted will always be successful.
If that is the rule you currently have then it would already redirect everything. In which case your problem would seem to the necessary DNS and server config directives as mentioned above.
From your directives, I assume that the other domain actually points to a different server (or different vHost on the same server). Otherwise, this would have resulted in a redirect-loop. In which case, you only need the much simpler Redirect directive that I posted above.
UPDATE#2: That works fine BUT the incoming links are still not forwarded cuz of a "%" in the url: https://axa-art.cdn.contento-v41.eu/axa-art%2F0eee9cec-58cb-45b2-a4e2-b5f73920068e_091216_axa+art_classic+car+study_de_rz.pdf
It's actually because of the %2F - an encoded slash (/) in the URL-path. By default, Apache will reject such URLs with a 404 (for security reasons).
To allow encoded slashes in the URL you would need to set AllowEncodedSlashes On in the server config (or vHost container). You cannot set this in .htaccess. (The server generated 404 occurs before .htaccess is even processed.)
However, I would express caution about enabling this feature. (Is there a specific requirement here? Are you recreating these documents on the new server?)
If this request was intended to map directly to a PDF file on disk then this actually looks like an incorrectly URL encoded request, since a slash / is not a permitted filename character on either Windows or Linux.
If you enable AllowEncodedSlashes then the above RewriteRule will redirect the request to /axa-art/0eee9cec....pdf - note the %-decoded / in the resulting URL. You would need to take additional steps to maintain the URL-encoding (if that was required), but as I say, that looks like a mistake to begin with.
environment http://etrafficcontrol.com/misc/proxy.png
I have two applications. One is an e-commerce site (Drupal 7 running on LAMP) hosted on AWS, and the other is the checkout system which is ASP on IIS-6, is located inside our company, and requires SSL.
Currently we put up with the situation where our customers get forwarded to another domain for checkout -- kind of like what happens with ebay and PayPal. But this leads to difficulty with site tracking code, and kind of feels wrong for the shopper to get forwarded off of the e-commerce site for checkout.
The main concern is that we use Google campaigns, so we want to track conversions from advertising to, and rich content on, domain-1, but the actual sale happens at the time of checkout on domain-2.
Rather than send visitors from www.domain1.com/cart to domain2.com/miscX, I've tried to setup ProxyPass and ProxyPassReverse so I can send them to www.domain1.com/shop/miscX.
App1 (drupal) is in domain1.com/*, and the .htaccess stuff bypasses Drupal's design to intercept everything. The "misc" paths come from the fact that I'm redirecting into a subdirectory, and then proxying from there. When the proxied pages render, they have some hard-coded paths to /miscX, and without making special provisions for those during the rediects, I wind up with /miscX/ (instead of /shop/miscX/ which will follow the proxy) and that causes missing css, js, etc.
Note: Our business customers can login directly to domain2.com, so I'd like to keep that portal unchanged.
Below, local-d7 is a local test instance of the domain1 server. A test of the proxy shows that this concept works, with SSL.
I have this almost working, but it seems like URL-encoded parameters are being lost (even though query strings are ok). When I introduce the proxy, server2 doesn't appear see encoded params (it's a specialized app and I don't know how to view what IIS is receiving). When I route the domain2 test portal login thru apache on server-1 in such a way that doesn't have encoded params, the login works.
In effect I'm trying to
reverse proxy
change path (put an app running in / on domain-2 and expose into a subdir "/shop" on Domain-1
support SSL
proxy an IIS server behind Apache
try to not modify the IIS server so that it can continue to be used by it's original domain-2.com URL, and
do this on a hosted server where I [may] have limited configuration control of Apache. (currently testing on XAMPP).
I've tried all sorts of things in addition to what's shown here, including rewriterules, redirects, etc. I'm just not experienced at all at mod_proxy or mod_rewrite, etc. But it seems to me that this arrangement of a proxy should be doable with some amount of work and possibly fixing server SSL certificates.
Advice? --Thanks
vhosts.conf
## Redirect /misc1/ https://local-d7/shop/misc1/
## Redirect /misc2/ https://local-d7/shop/misc2/
## Redirect /misc3/ https://local-d7/shop/misc3/
## ProxyRequests Off
## ProxyPreserveHost On
## RequestHeader set Proxy-SSL true
## ProxyPass /shop/ https://www.shop.com/
## ProxyPassReverse /shop/ https://www.shop.com/
ProxyPass /shop/ https://www.domain2.com/
ProxyPassReverse /shop/ https://www.domain2.com/
ProxyPass /misc1/ https://www.domain2.com/misc1/
ProxyPassReverse /misc1/ https://www.domain2.com/misc1/
ProxyPass /misc2/ https://www.domain2.com/misc2/
ProxyPassReverse /misc2/ https://www.domain2.com/misc2/
ProxyPass /misc3/ https://www.domain2.com/misc3/
ProxyPassReverse /misc3/ https://www.domain2.com/misc3/
.htaccess
RewriteCond %{REQUEST_URI} ^/misc1/
RewriteCond %{REQUEST_URI} ^/misc2/
RewriteCond %{REQUEST_URI} ^/misc3/
RewriteRule (.*) /shop/$1
I have a server server.example.com which serves Tomcat on port 80 via a ProxyPass/ProxyPassReverse to 8080 and a Drupal site on the same box at server.example.com:8001. If I enter in the port 8001 explicitly, the Drupal site behaves properly, but I need to make it accessible via server.example.com/blog so I created a ProxyPass/ProxyPassReverse for /blog http://server.example.com:8001 which serves the initial page for the Drupal site correctly, but once the form on the home page of Drupal is filled out and submitted, which POSTs to /, the site changes to the Tomcat site, presumably because the / is not relative to the current host on post :8001. How can I get the ProxyPass for /blog to remain persistent so that all subsequent requests remain within the :8001 VirtualHost (Drupal site)?
One thing I tried was with mod_rewrite:
RewriteCond %{HTTP_REFERER} /^blog/.*$
RewriteRule (.*) %{HTTP_HOST}:8001/$1 [L,P,NC]
But that did nothing at all as far as I can tell. I was hoping that if the initial request was for /blog then the referrer would be as well and I could keep requests on the :8001 virtualhost. Perhaps someone can explain why that is flawed.
The problem you are very likely running into is that the documents returned by Drupal include generated links that all reference / instead of /blog. mod_rewrite and proxypass don't do anything to the contents of documents -- they only act upon the request (or, in the case of ProxyPassReverse, on links such as Location: headers in returned content).
To make an application that normally expects to be installed as / operate on a different URL, you need either to :
(a) Configure the application to be aware of the proper base URL. Many applications include such a setting in order to support exactly the situation you have described.
(b) Install some sort of filtering proxy that can modify the content of returned documents. For Apache, mod_proxy_html is made to do exactly this. This is included natively in Apache 2.4 but may need to be installed separately for 2.2.
I have a local apache httpd hosting a mediawiki service that listen to port 3300. The service may access in my LAN via
http://mylan:3300/wiki/
I configure my internet router to add a port forwarding entry to the mylan:3300. I may then access to the wiki via something like:
http://<dynamic domain>:3300/wiki/
Next, I have a web site that serve globally. The web server is apache httpd too. I add a rewrite rule in .htaccess:
RewriteEngine On
RewriteRule ^/?wiki/?$ http://<dynamic domain>:3300/wiki/ [P]
I wish to access the wiki that host on my local LAN via the proxy method but using the global internet domain namespace:
http://<internet domain>/wiki/
After execute the above URL from internet browser, I can see the wiki contents. However, the URL shown in address bar change to
http://<dynamic domain>:3300/wiki/index.php/Main_Page
In order to test the proxy rewrite rule work, I try to change the rewrite rule to:
RewriteRule ^/?wiki/?$ http://www.google.com/search?q=test [P]
Open the URL:
http:///wiki/
lead me to google search page but the URL remain as http:///wiki/.
Any ideas why the rewrite rule
RewriteRule ^/?wiki/?$ http://<dynamic domain>:3300/wiki/ [P]
make the browser show the new URL address instead of internet domain name space:
http://<internet domain>/wiki/
A good example is:
RewriteRule ^/?wiki/(.*)$ http://en.wikipedia.org/wiki/$1 [P]
If we access the url:
http://<domain>/wiki/Country
The URL will always rewrite and shown as
http://en.wikipedia.org/wiki/Country
Instead, I expect it to show as
http://<domain>/wiki/Country
but the content is from http://en.wikipedia.org/wiki/Country
Probably a redirect that includes the full link. To rewrite them add something like:
ProxyPassReverse /wiki/ http://<dynamic domain>:3300/wiki/
I also notice in the Apache online documentation for URL Rewriting Guide - Advanced topics in the section on Content Handling, sub section Dynamic Mirror has this example:
RewriteEngine on
RewriteBase /~quux/
RewriteRule ^hotsheet/(.*)$ http://www.tstimpreso.com/hotsheet/$1 [P]
I'm pulling my hair out on what should be an insanely simple problem. We are running WebSphere IHS (Apache) through an F5 BigIP. BigIP is doing the https translation for us. Our url (changed for web, not valid) is https://superniftyserver.com/lawson/portal.
When someone types in just that without the slash after portal, Apache assumes "portal" to be a file and not a directory. When Apache finds out what it is, it sends the 301 Permanent Redirect. But since Apache knows only http, it sends the URL as http://superniftyserver.com/lawson/portal/ which then creates problems.
So I tried a server level httpd.conf change for mod_rewrite, this is one of the dozens of combinations I've tried.
RewriteEngine on
RewriteRule ^/lawson/portal(.*) /lawson/portal/$1
I also tried
RewriteRule ^/lawson/portal$ /lawson/portal/
Among many other things... What am I missing?
If you can't get an answer on the RewriteRule syntax, here are two other options for you: Write an custom iRule on BigIp (see F5 DevCentral) that looks for 301 responses and convert them to SSL; let the URL pass into your WebSphere server and do a programmatic redirect that sends out HTTPS. However, because F5 terminates the SSL connection, you have to set a custom header that you configure (see PQ86347) so the Java request.getScheme() works as you would expect.
Fixed!
SOL6912: Configuring an HTTP profile to rewrite URLs so that redirects from an HTTP server specify the HTTPS protocol
Updated: 8/7/07 12:00 AM
A ClientSSL virtual server is typically configured to accept HTTPS connections from a client, decrypt the SSL session, and send the unencrypted HTTP request to the web server.
When a requested URI does not include a trailing slash (a forward slash, such as /, at the end of the URI), some web servers generate a courtesy redirect. Without a trailing slash, the web server will first treat the resource specified in the URI as a file. If the file cannot be found, the web server may search for a directory with the same name and if found, send an HTTP 302 redirect response back to the client with a trailing slash. The redirect will be returned to the client in HTTP mode rather than HTTPS, causing the SSL session to fail.
Following is an example of how an HTTP 302 redirect response causes the SSL session to fail:
· To request an SSL session, a user types https://www.f5.com/stuff without a trailing slash.
· The client browser sends an SSL request to the ClientSSL virtual server, which resides on the BIG-IP LTM system.
· The BIG-IP LTM system then decrypts the request and sends a GET /stuff command to the web server.
· Since the /stuff file does not exist on the web server, but a /stuff/ virtual directory exists, the web server sends an HTTP 302 redirect response for the directory, but appends a trailing slash to the resource. When the web server sends the HTTP 302 redirect response, it specifies HTTP (not HTTPS).
· When the client receives the HTTP 302 redirect response, it sends a new request to the BIG-IP LTM virtual server that specifies HTTP (not HTTPS). As a result, the SSL connection fails.
Configuring an HTTP profile to rewrite URLs
In BIG-IP LTM version 9.x you can configure an HTTP profile to rewrite URLs so that redirects from an HTTP server specify the HTTPS protocol. To do so, perform the following procedure:
Log in to the Configuration utility.
Click Local Traffic.
Click Profiles.
Click the Create button.
Type a name for the profile.
Choose http from the Parent Profile drop-down menu.
Under Settings, set Redirect Rewrite to All, Matching, or Nodes, depending upon your configuration
For example:
o Choose All to rewrite any HTTP 301, 302, 303, 305, or 307 redirects to HTTPS
o Choose Matching to rewrite redirects when the path and query URI components of the request and the redirect are identical (except for the trailing slash)
o Choose Node to rewrite redirects when the redirect URI contains a node IP address instead of a host name, and you want the system to change it to the virtual server address
Click Finished.
You must now associate the new HTTP profile with the ClientSSL virtual server.
Try this:
# Trailing slash problem
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} -d
RewriteRule ^(.+[^/])$ https://<t:sitename/>$1/ [redirect,last]
LoadModule rewrite_module modules/mod_rewrite.so
make sure that line is somewhere in you httpd.conf file
RewriteEngine on
RewriteCond %{REQUEST_URI} ^/lawson/portal$ RewriteRule ^(.*)$ https://superniftyserver.com/lawson/portal/ [R=301,L]