Running Xampp - unintended 301 redirect occurring. I have added a page to localhost/kinetic/golf when I put this url in, it redirects me to localhost/kinetic/2020/12/15/golf-driving-distance-podcast/. It seems like it's a caching error, or it's not recognizing that the new page has been added. I've noticed that it autofills. So when I put in localhost/kinetic/run (page that does not exist) it redirects to localhost/kinetic/running (page does exist). How do I stop the golf redirect from occurring. Currently using firefox but same issue occurs on chrome.
I have cleared browser cache,
restarted server
restarted computer,
changed port # in config files
Related
IIS logging has logged that a specific GET request as been redirected.
Here is the relevant entry (ip address removed):
2021-10-06 02:48:59 xx.xx.xx.xx GET /test - 80 - xx.xxx.x.xxx Mozilla/5.0+(Windows+NT+6.1;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/93.0.4577.82+Safari/537.36 - 301 0 0 1
The application /test consists of a single index.php file that echo's the word 'hello'.
There are no url redirect rules set up in IIS. Nor are there any calls to header()
Any ideas as to how to determine why a redirect would occur on a simple web application like this? Or tips on how one can find out the cause?
For context, the server which this simple application runs on sits behind an AWS load balancer. However, the redirect definitely is occuring on the IIS server and not in some firewall or network configuration.
Additionally, the redirect only occurs when there is no "/" on the end. If there is a "/" on the end, it works. (status code = 200). I have more detailed info in this question here
This is IIS built-in behavior. When a URL maps to a directory and the trailing slash is missing, IIS sends a redirect to add the slash. It is known as a "courtesy redirect", as explained here.
I need to access http://server.com/folder and get a default index.php file with NO REDIRECT , which means I need Apache to deliver http://server.com/folder/index.php when http://server.com/folder is called with no redirect. How can this be done? I see many solutions but some do not seem to work or perhaps are incomplete while other cause a redirect. The client I want to use is Mopira for Scanning and does not respond to the redirect as I suspect others will not as well.
This is Apache2 running on a local Ubuntu server so i is not a server exposed to the Internet
Alternately if I can force http://server.com/filename to load http://server.com/filename.php with no redirects this would also work but redirects do not work!
I have a website on a lamp stack with little to no extra configuration other than FallbackResource /index.php present in my root .htaccess
When I load the root page (localhost ) in Chrome I receive
GET http://192.168.163.171/ net::ERR_INCOMPLETE_CHUNKED_ENCODING VM110:1
in the chrome console after about 10 seconds. If I attempt to follow the link at VM110:1 it takes me to the top of my inline Javascript.
More information / What I've tried
This does NOT occur on any other page but root
There are no 404's in the access log nor any other abnormal codes
There are no errors appearing in the apache error log.
The error does not occur in the latest version of IE or Firefox.
It caused a problem in both my local environment and hosted. The latter has absolutely no config changes and I expect to be a near default install.
When I remove the FallbackResource directive my page loads fine without the error
In index.php the root is treated no different than any other page.
This would all be a non-issue because everything loads properly BUT it prevents javascript relying on a finished page load from working.
Any further ideas on what is causing the problem or new things I can try? I've considered moving to just using mod_rewrite but this is much simpler.
Finally found the answer while working on another site:
Before FallbackResource directive be sure to add a DirectoryIndex directive with the same file. Haven't had time to research why but it fixed my issue. I blame it on a Chrome bug or possibly Chrome being super picky because no other major browser has an issue.
I fixed this error by removing the following lines from my php5filter.conf file in the Apache configuration:
<FilesMatch ".+\.ph(p3?|tml)$">
SetInputFilter PHP
SetOutputFilter PHP
</FilesMatch>
To add to Blaine's answer (as I can't yet comment):
I believe this is an Apache configuration issue, not specific to Chrome.
I recently experienced this issue, and noted the following effects in various clients, again only with the home page:
Chrome, as stated, displayed the ERR_INCOMPLETE_CHUNKED_ENCODING error, but also didn't display the page correctly. The page continued to "load" for another 5 seconds even after all the content was visible.
A simple CURL request outputted the error curl: (18) transfer closed with outstanding read data remaining. The full HTML appeared, followed by the error after a delay.
Firefox and IE initially displayed the page incorrectly, as with Chrome, and again had the ~5 second additional loading time. However, after this period, the page suddenly reformatted itself correctly. No errors were seen in the respective developer consoles.
The solution to set the DirectoryIndex to the same location as FallbackResource resolved this for all clients.
Edit: An alternative if using mod_rewrite is to use something like RewriteRule ^$ index.php which will avoid affecting all subdirectories.
I don't know whether this is expected behaviour of Apache or a bug.
In my json response '\n' causing the issue. So after removing it, issue has been solved.
I'm having a strange problem here and can't figure the cause. I have a php-script on an nginx server which triggers a redirect to a different (sub)domain on the same server:
For instance:
foo.domain.com/redirect.php
header("Status:301");
header("location:http://www.domain.com/new_url/");
The result is that I'm getting redirected to:
foo.domain.com/new_url
The domain doesn't change at all although my response headers look fine .
Any ideas?
Ok, I finally found the cause for my troubles. Neither Nginx, nor PHP caused the issues. My webservers are behind a loadbalancer running with Pound.
Pound has a feature to rewrite domains inside header redirects (enabled by default). We now turned this feature off and all redirects finally work as expected!
Check your containing your site in an iframe,
Some hosts can do this if its free hosting, all so some domains setup allows the site to be contained in an iframe witch would cause the properly your describing
I'm working with an intranet system that, on each page, checks the user's cookie, verifies that they can see the current page based on database permissions, and records a page hit that includes their id and the page URL.
I just noticed that in the pagehits table, I see an entry for 404.php (my custom 404 page specified in the Apache config) one second after each legitimate page hit.
Is this probably my fault, or does it have something to do with how Apache decides to load the 404 page?
I'm using Apache 2.2.14 (Win32) and PHP 5.3.2.
My guess would be that you have no favicon.ico defined for your site.
That means that every time a user requests a page, the browser is also requesting favicon.ico which results in a 404 being returned.
You probably have a request for a file which doesn't exist. Maybe your favicon. The Apache error or access logs will reveal what the 404 was for.
Try reading your logs and see which url trigger the 404 response code. Also you can install some log analyzer like awstats