This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
When trying to view test results at http://w3c-test.org/framework/review/i18n-html5/ I get the following error message: Not Found The requested URL /framework/loadresults was not found on this server. (I'm beginning to think we ought to have a test suite for the test framework, to ensure that development doesn't break things...)
I forgot to add that this happens for any test suite in the framework.
Fixed: http://dvcs.w3.org/hg/testframework/rev/f6fa20e8fd17 The cause of this is, there are places in the code where some .php files are referenced without their .php extensions; for example "loadresults" instead of "loadresults.php". I don't know why the code had them that way to begin with or why/how it worked. But anyway, the current server environment no longer seems to understand the references unless they include the full file names with the extensions.
I can now see the full set of test results, thanks Mike. But I'm still having problems with viewing results for a single test. For example, http://w3c-test.org/framework/details/i18n-html5/bidi-html5-021/engine/gecko/ doesn't work.
(In reply to comment #3) > I can now see the full set of test results, thanks Mike. > > But I'm still having problems with viewing results for a single test. For > example, > http://w3c-test.org/framework/details/i18n-html5/bidi-html5-021/engine/gecko/ > doesn't work. Fixed now: http://dvcs.w3.org/hg/testframework/rev/5d46281ac2aa This was due to some monkeying I did with a apache rewrites that the system uses. I inadvertently changed a lot more of than I needed to, and that broke a bunch of things. But those should all be fixed now.
Mike, the .php extensions were hidden on purpose as general best practice (better for security, and you get cleaner URLs not tied to PHP). Best guess is the MultiViews got turned off on your server. If you can't configure the server to handle the URLs properly (there are several ways to do it without multiviews if that really needs to be off for some reason), it would be better to override the URLs in the local config file rather than change the default config.
(In reply to comment #5) > Mike, the .php extensions were hidden on purpose as general best practice > (better for security, and you get cleaner URLs not tied to PHP). > > Best guess is the MultiViews got turned off on your server. Ah, OK. I'll check on (re)setting that and if it fixes the problems, then will revert all the previous changes I made to deal with this. > If you can't > configure the server to handle the URLs properly (there are several ways to do > it without multiviews if that really needs to be off for some reason), it would > be better to override the URLs in the local config file rather than change the > default config. OK. Hopefully setting Multiviews will just fix it and get us back to the state we had before.
(In reply to comment #5) > Mike, the .php extensions were hidden on purpose as general best practice > (better for security, and you get cleaner URLs not tied to PHP). OK, I think I've removed the .php extensions in the .htaccess file and returned the default config file to its original state. > Best guess is the MultiViews got turned off on your server. I turned out that MultiViews was still set, but it was not working due to this: http://www.php.net/manual/en/faq.installation.php#faq.installation.apache.multiviews And I think the reason it was working before is that the environment was using /etc/apache2/mods-available/php5.conf, which does a SetHandler, but we switched to /etc/apache2/mods-available/php5filter.conf, which does not.