Closed Bug 107166 Opened 23 years ago Closed 21 years ago

Mozilla.org could run Apache or AOLServer

Categories

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

Product:
mozilla.org Graveyard
Component:
Server Operations
Platform:
All
Linux
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: L.Wood, Unassigned)

References

Details

> lynx -head http://www.mozilla.org

HTTP/1.1 404 Not found
Server: Netscape-Enterprise/3.6
Date: Sat, 27 Oct 2001 22:22:32 GMT
Content-type: text/html
Content-length: 207
Connection: close

I filed a feature request on the mozilla browser, and got told about Netscape
Enterprise's server behaviour for my trouble.

mozilla.org should switch to using apache ASAP; I suspect shifting the
focus of mozilla engineers to interoperation with Apache, rather than interop
with Netscape's server, will be beneficial in the long run.
Not really on the top of the list.
Assignee: scbrown → nobody
Severity: critical → trivial
*** Bug 111057 has been marked as a duplicate of this bug. ***
In the light of Bug 111057, there's obvious enthusiasm in the mozilla team for
running apache for www.mozilla.org.

I suggest that work on setting up a parallel (initially-read-only limited
functionality?) public apache.mozilla.org can be started as a background effort,
in parallel with the existing mission-critical don't-dare-break-this
mozilla.org-on-Netscape-Enterprise gila installation. This gives the option
to switch to using apache at some future point.
It's much simpler than that, actually, since we can run two web servers at
different ports on a single box.  We just need apache to be installed on gila,
after which we can configure and test it in parallel with the current web server
before switching over completely.
Resetting severity and assignee.  Risto, if you can't do this yourself, please
re-assign it to someone at IC who can take it on.  Per Dawn's note in but 111057
this will take no more than a few minutes of someone's time.  Surely there are
adequate resources in your department for a project with these time requirements.
Assignee: nobody → rko
Severity: trivial → normal
There are few culprits in this. We need to make sure all the applications 
(bonsai (web)/htdig) will work in Apache as well. Also, there are some 
redirects we want to keep working.

Problem with other ports is that we need to get firewall opened for those. We 
might want to try it in port 443 which is currently unused on gila.


Changing the Summary. It's not politically correct to call a Apache "better".
Summary: Mozilla.org could run better webserver → Mozilla.org could run Apache
I know for a fact that bonsai works with apache because I have used it 
with apache on my box. My school also uses htdig for searching on a 
redhat linux box running apache so that should be ok. The important thing 
is to get the config file and .htaccess files setup right so that things 
happen correctly. Also, if we use apache we can use serverside includes 
for things like the release notes which is just a total hack at the moment.
I can understand the arguments here...  seems to me like this would be a tough
call to make on the part of Netscape...

On the one hand, since the machine is owned by Netscape, it makes perfect sense
for it to be running Netscape Enterprise, one of the company's own products.

On the other hand, mozilla.org exists to promote open source.  Apache is open
source.  Netscape Enterprise isn't.
*** Bug 85499 has been marked as a duplicate of this bug. ***
Risto wrote:

>There are few culprits in this. We need to make sure all the applications 
>(bonsai (web)/htdig) will work in Apache as well. Also, there are some 
>redirects we want to keep working.

Agreed.

>Problem with other ports is that we need to get firewall opened for those. We 
>might want to try it in port 443 which is currently unused on gila.

Sounds good to me.


Dave wrote:

>On the one hand, since the machine is owned by Netscape, it makes perfect sense
>for it to be running Netscape Enterprise, one of the company's own products.

I disagree.  Although, Netscape supplies the many of the machines on which
mozilla.org runs its web site and services, it has never to my knowledge
indicated any interest in our running its software products on our systems.  In
fact, the Netscape Enterprise installation on gila is the only example I'm aware
of where mozilla.org runs a Netscape software product.

>On the other hand, mozilla.org exists to promote open source.  Apache is open
>source.  Netscape Enterprise isn't.

Exactly.  Plus, mozilla.org has already standardized around Apache for all its
other web servers (lounge, mothra, etc.) and has been talking for years about
finishing the job by replacing the Netscape Enterprise installation on gila with
Apache.

Configuration and testing will take time, but the first step we need to get the
ball rolling--installation of Apache--is quick and easy to do.  Risto, when can
you or another member of your staff take care of it?


I still fail to see couple of points, please explain more...

a) the software is there to serve your web pages to general audience. And NES 
does it well. It ain't broken or at least nobody have explained to me what is 
broken.
b) what are benefits of using Apache vs. NES? Answer "Apache is Open Source" 
isn't good enough. We are here to provide you a web service and AFAIK it works 
fine. "If it ain't broken, don't fix it."
c) we are also using Solaris. Are you going to ask to convert to Linux next?
d) Your argumentation doesn't really fly, but I can help it fly. You are trying 
to give us solution/answers to a problem that haven't even been defined. Your 
requirement to us is/was that you want web pages served and we have provided 
you a solution based on that requirement. Where are other requirements and 
something that isn't fulfilled with NES?

Please make a better business case. What is the business need for moving to 
Apache and what are your web service (the product we provide in this case) 
requirements? We'd be happy to take a look at those and how those have changed 
since early days. Please don't provide answers; provide problems and we will 
find you the best answers.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
> And NES does it well. It ain't broken or at least
> nobody have explained to me what is broken.

Please read bug 107160, which led to my opening this bug:

$ Also note that some versions of the ns webserver will return a 400 response to
$ any HEAD request - try it on www.m.o, for example

That broken behaviour has led to lots of complaints on e.g. the W3C validator list.

