User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7 (ax) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7 (ax) This is a weird bug to explain, but it seems quite reproduceable. Basically, if you enter a url without the file extension on a PHP file (I haven't tried any other types), firefox still navigates to the page. I don't know if this is supposed to be a feature, or if its a bug. For example, http://aspa.swcconsulting.ca/calendar.php exists, and if I go to http://aspa.swcconsulting.ca/calendar, I see calendar.php. The weird part is if you add non-existant subdirectories after the filename, it still finds the PHP file, but displays it without styles or images (basically it breaks all the client-side file references, although PHP includes are fine). So, if you go to http://aspa.swcconsulting.ca/calendar/gibberish, you see calendar.php without any images or styles. Reproducible: Always Steps to Reproduce: 1. Go to http://aspa.swcconsulting.ca/calendar.php 2. Go to http://aspa.swcconsulting.ca/calendar 3. Go to http://aspa.swcconsulting.ca/calendar/gibberish Actual Results: 1. calendar.php displays properly 2. calendar.php displays properly 3. calendar.php displays without styles or images Expected Results: 1. calendar.php displays properly 2. calendar.php displays properly (if its a feature), 404 error message (if this is a bug) 3. 404 error message
Oops ... forgot to mention that I have only noticed this since the 1.0.7 release, although it may have been there earlier. It happened to me on my Linux box (mozilla-firefox-1.0.7-r2) and my Windows XP box.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b5) Gecko/20051018 Firefox/1.4.1 ID:2005101805 WFM (404)
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b5) Gecko/20051003 Firefox/1.4.1 WFM on Linux as well. Your issue no. 2 seems to be a server configuration problem (if the behaviour is not intended), the HTTP server is sending a redirect to a different URL.
Looks like you've changed things around with those URLs, but comment 3 is right: we're not adding .php onto what we request, so if your server was sending us calendar.php for calendar, that was its decision.