Apache FAQ (experimental first posting)

301 views

Skip to first unread message

Rodent of Unusual Size

unread,

May 13, 1997, 3:00:00 AM5/13/97

[APACHE DOCUMENTATION]

Apache Server Frequently Asked Questions

$Revision: 1.57 $ ($Date: 1997/05/10 23:30:03 $)

The latest version of this FAQ is always available from the main
Apache web site, at <[1]http://www.apache.org/docs/misc/FAQ>.

If you are reading a text-only version of this FAQ, you may find
numbers enclosed in brackets (such as "[12]"). These refer to the list
of reference URLs to be found at the end of the document. These
references do not appear, and are not needed, for the hypertext
version.

The Questions

* _Background_
1. [2]What is Apache?
2. [3]Why was Apache created?
3. [4]How does The Apache Group's work relate to other servers?
4. [5]Why the name "Apache"?
5. [6]OK, so how does Apache compare to other servers?
6. [7]How thoroughly tested is Apache?
7. [8]What are the future plans for Apache?
8. [9]Whom do I contact for support?
9. [10]Is there any more information on Apache?
10. [11]Where can I get Apache?
* _Technical Questions_
11. [12]"Why can't I ...? Why won't ... work?" What to do in case
of problems
12. [13]How compatible is Apache with my existing NCSA 1.3 setup?
13. [14]How do I enable CGI execution in directories other than
the ScriptAlias?
14. [15]What does it mean when my CGIs fail with "Premature end
of script headers"?
15. [16]How do I enable SSI (parsed HTML)?
16. [17]Why don't my parsed files get cached?
17. [18]How can I have my script output parsed?
18. [19]Does or will Apache act as a Proxy server?
19. [20]What are "multiviews"?
20. [21]Why can't I run more than <n> virtual hosts?
21. [22]Why do I keep getting "access denied" for form POST
requests?
22. [23]Can I use my /etc/passwd file for Web page
authentication?
23. [24]Why doesn't my ErrorDocument 401 work?
24. [25]Why do I get "setgid: Invalid argument" at startup?
25. [26]Why does Apache send a cookie on every response?
26. [27]Why don't my cookies work, I even compiled in
mod_cookies?
27. [28]Why do my Java app[let]s give me plain text when I
request an URL from an Apache server?
28. [29]Why can't I publish to my Apache server using PUT on
Netscape Gold and other programs?
29. [30]Why isn't FastCGI included with Apache any more?
30. [31]Why am I getting "httpd: could not set socket option
TCP_NODELAY" in my error log?
31. [32]How can I get my script's output without Apache buffering
it?
32. [33]Why do I get complaints about redefinition of `struct
iovec' when compiling under Linux?
33. [34]The errorlog says Apache dumped core, but where's the
dump file?
34. [35]Why isn't restricting access by host or domain name
working correctly?
35. [36]Why doesn't Apache include SSL?
36. [37]Why do I get core dumps under HPUX using HP's ANSI C
compiler?
37. [38]How do I get Apache to send a MIDI file so the browser
can play it?
38. [39]Why won't Apache compile with my system's cc?
39. [40]How do I add browsers and referrers to my logs?
40. [41]Why do Java applets and applications not work with
documents on my Apache server?
_________________________________________________________________

The Answers

Background

1. _What is Apache?_
Apache was originally based on code and ideas found in the most
popular HTTP server of the time.. NCSA httpd 1.3 (early 1995). It
has since evolved into a far superior system which can rival (and
probably surpass) almost any other UNIX based HTTP server in terms
of functionality, efficiency and speed.
Since it began, it has been completely rewritten, and includes
many new features. Apache is, as of January 1997, the most popular
WWW server on the Internet, according to the [42]Netcraft Survey.
_____________________________________________________________

2. _Why was Apache created?_
To address the concerns of a group of WWW providers and part-time
httpd programmers that httpd didn't behave as they wanted it to
behave. Apache is an entirely volunteer effort, completely funded
by its members, not by commercial sales.
_____________________________________________________________

3. _How does The Apache Group's work relate to other server efforts,
such as NCSA's?_
We, of course, owe a great debt to NCSA and their programmers for
making the server Apache was based on. We now, however, have our
own server, and our project is mostly our own. The Apache Project
is an entirely independent venture.
_____________________________________________________________

4. _Why the name "Apache"?_
A cute name which stuck. Apache is "_A PA_t_CH_y server". It was
based on some existing code and a series of "patch files".
_____________________________________________________________

5. _OK, so how does Apache compare to other servers?_
For an independent assessment, see [43]Web Compare's comparison
chart.
Apache has been shown to be substantially faster than many other
free servers. Although certain commercial servers have claimed to
surpass Apache's speed (it has not been demonstrated that any of
these "benchmarks" are a good way of measuring WWW server speed at
any rate), we feel that it is better to have a mostly-fast free
server than an extremely-fast server that costs thousands of
dollars. Apache is run on sites that get millions of hits per day,
and they have experienced no performance difficulties.
_____________________________________________________________

6. _How thoroughly tested is Apache?_
Apache is run on over 400,000 Internet servers (as of April 1997).
It has been tested thoroughly by both developers and users. The
Apache Group maintains rigorous standards before releasing new
versions of their server, and our server runs without a hitch on
over one third of all WWW servers available on the Internet. When
bugs do show up, we release patches and new versions as soon as
they are available.
The Apache project's web site includes a page with a partial list
of [44]sites running Apache.
_____________________________________________________________

7. _What are the future plans for Apache?_
+ to continue as a public domain HTTP server,
+ to keep up with advances in HTTP protocol and web
developments in general,
+ to collect suggestions for fixes/improvements from its users,
+ to respond to needs of large volume providers as well as
occasional users.
_____________________________________________________________

8. _Whom do I contact for support?_
There is no official support for Apache. None of the developers
want to be swamped by a flood of trivial questions that can be
resolved elsewhere. Bug reports and suggestions should be sent
_via_ [45]the bug report page. Other questions should be directed
to the [46]comp.infosystems.www.servers.unix newsgroup, where some
of the Apache team lurk, in the company of many other httpd gurus
who should be able to help.
Commercial support for Apache is, however, available from a number
of third parties.
_____________________________________________________________

9. _Is there any more information available on Apache?_
Indeed there is. See the main [47]Apache web site. There is also a
regular electronic publication called [48]Apache Week available.
Links to relevant _Apache Week_ articles are included below where
appropriate.
_____________________________________________________________

10. _Where can I get Apache?_
You can find out how to download the source for Apache at the
project's [49]main web page.
_____________________________________________________________

Technical Questions

11. _"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/etc/httpd/logs/error_log, but see the
[50]ErrorLog directive in your config files for the location
on your server.
2. _Check the [51]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 [52]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 the comp.infosystems.www.servers.unix USENET
newsgroup_
A lot of common problems never make it to the bug database
because there's already high Q&A traffic about them in the
[53]comp.infosystems.www.servers.unix newsgroup. Many Apache
users, and some of the developers, can be found roaming its
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 [54]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.)
_____________________________________________________________

12. _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.
_____________________________________________________________

13. _How do I enable CGI execution in directories other than the
ScriptAlias?_
Apache recognizes all files in a directory named as a
[55]ScriptAlias as being eligible for execution rather than
processing as normal documents. This applies regardless of the
file name, so scripts in a ScriptAlias directory don't need to be
named "*.cgi" or "*.pl" or whatever. In other words, _all_ files
in a ScriptAlias directory are scripts, as far as Apache is
concerned.
To persuade Apache to execute scripts in other locations, such as
in directories where normal documents may also live, you must tell
it how to recognize them - and also that it's okay to execute
them. For this, you need to use something like the [56]AddHandler
directive.
1. In an appropriate section of your server configuration files,
add a line such as

AddHandler cgi-script .cgi

The server will then recognize that all files in that
location (and its logical descendants) that end in ".cgi" are
script files, not documents.
2. Make sure that the directory location is covered by an
[57]Options declaration that includes the ExecCGI option.
_____________________________________________________________

14. _What does it mean when my CGIs fail with "Premature end of script
headers"?_
It means just what it says: the server was expecting a complete
set of HTTP headers (one or more followed by a blank line), and
didn't get them. The most common cause of this (aside from people
not outputting the required headers at all) a result of an
interaction with perl's output buffering. To make perl flush its
buffers after each output statement, insert the following
statements before your first print or write statement:

$cfh = select (STDOUT);
$| = 1;
select ($cfh);

This is generally only necessary when you are calling external
programs from your script that send output to stdout.
If your script isn't written in Perl, do the equivalent thing for
whatever language you _are_ using (_e.g._, for C, call fflush()
after writing the headers).
_____________________________________________________________

15. _How do I enable SSI (parsed HTML)?_
SSI (an acronym for Server-Side Include) directives allow static
HTML documents to be enhanced at run-time (_e.g._, when delivered
to a client by Apache). The format of SSI directives is covered in
the [58]mod_include manual; suffice it to say that Apache supports
not only SSI but xSSI (eXtended SSI) directives.
Processing a document at run-time is called _parsing_ it; hence
the term "parsed HTML" sometimes used for documents that contain
SSI instructions. Parsing tends to be _extremely_
resource-consumptive, and is not enabled by default.
To enable SSI processing, you need to
+ Build your server with the [59]mod_include module. This is
normally compiled in by default.
+ Make sure your server configuration files have an [60]Options
directive which permits Includes.
+ Make sure that the directory where you want the SSI documents
to live is covered by the "server-parsed" content handler,
either explicitly or in some ancestral location. That can be
done with the following [61]AddHandler directive:

AddHandler server-parsed .shtml

This indicates that all files ending in ".shtml" in that
location (or its descendants) should be parsed. Note that
using ".html" will cause all normal HTML files to be parsed,
which may put an inordinate load on your server.
For additional information, see the _Apache Week_ article on
[62]Using Server Side Includes.
_____________________________________________________________

16. _Why don't my parsed files get cached?_
Since the server is performing run-time processing of your SSI
directives, which may change the content shipped to the client, it
can't know at the time it starts parsing what the final size of
the result will be, or whether the parsed result will always be
the same. This means that it can't generate Content-Length or
Last-Modified headers. Caches commonly work by comparing the
Last-Modified of what's in the cache with that being delivered by
the server. Since the server isn't sending that header for a
parsed document, whatever's doing the caching can't tell whether
the document has changed or not - and so fetches it again to be on
the safe side.
You can work around this in some cases by causing an Expires
header to be generated. (See the [63]mod_expires documentation for
more details.) Another possibility is to use the [64]XBitHack Full
mechanism, which tells Apache to send (under certain circumstances
detailed in the XBitHack directive description) a Last-Modified
header based upon the last modification time of the file being
parsed. Note that this may actually be lying to the client if the
parsed file doesn't change but the SSI-inserted content does; if
the included content changes often, this can result in stale
copies being cached.
_____________________________________________________________

17. _How can I have my script output parsed?_
So you want to include SSI directives in the output from your CGI
script, but can't figure out how to do it? The short answer is
"you can't." This is potentially a security liability and, more
importantly, it can not be cleanly implemented under the current
server API. The best workaround is for your script itself to do
what the SSIs would be doing. After all, it's generating the rest
of the content.
This is a feature The Apache Group hopes to add in the next major
release after 1.2.
_____________________________________________________________

18. _Does or will Apache act as a Proxy server?_
Apache version 1.1 and above comes with a proxy module. If
compiled in, this will make Apache act as a caching-proxy server.
_____________________________________________________________

19. _What are "multiviews"?_
"Multiviews" is the general name given to the Apache server's
ability to provide language-specific document variants in response
to a request. This is documented quite thoroughly in the
[65]content negotiation description page. In addition, _Apache
Week_ carried an article on this subject entitled "[66]Content
Negotiation Explained".
_____________________________________________________________

20. _Why can't I run more than <n> virtual hosts?_
You are probably running into resource limitations in your
operating system. The most common limitation is the _per_-process
limit on _file descriptors_, which is almost always the cause of
problems seen when adding virtual hosts. Apache often does not
give an intuitive error message because it is normally some
library routine (such as gethostbyname()) which needs file
descriptors and doesn't complain intelligibly when it can't get
them.
Each log file requires a file descriptor, which means that if you
are using separate access and error logs for each virtual host,
each virtual host needs two file descriptors. Each [67]Listen
directive also needs a file descriptor.
Typical values for <_n_> that we've seen are in the neighborhood
of 128 or 250. When the server bumps into the file descriptor
limit, it may dump core with a SIGSEGV, it might just hang, or it
may limp along and you'll see (possibly meaningful) errors in the
error log. One common problem that occurs when you run into a file
descriptor limit is that CGI scripts stop being executed properly.
As to what you can do about this:
1. Reduce the number of [68]Listen directives. If there are no
other servers running on the machine and all of them are
running on the same port, you normally don't need any Listen
directives at all.
2. Reduce the number of log files. You can use
[69]mod_log_config to log all requests to a single log file
while including the name of the virtual host in the log file.
You can then write a script to split the logfile into
separate files later if necessary.
3. Increase the number of file descriptors available to the
server (see your system's documentation on the limit or
ulimit commands). For some systems, information on how to do
this is available in the [70]performance hints page.
4. "Don't do that" - try to run with fewer virtual hosts
5. Spread your operation across multiple server processes (using
[71]Listen for example, but see the first point) and/or
ports.
Since this is an operating-system limitation, there's not much
else available in the way of solutions.
_____________________________________________________________

21. _Why do I keep getting "access denied" for form POST requests?_
The most common cause of this is a <Limit> section that only names
the GET method. Look in your configuration files for something
that resembles the following and would affect the location where
the POST-handling script resides:

<Limit GET>
:

Change that to <Limit GET POST> and the problem will probably go
away.
_____________________________________________________________

22. _Can I use my /etc/passwd file for Web page authentication?_
Yes, you can - but it's a _very bad idea_. Here are some of the
reasons:
+ The Web technology provides no governors on how often or how
rapidly password (authentication failure) retries can be
made. That means that someone can hammer away at your
system's root password using the Web, using a dictionary or
similar mass attack, just as fast as the wire and your server
can handle the requests. Most operating systems these days
include attack detection (such as _n_ failed passwords for
the same account within _m_ seconds) and evasion (breaking
the connection, disabling the account under attack, disabling
_all_ logins from that source, _et cetera_), but the Web does
not.
+ An account under attack isn't notified (unless the server is
heavily modified); there's no "You have 19483 login failures"
message when the legitimate owner logs in.
+ Without an exhaustive and error-prone examination of the
server logs, you can't tell whether an account has been
compromised. Detecting that an attack has occurred, or is in
progress, is fairly obvious, though - _if_ you look at the
logs.
+ Web authentication passwords (at least for Basic
authentication) generally fly across the wire, and through
intermediate proxy systems, in what amounts to plaintext.
"O'er the net we go/Caching all the way;/O what fun it is to
surf/Giving my password away!"
+ Since HTTP is stateless, information about the authentication
is transmitted _each and every time_ a request is made to the
server. Essentially, the client caches it after the first
successful access, and transmits it without asking for all
subsequent requests to the same server.
+ It's relatively trivial for someone on your system to put up
a page that will steal the cached password from a client's
cache without them knowing. Can you say "password grabber"?
If you still want to do this in light of the above disadvantages,
the method is left as an exercise for the reader. It'll void your
Apache warranty, though, and you'll lose all accumulated UNIX guru
points.
_____________________________________________________________

23. _Why doesn't my ErrorDocument 401 work?_
You need to use it with a URL in the form "/foo/bar" and not one
with a method and hostname such as "http://host/foo/bar". See the
[72]ErrorDocument documentation for details. This was incorrectly
documented in the past.
_____________________________________________________________

24. _Why do I get "setgid: Invalid argument" at startup?_
Your [73]Group directive (probably in conf/httpd.conf) needs to
name a group that actually exists in the /etc/group file (or your
system's equivalent).
_____________________________________________________________

25. _Why does Apache send a cookie on every response?_
Apache does _not_ send automatically send a cookie on every
response, unless you have re-compiled it with the [74]mod_cookies
module. This module was distributed with Apache prior to 1.2. This
module may help track users, and uses cookies to do this. If you
are not using the data generated by mod_cookies, do not compile it
into Apache. Note that in 1.2 this module was renamed to the more
correct name [75]mod_usertrack, and cookies have to be
specifically enabled with the [76]CookieTracking directive.
_____________________________________________________________

26. _Why don't my cookies work, I even compiled in mod_cookies? _
Firstly, you do _not_ need to compile in mod_cookies in order for
your scripts to work (see the [77]previous question for more about
mod_cookies). Apache passes on your Set-Cookie header fine, with
or without this module. If cookies do not work it will be because
your script does not work properly or your browser does not use
cookies or is not set-up to accept them.
_____________________________________________________________

27. _Why do my Java app[let]s give me plain text when I request an URL
from an Apache server?_
As of version 1.2, Apache is an HTTP/1.1 (HyperText Transfer
Protocol version 1.1) server. This fact is reflected in the
protocol version that's included in the response headers sent to a
client when processing a request. Unfortunately, the URL methods
(URLConnection and friends) in the Java Development Kit (JDK)
versions 1.0.2 through 1.1.1 expect to see the version string
"HTTP/1.0" and do not correctly interpret the "HTTP/1.1" value
Apache is sending (this part of the response is a declaration of
what the server can do rather than a declaration of the dialect of
the response). The result is that the JDK methods do not correctly
parse the headers, and include them with the document content by
mistake.
This is definitely a bug in the JDK, but it's unclear when (or
whether) it will be fixed. In the meantime, a workaround is to
tell Apache to "fake" an HTTP/1.0 response to requests that come
from the JDK methods; this can be done by including a line such as
the following in your server configuration files:

BrowserMatch HotJava/1.0 force-response-1.0
_____________________________________________________________

28. _Why can't I publish to my Apache server using PUT on Netscape
Gold and other programs?_
Because you need to install and configure a script to handle the
uploaded files. This script is often called a "PUT" handler. There
are several available, but they may have security problems. Using
FTP uploads may be easier and more secure, at least for now. For
more information, see the _Apache Week_ article [78]Publishing
Pages with PUT.
_____________________________________________________________

29. _Why isn't FastCGI included with Apache any more?_
The simple answer is that it was becoming too difficult to keep
the version being included with Apache synchronized with the
master copy at the [79]FastCGI web site. When a new version of
Apache was released, the version of the FastCGI module included
with it would soon be out of date.
You can still obtain the FastCGI module for Apache from the master
FastCGI web site.
_____________________________________________________________

30. _Why am I getting "httpd: could not set socket option TCP_NODELAY"
in my error log?_
This message almost always indicates that the client disconnected
before Apache reached the point of calling setsockopt() for the
connection. It shouldn't occur for more than about 1% of the
requests your server handles, and it's advisory only in any case.
_____________________________________________________________

31. _How can I get my script's output without Apache buffering it?_
In order to improve network performance, Apache buffers script
output into relatively large chunks. If you have a script that
sends information in bursts (such as partial-done messages in a
multi-commit database transaction, perhaps), the client will not
necessarily get the output as the script is generating it.
To avoid this, Apache recognizes scripts whose names begin with
"nph-" as _non-parsed-header_ scripts. That is, Apache won't
buffer their output, but connect it directly to the socket going
back to the client.
While this will probably do what you want, there _are_ some
disadvantages to it:
+ _YOU_ (the script) are responsible for generating _ALL_ of
the HTTP headers, and no longer _just_ the "Content-type" or
"Location" headers
+ Unless your script generates its output carefully, you will
see a performance penalty as excessive numbers of packets go
back and forth
As an example how you might handle the former (in a Perl script):

if ($0 =~ m:/*nph-:) {
$HTTP_headers = "HTTP/1.1 200 OK\015\012";
$HTTP_headers .= "Connection: close\015\012";
printf ($HTTP_headers);
};

and then follow with your normal non-nph headers.
_____________________________________________________________

32. _Why do I get complaints about redefinition of `struct iovec' when
compiling under Linux?_
This is a conflict between your C library includes and your kernel
includes. You need to make sure that the versions of both are
matched properly. There are two workarounds, either one will solve
the problem:
+ Remove the definition of struct iovec from your C library
includes. It is located in /usr/include/sys/uio.h. _Or,_
+ Add -DNO_WRITEV to the EXTRA_CFLAGS line in your
Configuration and reconfigure/rebuild. This hurts performance
and should only be used as a last resort.
_____________________________________________________________

