New answers tagged

1

Yes, this seems like a good configuration. I don't see any obvious problems, except the one in your question 3. The only problem with letting the http://*.domain.com:6xxx connection through is that it's HTTP, not HTTPS. To prevent that you can redirect those connections too: RewriteCond %{HTTP_HOST} ^(.*)\.domain\.com$ RewriteCond %{HTTPS} off RewriteRule (.*...


0

This could be achieved by using nginx map feature. Define the following map in http level: map $http_referer $redirectold { default 1; "~^http://example.com/" 0; } And in main configuration: server { if ($redirectold) { rewrite ^/old-article.html http://example.com/new-article.html permanent; } }


1

I just had the same issue - I resolved it by using RewriteOptions InheritBefore instead of just RewriteOptions Inherit so the .htaccess file in the parent directory was processed before the one in the sub-directory


0

What finally worked, was using seleniumwire and driver.header_overrides = {'Referer': 'com.google.android.gm'} Apparently, it was clicking the link from my gmail app, rather than using Kiwi. I reproduced the redirection on Chrome using the same referer.


0

You could set it up like me server { #redirect all naked domains to https and www if ($host = aihello.com) { return 301 https://www.aihello.com$request_uri; } #redirect all unsecure www to secure www if ($host = www.aihello.com) { return 301 https://www.aihello.com$request_uri; } ...


1

I've been having the same issue almost 3 years later and it seems pretty clear that this is not possible through DNS/Google alone. You have to host somewhere separately with an SSL cert installed for the naked domain otherwise it won't work, so unfortunately the answer is: No At least Google have updated their article to explicitly state that the redirect ...


1

For your second rewrite expression RewriteCond %{REQUEST_URI} /cgi-bin/something? RewriteCond %{QUERY_STRING} ^keywords=([0-9]{1,})$ This matches will match the string /cgi-bin/something?keywords=123 But will not match /cgi-bin/something?keywords=123&offset=120 The regex you are using ^keywords=([0-9]{1,})$ has a dollar sign ($) saying that after the ...


4

But that redirects to example.php/ That is caused by the first (original) rule. Note that the earlier (erroneous) 301 will likely have been cached by the browser. Test with 302 (temporary) redirects to avoid potential caching issues. The Redirect directive is prefix-matching (whole path segments), and everything after the match is appended to the end of the ...


0

Unfortunatly you can't redirect the Client, without having a valid certificate. As the TLS Handshake happens before the redirect. Since it seems as you are using Letsencrypt the best solution would be the get a certificate with both Names. If you are using certbot you could just add the -d Domain flag multiple times. certbot -d yachtenwelt.de -d www....


0

This worked for me: # rules server { #general listen 80; # add www. if ($host ~ ^(?!www)) { rewrite ^/(.*)$ http://www.$host/$1 permanent; } # remove subdomain if ($host ~ "^www\.(.*?)\.(.{3,}\.([a-z]{2}\.[a-z]{2}|[a-z]{2,4}))$") { set $host_without_sub $2; rewrite ^/(.*)$ http://www.$...


0

While the mentions above make very clear that DNS records are port agnostic (except for SRV records -- that are not incorporated in most clients); there is a possibility: to use URL forwarding services that are offered by most DNS providers (eg. easyDNS) This will allow you to make easier for the user: so from your exemple www.example.com goes to port 87, ...


0

The web server probably does some sort of User-Agent header inspection and redirects based on that. Using apache, something like the following could be used to conditionally redirect specific clients to different locations: RewriteEngine On RewriteCond %{HTTP_HOST} example.com$ [NC] RewriteCond %{HTTP_USER_AGENT} Firefox [OR] RewriteCond %{HTTP_USER_AGENT} ...


0

Both nginx and curl connect exactly same way to upstream. They resolve the IP address with a DNS query and then connect to the IP address. In your case, it seems that there are issues with IPv6 routing on the server, and Cloudflare's servers aren't reachable with IPv6. You need to discuss this with your service provider so they can fix it.


Top 50 recent answers are included