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
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
|
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML>
<HEAD>
<TITLE>Apache Server Frequently Asked Questions</TITLE>
</HEAD>
<BODY>
<!--#include virtual="header.html" -->
<H1>Apache Server Frequently Asked Questions</H1>
<P>
$Revision: 1.47 $ ($Date: 1997/04/30 20:30:35 $)
</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"
REL="Help"
><SAMP>http://www.apache.org/docs/misc/FAQ</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. Leave off the ".html" extension for absolute -->
<!-- links to sites which are known to run multiviews (e.g., -->
<!-- apache.org or apacheweek.com). -->
<!-- - When adding items, make sure they're put in the right place -->
<!-- - verify that the numbering matches up. -->
<!-- - 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>
<!-- Stuff to Add: -->
<!-- - can't bind to port 80 -->
<!-- - permission denied -->
<!-- - address already in use -->
<!-- - mod_auth & passwd lines "user:pw:.*" - ++1st colon onward is -->
<!-- treated as pw, not just ++1st to --2nd. -->
<!-- - SSL: -->
<!-- Can I use Apache-SSL for free in Canada? -->
<!-- Why can't I use Apache-SSL in the U.S.? -->
<!-- - How can I found out how many visitors my site gets? -->
<!-- - How do I add a counter? -->
<!-- - How do I configure Apache as a proxy? -->
<!-- - What browsers support HTTP/1.1? -->
<!-- - What's the point of vhosts-by-name is there aren't any -->
<!-- HTTP/1.1 browsers? -->
<!-- - Is there an Apache for W95/WNT? -->
<!-- - Why does Apache die when a vhost can't be DNS-resolved? -->
<!-- - How do I add browsers and referrers to my logs? -->
<!-- - How do I setup an access restriction so that people from -->
<!-- this domain don't have to authenticate, and all others can -->
<!-- do so via a username and password? -->
<!-- - How do I get Apache to send a MIDI file so the browser can -->
<!-- play it? (e.g., PR#514) -->
<UL>
<LI><STRONG>Background</STRONG>
<OL START=1>
<LI><A HREF="#what">What is Apache?</A>
</LI>
<LI><A HREF="#why">Why was Apache created?</A>
</LI>
<LI><A HREF="#relate">How does The Apache Group's work relate to
other servers?</A>
</LI>
<LI><A HREF="#name">Why the name "Apache"?</A>
</LI>
<LI><A HREF="#compare">OK, so how does Apache compare to other servers?</A>
</LI>
<LI><A HREF="#tested">How thoroughly tested is Apache?</A>
</LI>
<LI><A HREF="#future">What are the future plans for Apache?</A>
</LI>
<LI><A HREF="#support">Whom do I contact for support?</A>
</LI>
<LI><A HREF="#more">Is there any more information on Apache?</A>
</LI>
<LI><A HREF="#where">Where can I get Apache?</A>
</LI>
</OL>
</LI>
<LI><STRONG>Technical Questions</STRONG>
<OL START=11>
<LI><A HREF="#what2do">"Why can't I ...? Why won't ...
work?" What to do in case of problems</A>
</LI>
<LI><A HREF="#compatible">How compatible is Apache with my existing
NCSA 1.3 setup?</A>
</LI>
<LI><A HREF="#CGIoutsideScriptAlias">How do I enable CGI execution
in directories other than the ScriptAlias?</A>
</LI>
<LI><A HREF="#premature-script-headers">What does it mean when my
CGIs fail with "<SAMP>Premature end of script
headers</SAMP>"?</A>
</LI>
<LI><A HREF="#ssi-part-i">How do I enable SSI (parsed HTML)?</A>
</LI>
<LI><A HREF="#ssi-part-ii">Why don't my parsed files get cached?</A>
</LI>
<LI><A HREF="#ssi-part-iii">How can I have my script output parsed?</A>
</LI>
<LI><A HREF="#proxy">Does or will Apache act as a Proxy server?</A>
</LI>
<LI><A HREF="#multiviews">What are "multiviews"?</A>
</LI>
<LI><A HREF="#fdlim">Why can't I run more than <<EM>n</EM>>
virtual hosts?</A>
</LI>
<LI><A HREF="#limitGET">Why do I keep getting "access denied" for
form POST requests?</A>
</LI>
<LI><A HREF="#passwdauth">Can I use my <SAMP>/etc/passwd</SAMP> file
for Web page authentication?</A>
</LI>
<LI><A HREF="#errordoc401">Why doesn't my <CODE>ErrorDocument
401</CODE> work?</A>
</LI>
<LI><A HREF="#setgid">Why do I get "<SAMP>setgid: Invalid
argument</SAMP>" at startup?</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="#putsupport">Why can't I publish to my Apache server
using PUT on Netscape Gold and other programs?</A>
</LI>
<LI><A HREF="#fastcgi">Why isn't FastCGI included with Apache any
more?</A>
</LI>
<LI><A HREF="#nodelay">Why am I getting "<SAMP>httpd: could not
set socket option TCP_NODELAY</SAMP>" in my error log?</A>
</LI>
<LI><A HREF="#nph-scripts">How can I get my script's output without
Apache buffering it?</A>
</LI>
<LI><A HREF="#linuxiovec">Why do I get complaints about redefinition
of `struct iovec' when compiling under Linux?</A>
</LI>
<LI><A HREF="#wheres-the-dump">The errorlog says Apache dumped core,
but where's the dump file?</A>
</LI>
<LI><A HREF="#dnsauth">Why isn't restricting access by host or domain name
working correctly?</A>
</LI>
<LI><A HREF="#SSL-i">Why doesn't Apache include SSL?</A>
</LI>
<LI><A HREF="#HPUX-core">Why do I get core dumps under HPUX using
HP's ANSI C compiler?</A>
</LI>
</OL>
</LI>
</UL>
<HR>
<H2>The Answers</H2>
<P>
</P>
<H3>
Background
</H3>
<OL START=1>
<LI><A NAME="what">
<STRONG>What is Apache?</STRONG>
</A>
<P>
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.
</P>
<P>
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
<A
HREF="http://www.netcraft.com/Survey/"
>Netcraft Survey</A>.
</P>
<HR>
</LI>
<LI><A NAME="why">
<STRONG>Why was Apache created?</STRONG>
</A>
<P>
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.
<HR>
</P>
</LI>
<LI><A NAME="relate">
<STRONG>How does The Apache Group's work relate to other
server efforts, such as NCSA's?</STRONG>
</A>
<P>
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.
</P>
<HR>
</LI>
<LI><A NAME="name">
<STRONG>Why the name "Apache"?</STRONG>
</A>
<P>
A cute name which stuck. Apache is "<STRONG>A
PA</STRONG>t<STRONG>CH</STRONG>y server". It was
based on some existing code and a series of "patch files".
</P>
<HR>
</LI>
<LI><A NAME="compare">
<STRONG>OK, so how does Apache compare to other servers?</STRONG>
</A>
<P>
For an independent assessment, see
<A
HREF="http://webcompare.iworld.com/compare/chart.html"
>Web Compare</A>'s
comparison chart.
</P>
<P>
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.
</P>
<HR>
</LI>
<LI><A NAME="tested">
<STRONG>How thoroughly tested is Apache?</STRONG>
</A>
<P>
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.
</P>
<P>
The Apache project's web site includes a page with a partial list of
<A
HREF="http://www.apache.org/info/apache_users"
>sites running Apache</A>.
</P>
<HR>
</LI>
<LI><A NAME="future">
<STRONG>What are the future plans for Apache?</STRONG>
</A>
<P>
<UL>
<LI>to continue as a public domain HTTP server,
</LI>
<LI>to keep up with advances in HTTP protocol and web developments in
general,
</LI>
<LI>to collect suggestions for fixes/improvements from its users,
</LI>
<LI>to respond to needs of large volume providers as well as
occasional users.
</LI>
</UL>
</P>
<HR>
</LI>
<LI><A NAME="support">
<STRONG>Whom do I contact for support?</STRONG>
</A>
<P>
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 <EM>via</EM>
<A
HREF="http://www.apache.org/bug_report"
>the bug report page</A>.
Other questions should be directed to the
<A
HREF="news:comp.infosystems.www.servers.unix"
><SAMP>comp.infosystems.www.servers.unix</SAMP></A>
newsgroup, where some of the Apache team lurk,
in the company of many other httpd gurus who should be able
to help.
</P>
<P>
Commercial support for Apache is, however, available from a number
of third parties.
</P>
<HR>
</LI>
<LI><A NAME="more">
<STRONG>Is there any more information available on
Apache?</STRONG>
</A>
<P>
Indeed there is. See the main
<A
HREF="http://www.apache.org/"
>Apache web site</A>.
There is also a regular electronic publication called
<A
HREF="http://www.apacheweek.com/"
REL="Help"
><CITE>Apache Week</CITE></A>
available.
</P>
<HR>
</LI>
<LI><A NAME="where">
<STRONG>Where can I get Apache?</STRONG>
</A>
<P>
You can find out how to download the source for Apache at the
project's
<A
HREF="http://www.apache.org/"
>main web page</A>.
</P>
<HR>
</LI>
</OL>
<H3>
Technical Questions
</H3>
<OL START=11>
<LI><A NAME="what2do">
<STRONG>"Why can't I ...? Why won't ... work?" What to
do in case of problems</STRONG>
</A>
<P>
If you are having trouble with your Apache server software, you should
take the following steps:
</P>
<OL>
<LI><STRONG>Check the errorlog!</STRONG>
<P>
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
<CODE>/usr/local/etc/httpd/logs/error_log</CODE>, but see the
<A
HREF="../mod/core.html#errorlog"
><SAMP>ErrorLog</SAMP></A>
directive in your config files for the location on your server.
</P>
</LI>
<LI><STRONG>Check the
<A
HREF="http://www.apache.org/docs/misc/FAQ.html"
>FAQ</A>!</STRONG>
<P>
The latest version of the Apache Frequently-Asked Questions list can
always be found at the main Apache web site.
</P>
</LI>
<LI><STRONG>Check the Apache bug database</STRONG>
<P>
Most problems that get reported to The Apache Group are recorded in
the
<A
HREF="http://www.apache.org/bugdb.cgi"
>bug database</A>.
<EM><STRONG>Please</STRONG> check the existing reports, open
<STRONG>and</STRONG> closed, before adding one.</EM> If you find
that your issue has already been reported, please <EM>don't</EM> 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.
</P>
</LI>
<LI><STRONG>Ask in the <SAMP>comp.infosystems.www.servers.unix</SAMP>
USENET newsgroup</STRONG>
<P>
A lot of common problems never make it to the bug database because
there's already high Q&A traffic about them in the
<A
HREF="news:comp.infosystems.www.servers.unix"
><SAMP>comp.infosystems.www.servers.unix</SAMP></A>
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 <EM>don't</EM> see
your question already posted.
</P>
</LI>
<LI><STRONG>If all else fails, report the problem in the bug
database</STRONG>
<P>
If you've gone through those steps above that are appropriate and
have obtained no relief, then please <EM>do</EM> let The Apache
Group know about the problem by
<A
HREF="http://www.apache.org/bugdb.cgi"
>logging a bug report</A>.
</P>
<P>
If your problem involves the server crashing and generating a core
dump, please include a backtrace (if possible). As an example,
</P>
<P>
<CODE>
<DL>
<DD># cd <EM>ServerRoot</EM>
</DD>
<DD># dbx httpd core
</DD>
<DD>(dbx) where
</DD>
</DL>
</CODE>
</P>
<P>
(Substitute the appropriate locations for your
<SAMP>ServerRoot</SAMP> and your <SAMP>httpd</SAMP> and
<SAMP>core</SAMP> files. You may have to use <CODE>gdb</CODE>
instead of <CODE>dbx</CODE>.)
</P>
</LI>
</OL>
<HR>
</LI>
<LI><A NAME="compatible">
<STRONG>How compatible is Apache with my existing NCSA 1.3
setup?</STRONG>
</A>
<P>
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.
</P>
<P>
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.
</P>
<P>
Friendly interaction between Apache and NCSA developers should ensure
that fundamental feature enhancements stay consistent between the two
servers for the foreseeable future.
</P>
<HR>
</LI>
<LI><A NAME="CGIoutsideScriptAlias">
<STRONG>How do I enable CGI execution in directories other than
the ScriptAlias?</STRONG>
</A>
<P>
Apache recognizes all files in a directory named as a
<A
HREF="../mod/mod_alias.html#scriptalias"
><SAMP>ScriptAlias</SAMP></A>
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
"<SAMP>*.cgi</SAMP>" or "<SAMP>*.pl</SAMP>" or
whatever. In other words, <EM>all</EM> files in a ScriptAlias
directory are scripts, as far as Apache is concerned.
</P>
<P>
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
<A
HREF="../mod/mod_mime.html#addhandler"
><SAMP>AddHandler</SAMP></A>
directive.
</P>
<OL>
<LI>In an appropriate section of your server configuration files, add
a line such as
<P>
<DL>
<DD><CODE>AddHandler cgi-script .cgi</CODE>
</DD>
</DL>
</P>
The server will then recognize that all files in that location (and
its logical descendants) that end in "<SAMP>.cgi</SAMP>"
are script files, not documents.
</LI>
<LI>Make sure that the directory location is covered by an
<A
HREF="../mod/core.html#options"
><SAMP>Options</SAMP></A>
declaration that includes the <SAMP>ExecCGI</SAMP> option.
</LI>
</OL>
<HR>
</LI>
<LI><A NAME="premature-script-headers">
<STRONG>What does it mean when my CGIs fail with
"<SAMP>Premature end of script headers</SAMP>"?</STRONG>
</A>
<P>
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 <CODE>print</CODE> or <CODE>write</CODE> statement:
</P>
<P>
<CODE>
<DL>
<DD>$cfh = select (STDOUT);
</DD>
<DD>$| = 1;
</DD>
<DD>select ($cfh);
</DD>
</DL>
</CODE>
</P>
<P>
This is generally only necessary when you are calling external
programs from your script that send output to stdout.
<P>
If your script isn't written in Perl, do the equivalent thing for
whatever language you <EM>are</EM> using (<EM>e.g.</EM>, for C, call
<CODE>fflush()</CODE> after writing the headers).
</P>
<HR>
</LI>
<LI><A NAME="ssi-part-i">
<STRONG>How do I enable SSI (parsed HTML)?</STRONG>
</A>
<P>
SSI (an acronym for Server-Side Include) directives allow static HTML
documents to be enhanced at run-time (<EM>e.g.</EM>, when delivered to
a client by Apache). The format of SSI directives is covered
in the <A HREF="../mod/mod_include.html">mod_include manual</A>;
suffice it to say that Apache supports not only SSI but
xSSI (eXtended SSI) directives.
</P>
<P>
Processing a document at run-time is called <EM>parsing</EM> it; hence
the term "parsed HTML" sometimes used for documents that
contain SSI instructions. Parsing tends to be <EM>extremely</EM>
resource-consumptive, and is not enabled by default.
</P>
<P>
To enable SSI processing, you need to
</P>
<UL>
<LI>Build your server with the
<A
HREF="../mod/mod_include.html"
><SAMP>mod_include</SAMP></A>
module. This is normally compiled in by default.
</LI>
<LI>Make sure your server configuration files have an
<A
HREF="../mod/core.html#options"
><SAMP>Options</SAMP></A>
directive which permits <SAMP>Includes</SAMP>.
</LI>
<LI>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
<A
HREF="../mod/mod_mime.html#addhandler"
><SAMP>AddHandler</SAMP></A>
directive:
<P>
<DL>
<DD><CODE>AddHandler server-parsed .shtml</CODE>
</DD>
</DL>
</P>
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.
</LI>
</UL>
<HR>
</LI>
<LI><A NAME="ssi-part-ii">
<STRONG>Why don't my parsed files get cached?</STRONG>
</A>
<P>
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 <SAMP>Content-Length</SAMP> or
<SAMP>Last-Modified</SAMP> headers. Caches commonly work by comparing
the <SAMP>Last-Modified</SAMP> 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.
</P>
<P>
You can work around this in some cases by causing an
<SAMP>Expires</SAMP> header to be generated. (See the
<A
HREF="../mod/mod_expires.html"
REL="Help"
><SAMP>mod_expires</SAMP></A>
documentation for more details.) Another possibility is to use the
<A
HREF="../mod/mod_include.html#xbithack"
REL="Help"
><SAMP>XBitHack Full</SAMP></A>
mechanism, which tells Apache to send (under certain circumstances
detailed in the XBitHack directive description) a
<SAMP>Last-Modified</SAMP> 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.
</P>
<HR>
</LI>
<LI><A NAME="ssi-part-iii">
<STRONG>How can I have my script output parsed?</STRONG>
</A>
<P>
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.
</P>
<P>
This is a feature The Apache Group hopes to add in the next major
release after 1.2.
</P>
<HR>
</LI>
<LI><A NAME="proxy">
<STRONG>Does or will Apache act as a Proxy server?</STRONG>
</A>
<P>
Apache version 1.1 and above comes with a proxy module. If compiled
in, this will make Apache act as a caching-proxy server.
</P>
<HR>
</LI>
<LI><A NAME="multiviews">
<STRONG>What are "multiviews"?</STRONG>
</A>
<P>
"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
<A
HREF="../content-negotiation.html"
REL="Help"
>content negotiation</A>
description page.
</P>
<HR>
</LI>
<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/core.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/core.html#listen"
><SAMP>Listen</SAMP></A>
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.
</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.
</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.html"
>performance hints</A>
page.
</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/core.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>
<HR>
<LI><A NAME="limitGET">
<STRONG>Why do I keep getting "access denied" for form POST
requests?</STRONG>
</A>
<P>
The most common cause of this is a <SAMP><Limit></SAMP> section
that only names the <SAMP>GET</SAMP> method. Look in your
configuration files for something that resembles the following and
would affect the location where the POST-handling script resides:
</P>
<P>
<CODE>
<DL>
<DD><Limit GET>
</DD>
<DD> :
</DD>
</DL>
</CODE>
</P>
<P>
Change that to <SAMP><Limit GET POST></SAMP> and the problem
will probably go away.
</P>
<HR>
</LI>
<LI><A NAME="passwdauth">
<STRONG>Can I use my <SAMP>/etc/passwd</SAMP> file
for Web page authentication?</STRONG>
</A>
<P>
Yes, you can - but it's a <STRONG>very bad idea</STRONG>. Here are
some of the reasons:
</P>
<UL>
<LI>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
<SAMP>root</SAMP> 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 <EM>n</EM> failed passwords for the same
account within <EM>m</EM> seconds) and evasion (breaking the
connection, disabling the account under attack, disabling
<EM>all</EM> logins from that source, <EM>et cetera</EM>), but the
Web does not.
</LI>
<LI>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.
</LI>
<LI>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 - <EM>if</EM> you look at the logs.
</LI>
<LI>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!"
</LI>
<LI>Since HTTP is stateless, information about the authentication is
transmitted <EM>each and every time</EM> 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.
</LI>
<LI>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"?
</LI>
</UL>
<P>
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.
</P>
<HR>
<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 "/foo/bar" and not one
with a method and hostname such as "http://host/foo/bar". 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="setgid">
<STRONG>Why do I get "<SAMP>setgid: Invalid
argument</SAMP>" at startup?</STRONG>
</A>
<P>
Your
<A
HREF="../mod/core.html#group"
><SAMP>Group</SAMP></A>
directive (probably in <SAMP>conf/httpd.conf</SAMP>) needs to name a
group that actually exists in the <SAMP>/etc/group</SAMP> file (or
your system's equivalent).
</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> send automatically send a cookie on every
response, unless you have re-compiled it with the
<A
HREF="../mod/mod_cookies.html"
><SAMP>mod_cookies</SAMP></A>
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 <SAMP>mod_cookies</SAMP>, do
not compile it into Apache. Note that in 1.2 this module was renamed
to the more correct name
<A
HREF="../mod/mod_usertrack.html"
><SAMP>mod_usertrack</SAMP></A>,
and cookies
have to be specifically enabled with the
<A
HREF="../mod/mod_usertrack.html#cookietracking"
><SAMP>CookieTracking</SAMP></A>
directive.
</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, 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.
</P>
<P>
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:
</P>
<P>
<DL>
<DD><CODE>BrowserMatch HotJava/1.0 force-response-1.0</CODE>
</DD>
</DL>
</P>
<HR>
</LI>
<LI><A NAME="putsupport">
<STRONG>Why can't I publish to my Apache server using PUT on
Netscape Gold and other programs?</STRONG>
</A>
<P>
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 <CITE>Apache Week</CITE> article
<A
HREF="http://www.apacheweek.com/features/put"
><CITE>Publishing Pages with PUT</CITE></A>.
</P>
<HR>
</LI>
<LI><A NAME="fastcgi">
<STRONG>Why isn't FastCGI included with Apache any more?</STRONG>
</A>
<P>
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
<A
HREF="http://www.fastcgi.com/servers/apache/"
>FastCGI web site</A>. When a new version of Apache was released, the
version of the FastCGI module included with it would soon be out of date.
</P>
<P>
You can still obtain the FastCGI module for Apache from the master
FastCGI web site.
</P>
<HR>
</LI>
<LI><A NAME="fastcgi">
<STRONG>Why am I getting "<SAMP>httpd: could not set socket
option TCP_NODELAY</SAMP>" in my error log?</STRONG>
</A>
<P>
This message almost always indicates that the client disconnected
before Apache reached the point of calling <CODE>setsockopt()</CODE>
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.
</P>
<HR>
</LI>
<LI><A NAME="nph-scripts">
<STRONG>How can I get my script's output without Apache buffering
it?</STRONG>
</A>
<P>
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.
</P>
<P>
To avoid this, Apache recognizes scripts whose names begin with
"<SAMP>nph-</SAMP>" as <EM>non-parsed-header</EM> scripts.
That is, Apache won't buffer their output, but connect it directly to
the socket going back to the client.
</P>
<P>
While this will probably do what you want, there <EM>are</EM> some
disadvantages to it:
</P>
<UL>
<LI><STRONG>YOU</STRONG> (the script) are responsible for generating
<STRONG>ALL</STRONG> of the HTTP headers, and no longer
<EM>just</EM> the "<SAMP>Content-type</SAMP>" or
"<SAMP>Location</SAMP>" headers
</LI>
<LI>Unless your script generates its output carefully, you will see a
performance penalty as excessive numbers of packets go back and forth
</LI>
</UL>
<P>
As an example how you might handle the former (in a Perl script):
</P>
<CODE>
<DL>
<DD>if ($0 =~ m:/*nph-:) {
<BR>
$HTTP_headers =
"HTTP/1.1 200 OK\015\012";
<BR>
$HTTP_headers .=
"Connection: close\015\012";
<BR>
printf ($HTTP_headers);
<BR>
};
</DD>
</DL>
</CODE>
<P>
and then follow with your normal non-<SAMP>nph</SAMP> headers.
</P>
<HR>
</LI>
<LI><A NAME="linuxiovec">
<STRONG>Why do I get complaints about redefinition
of `struct iovec' when compiling under Linux?</STRONG>
</A>
<P>
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:
</P>
<UL>
<LI>Remove the definition of <CODE>struct iovec</CODE> from your C
library includes. It is located in <CODE>/usr/include/sys/uio.h</CODE>.
<STRONG>Or,</STRONG>
</LI>
<LI>Add <CODE>-DNO_WRITEV</CODE> to the <CODE>EXTRA_CFLAGS</CODE>
line in your <SAMP>Configuration</SAMP> and reconfigure/rebuild.
This hurts performance and should only be used as a last resort.
</LI>
</UL>
<HR>
</LI>
<LI><A NAME="wheres-the-dump">
<STRONG>The errorlog says Apache dumped core, but where's the dump
file?</STRONG>
</A>
<P>
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 <CODE>setuid()</CODE> 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.
</P>
<P>
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 <EM>is</EM> a documented way
of bypassing it, it is recommended that you bypass it only for the
<SAMP>httpd</SAMP> server process if possible.
</P>
<P>
The canonical location for Apache's core-dump files is the
<A
HREF="../mod/core.html#serverrot"
>ServerRoot</A>
directory.
</P>
<HR>
</LI>
<LI><A NAME="dnsauth">
<STRONG>Why isn't restricting access by host or domain name
working correctly?</STRONG>
</A>
<P>
Two of the most common causes of this are:
</P>
<OL>
<LI><STRONG>An error, inconsistency, or unexpected mapping in the DNS
registration</STRONG>
<BR>
This happens frequently: your configuration restricts access to
<SAMP>Host.FooBar.Com</SAMP>, but you can't get in from that host.
The usual reason for this is that <SAMP>Host.FooBar.Com</SAMP> is
actually an alias for another name, and when Apache performs the
address-to-name lookup it's getting the <EM>real</EM> name, not
<SAMP>Host.FooBar.Com</SAMP>. 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.
</LI>
<LI><STRONG>Inadequate checking and verification in your
configuration of Apache</STRONG>
<BR>
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 <SAMP>-DMAXIMUM_DNS</SAMP> clause to the
<SAMP>EXTRA_CFLAGS</SAMP> definition in your
<SAMP>Configuration</SAMP> file. For example:
<DL>
<DD><CODE>EXTRA_CFLAGS=-DMAXIMUM_DNS</CODE>
</DD>
</DL>
<P>
This will cause Apache to be very paranoid about making sure a
particular host address is <EM>really</EM> assigned to the name it
claims to be. Note that this <EM>can</EM> incur a significant
performance penalty, however, because of all the name resolution
requests being sent to a nameserver.
</P>
</LI>
</OL>
<HR>
</LI>
<LI><A NAME="SSL-i">
<STRONG>Why doesn't Apache include SSL?</STRONG>
</A>
<P>
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 <A HREF="http://www.rsa.com/">RSA Data Security</A>,
who restricts its use without a license.
</P>
<P>
Some SSL implementations of Apache are available, however; see the
"<A
HREF="http://www.apache.org/related_projects"
>related projects</A>"
page at the main Apache web site.
</P>
<HR>
</LI>
<LI><A NAME="HPUX-core">
<STRONG>Why do I get core dumps under HPUX using HP's ANSI
C compiler?</STRONG>
</A>
<P>
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.
</P>
<HR>
<!-- Don't forget to add HR tags at the end of each list item.. -->
</LI>
</OL>
<!--#include virtual="footer.html" -->
</BODY>
</HTML>
|