33. _The errorlog says Apache dumped core, but where's the dump file?_
In Apache version 1.2 (beginning with 1.2b8), the error log
message about dumped core includes the directory where the dump
file should be located. However, many Unixes do not allow a
process that has called setuid() to dump core for security
reasons; the typical Apache setup has the server started as root
to bind to port 80, after which it changes UIDs to a
non-privileged user to serve requests.
Dealing with this is extremely operating system-specific, and may
require rebuilding your system kernel. Consult your operating
system documentation or vendor for more information about whether
your system does this and how to bypass it. If there _is_ a
documented way of bypassing it, it is recommended that you bypass
it only for the httpd server process if possible.
The canonical location for Apache's core-dump files is the
[80]ServerRoot directory.
_____________________________________________________________

34. _Why isn't restricting access by host or domain name working
correctly?_
Two of the most common causes of this are:
1. _An error, inconsistency, or unexpected mapping in the DNS
registration_
This happens frequently: your configuration restricts access
to Host.FooBar.Com, but you can't get in from that host. The
usual reason for this is that Host.FooBar.Com is actually an
alias for another name, and when Apache performs the
address-to-name lookup it's getting the _real_ name, not
Host.FooBar.Com. You can verify this by checking the reverse
lookup yourself. The easiest way to work around it is to
specify the correct host name in your configuration.
2. _Inadequate checking and verification in your configuration
of Apache_
If you intend to perform access checking and restriction
based upon the client's host or domain name, you really need
to configure Apache to double-check the origin information
it's supplied. You do this by adding the -DMAXIMUM_DNS clause
to the EXTRA_CFLAGS definition in your Configuration file.
For example:

EXTRA_CFLAGS=-DMAXIMUM_DNS

This will cause Apache to be very paranoid about making sure
a particular host address is _really_ assigned to the name it
claims to be. Note that this _can_ incur a significant
performance penalty, however, because of all the name
resolution requests being sent to a nameserver.
_____________________________________________________________

35. _Why doesn't Apache include SSL?_
SSL (Secure Socket Layer) data transport requires encryption, and
many governments have restrictions upon the import, export, and
use of encryption technology. If Apache included SSL in the base
package, its distribution would involve all sorts of legal and
bureaucratic issues, and it would no longer be freely available.
Also, some of the technology required to talk to current clients
using SSL is patented by [81]RSA Data Security, who restricts its
use without a license.
Some SSL implementations of Apache are available, however; see the
"[82]related projects" page at the main Apache web site.
You can find out more about this topic in the _Apache Week_
article about [83]Apache and Secure Transactions.
_____________________________________________________________

36. _Why do I get core dumps under HPUX using HP's ANSI C compiler?_
We have had numerous reports of Apache dumping core when compiled
with HP's ANSI C compiler using optimization. Disabling the
compiler optimiation has fixed these problems.
_____________________________________________________________

37. _How do I get Apache to send a MIDI file so the browser can play
it?_
Even though the registered MIME type for MIDI files is audio/midi,
some browsers are not set up to recognize it as such; instead,
they look for audio/x-midi. There are two things you can do to
address this:
1. Configure your browser to treat documents of type audio/midi
correctly. This is the type that Apache sends by default.
This may not be workable, however, if you have many client
installations to change, or if some or many of the clients
are not under your control.
2. Instruct Apache to send a different Content-type header for
these files by adding the following line to your server's
configuration files:

