> 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.
*** 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.
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".
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.
> 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?
> 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.
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
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
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/
> 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 <email@example.com> To: Terje Bless <firstname.lastname@example.org> Cc: W3C Validator <email@example.com> Subject: Re: bug in checklink Resent-Date: Sat, 2 Nov 2002 16:01:00 -0500 (EST) Resent-From: firstname.lastname@example.org * Terje Bless wrote: >Lloyd Wood <email@example.com> 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
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. :)
http://www.livejournal.com/users/jwz/268332.html?thread=2173740#t2173740 in retrospect, suggesting AOLServer was perhaps a mistake.