- Mar 03, 1998
-
-
dgaudet authored
wasting resources trying to solve what may end up being bugs in solaris. PR: 1779, 1854, 1904 git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80364 13f79535-47bb-0310-9956-ffa450edef68
-
- Feb 28, 1998
-
-
Ralf S. Engelschall authored
adapted patch against 1.3 of Todd Eigenschink <eigenstr@mixi.net>'s original patch for 1.2.5. For 1.2.5 we don't want it because its a feature. I also added corresponding entries to the CHANGES and mod_log_config.html file. Submitted by: Todd Eigenschink <eigenstr@mixi.net> Reviewed by: Ralf S. Engelschall git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80340 13f79535-47bb-0310-9956-ffa450edef68
-
- Feb 26, 1998
-
-
dgaudet authored
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80322 13f79535-47bb-0310-9956-ffa450edef68
-
- Feb 25, 1998
-
-
Ralf S. Engelschall authored
constructs, thus no one noticed that it can be used to lookup the REMOTE_USER variable (one of the mod_rewrite FAQs) even in per-server context. One just has to use %{LA-U:REMOTE_USER} instead of %{REMOTE_USER} there. Notice that %{REMOTE_USER} is also useful, but only for per-dir context. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80320 13f79535-47bb-0310-9956-ffa450edef68
-
- Feb 24, 1998
-
-
Ralf S. Engelschall authored
Unix derivates who doesn't accept the locking of pipes directly. But we perhaps have another problem: According to FreeBSD's manpage and a hint by the submitter of PR#1029 flock() has to be used on opened filedescriptors which are _not_ duplicated via fork(). This currently is not the case... Submitted by: Ralf S. Engelschall Reviewed by: Ralf S. Engelschall, Jim Jagielski git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80311 13f79535-47bb-0310-9956-ffa450edef68
-
- Feb 23, 1998
-
-
Ralf S. Engelschall authored
be used as a Reverse Proxy (where the backend servers are choosen via a `rnd' map) and to allow mass virtual hosting without <VirtualHost> sections (where you have to fix the case of server names when translating the Host-Header to a directory structure). Together with the comitted ProxyPassReverse directive we now have solved two things the users have asked in the past: 1. The ability to use Apache as a full-featured Reverse Proxy 2. The ability to do mass virtual hosting without <VirtualHost> sections. For both topics we should write stand-alone documents (perhaps inside htdocs/manual/misc/) because they are not trivial to do, even when we now have the functionality ;-) Submitted by: Ralf S. Engelschall Reviewed by: Dean Gaudet, Ralf S. Engelschall git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80298 13f79535-47bb-0310-9956-ffa450edef68
-
Ralf S. Engelschall authored
used as a full-featured Reverse Proxy in front of a backend webserver cluster. Submitted by: Ralf S. Engelschall Reviewed by: Martin Kraemer, Ralf S. Engelschall git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80296 13f79535-47bb-0310-9956-ffa450edef68
-
- Feb 20, 1998
-
-
dgaudet authored
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80251 13f79535-47bb-0310-9956-ffa450edef68
-
dgaudet authored
fix slight semantic error git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80249 13f79535-47bb-0310-9956-ffa450edef68
-
- Feb 18, 1998
-
-
dgaudet authored
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80244 13f79535-47bb-0310-9956-ffa450edef68
-
dgaudet authored
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80240 13f79535-47bb-0310-9956-ffa450edef68
-
dgaudet authored
error messages generated. Introduced cmd->end_token to make it easier to do nested sections with proper error reporting. (Note that it can't be used for <IfModule> or <Limit> unfortunately.) PR#379: <Files> is not allowed within <Location> because it has no effect. PR#1817: Change <Files> to work with basenames only. This fixes both the bug introduced by the wildcarding change (* doesn't match /) and bugs such as <Files a*b> not working. PR: 379, 1817 git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80233 13f79535-47bb-0310-9956-ffa450edef68
-
- Feb 15, 1998
-
-
dgaudet authored
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80220 13f79535-47bb-0310-9956-ffa450edef68
-
- Feb 14, 1998
-
-
dgaudet authored
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80213 13f79535-47bb-0310-9956-ffa450edef68
-
dgaudet authored
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80211 13f79535-47bb-0310-9956-ffa450edef68
-
- Feb 12, 1998
-
-
dgaudet authored
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80193 13f79535-47bb-0310-9956-ffa450edef68
-
- Feb 11, 1998
-
-
Ken Coar authored
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80190 13f79535-47bb-0310-9956-ffa450edef68
-
Ken Coar authored
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80188 13f79535-47bb-0310-9956-ffa450edef68
-
- Feb 07, 1998
-
-
dgaudet authored
page. Submitted by: Lars Eilebrecht Reviewed by: Dean Gaudet git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80155 13f79535-47bb-0310-9956-ffa450edef68
-
brian authored
lost connection no longer a "warn" error, so needed a new one. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80145 13f79535-47bb-0310-9956-ffa450edef68
-
brian authored
Playing whack-a-mole; first stab at docs for LogLevel. Could someone confirm? git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80141 13f79535-47bb-0310-9956-ffa450edef68
-
- Feb 05, 1998
-
-
Ken Coar authored
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80134 13f79535-47bb-0310-9956-ffa450edef68
-
Ken Coar authored
It has been said, and verily it is true, that weblint rocks. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80132 13f79535-47bb-0310-9956-ffa450edef68
-
Ken Coar authored
corrections coming up. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80130 13f79535-47bb-0310-9956-ffa450edef68
-
Ken Coar authored
Submitted by: Brian K Smith <briank.smith@computer.org> git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80128 13f79535-47bb-0310-9956-ffa450edef68
-
Martin Kraemer authored
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80121 13f79535-47bb-0310-9956-ffa450edef68
-
Martin Kraemer authored
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
-
- Feb 04, 1998
-
-
dgaudet authored
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80114 13f79535-47bb-0310-9956-ffa450edef68
-
- Feb 03, 1998
-
-
pcs authored
still pretty minimal. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80100 13f79535-47bb-0310-9956-ffa450edef68
-
- Feb 01, 1998
-
-
dgaudet authored
redirects are generated. This was at least approved in spirit by a handful of folks two weeks ago. The default should be no behaviour change. This changes the prototype of construct_url(), and adds two new API functions: get_server_name() and get_server_port(). So the MODULE_MAGIC_NUMBER has been bumped. PR: 315, 459, 485, 1433 Submitted by: Michael Douglass <mikedoug@texas.net>, Dean Gaudet git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80076 13f79535-47bb-0310-9956-ffa450edef68
-
- Jan 30, 1998
-
-
lookit authored
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80051 13f79535-47bb-0310-9956-ffa450edef68
-
- Jan 28, 1998
-
-
Ken Coar authored
are now links back to a description of what the attributes mean. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80041 13f79535-47bb-0310-9956-ffa450edef68
-
- Jan 26, 1998
-
-
lookit authored
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80023 13f79535-47bb-0310-9956-ffa450edef68
-
Ken Coar authored
'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
-
brian authored
tsk tsk, randy. Can't find this on covalent.net either. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80015 13f79535-47bb-0310-9956-ffa450edef68
-
brian authored
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
-
brian authored
If SGI is going to break their links, I'm not about to go ferreting around their site looking for where they moved it to. Since the other entry is generic for all OS's (or at least doesn't clearly state HOW it's related), I've removed the SGI entry. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80011 13f79535-47bb-0310-9956-ffa450edef68
-
brian authored
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
-
brian authored
Make all references complete. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80006 13f79535-47bb-0310-9956-ffa450edef68
-
brian authored
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80004 13f79535-47bb-0310-9956-ffa450edef68
-