Closed Bug 278736 Opened 20 years ago Closed 20 years ago

developer.mozilla.org apache config regression

Categories

(mozilla.org Graveyard :: Server Operations, task)

task
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: fantasai.bugs, Assigned: justdave)

Details

(Keywords: regression)

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
Closed: 20 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.