We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
He, we are using cachify for long time and our prefered method is hdd caching with nginx setup.
works fine but now we found a problem at our server setup, that if we use caching and there is a hit, then its possible that urls could have multiple slashes in URL at the end and its always the same response.... ie: https://domain.com/the-slug/ is cached... then those urls all returns the cached site: https://domain.com/the-slug// https://domain.com/the-slug/// https://domain.com/the-slug////
Thats naturally not very good for duplicate content resons (although canonical helps there already).
my Quickfix now is this solution above your nginx.conf:
merge_slashes off; rewrite ^(.*?)//+(.*?)$ $1/$2 permanent;
This lets nginx redirect first the multiple slashes before it searches for cached files on hdd.
perhaps you have a smarter solution for it, pls let me know :)
The text was updated successfully, but these errors were encountered:
This behaviour is not limited to nginx. It's the same on Apache.
Without the cachify, WordPress automatically redirects to the "single-slash" version.
Sorry, something went wrong.
No branches or pull requests
He, we are using cachify for long time and our prefered method is hdd caching with nginx setup.
works fine but now we found a problem at our server setup, that if we use caching and there is a hit, then its possible that urls could have multiple slashes in URL at the end and its always the same response....
ie:
https://domain.com/the-slug/ is cached...
then those urls all returns the cached site:
https://domain.com/the-slug//
https://domain.com/the-slug///
https://domain.com/the-slug////
Thats naturally not very good for duplicate content resons (although canonical helps there already).
my Quickfix now is this solution above your nginx.conf:
This lets nginx redirect first the multiple slashes before it searches for cached files on hdd.
perhaps you have a smarter solution for it, pls let me know :)
The text was updated successfully, but these errors were encountered: