The configuration for developer.mozilla.org has regressed within the past few days. MultiViews is no longer working (this causes a lot of broken links), charset UTF-8 is not being sent, etc. I asked Anne how recent the changes were, this is his response: > Well, the first day it worked perfectly, when justdave marked the bug as > FIXED. The day after, however, it was already broken I believe.
Anyone make changes to the .htaccess files? The server config hasn't changed. In fact, it's the same VirtualHost block that developer-test had, I just changed the ServerName on it, and got rid of the old VirtualHost for developer that had the redirect in it.
I don't know what happened, but links like http://developer.mozilla.org/about/meta and http://developer.mozilla.org/about/ aren't working properly. The following rules should be in effect for devmo: AddDefaultCharset UTF-8 LanguagePriority en Options +MultiViews DirectoryIndex index
meta.en.html says: filename extensions should be of the form filename.lang.format however if there are no language ready that client prefer(e.g. no, ru, etc), httpd returns 406, then, adding another file that includes en file to avoid 406(*), but Apache doesn't serve expected content. If the form is filename.format.lang, that is used by Apache docs, it works fine. (*)e.g. add index.html.html that includes index.html.en.
victory -- 406 errors are something that switching to Apache 2.0 will take care of. This bug is about a regression in the 1.3 server config that we're working with for now. justdave -- according to Anne, the site was working immediately after the subdomain switch, so it wasn't that. Was there a second round of config-tweaking after that? Maybe there's a syntax error somewhere...
#AddLanguage en .en That was commented out at Anne's request a few days after the domain name switch. Something about working around a 406 error and making sure people who didn't have en in their language list could still see the site.
Yeah, I remember asking you about that. *tries something* Ok, I think that's causing the problem; .en is no longer recognized as an extension, it's part of the filename. So, let's try adding this: AddCharset UTF-8 .en See if that fixes the problem. While we're at it, we should also have AddDefaultCharset UTF-8 in the config. Web-sniffer isn't reporting a charset http://web-sniffer.net/?url=http%3A%2F%2Fdeveloper.mozilla.org%2F&submit=Submit&gzip=yes&type=GET&ua=Mozilla%2F5.0+%28X11%3B+U%3B+Linux+i686%3B+en-US%3B+rv%3A1.7.5%29+Gecko%2F20041202+Firefox%2F1.0+Web-Sniffer%2F1.0.19 and we'll need that once I start checking in victory's translations.
So devmo can not be made public until it is, and always will be, on Apache 2 or similar webserver taking in account the current file structure?
OK, devmo has been deployed on reptile, which is an RHEL3 machine running Apache2, and DNS has been switched. Testing would be appreciated.
This particular regression has been fixed. If we're on Apache 2.0 now, you should be able to revert to the "AddLanguage en .en" instead of "AddCharset UTF-8 .en" These two rules: LanguagePriority en ForceLanguagePriority Prefer Fallback should make the 406 error problem go away.
(In reply to comment #10) > LanguagePriority en > ForceLanguagePriority Prefer Fallback Added. try now.
Awesome. Everything's still working great, even though I'm only accepting French. I'll test it with multiple languages tomorrow. :) Thank you so, so much. I've been dreaming about this setup for years. :D
OK, guess that makes this fixed. reopen if anyone disagrees.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.