1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
|
<!--#if expr="$FAQMASTER" -->
<!--#set var="STANDALONE" value="" -->
<!--#set var="INCLUDED" value="YES" -->
<!--#if expr="$QUERY_STRING = TOC" -->
<!--#set var="TOC" value="YES" -->
<!--#set var="CONTENT" value="" -->
<!--#else -->
<!--#set var="TOC" value="" -->
<!--#set var="CONTENT" value="YES" -->
<!--#endif -->
<!--#else -->
<!--#set var="STANDALONE" value="YES" -->
<!--#set var="INCLUDED" value="" -->
<!--#set var="TOC" value="" -->
<!--#set var="CONTENT" value="" -->
<!--#endif -->
<!--#if expr="$STANDALONE" -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<TITLE>Apache Server Frequently Asked Questions</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<!--#include virtual="header.html" -->
<H1 ALIGN="CENTER">Apache Server Frequently Asked Questions</H1>
<P>
$Revision: 1.7 $ ($Date: 2001/02/28 03:35:59 $)
</P>
<P>
The latest version of this FAQ is always available from the main
Apache web site, at
<<A
HREF="http://www.apache.org/docs/misc/FAQ.html"
REL="Help"
><SAMP>http://www.apache.org/docs/misc/FAQ.html</SAMP></A>>.
</P>
<!-- Notes about changes: -->
<!-- - If adding a relative link to another part of the -->
<!-- documentation, *do* include the ".html" portion. There's a -->
<!-- good chance that the user will be reading the documentation -->
<!-- on his own system, which may not be configured for -->
<!-- multiviews. -->
<!-- - When adding items, make sure they're put in the right place -->
<!-- - verify that the numbering matches up. -->
<!-- - *Don't* use <PRE></PRE> blocks - they don't appear -->
<!-- correctly in a reliable way when this is converted to text -->
<!-- with Lynx. Use <DL><DD><CODE>xxx<BR>xx</CODE></DD></DL> -->
<!-- blocks inside a <P></P> instead. This is necessary to get -->
<!-- the horizontal and vertical indenting right. -->
<!-- - Don't forget to include an HR tag after the last /P tag -->
<!-- but before the /LI in an item. -->
<P>
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.
</P>
<H2>The Questions</H2>
<OL TYPE="A">
<!--#endif -->
<!--#if expr="$TOC || $STANDALONE" -->
<LI VALUE="5"><STRONG>Configuration Questions</STRONG>
<OL>
<LI><A HREF="#fdlim">Why can't I run more than <<EM>n</EM>>
virtual hosts?</A>
</LI>
<LI><A HREF="#freebsd-setsize">Can I increase <SAMP>FD_SETSIZE</SAMP>
on FreeBSD?</A>
</LI>
<LI><A HREF="#errordoc401">Why doesn't my <CODE>ErrorDocument
401</CODE> work?</A>
</LI>
<LI><A HREF="#cookies1">Why does Apache send a cookie on every response?</A>
</LI>
<LI><A HREF="#cookies2">Why don't my cookies work, I even compiled in
<SAMP>mod_cookies</SAMP>?</A>
</LI>
<LI><A HREF="#jdk1-and-http1.1">Why do my Java app[let]s give me plain text
when I request an URL from an Apache server?</A>
</LI>
<LI><A HREF="#midi">How do I get Apache to send a MIDI file so the
browser can play it?</A>
</LI>
<LI><A HREF="#addlog">How do I add browsers and referrers to my logs?</A>
</LI>
<LI><A HREF="#set-servername">Why does accessing directories only work
when I include the trailing "/"
(<EM>e.g.</EM>, <SAMP>http://foo.domain.com/~user/</SAMP>) but
not when I omit it
(<EM>e.g.</EM>, <SAMP>http://foo.domain.com/~user</SAMP>)?</A>
</LI>
<LI><A HREF="#no-info-directives">Why doesn't mod_info list any
directives?</A>
</LI>
<LI><A HREF="#namevhost">I upgraded to Apache 1.3 and now my
virtual hosts don't work!</A>
</LI>
<LI><A HREF="#redhat-htm">I'm using RedHat Linux and my .htm files are
showing up as HTML source rather than being formatted!</A>
</LI>
<LI><A HREF="#htaccess-work">My <CODE>.htaccess</CODE> files are being
ignored.</A>
</LI>
<LI><A HREF="#forbidden">Why do I get a
"<SAMP>Forbidden</SAMP>" message whenever I try to
access a particular directory?</A>
<LI><A HREF="#ie-ignores-mime">Why do my files appear correctly in
Internet Explorer, but show up as source or trigger a save
window with Netscape?</A>
</OL>
</LI>
<!--#endif -->
<!--#if expr="$STANDALONE" -->
</OL>
<HR>
<H2>The Answers</H2>
<!--#endif -->
<!--#if expr="! $TOC" -->
<H3>E. Configuration Questions</H3>
<OL>
<LI><A NAME="fdlim">
<STRONG>Why can't I run more than <<EM>n</EM>>
virtual hosts?</STRONG>
</A>
<P>
You are probably running into resource limitations in your
operating system. The most common limitation is the
<EM>per</EM>-process limit on <STRONG>file descriptors</STRONG>,
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
<CODE>gethostbyname()</CODE>) which needs file descriptors and
doesn't complain intelligibly when it can't get them.
</P>
<P>
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
<A HREF="../mod/mpm_common.html#listen"><SAMP>Listen</SAMP></A>
directive also needs a file descriptor.
</P>
<P>
Typical values for <<EM>n</EM>> 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.
</P>
<P>
As to what you can do about this:
</P>
<OL>
<LI>Reduce the number of
<A HREF="../mod/mpm_common.html#listen"><SAMP>Listen</SAMP></A>
directives. If there are no other servers running on the machine
on the same port then you normally don't
need any Listen directives at all. By default Apache listens to
all addresses on port 80.
</LI>
<LI>Reduce the number of log files. You can use
<A HREF="../mod/mod_log_config.html"><SAMP>mod_log_config</SAMP></A>
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. Such a script is provided with the Apache 1.3 distribution
in the <SAMP>src/support/split-logfile</SAMP> file.
</LI>
<LI>Increase the number of file descriptors available to the server
(see your system's documentation on the <CODE>limit</CODE> or
<CODE>ulimit</CODE> commands). For some systems, information on
how to do this is available in the
<A HREF="perf-tuning.html">performance hints</A> page. There is a specific
note for <A HREF="#freebsd-setsize">FreeBSD</A> below.
<P>
For Windows 95, try modifying your <SAMP>C:\CONFIG.SYS</SAMP> file to
include a line like
</P>
<DL>
<DD><CODE>FILES=300</CODE>
</DD>
</DL>
<P>
Remember that you'll need to reboot your Windows 95 system in order
for the new value to take effect.
</P>
</LI>
<LI>"Don't do that" - try to run with fewer virtual hosts
</LI>
<LI>Spread your operation across multiple server processes (using
<A HREF="../mod/mpm_common.html#listen"><SAMP>Listen</SAMP></A>
for example, but see the first point) and/or ports.
</LI>
</OL>
<P>
Since this is an operating-system limitation, there's not much else
available in the way of solutions.
</P>
<P>
As of 1.2.1 we have made attempts to work around various limitations
involving running with many descriptors.
<A HREF="descriptors.html">More information is available.</A>
</P>
<HR>
</LI>
<LI><A NAME="freebsd-setsize">
<STRONG>Can I increase <SAMP>FD_SETSIZE</SAMP> on FreeBSD?</STRONG>
</A>
<P>
On versions of FreeBSD before 3.0, the <SAMP>FD_SETSIZE</SAMP> define
defaults to 256. This means that you will have trouble usefully using
more than 256 file descriptors in Apache. This can be increased, but
doing so can be tricky.
</P>
<P>
If you are using a version prior to 2.2, you need to recompile your
kernel with a larger <SAMP>FD_SETSIZE</SAMP>. This can be done by adding a
line such as:
</P>
<DL>
<DD><CODE>options FD_SETSIZE <EM>nnn</EM></CODE>
</DD>
</DL>
<P>
to your kernel config file. Starting at version 2.2, this is no
longer necessary.
</P>
<P>
If you are using a version of 2.1-stable from after 1997/03/10 or
2.2 or 3.0-current from before 1997/06/28, there is a limit in
the resolver library that prevents it from using more file descriptors
than what <SAMP>FD_SETSIZE</SAMP> is set to when libc is compiled. To
increase this, you have to recompile libc with a higher
<SAMP>FD_SETSIZE</SAMP>.
</P>
<P>
In FreeBSD 3.0, the default <SAMP>FD_SETSIZE</SAMP> has been increased to
1024 and the above limitation in the resolver library
has been removed.
</P>
<P>
After you deal with the appropriate changes above, you can increase
the setting of <SAMP>FD_SETSIZE</SAMP> at Apache compilation time
by adding "<SAMP>-DFD_SETSIZE=<EM>nnn</EM></SAMP>" to the
<SAMP>EXTRA_CFLAGS</SAMP> line in your <SAMP>Configuration</SAMP>
file.
</P>
<HR>
</LI>
<LI><A NAME="errordoc401">
<STRONG>Why doesn't my <CODE>ErrorDocument 401</CODE> work?</STRONG>
</A>
<P>
You need to use it with a URL in the form
"<SAMP>/foo/bar</SAMP>" and not one with a method and
hostname such as "<SAMP>http://host/foo/bar</SAMP>". See the
<A HREF="../mod/core.html#errordocument"><SAMP>ErrorDocument</SAMP></A>
documentation for details. This was incorrectly documented in the past.
</P>
<HR>
</LI>
<LI><A NAME="cookies1">
<STRONG>Why does Apache send a cookie on every response?</STRONG>
</A>
<P>
Apache does <EM>not</EM> automatically send a cookie on every
response, unless you have re-compiled it with the
<A HREF="../mod/mod_usertrack.html"><SAMP>mod_usertrack</SAMP></A>
module, and specifically enabled it with the
<A HREF="../mod/mod_usertrack.html#cookietracking"
><SAMP>CookieTracking</SAMP></A>
directive.
This module has been in Apache since version 1.2.
This module may help track users, and uses cookies to do this. If
you are not using the data generated by <SAMP>mod_usertrack</SAMP>, do
not compile it into Apache.
</P>
<HR>
</LI>
<LI><A NAME="cookies2">
<STRONG>Why don't my cookies work, I even compiled in
<SAMP>mod_cookies</SAMP>?
</STRONG>
</A>
<P>
Firstly, you do <EM>not</EM> need to compile in
<SAMP>mod_cookies</SAMP> in order for your scripts to work (see the
<A HREF="#cookies1">previous question</A>
for more about <SAMP>mod_cookies</SAMP>). Apache passes on your
<SAMP>Set-Cookie</SAMP> 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.
</P>
<HR>
</LI>
<LI><A NAME="jdk1-and-http1.1">
<STRONG>Why do my Java app[let]s give me plain text when I request
an URL from an Apache server?</STRONG>
</A>
<P>
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, low-level Web access classes
included in the Java Development Kit (JDK) version 1.0.2 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.
</P>
<P>
This is definitely a bug in the JDK 1.0.2 foundation classes from Sun,
and it has been fixed in version 1.1. However, the classes in
question are part of the virtual machine environment, which means
they're part of the Web browser (if Java-enabled) or the Java
environment on the client system - so even if you develop
<EM>your</EM> classes with a recent JDK, the eventual users might
encounter the problem.
The classes involved are replaceable by vendors implementing the
Java virtual machine environment, and so even those that are based
upon the 1.0.2 version may not have this problem.
</P>
<P>
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:
</P>
<P>
<DL>
<DD><CODE>BrowserMatch Java1.0 force-response-1.0
<BR>
BrowserMatch JDK/1.0 force-response-1.0</CODE>
</DD>
</DL>
<P></P>
<P>
More information about this issue can be found in the
<A HREF="http://www.apache.org/info/jdk-102.html"
><CITE>Java and HTTP/1.1</CITE></A>
page at the Apache web site.
</P>
<HR>
</LI>
<LI><A NAME="midi">
<STRONG>How do I get Apache to send a MIDI file so the browser can
play it?</STRONG>
</A>
<P>
Even though the registered MIME type for MIDI files is
<SAMP>audio/midi</SAMP>, some browsers are not set up to recognize it
as such; instead, they look for <SAMP>audio/x-midi</SAMP>. There are
two things you can do to address this:
</P>
<OL>
<LI>Configure your browser to treat documents of type
<SAMP>audio/midi</SAMP> 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.
</LI>
<LI>Instruct Apache to send a different <SAMP>Content-type</SAMP>
header for these files by adding the following line to your server's
configuration files:
<P>
<DL>
<DD><CODE>AddType audio/x-midi .mid .midi .kar</CODE>
</DD>
</DL>
<P></P>
<P>
Note that this may break browsers that <EM>do</EM> recognize the
<SAMP>audio/midi</SAMP> MIME type unless they're prepared to also
handle <SAMP>audio/x-midi</SAMP> the same way.
</P>
</LI>
</OL>
<HR>
</LI>
<LI><A NAME="addlog">
<STRONG>How do I add browsers and referrers to my logs?</STRONG>
</A>
<P>
Apache provides a couple of different ways of doing this. The
recommended method is to compile the
<A HREF="../mod/mod_log_config.html"><SAMP>mod_log_config</SAMP></A>
module into your configuration and use the
<A HREF="../mod/mod_log_config.html#customlog"><SAMP>CustomLog</SAMP></A>
directive.
</P>
<P>
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:
</P>
<P>
<CODE>
CustomLog logs/access_log "%h %l %u %t \"%r\" %s %b \"%{Referer}i\" \"%{User-Agent}i\""
</CODE>
</P>
<P>
This will add the values of the <SAMP>User-agent:</SAMP> and
<SAMP>Referer:</SAMP> headers, which indicate the client and the
referring page, respectively, to the end of each line in the access
log.
</P>
<P>
You may want to check out the <CITE>Apache Week</CITE> article
entitled:
"<A HREF="http://www.apacheweek.com/features/logfiles" REL="Help"
><CITE>Gathering Visitor Information: Customizing Your
Logfiles</CITE></A>".
</P>
<HR>
</LI>
<LI><A NAME="set-servername">
<STRONG>Why does accessing directories only work when I include
the trailing "/"
(<EM>e.g.</EM>, <SAMP>http://foo.domain.com/~user/</SAMP>)
but not when I omit it
(<EM>e.g.</EM>, <SAMP>http://foo.domain.com/~user</SAMP>)?</STRONG>
</A>
<P>
When you access a directory without a trailing "/", Apache needs
to send what is called a redirect to the client to tell it to
add the trailing slash. If it did not do so, relative URLs would
not work properly. When it sends the redirect, it needs to know
the name of the server so that it can include it in the redirect.
There are two ways for Apache to find this out; either it can guess,
or you can tell it. If your DNS is configured correctly, it can
normally guess without any problems. If it is not, however, then
you need to tell it.
</P>
<P>
Add a <A HREF="../mod/core.html#servername">ServerName</A> directive
to the config file to tell it what the domain name of the server is.
</P>
<HR>
</LI>
<LI><A NAME="no-info-directives">
<STRONG>Why doesn't mod_info list any directives?</STRONG>
</A>
<P>
The <A HREF="../mod/mod_info.html"><SAMP>mod_info</SAMP></A>
module allows you to use a Web browser to see how your server is
configured. Among the information it displays is the list modules and
their configuration directives. The "current" values for
the directives are not necessarily those of the running server; they
are extracted from the configuration files themselves at the time of
the request. If the files have been changed since the server was last
reloaded, the display will not match the values actively in use.
If the files and the path to the files are not readable by the user as
which the server is running (see the
<A HREF="../mod/mpm_common.html#user"><SAMP>User</SAMP></A>
directive), then <SAMP>mod_info</SAMP> cannot read them in order to
list their values. An entry <EM>will</EM> be made in the error log in
this event, however.
</P>
<HR>
</LI>
<LI><A NAME="namevhost">
<STRONG>I upgraded to Apache 1.3 and now my virtual hosts don't
work!</STRONG>
</A>
<P>
In versions of Apache prior to 1.3b2, there was a lot of confusion
regarding address-based virtual hosts and (HTTP/1.1) name-based
virtual hosts, and the rules concerning how the server processed
<SAMP><VirtualHost></SAMP> definitions were very complex and not
well documented.
</P>
<P>
Apache 1.3b2 introduced a new directive,
<A HREF="http://www.apache.org/docs/mod/core.html#namevirtualhost"
><SAMP>NameVirtualHost</SAMP></A>,
which simplifies the rules quite a bit. However, changing the rules
like this means that your existing name-based
<SAMP><VirtualHost></SAMP> containers probably won't work
correctly immediately following the upgrade.
</P>
<P>
To correct this problem, add the following line to the beginning of
your server configuration file, before defining any virtual hosts:
</P>
<DL>
<DD><CODE>NameVirtualHost <EM>n.n.n.n</EM></CODE>
</DD>
</DL>
<P>
Replace the "<SAMP>n.n.n.n</SAMP>" with the IP address to
which the name-based virtual host names resolve; if you have multiple
name-based hosts on multiple addresses, repeat the directive for each
address.
</P>
<P>
Make sure that your name-based <SAMP><VirtualHost></SAMP> blocks
contain <SAMP>ServerName</SAMP> and possibly <SAMP>ServerAlias</SAMP>
directives so Apache can be sure to tell them apart correctly.
</P>
<P>
Please see the <A HREF="../vhosts/">Apache
Virtual Host documentation</A> for further details about configuration.
</P>
<HR>
</LI>
<LI><A NAME="redhat-htm">
<STRONG>I'm using RedHat Linux and my .htm files are showing
up as HTML source rather than being formatted!</STRONG>
</A>
<P>
RedHat messed up and forgot to put a content type for <CODE>.htm</CODE>
files into <CODE>/etc/mime.types</CODE>. Edit <CODE>/etc/mime.types</CODE>,
find the line containing <CODE>html</CODE> and add <CODE>htm</CODE> to it.
Then restart your httpd server:
</P>
<DL>
<DD><CODE>kill -HUP `cat /var/run/httpd.pid`</CODE>
</DD>
</DL>
<P>
Then <STRONG>clear your browsers' caches</STRONG>. (Many browsers won't
re-examine the content type after they've reloaded a page.)
</P>
<HR>
</LI>
<LI><A NAME="htaccess-work">
<STRONG>My <CODE>.htaccess</CODE> files are being ignored.</STRONG></A>
<P>
This is almost always due to your <A HREF="../mod/core.html#allowoverride">
AllowOverride</A> directive being set incorrectly for the directory in
question. If it is set to <CODE>None</CODE> then .htaccess files will
not even be looked for. If you do have one that is set, then be certain
it covers the directory you are trying to use the .htaccess file in.
This is normally accomplished by ensuring it is inside the proper
<A HREF="../mod/core.html#directory">Directory</A> container.
</P>
<HR>
</LI>
<LI><A NAME="forbidden">
<STRONG>Why do I get a "<SAMP>Forbidden</SAMP>" message
whenever I try to access a particular directory?</STRONG></A>
<P>
This message is generally caused because either
</P>
<UL>
<LI>The underlying file system permissions do not allow the
User/Group under which Apache is running to access the necessary
files; or
<LI>The Apache configuration has some access restrictions in
place which forbid access to the files.
</UL>
<P>
You can determine which case applies to your situation by checking the
error log.
</P>
<P>
In the case where file system permission are at fault, remember
that not only must the directory and files in question be readable,
but also all parent directories must be at least searchable by the
web server in order for the content to be accessible.
</P>
<HR>
</LI>
<LI><A NAME="ie-ignores-mime">
<STRONG>Why do my files appear correctly in Internet
Explorer, but show up as source or trigger a save window
with Netscape?</STRONG></A>
<P>
Internet Explorer (IE) and Netscape handle mime type detection in different
ways, and therefore will display the document differently. In particular,
IE sometimes relies on the file extension to determine the mime type. This
can happen when the server specifies a mime type of
<CODE>application/octet-stream</CODE> or <CODE>text/plain</CODE>.
(Unfortunately, this behavior makes it impossible to properly send plain
text in some situations unless the file extension is <CODE>txt</CODE>.)
There are more details available on IE's mime type detection behavior in an
<A HREF="http://msdn.microsoft.com/workshop/networking/moniker/overview/appendix_a.asp">MSDN
article</A>.
</P>
<P>
In order to make all browsers work correctly, you should assure
that Apache sends the correct mime type for the file. This is
accomplished by editing the <CODE>mime.types</CODE> file or using
an <A HREF="../mod/mod_mime.html#addtype"><CODE>AddType</CODE></A>
directive in the Apache configuration files.
</P>
<HR>
</LI>
</OL>
<!--#endif -->
<!--#if expr="$STANDALONE" -->
<!-- Don't forget to add HR tags at the end of each list item.. -->
<!--#include virtual="footer.html" -->
</BODY>
</HTML>
<!--#endif -->
|