AddType audio/x-midi .mid .midi .kar

Note that this may break browsers that _do_ recognize the
audio/midi MIME type unless they're prepared to also handle
audio/x-midi the same way.
_____________________________________________________________

38. _Why won't Apache compile with my system's cc?_
If the server won't compile on your system, it is probably due to
one of the following causes:
+ _The Configure script doesn't recognize your system
environment._
This might be either because it's completely unknown or
because the specific environment (include files, OS version,
_et cetera_) isn't explicitly handled. If this happens, you
may need to port the server to your OS yourself.
+ _Your system's C compiler is garbage._
Some operating systems include a default C compiler that is
either not ANSI C-compliant or suffers from other
deficiencies. The usual recommendation in cases like this is
to acquire, install, and use gcc.
+ _Your include files may be confused._
In some cases, we have found that a compiler installation or
system upgrade has left the C header files in an inconsistent
state. Make sure that your include directory tree is in sync
with the compiler and the operating system.
+ _Your operating system or compiler may be out of revision._
Software vendors (including those that develop operating
systems) issue new releases for a reason; sometimes to add
functionality, but more often to fix bugs that have been
discovered. Try upgrading your compiler and/or your operating
system.
The Apache Group tests the ability to build the server on many
different platforms. Unfortunately, we can't test all of the OS
platforms there are. If you have verified that none of the above
issues is the cause of your problem, and it hasn't been reported
before, please submit a [84]problem report. Be sure to include
_complete_ details, such as the compiler & OS versions and exact
error messages.
_____________________________________________________________

