Web site hosting and domain registration services by Active-Venture.com
  

Apache Server Frequently Asked Questions

B. General Technical Questions

  1. "Why can't I ...? Why won't ... work?" What to do in case of problems

    If you are having trouble with your Apache server software, you should take the following steps:

    1. Check the errorlog!

      Apache tries to be helpful when it encounters a problem. In many cases, it will provide some details by writing one or messages to the server error log. Sometimes this is enough for you to diagnose & fix the problem yourself (such as file permissions or the like). The default location of the error log is /usr/local/apache/logs/error_log, but see the ErrorLog directive in your config files for the location on your server.

    2. Check the FAQ!

      The latest version of the Apache Frequently-Asked Questions list can always be found at the main Apache web site.

    3. Check the Apache bug database

      Most problems that get reported to The Apache Group are recorded in the bug database. Please check the existing reports, open and closed, before adding one. If you find that your issue has already been reported, please don't add a "me, too" report. If the original report isn't closed yet, we suggest that you check it periodically. You might also consider contacting the original submitter, because there may be an email exchange going on about the issue that isn't getting recorded in the database.

    4. Ask in a user support group.

      A lot of common problems never make it to the bug database because there's already high Q&A traffic about them in the Users mailing list or comp.infosystems.www.servers.unix and related newsgroups. These newsgroups are also available via Google. Many Apache users, and some of the developers, can be found roaming their virtual halls, so it is suggested that you seek wisdom there. The chances are good that you'll get a faster answer there than from the bug database, even if you don't see your question already posted.

    5. If all else fails, report the problem in the bug database

      If you've gone through those steps above that are appropriate and have obtained no relief, then please do let The Apache Group know about the problem by logging a bug report.

      If your problem involves the server crashing and generating a core dump, please include a backtrace (if possible). As an example,

      # cd ServerRoot
      # dbx httpd core
      (dbx) where

      (Substitute the appropriate locations for your ServerRoot and your httpd and core files. You may have to use gdb instead of dbx.)

  2. How compatible is Apache with my existing NCSA 1.3 setup?

    Apache attempts to offer all the features and configuration options of NCSA httpd 1.3, as well as many of the additional features found in NCSA httpd 1.4 and NCSA httpd 1.5.

    NCSA httpd appears to be moving toward adding experimental features which are not generally required at the moment. Some of the experiments will succeed while others will inevitably be dropped. The Apache philosophy is to add what's needed as and when it is needed.

    Friendly interaction between Apache and NCSA developers should ensure that fundamental feature enhancements stay consistent between the two servers for the foreseeable future.

  3. Is Apache Year 2000 compliant?

    Yes, Apache is Year 2000 compliant.

    Apache internally never stores years as two digits. On the HTTP protocol level RFC1123-style addresses are generated which is the only format a HTTP/1.1-compliant server should generate. To be compatible with older applications Apache recognizes ANSI C's asctime() and RFC850-/RFC1036-style date formats, too. The asctime() format uses four-digit years, but the RFC850 and RFC1036 date formats only define a two-digit year. If Apache sees such a date with a value less than 70 it assumes that the century is 20 rather than 19.

    Although Apache is Year 2000 compliant, you may still get problems if the underlying OS has problems with dates past year 2000 (e.g., OS calls which accept or return year numbers). Most (UNIX) systems store dates internally as signed 32-bit integers which contain the number of seconds since 1st January 1970, so the magic boundary to worry about is the year 2038 and not 2000. But modern operating systems shouldn't cause any trouble at all.

    Users of Apache 1.2.x should upgrade to a current version of Apache 1.3 (see year-2000 improvements in Apache 1.3 for details).

    The Apache HTTP Server project is an open-source software product of the Apache Software Foundation. The project and the Foundation cannot offer legal assurances regarding any suitability of the software for your application. There are several commercial Apache support organizations and derivative server products available that may be able to stand behind the software and provide you with any assurances you may require. You may find links to some of these vendors at <http://www.apache.org/info/support.cgi>.

    The Apache HTTP server software is distributed with the following disclaimer, found in the software license:

       THIS SOFTWARE IS PROVIDED BY THE APACHE GROUP ``AS IS'' AND ANY
   EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
   IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
   PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE APACHE GROUP OR
   ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
   NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
   LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
   HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
   STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
   ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
   OF THE POSSIBILITY OF SUCH DAMAGE.
  4. How do I submit a patch to the Apache Group?

    The Apache Group encourages patches from outside developers. There are 2 main "types" of patches: small bugfixes and general improvements. Bugfixes should be submitting using the Apache bug report page. Improvements, modifications, and additions should follow the instructions below.

    In general, the first course of action is to be a member of the dev@httpd.apache.org mailing list. This indicates to the Group that you are closely following the latest Apache developments. Your patch file should be generated using either 'diff -c' or 'diff -u' against the latest CVS tree. To submit your patch, send email to dev@httpd.apache.org with a Subject: line that starts with [PATCH] and includes a general description of the patch. In the body of the message, the patch should be clearly described and then included at the end of the message. If the patch-file is long, you can note a URL to the file instead of the file itself. Use of MIME enclosures/attachments should be avoided.

    Be prepared to respond to any questions about your patches and possibly defend your code. If your patch results in a lot of discussion, you may be asked to submit an updated patch that incorporates all changes and suggestions.

  5. Why has Apache stolen my favourite site's Internet address?

    The simple answer is: "It hasn't." This misconception is usually caused by the site in question having migrated to the Apache Web server software, but not having migrated the site's content yet. When Apache is installed, the default page that gets installed tells the Webmaster the installation was successful. The expectation is that this default page will be replaced with the site's real content. If it doesn't, complain to the Webmaster, not to the Apache project -- we just make the software and aren't responsible for what people do (or don't do) with it.

  6. Why am I getting spam mail from the Apache site?

    The short answer is: "You aren't." Usually when someone thinks the Apache site is originating spam, it's because they've traced the spam to a Web site, and the Web site says it's using Apache. See the previous FAQ entry for more details on this phenomenon.

    No marketing spam originates from the Apache site. The only mail that comes from the site goes only to addresses that have been requested to receive the mail.

  7. May I include the Apache software on a CD or other package I'm distributing?

    The detailed answer to this question can be found in the Apache license, which is included in the Apache distribution in the file LICENSE. You can also find it on the Web at <http://www.apache.org/LICENSE.txt>.

  8. What's the best hardware/operating system/... How do I get the most out of my Apache Web server?

    Check out Dean Gaudet's performance tuning page.

  9. What are "regular expressions"?

    Regular expressions are a way of describing a pattern - for example, "all the words that begin with the letter A" or "every 10-digit phone number" or even "Every sentence with two commas in it, and no capital letter Q". Regular expressions (aka "regex"s) are useful in Apache because they let you apply certain attributes against collections of files or resources in very flexible ways - for example, all .gif and .jpg files under any "images" directory could be written as /\/images\/.*(jpg|gif)$/.

    The best overview around is probably the one which comes with Perl. We implement a simple subset of Perl's regex support, but it's still a good way to learn what they mean. You can start by going to the CPAN page on regular expressions, and branching out from there.

  10. Why isn't there a binary for my platform?

    The developers make sure that the software builds and works correctly on the platforms available to them; this does not necessarily mean that your platform is one of them. In addition, the Apache HTTP server project is primarily source oriented, meaning that distributing valid and buildable source code is the purpose of a release, not making sure that there is a binary package for all of the supported platforms.

    If you don't see a kit for your platform listed in the binary distribution area (<URL:http://httpd.apache.org/dist/httpd/binaries/>), it means either that the platform isn't available to any of the developers, or that they just haven't gotten around to preparing a binary for it. As this is a voluntary project, they are under no obligation to do so. Users are encouraged and expected to build the software themselves.

    The sole exception to these practices is the Windows package. Unlike most Unix and Unix-like platforms, Windows systems do not come with a bundled software development environment, so we do prepare binary kits for Windows when we make a release. Again, however, it's a voluntary thing and only a limited number of the developers have the capability to build the InstallShield package, so the Windows release may lag somewhat behind the source release. This lag should be no more than a few days at most.

 

 

 

© 2005 Active-Venture.com Web Page Hosting Service

Buy domain name registration | Register cheap domain name | Domain registration services 

< Computers make it easier to do a lot of things, but most of the things they make it easier to do don't need to be done.   >

 

 
 

Disclaimer: This documentation is provided only for the benefits of our hosting customers.
For authoritative source of the documentation, please refer to http://httpd.apache.org/docs/