Removed because an unmaintained list of known bugs is worse than useless.
We have all this in the bug database, it's maintained there, and providing
historical known_bug issues is counterproductive.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@81253 13f79535-47bb-0310-9956-ffa450edef68
Slightly improve the grammar; however, in my opinion this whole chunk can just
be tossed out of the FAQ. I can't believe we're actually asked "how can I make
only one file executable?".
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@81131 13f79535-47bb-0310-9956-ffa450edef68
entry is extremely misleading, and answering a Q that isn't really FA,
and I see someone posting somewhere every week who tries this to
fix their "method not allowed" problems.
PR:
Obtained from:
Submitted by:
Reviewed by:
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80861 13f79535-47bb-0310-9956-ffa450edef68
to custom-tailor the apache ErrorDocuments to taste, adding the
advantage of returning internationalized versions of the error
messages depending on the client's language preferences.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80119 13f79535-47bb-0310-9956-ffa450edef68
'i' and 'b' to 'EM' and 'STRONG' respectively. Been threatening
to do this for months.. no-one need try to maintain this when
writing/modifiying the docs.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80021 13f79535-47bb-0310-9956-ffa450edef68
David Robinson's CGI specification is no longer available at this URL. perhaps
we should point at other CGI resources online?
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80013 13f79535-47bb-0310-9956-ffa450edef68
If SCO's going to break their links, I'm not going to go searching for where they
moved it to.
Cold and rainy and dark.
ml" -->
<H1 ALIGN="CENTER">Connections in the FIN_WAIT_2 state and Apache</H1>
<OL>
<LI><H2>What is the FIN_WAIT_2 state?</H2>
Starting with the Apache 1.2 betas, people are reporting many more
connections in the FIN_WAIT_2 state (as reported by
<code>netstat</code>) than they saw using older versions. When the
server closes a TCP connection, it sends a packet with the FIN bit
sent to the client, which then responds with a packet with the ACK bit
set. The client then sends a packet with the FIN bit set to the
server, which responds with an ACK and the connection is closed. The
state that the connection is in during the period between when the
server gets the ACK from the client and the server gets the FIN from
the client is known as FIN_WAIT_2. See the <A
HREF="ftp://ds.internic.net/rfc/rfc793.txt">TCP RFC</A> for the
technical details of the state transitions.<P>
The FIN_WAIT_2 state is somewhat unusual in that there is no timeout
defined in the standard for it. This means that on many operating
systems, a connection in the FIN_WAIT_2 state will stay around until
the system is rebooted. If the system does not have a timeout and
too many FIN_WAIT_2 connections build up, it can fill up the space
allocated for storing information about the connections and crash
the kernel. The connections in FIN_WAIT_2 do not tie up an httpd
process.<P>
<LI><H2>But why does it happen?</H2>
There are numerous reasons for it happening, some of them may not
yet be fully clear. What is known follows.<P>
<H3>Buggy clients and persistent connections</H3>
Several clients have a bug which pops up when dealing with
<A HREF="../keepalive.html">persistent connections</A> (aka keepalives).
When the connection is idle and the server closes the connection
(based on the <A HREF="../mod/core.html#keepalivetimeout">
KeepAliveTimeout</A>), the client is programmed so that the client does
not send back a FIN and ACK to the server. This means that the
connection stays in the FIN_WAIT_2 state until one of the following
happens:<P>
<UL>
<LI>The client opens a new connection to the same or a different
site, which causes it to fully close the older connection on
that socket.
<LI>The user exits the client, which on some (most?) clients
causes the OS to fully shutdown the connection.
<LI>The FIN_WAIT_2 times out, on servers that have a timeout
for this state.
</UL><P>
If you are lucky, this means that the buggy client will fully close the
connection and release the resources on your server. However, there
are some cases where the socket is never fully closed, such as a dialup
client disconnecting from their provider before closing the client.
In addition, a client might sit idle for days without making another
connection, and thus may hold its end of the socket open for days
even though it has no further use for it.
<STRONG>This is a bug in the browser or in its operating system's
TCP implementation.</STRONG> <P>
The clients on which this problem has been verified to exist:<P>
<UL>
<LI>Mozilla/3.01 (X11; I; FreeBSD 2.1.5-RELEASE i386)
<LI>Mozilla/2.02 (X11; I; FreeBSD 2.1.5-RELEASE i386)
<LI>Mozilla/3.01Gold (X11; I; SunOS 5.5 sun4m)
<LI>MSIE 3.01 on the Macintosh
<LI>MSIE 3.01 on Windows 95
</UL><P>
This does not appear to be a problem on:
<UL>
<LI>Mozilla/3.01 (Win95; I)
</UL>
<P>
It is expected that many other clients have the same problem. What a
client <STRONG>should do</STRONG> is periodically check its open
socket(s) to see if they have been closed by the server, and close their
side of the connection if the server has closed. This check need /export/home/cvs/CVSROOT/cvsedit
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80009 13f79535-47bb-0310-9956-ffa450edef68
Obtained from:
Submitted by: Jim Jagielski
Reviewed by:
Best of both worlds... Let the world know if we have mmap and/or
shmget as well as controlling which to use for scoreboard. This
should be a complete patch, so if any docs were skipped, feel free
to update 'em
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@79969 13f79535-47bb-0310-9956-ffa450edef68
Do make the code a bit clearer, some minor #define changes (and
the resultant flow-thru in the docs).
SAFE_UNSERIALIZED_ACCEPT -> SINGLE_LISTEN_UNSERIALIZED_ACCEPT
HAVE_MMAP -> USE_MMAP_SCOREBOARD
HAVE_SHMGET -> USE_SHMGET_SCOREBOARD
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@79959 13f79535-47bb-0310-9956-ffa450edef68
the software area now really gets removed, but at least the
solutions survive in my paperwork area where they make up a
new document.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@79707 13f79535-47bb-0310-9956-ffa450edef68
how to set the perms on the serverroot. But I don't think we document it
anywhere. Nowhere that's easily found direct from the "how to install"
page. Document it better, link to it. Remove the install_1_1 docs.
Update a 1.2 reference to 1.3.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@79686 13f79535-47bb-0310-9956-ffa450edef68
Hi,
the attachment includes a reworked Apache manual with the
new virtual host documentation.
As Dean suggested I created a new directory named 'vhosts' and moved the
updated vhosts-in-depth etc. documents into the new directory, renamed
them and updated all other documents which refered to the old docs
(at least I tried to find all documents...).
Submitted by: Lars Eilebrecht <sfx@unix-ag.org>
Reviewed by: Martin Kraemer
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@79568 13f79535-47bb-0310-9956-ffa450edef68
Hopefully (!) this will ease some of the confusion about 1.3
features described therein that people think apply to 1.2..
Reviewed by: Dean Gaudet
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@79503 13f79535-47bb-0310-9956-ffa450edef68