39. _How do I add browsers and referrers to my logs?_
Apache provides a couple of different ways of doing this. The
recommended method is to compile the [85]mod_log_config module
into your configuration and use the [86]CustomLog directive.
You can either log the additional information in files other than
your normal transfer log, or you can add them to the records
already being written. For example:
CustomLog logs/access_log "%h %l %u %t \"%r\" %s %b \"%{Referer}i\
" \"%{User-Agent}i\""
This will add the values of the User-agent: and Referer: headers,
which indicate the client and the referring page, respectively, to
the end of each line in the access log.
You may want to check out the _Apache Week_ article entitled:
"[87]Gathering Visitor Information: Customising Your Logfiles".
_____________________________________________________________

40. _Why do Java applets and applications not work with documents on
my Apache server?_

The Java Development Kit (JDK) libraries versions 1.0.2 and 1.1 do not
correctly interpret the "HTTP/1.1" response header that Apache 1.2
sends. Instead, if they don't see an exact match for "HTTP/1.0", they
assume the headers are part of the document content.

This is a known problem, and it has been reported to Sun's JavaSoft
unit. In the meantime, Apache 1.2 servers can work around this by
adding the following lines to their configuration files:

BrowserMatch HotJava/1. force-response-1.0
BrowserMatch Java1. force-response-1.0
_________________________________________________________________
_________________________________________________________________

[88]Index

References

Reply all

Reply to author

Forward

0 new messages