Mailing List Archive: cvs commit: apache/htdocs/manual/misc FAQ.html

coar 97/04/22 03:26:41

Modified: htdocs/manual/misc FAQ.html
Log:
Added note about JDK 1.1.1 being broken, too. Changed TABs to
spaces. Some CODE versus SAMP cleanup. Some format cleanup.
Some mispaced tag cleanup. Exactly 1024 lines; seems like a
good time to commit. ;-> More cleanup to follow..

Revision Changes Path
1.38 +98 -83 apache/htdocs/manual/misc/FAQ.html

Index: FAQ.html
===================================================================
RCS file: /export/home/cvs/apache/htdocs/manual/misc/FAQ.html,v
retrieving revision 1.37
retrieving revision 1.38
diff -C3 -r1.37 -r1.38
*** FAQ.html 1997/04/22 03:01:25 1.37
--- FAQ.html 1997/04/22 10:26:39 1.38
***************
*** 8,14 ****

<H1>Apache Server Frequently Asked Questions</H1>

! $Revision: 1.37 $ ($Date: 1997/04/22 03:01:25 $)


If you are reading a text-only version of this FAQ, you may find numbers
--- 8,14 ----

<H1>Apache Server Frequently Asked Questions</H1>

! $Revision: 1.38 $ ($Date: 1997/04/22 10:26:39 $)


If you are reading a text-only version of this FAQ, you may find numbers
***************
*** 17,43 ****
do not appear, and are not needed, for the hypertext version.

<H2>The Questions</H2>
! 
! 
! 
! 

! 

! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
<UL>
<LI>Background
<OL START=1>
--- 17,43 ----
do not appear, and are not needed, for the hypertext version.

<H2>The Questions</H2>
! 
! 
! 
! 

! 

! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
! 
<UL>
<LI>Background
<OL START=1>
***************
*** 76,82 ****
in directories other than the ScriptAlias?</A>
</LI>
<LI><A HREF="#premature-script-headers">What does it mean when my
! CGIs fail with "Premature end of script headers"?</A>
</LI>
<LI><A HREF="#ssi-part-i">How do I enable SSI (parsed HTML)?</A>
</LI>
--- 76,83 ----
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>
***************
*** 97,107 ****
<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 <SAMP>ErrorDocument
! 401</SAMP> work?</A>
</LI>
! <LI><A HREF="#setgid">Why do I get "setgid: Invalid
! argument" at startup?</A>
</LI>
<LI><A HREF="#cookies1">Why does Apache send a cookie on every response?</A>
</LI>
--- 98,108 ----
<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>
***************
*** 123,130 ****
<LI><A HREF="#nph-scripts">How can I get my script's output without
Apache buffering it?</A>
</LI>
! <LI><A HREF="#linuxiovec">When compiling under Linux it complains
! about redefinition of `struct iovec'.</A>
</LI>
</OL>
</LI>
--- 124,131 ----
<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>
</OL>
</LI>
***************
*** 139,147 ****
Background
</H3>
<OL START=1>
! <LI><A
! NAME="what"
! >What is Apache?</A>

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
--- 140,148 ----
Background
</H3>
<OL START=1>
! <LI><A NAME="what">
! What is Apache?
! </A>

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
***************
*** 331,336 ****
--- 332,346 ----
fix the problem yourself (such as file permissions or the like).

</LI>
+ <LI>Check the
+ <A
+ HREF="http://www.apache.org/docs/misc/FAQ"
+ >FAQ</A>!
+ 
+ The latest version of the Apache Frequently-Asked Questions list can
+ always be found at the main Apache web site.
+ 
+ </LI>
<LI>Check the Apache bug database

Most problems that get reported to The Apache Group are recorded in
***************
*** 392,399 ****

(Substitute the appropiate locations for your
<SAMP>ServerRoot</SAMP> and your <SAMP>httpd</SAMP> and
! <SAMP>core</SAMP> files. You may have to use <SAMP>gdb</SAMP>
! instead of <SAMP>dbx</SAMP>.)

</LI>
</OL>
--- 402,409 ----

(Substitute the appropiate 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>.)

</LI>
</OL>
***************
*** 471,488 ****
</OL>
<HR>
</LI>
! <LI><A
! NAME="premature-script-headers"
! >What does it mean when my CGIs fail with "Premature
! end of script headers"?</A>
! 
! 

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 is Perl scripts which haven't
disabled buffering; if you insert the following statements before your
! first <SAMP>print</SAMP> statement, this will probably go away.


<CODE>
--- 481,496 ----
</OL>
<HR>
</LI>
! <LI><A NAME="premature-script-headers">
! What does it mean when my CGIs fail with
! "<SAMP>Premature end of script headers</SAMP>"?
! </A>

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 is Perl scripts which haven't
disabled buffering; if you insert the following statements before your
! first <CODE>print</CODE> statement, this will probably go away.


<CODE>
***************
*** 499,505 ****

If your script isn't written in Perl, do the equivalent thing for
whatever language you are using (e.g., for C, call
! <SAMP>fflush()</SAMP> after writing the headers).

<HR>
</LI>
--- 507,513 ----

If your script isn't written in Perl, do the equivalent thing for
whatever language you are using (e.g., for C, call
! <CODE>fflush()</CODE> after writing the headers).

<HR>
</LI>
***************
*** 526,532 ****
<LI>Build your server with the
<A
HREF="../mod/mod_include.html"
! ><CODE>mod_include</CODE></A>
module. This is normally compiled in by default.
</LI>
<LI>Make sure your server configuration files have an
--- 534,540 ----
<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
***************
*** 565,573 ****
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 <CODE>Content-Length</CODE> or
! <CODE>Last-Modified</CODE> headers. Caches commonly work by comparing
! the <CODE>Last-Modified</CODE> 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
--- 573,581 ----
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
***************
*** 575,585 ****


You can work around this in some cases by causing an
! <CODE>Expires</CODE> header to be generated. (See the
<A
HREF="../mod/mod_expires.html"
REL="Help"
! ><CODE>mod_expires</CODE></A>
documentation for more details.) Another possibility is to use the
<A
HREF="../mod/mod_include.html#xbithack"
--- 583,593 ----


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"
***************
*** 641,647 ****
on file descriptors, and that's almost always the
cause of problems seen when adding virtual hosts. In this
case, it is often not actually Apache that's encountering the problem, but
! some library routine (such as <SAMP>gethostbyname()</SAMP>)
which needs file descriptors and doesn't complain intelligibly when it
can't get them.

--- 649,655 ----
on file descriptors, and that's almost always the
cause of problems seen when adding virtual hosts. In this
case, it is often not actually Apache that's encountering the problem, but
! some library routine (such as <CODE>gethostbyname()</CODE>)
which needs file descriptors and doesn't complain intelligibly when it
can't get them.

***************
*** 678,690 ****
<LI>Reduce the number of log files. You can use
<A
HREF="../mod/mod_log_config.html"
! ><CODE>mod_log_config</CODE></A>
to log all requests to a single log file while including the name
of the virtual host in the log file.
</LI>
<LI>Increase the number of file descriptors available to the server
! (see your system's documentation on the <SAMP>limit</SAMP> or
! <SAMP>ulimit</SAMP> commands). For some systems, information on
how to do this is available in the
<A
HREF="perf.html"
--- 686,698 ----
<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.
</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"
***************
*** 785,791 ****

<HR>
<LI><A NAME="errordoc401">
! Why doesn't my <SAMP>ErrorDocument 401</SAMP> work?
</A>

You need to use it with a URL in the form "/foo/bar" and not one
--- 793,799 ----

<HR>
<LI><A NAME="errordoc401">
! Why doesn't my <CODE>ErrorDocument 401</CODE> work?
</A>

You need to use it with a URL in the form "/foo/bar" and not one
***************
*** 798,805 ****
<HR>
</LI>
<LI><A NAME="setgid">
! Why do I get "setgid: Invalid argument" at
! startup?
</A>

Your
--- 806,813 ----
<HR>
</LI>
<LI><A NAME="setgid">
! Why do I get "<SAMP>setgid: Invalid
! argument</SAMP>" at startup?
</A>

Your
***************
*** 812,826 ****

<HR>
</LI>
- </LI>
<LI><A NAME="cookies1">
! Why does Apache send a cookie on every response?</A>

Apache does not send automatically send a cookie on every
response, unless you have re-compiled it with the
<A
HREF="../mod/mod_cookies.html"
! ><CODE>mod_cookies</CODE></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
--- 820,834 ----

<HR>
</LI>
<LI><A NAME="cookies1">
! Why does Apache send a cookie on every response?
! </A>

Apache does not 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
***************
*** 829,835 ****
more correct name
<A
HREF="../mod/mod_usertrack.html"
! ><CODE>mod_usertrack</CODE></A>,
and cookies
have to be specifically enabled with the
<A
--- 837,843 ----
more correct name
<A
HREF="../mod/mod_usertrack.html"
! ><SAMP>mod_usertrack</SAMP></A>,
and cookies
have to be specifically enabled with the
<A
***************
*** 861,874 ****
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 Java Development Kit (JDK)
! version 1.0.2 URL methods (URLConnection and friends) 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
--- 869,882 ----
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
***************
*** 969,1009 ****
<DL>
<DD>if ($0 =~ m:/*nph-:) {
 
!     
! $HTTP_headers = 
! "HTTP/1.1 200 OK\015\012";
 
!     
! $HTTP_headers .= 
! "Connection: close\015\012";
 
!     
! printf ($HTTP_headers);
! 
! };
</DD>
</DL>
</CODE>

and then follow with your normal non-<SAMP>nph</SAMP> headers.

</LI>
- <HR>
<LI><A NAME="linuxiovec">
! When compiling under Linux it complains about redefinition
! of `struct iovec'.
</A>

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. One is to remove the definition
! of struct iovec from your C library includes. Another is to add
! <code>-DNO_WRITEV</code> to the <code>EXTRA_CFLAGS</code> line in
! your <code>Configuration</code> and reconfigure/rebuild.

</LI>
</OL>
- <HR>

</BODY>
</HTML>
--- 977,1024 ----
<DL>
<DD>if ($0 =~ m:/*nph-:) {
 
!     
! $HTTP_headers = 
! "HTTP/1.1 200 OK\015\012";
! 
!     
! $HTTP_headers .= 
! "Connection: close\015\012";
 
!     
! printf ($HTTP_headers);
 
! };
</DD>
</DL>
</CODE>

and then follow with your normal non-<SAMP>nph</SAMP> headers.

+ <HR>
</LI>
<LI><A NAME="linuxiovec">
! Why do I get complaints about redefinition
! of `struct iovec' when compiling under Linux?
</A>

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:
! 
! <UL>
! <LI>Remove the definition of <CODE>struct iovec</CODE> from your C
! library includes. Or,
! </LI>
! <LI>Add <CODE>-DNO_WRITEV</CODE> to the <CODE>EXTRA_CFLAGS</CODE>
! line in your <SAMP>Configuration</SAMP> and reconfigure/rebuild.
! </LI>
! </UL>

+ <HR>
+ 
</LI>
</OL>

</BODY>
</HTML>