I suppose you're not going to upgrade NES either?
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
> I suppose you're not going to upgrade NES either?

You don't hear me correctly... we will do our best to meet requirements. The 
product to meet them isn't important.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WONTFIX
Reopening.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Ok, I reopened the bug since we have some new requirements from mozilla.org 
about things they'd like to do with their web server. Also, moving the bug to 
Ray's queue.

Those new requirements are:
1. HTTP/1.1 content negotiation
2. defenses against DOS attacks
3. SSI
4. URL rewriting
5. WebDAV
Assignee: rko → daruszka
Status: REOPENED → NEW
Bug 85499 says:
This is a side effect of having "Directory Indexing" turned to off within
the Netscape Enterprise Server 3.6.  If you do a "HEAD" of a specific 
file, i.e. "HEAD mozilla.org/index.html" you will get a successful return
code and actual data returned.  We usually prefer to leave the directory
indexing feature turned off so people can't just generically troll through
the web site and find all the content.  I think in NES 4.1 you get a correct
return code in this instance, though.  I'll verify that and then see about
upgrading install base for www.mozilla.org.


I'm OK with this:-)
Mass changing IC's ticket to reflect current situation.

mozilla.org, AOL employees:

If you want IC to look at issues reported in bugzilla, please open a Helpdesk
ticket and ask it to be routed to AOL R1 Server Operations. We currently have no
way to handle comprehensive problem resolution through bugzilla. This is not a
change in the way we are supporting mozilla.org - we are still supporting you on
the level as before. IC's support is based on Helpdesk ticket system - not
bugzilla which only few hard-core people are looking at. 

Also, projects are handled elsewhere - not in bugzilla. If you have projects you
need us to deliver please feel free to contact me directly.

Summa summarum: tickets -> Helpdesk
Project initiations -> RKotalampi@aol.com
Assignee: daruszka → nobody
NES6.x addresses the HEAD problem that Lloyd has reported. Upgrading would make
the badness go away.

Risto said:

Those new requirements are:
1. HTTP/1.1 content negotiation

In what way, exactly? Are we talking about Content-encoding: ?

2. defenses against DOS attacks

In what way, exactly?

3. SSI

NES has supported SSI for years. What is lacking in its support? The NES team
will happily look into problems/RFEs in its SSI support.

4. URL rewriting

In what way, exactly?

5. WebDAV

WebDAV is not currently supported by NES (any version). The various Open Source
implementations could probably be adapted to work with it though (especially
those that are implemented via Java)
I see netcraft is reporting that the various netscape.com sites have
switched from using Netscape Enterprise to using AOLServer/3.4.2 on
Solaris.

I could understand mozilla.org running Apache (which would match other
internal servers) or AOLServer (all hail the corporate masters!)
Either is open-source, and either would be preferable to an obsolete version
of Enterprise. There are probably good internal arguments for running
AOLServer instead of Apache.

http://www.aolserver.com/
http://www.apache.org/
http://www.netcraft.co.uk/
Summary: Mozilla.org could run Apache → Mozilla.org could run Apache or AOLServer
> NES6.x addresses the HEAD problem that Lloyd has reported.
> Upgrading would make the badness go away.

NES6.x introduces its own HEAD problem, so it's not an ideal solution.
Let this mail from the W3C-validator list explain:

Date: Sat, 02 Nov 2002 22:01:16 +0100
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Terje Bless <link@pobox.com>
Cc: W3C Validator <www-validator@w3.org>
Subject: Re: bug in checklink
Resent-Date: Sat, 2 Nov 2002 16:01:00 -0500 (EST)
Resent-From: www-validator@w3.org


* Terje Bless wrote:
>Lloyd Wood <l.wood@eim.surrey.ac.uk> wrote:
>
>>It's netscape Enterprise/3.6.
>>
>>www.mozilla.org also runs that, and has similar problems with HEAD
>>(returns a 500 error at present).
>
>This product is defunct now, isn't it? At least I was unable to find it on
>netscape.com.

http://enterprise.netscape.com/products/contentsvcs/enterprise.html

The server seems to be running the latest version, but

  % http-head http://enterprise.netscape.com/
  HTTP/1.1 200 OK
  Server: Netscape-Enterprise/6.0 AOL
  Date: Sat, 02 Nov 2002 21:03:55 GMT
  Content-type: text/html
  Content-length: 0
  Connection: close

is obviously still buggy, GET returns

  ...
  Content-length: 7504

i.e., the Content-Length length header is plain wrong for HEAD requests.
At least it does not respond with 500...
Wow. I finally got a bug I opened resolved. Thanks.

lynx -head http://www.mozilla.org/

HTTP/1.1 200 OK
Date: Sat, 22 Nov 2003 22:52:57 GMT
Server: Apache/1.3.27 (Unix)  (Red-Hat/Linux) PHP/4.1.2
Last-Modified: Thu, 20 Nov 2003 19:47:17 GMT
ETag: "380003-2768-3fbd1a45"
Accept-Ranges: bytes
Content-Length: 10088
Content-Type: text/html
Connection: Close
Status: NEW → RESOLVED
Closed: 23 years ago → 21 years ago
Resolution: --- → FIXED
verify fixed.  :)

This was one of the benefits of getting out of AOL :)

Mozilla Foundation has its own servers now that we can do what we want with. :)
Status: RESOLVED → VERIFIED
http://www.livejournal.com/users/jwz/268332.html?thread=2173740#t2173740

in retrospect, suggesting AOLServer was perhaps a mistake.
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.