I'm looking for a safe way to prevent 404s with smart redirection.
http://www.domain.com/test (results in 404)
http://www.domain.com/test.html (results in page)
Is there a way I can configure Apache to try appending .html to the URL if the page is 404? So basically if I visit: http://www.domain.com/test Apache would say "this page doesn't exist, lets try adding .html suffix to it and see if that exists".
Thanks!
Instead of configuring the apache I reverted to some logic in my application layer for these edge cases.
Related
I found a vulnerability for content-spoofing on my webpage.
This URL:
https://www.mygreatsite.com/www.mygreatsite.com%20has%20moved%20to%20www.evilsite.com.%20CHECK%200UT%20H0W%20COOL%20THE%20NEW%20SITE%20IS!%20Sadly,%20the%20file%00
Apache Output:
Not Found
The requested URL /www.mygreatsite.com has moved to www.evilsite.com. CHECK 0UT H0W COOL THE NEW SITE IS! Sadly, the file was not found on this server.
--
The URL Overrides the Apache-Error and outputs the text added to the URL in the Browser, along with a 404-Error.
Actually, all requests to the server should be redirected to the CMS (Typo3) which in turn handles the 404-error and shows a custom page.
When I enter an URL that doesn't exist, this works perfectly. Just the above mentioned URL screws everything up.
Interestingly, when I delete the «%00» from the end of the URL, the request is forwarded to the CMS and the correct error document is displayed.
I tried to add a separate ErrorDocument-Directive to the htaccess-file - with no success.
Any ideas what goes wrong and how I could solve this?
As Anubhava points out, when a NULL-Byte is detected, Apache doesn't load any modules and just throws the 404. That's why ErrorDocument and mod_rewrite in the htaccess don't work.
[Edit for clarification]
%00 or in Hex \x00 is a NULL byte. When web server finds a NULL byte at the end then web server thinks it is a spoofing request and considers it to be dangerous to be processed by any directives.
Due to security reasons web server doesn't load any modules for this request and returns a 404 / Not found status. Browser shows default 404 page with your decoded URL just below Not Found text.
I am trying to access rest API for Guest User through
http://localhost/b_marketing/api/rest/products, but the page redirects to 404 page. I have checked retrive catalog products in ACL attributes RULES, REST - attributes and REST - ROLES, correctly. It also works correctly on my other project by using these all configurations.
There is one thing I need to mention here that my project works only when I use http://localhost/b_marketing/index.php , despite of setting up the htaccess rewrites and setting rewrite from admin panel. My apache rewrites are also set.
When I use http://localhost/b_marketing/api/?wsdl it works and some xml returns.
But I cannot use http://localhost/b_marketing/api/rest/products
The Response Header is always 404.
I also cannot access REST API using http://localhost/b_marketing/index.php/api/rest/products as well.
Make sure you have rewrite rule in .htaccess.
Go to magento root folder, in your case it is b_marketing
Open .htaccess file in any editor
Locate rewrite rule for api
If you don't have .htaccess file in place, you may consider to copy fron original
Magento packagem
If you run nginx:
.htaccess is not supported. Edit the nginx configuration and add the line:
location /api {
rewrite ^/api/rest /api.php?type=rest last;
}
I read that that line sometimes is already there however with the the word break instead of last. Thats wrong, change it to last.
Make sure to use -MultiViews. As the api.php and /api path have the same name (without extension), Apache might resolve api automatically to api.php and cause trouble.
When you use modrewrite to rewrite your urls, when does the rewrite occur. Will the user be able to see the url before rewrite, when hovering over the link? When they hover over a link will their browser display the rewritten url or the url before it was modified with modrewrite?
The rewrite is done in the server so the user will never know,
PHP also doesn't know what link its pointing to only the script file
mod_rewrite acts on the server side, meaning that apache rewrites incoming URLs before responding to the request. Any HTML links you add to a page will point to the URL you entered, as mod_rewrite doesn't modify any outgoing data.
The rewrite occurs when Apache has parsed the request - before the PHP interpreter has been started.
I'm new to Apache mod_rewrite but I was able to get it to work for simple URL translation for static pages accessed using the GET method.
I'm having trouble to get the URL translation to work for web services though. Basically all I want is to redirect the request from Apache to tomcat that runs under 8093 . I tried:
RewriteRule myproject/myservices/myService/(.*) http://www.localhost:8093/myproject/myservices/myService/$1
But I get a "The document has moved here" response. Any ideas would be appreciated. Thanks.
I think the problem is that your request is only rewritten, but not proxied. You could try to append [P] at the end or look into mod_proxy: http://httpd.apache.org/docs/2.0/mod/mod_proxy.html
For SEO purposes. How do I force user gets redirected to mysite.com/index when types mysite.com on browser ?
I've tried Redirect / en/index
But I'm getting "Firefox has detected that the server is redirecting the request to this address in a way that will never end."
Also, can this redirection consired set language (php psession, cookies?)
p.s. xampp/windows
Redirect works on path prefixes. Redirect / … matches any path its prefix is / (so virtually any path). Use RedirectMatch instead:
RedirectMatch ^/$ /en/index
I believe the error you're getting from Firefox is because you're entering an infinite loop with this redirection. If you try to redirect to a page that doesn't exist, and your server is set up to redirect to a page that doesn't exist on 404, you'll enter a loop. So, ensure that your redirect is going somewhere significant. Does /index exist? Try redirecting to Google instead and see if you get the same error.
(My server knowledge is limited to goofing around while working on school projects, so take anything I say with a grain of salt)
This probably means you have an error in your redirect code. What Firefox is detecting is that the page are trying to view is redirecting you to itself. Without this protection it would just seem like the page wasn't loading.
If you are running windows on your workstation, I would recommend downloading Fiddler2. It will let you see the series of redirects that your server is sending.