Ok I'm extremely noob to nginx and did something very stupid. I wrote the following code in my sites available file. Deleting it doesn't seem to undo it.
location ~* .(jpg|jpeg|png|gif|ico|css|js)$ {
rewrite ^/(.*)/$ /?page=$1 last;
rewrite ^(.*[^/])$ $1/ permanent;
}
I wrote this before I fully understood what it meant and since have removed it from my configuration file. Despite removing this it looks like it is still effecting one page of my website. I have tried different browsers other than the one that I loaded this page on when the rule was applied and it is still not serving the images correctly.
How can I undo this?
The site is not yet public so I'm not worried about other people's browsers catches still redirecting after this issue is resolved.
Is there a place in my server that is continuing to redirect despite the rule no longer in my sites-available and sites-enabled folder? It is a linux/ubuntu server and so far this is the first site that this server is running.
Thank you for any help or ideas on how to solve this!
According to the rfc2616 section 10.3.2 about http status 301
The requested resource has been assigned a new permanent URI and any
future references to this resource SHOULD use one of the returned
URIs. Clients with link editing capabilities ought to automatically
re-link references to the Request-URI to one or more of the new
references returned by the server, where possible. This response is
cacheable unless indicated otherwise.
A lot of browsers use that to cache the response locally, so that it doesn't waste another request when calling the same URL, unlike 302 which redirects but doesn't cache.
To solve this you just need to clear the local cache, and not even the whole cache, if you did this today you could just clear today's cache and every thing will be back to normal.
If you have add this location block to your/one of your site conf in nginx/sites-available and thereafter symlinked the file to nginx/sites-enabled, it can only be in the nginx/sites-available/site.
However if you copied /nginx/sites-available/site to nginx/sites-enabled/site you also have to delete the file in sites-enabled...
To be sure, did you reload nginx after deleting configuration ?
Related
We have a FAQ page /faq (tab style) where every question should have its own 'ghost' url/page. So users could visit eg.
/faq/question-1
/faq/question-2
/faq/question-3
The problem is question-1, question-2, question-3 are not actual pages but just sections on /faq. For SEO, aesthetics and usability reasons we do not want to work with ?q= or #
I've searched and tried every .htaccess thread I came across but without result.
Is there a way we can show the page/faq when visiting /faq/question-1 and keep the url /faq/question-1 with mod_rewrite? (we cannot hardcode it because we do not know all future question slugs) So basically something that tells the browser: if the first url part is /faq/, just ignore everything that comes behind but keep the url.
Thanks
This is a trivial rewriting task and it is unclear why this should not work for you:
RewriteEngine on
RewriteRule ^/?faq/.+ /faq [END]
Since you claim that you "tried every .htaccess thread you came across" and this clearly works the question is: why not in your setup? But since you did not tell us anything about your setup we cannot really offer more help...
These are some general hints though which you should go through:
Where did you implement the rules you tried? In the http server's host configuration or in a distributed configuration file?
If you are using a distributed configuration file (".htaccess") then how did you make sure such files are interpreted by your http server and how did you test that?
Did you check your http server's error log file for hints?
Did you make sure that you are not actually looking at cached responses? So did you really test with a fresh anonymous browser window using a "deep reload"?
Since the CMS you are using requires own rewriting rules, where did you add those rules you tried? Remember: the order is important!
My website currently online is completely static and all the URLs have a trailing slash at the end : https://www.website.com/blog/article-1/
I'm working on my new website which is using Prestashop. On Prestashop, URLs don't have a trailing slash : https://www.website.com/blog/article-1
Problem: I have an excellent SEO on my current website and I need to keep the actual URLs (with trailing slash) available. For user experience, I'd like URLs to work with or without trailing slash.
How can I redirect my new URLs to the same URL + trailing slash? If possible, I'd like to rewrite URLs so that users always see the URL with a trailing slash.
Example :
https://www.website.com/blog/article-1/ is redirected to https://www.website.com/blog/article-1 and the URL visible in the address bar is https://www.website.com/blog/article-1/.
Well, ask "How can I redirect my new URLs to the same URL + trailing slash"...
The answer obviously is: by implementing exactly that rule. There are thousands of examples for this alone here on SO. None of those helped? Why not?
Anyway, here is another one:
RewriteEngine on
RewriteRule ^/blog/([^/]+)$ /blog/$1/ [R=301]
RewriteRule ^/blog/([^/]+)/$ /blog/$1 [END]
You need to take care to send out references with leading slashes with this setup. Since otherwise your site will be dead slow, since the clients will have to request every single page twice due to the redirection then required for every single page...
It is a good idea to start out with a 302 temporary redirection and only change that to a 301 permanent redirection later, once you are certain everything is correctly set up. That prevents caching issues while trying things out...
In case you receive an internal server error (http status 500) using the rule above then chances are that you operate a very old version of the apache http server. You will see a definite hint to an unsupported [END] flag in your http servers error log file in that case. You can either try to upgrade or use the older [L] flag, it probably will work the same in this situation, though that depends a bit on your setup.
This rule will work likewise in the http servers host configuration or inside a dynamic configuration file (".htaccess" file). Obviously the rewriting module needs to be loaded inside the http server and enabled in the http host. In case you use a dynamic configuration file you need to take care that it's interpretation is enabled at all in the host configuration and that it is located in the host's DOCUMENT_ROOT folder.
And a general remark: you should always prefer to place such rules in the http servers host configuration instead of using dynamic configuration files (".htaccess"). Those dynamic configuration files add complexity, are often a cause of unexpected behavior, hard to debug and they really slow down the http server. They are only provided as a last option for situations where you do not have access to the real http servers host configuration (read: really cheap service providers) or for applications insisting on writing their own rules (which is an obvious security nightmare).
If you mean default prestashop links like products, categories etc. you can just change their way to be built. Prestsahop allows us to achieve this within admin-panel Configure->Shop Parameters->Traffic & SEO->SEO and URL's>Schema of URLs (for PS 1.7).
And there change an URL in interest, for example, Route to category
from {id}-{rewrite} to {id}-{rewrite}/. And you won't need to redirect anything.
I recently moved a website to another domain, but I am keeping the original domain for a future website. The recently moved website is permanently moved, but I only want traffic to be redirected temporarily to the other domain.
I have read countless 301 vs 302 posts, articles, etc. and have failed to find any that address this particular situation. And no one answered this similar question:
Moving to a new domain and using the old one for a new website - how to handle 301 redirects?
But the difference with my question is: I don't even know that I should be using a 301 redirect for this. What's the best way to handle this situation in general?
301 Moved Permanently doesn't mean that the domain name should never be used again; it means that the content the user requested has moved permanently, which is exactly the situation you describe.
(308 Permanent Redirect is supposed to supplement 301, but it is sometimes treated oddly and doesn't work at all on Windows 7 or 8.1 under IE.)
When you decide to re-use the old domain for a new set of resources, you can simply stop redirecting away from it. By then you hope that people looking for the old resource have updated their bookmarks/links thanks to the 301. It might be polite to allow some duration of time for this transition to occur.
Neither 302 Found nor its replacement 307 Temporary Redirect is appropriate here, as both misrepresent the situation and do not signify that people should permanently look for the old content in the new location: they're going to be mighty confused when the original domain no longer redirects, allegedly the end of a temporary situation, but then also does not serve the expected content.
You can use the .htaccess file to redirect with 307 status code (the successor of 302 in HTTP/1.1)
Redirect 307 / http://other-domain/
Here's a link that you may find helpful. You can also redirect with 308 status code also as #István Rábel suggested
Earlier today I asked a question on SO regarding a redirect in the htaccess file. The answer given to me was actually correct, but because I had failed to clear my cache, my browser was still using a cached version of the htaccess file without my update. After clearing my cache, the redirect worked as expected. I've just installed an SSL certificate for a different client and added some rules to redirect from HTTP to HTTPS. However, I'm thinking about the issue I had this morning. The customer, as well as their return visitors, would have cached the old htaccess file and therefore won't use the updated version. If this was a stylesheet or an image, I'd just add a version number, change the file name, or change the path, to "force" the update. I obviously can't do that here. Is there anything that can be done to force return users to use the updated htaccess file?
There is nothing you can do about other peoples cache I'm afraid. Eventually the cache will refresh and display the new changes. All it takes is a refresh of the page.
You can tell your website not to cache by using:
ExpiresActive On
ExpiresDefault A1
Header append Cache-Control must-revalidate
But I don't really see much point in doing that unless you're making constant changes to said page. If a client asks you to make a change that requires their cache to be reset, then just tell them to do so, so that they can see it.
I'm new to .htaccess file.
My site is hosted on 1and1 and by default it shows www.mydomain.com/defaultsite when nothing is uploaded to my account. Now I've uploaded my wp site and have managed to make it go to index, but if someone inputs in the url www.domain.com/defaultsite he will still get the wrong place.
How can I manage this issue with .htaccess file so that any request to defaultsite will take the user to www.mydomain.com ?
I'm not a 1and1 user, but this could be a DNS cache issue. First, check your document root for the presence of a directory called defaultsite. If it exists, remove it. If not, then you can attempt removing it using mod_rewrite. Insert this rule immediately after RewriteEngine On in your .htaccess file:
RewriteRule ^defaultsite/?$ http://yourdomain.com/ [R=302,L]
If it's working for you, you can safely change 302 to 301 to make in permanent and cache-able.
I have also seen comments referring to an index.html file in the document root. If you see one, delete it - it could be that, internally, 1and1 maps defaultsite to index.html.
Also, it will help for you to clear the cache in your browser when testing. If using Chrome, you can open the Developer Tools (Ctrl+Shift+I), click on the settings cog at the top right of the panel that opens, and check 'Disable cache (while DevTools is open)`.
I had a similar issue and was pulling out my hair trying to figure this out. 1&1 is hosting while Namecheap holds my domain. I was able to access my page without /defaultsite on Safari and mobile Chrome. But on desktop Chrome I was being redirected to /defaultsite.
To remedy this I cleared my cache, flushed my DNS cache, and cleared my browsing history. Not sure if the latter 2 were necessary but having done all three it did help resolve this issue.