I have the following FD routes as fictional examples:
mysite.azurefd.net/app1 --forwards--> "app1.azurewebsites.net"
mysite.azurefd.net/app2 --forwards--> "app2.azurewebsites.net"
However, Front Door is still sending the examples paths /app1 and /app2 and I get error HTTP 404.
Custom forwarding path is set like this:
Setting the match patterns like this solved my problem.
https://learn.microsoft.com/en-us/azure/frontdoor/front-door-url-rewrite
This along with setting the Custom forward path under URL rewrite is very important to make it work.
Related
I like to simplify code if possible but I am not to familiar with .htaccess, I had error documents redirect rule hard coded
ErrorDocument 403 http://example.com/error/404
Then I made it
ErrorDocument 403 http://%{HTTP_HOST}/error/404
my question is so that the .htaccess does not have to be manually modified is there a way to tell it if its https or http? because the above example if i use https ill have to hard code https I would like to check automatically.
Don't use an absolute URL in the ErrorDocument directive
ErrorDocument 403 http://example.com/error/404
You shouldn't be using an absolute URL in the ErrorDocument directive to begin with! This will trigger a 302 response (ie. a 302 temporary redirect) to the target URL. So, this won't send a 403 (or 404) response back to the user-agent on the first response.
(This format of the ErrorDocument directive should only be used in very exceptional circumstances since you also lose a lot of information about the URL that triggered the response in the first place.)
To internally serve a custom error document on the same server, this should be a root-relative URL, starting with a slash (no scheme or hostname). For example:
ErrorDocument 403 /error/404
However, /error/404 is unlikely to be a valid end-point. This should represent a valid resource that can be served. eg. /error/404.html.
(And this naturally gets round the issue of having to specifying HTTP vs HTTPS.)
To answer your specific question...
because the above example if i use https ill have to hard code https
(Although, arguably, you should be HTTPS everywhere these days.)
However, to do what you are asking, you could do something like the following using the REQUEST_SCHEME server variable, for example:
ErrorDocument 403 %{REQUEST_SCHEME}://%{HTTP_HOST}/error/404
Or, if the REQUEST_SCHEME server variable is not available then you can construct this from the HTTPS server variable using mod_rewrite and assign this to an environment variable. For example:
RewriteEngine On
RewriteCond %{HTTPS}s ^on(s)|
RewriteRule ^ - [E=PROTO:http%1]
ErrorDocument 403 %{reqenv:PROTO}://%{HTTP_HOST}/error/404
The %1 backreference contains s when HTTPS is on and is empty otherwise. So the PROTO environment variable is set to either http or https.
This does assume that the SSL is managed by the application server and not a front-end proxy (like Cloudflare Flexible SSL etc.).
Working on a BackBone app that has this mod_rewrite in place to handle routing all traffic through index.html that isn't targeting a file:
modRewrite(['^[^\\.]*$ /index.html [L]'])
It's working beautifully, but now I need to update it so that it ignores that root-level api directory. My API calls look like this:
http://localhost:9000/api/customers/
They're all breaking because it's trying to route them through index.html. FYI, I'm using Grunt connect-modrewrite locally to manage issues with routing and localhost.
You can try negative lookahead based regex:
modRewrite(['^(?!/?api)[^\\.]*$ /index.html [L]'])
I have a simple 404 redirect in a .htaccess file which works fine for Http requests:-
ErrorDocument 404 /apps/handle_error.php
The handle_error.php returns an appropriate PNG image depending on the URL path. However, when I replace the request with Https, it returns the default 404 error page and never does the redirect.
I know my SSL certificate is installed correctly as I get valid content returned for normal static pages. Is there something I am missing in my htaccess file regarding 404 error redirects for Https requests?
(A similar question was asked here but with no clear resolution)
After much soul searching I found the answer, for my specific case anyway.
My Apache2, mod_ssl and mod_rewrite was not configured correctly to work together. The default AllowOverride setting in my SSL config was set to "None" and mod_rewrite requires a minimum of AllowOverride of "FileInfo".
(To be fair, I got my answer from ServerFault)
I'm having some trouble with redirects within wordpress redirection causing the domain to change.
Example:
Site - noncdn.somedomain.com
CDN URL - www.domain.com
When I open links w/o a trailing slash there is a 301 redirect:
Going here: www.domain.com/page
Takes you here: noncdn.somedomain.com/page/
Since Cloudfront is hitting the server using Origin Domain, the server doesn't even know that requests are coming in from a different domain.
How do I force this 301 to use FQDN w/ correct CDN domain instead of doing a relative redirect?
I've already added this so that links on the site and images all load from Cloudfront domain, but it seems to have no effect on the redirect behavior:
add_filter('home_url','home_url_cdn',10,2);
function home_url_cdn( $path = '', $scheme = null ) {
return get_home_url_cdn( null, $path, $scheme );
}
function get_home_url_cdn( $blog_id = null, $path = '', $scheme = null ) {
$cdn_url = get_option('home');
if(get_option('bapi_site_cdn_domain')){
$cdn_url = get_option('bapi_site_cdn_domain');
}
$home_url = str_replace(get_option('home'),$cdn_url,$path);
//echo $home_url;
return $home_url;
}
Any Help is much appreciated!
Thanks!
I was tracking down a very similar issue for a while with a Cloudfront distribution of a standard static website running on Nginx. The symptoms were the same, links with a trailing slash (e.g. www.acme.com/products/) worked correctly, but omitting the trailing slash caused the user to be redirected to the origin.
The issue is that the webserver software itself is not properly attempting to resolve URIs and is instead responding with a redirect to a URL it can serve. You can test this by using curl against your site:
$ curl http://myhost.com/noslashurl
HTTP/1.1 301 Moved Permanently [...]
CloudFront is returning exactly what your server returns, in this case a 301 redirect to your origin URL. Instead of following the redirect and caching that, CloudFront caches the redirect itself. The only way to correct this is to ensure that your origin properly handles the requests and does not respond with a 301.
In my particular case, that meant updating the try_files directive for my location in the nginx configuration. As I mentioned this is a static site, and so my try_files became:
location / {
[...]
try_files $uri $uri/index.shtml /index.shtml =404;
}
You want to be sure that the try_files has an endgame, to avoid redirection cycling which will cause your server to return 500 Server Errors when a non-existent URL is requested. In this case, /index.shtml is the last-ditch attempt and failing that, it will return a 404.
I know this doesn't precisely answer your question, but yours was one of a very few I found when searching for "cloudfront without trailing slash redirects to origin", and you've not had an answer for a year, so I figured it was worth sending a response.
I had the same problem.
I fixed the issue changing some wordpress parameters.
In the elasticbeanstalk I set the parameter CUSTOM_URL for my custom domain and in the file /var/www/html/wp-includes/load.php
I set the parameters HTTP_HOST and SERVER_NAME to same value of CUSTOM_URL, and it resolved the redirect to elasticbeanstalk url.
$_SERVER['HTTP_HOST'] = $_SERVER['CUSTOM_URL'];
$_SERVER['SERVER_NAME'] = $_SERVER['CUSTOM_URL'];
I'm using Passport-google to login users in example.com:3000. It works great. But if I put the Node.js server behind a proxy (IIS7; don't ask why, I had to), and access to my site in example.com (not in example.com:3000), I can't login with Passport-google. My RewriteRule in IIS:
Pattern (.*)
{HTTP_HOST} Matches myserver.com
{SERVER_PORT} Does not match 3000
Rewrite URL: http://127.0.0.1:3000/{R:1}
The error I got:
Cannot GET /accounts/o8/ud?
Also I have the same problem with Passport-twitter, and Passport-facebook.
I think I should set some other rule in IIS, or set some proxy settings in Passport.js, or OpenID, but haven't figured out yet. Any ideas?
The IIS proxy had a bad configuration. under Application Request Routing (ARR) / Server proxy settings Reverse rewrite host in response headers was switched on, so when passport sent a 302 with a location in header set to https://www.google.com/accounts/o8/... the IIS proxy replaced it to http://myserver.com/accounts/o8/... . which of course was an invalid link.