1. 14 Feb, 1998 1 commit
  2. 12 Feb, 1998 1 commit
  3. 11 Feb, 1998 2 commits
  4. 07 Feb, 1998 3 commits
  5. 05 Feb, 1998 6 commits
  6. 04 Feb, 1998 1 commit
  7. 03 Feb, 1998 1 commit
  8. 01 Feb, 1998 1 commit
  9. 30 Jan, 1998 1 commit
  10. 28 Jan, 1998 1 commit
  11. 26 Jan, 1998 8 commits
    • lookit's avatar
      Server-generated pages can be server-signed now (new directive) · 195d88e2
      lookit authored
      
      git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80023 13f79535-47bb-0310-9956-ffa450edef68
      195d88e2
    • Ken Coar's avatar
      A truly mighty mod normalising HTML tags to uppercase, and · 77d6039c
      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
      77d6039c
    • brian's avatar
      PR: · eaeb52c6
      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
      eaeb52c6
    • brian's avatar
      PR: · 52374e06
      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
      52374e06
    • brian's avatar
      PR: · f9b19ae6
      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
      f9b19ae6
    • brian's avatar
      PR: · b6ba7d5b
      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
      b6ba7d5b
    • brian's avatar
      PR: · 121bd13d
      brian authored
      Make all references complete.
      
      
      git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80006 13f79535-47bb-0310-9956-ffa450edef68
      121bd13d
    • brian's avatar
      PR: · 16ac5365
      brian authored
      
      git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80004 13f79535-47bb-0310-9956-ffa450edef68
      16ac5365
  12. 25 Jan, 1998 1 commit
    • dgaudet's avatar
      - no need to use stat() since r->finfo is already what we need · 66db3449
      dgaudet authored
      - no need to play with atime/mtime crud, the web server doesn't preserve
          that info normally anyhow
      - deal with r->finfo.st_mode == 0 || !r->filename (i.e. not a disk file)
      - don't reference mime_module.type_checker, this should be controlled by
          the ordering within Configuration
      - work properly with multiple vhosts
      - doc update: even prior to this patch, the code was disabled if there
          was no MimeMagicFile directive.
      
      
      git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@79997 13f79535-47bb-0310-9956-ffa450edef68
      66db3449
  13. 23 Jan, 1998 2 commits
  14. 22 Jan, 1998 4 commits
  15. 20 Jan, 1998 1 commit
    • brian's avatar
      PR: · 725d30f3
      brian authored
      First stab at updating.  Other windows developers need to make sure this
      still makes sense!  Notably, does the line break problem mean that the .tar.gz
      distribution can't be compiled on NT?
      
      
      git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@79923 13f79535-47bb-0310-9956-ffa450edef68
      725d30f3
  16. 07 Jan, 1998 1 commit
  17. 29 Dec, 1997 1 commit
  18. 22 Dec, 1997 1 commit
    • Marc Slemko's avatar
      Misc cleanups: · 4b319f37
      Marc Slemko authored
      	- cleanup HTML, <e> --> <em>
      	- remove bogus security warning about LockFile
      	- add warning about possible denial of service attack with
      	  LockFile in world writable directory
      	- remove security encouragement to use inetd; add warning that
      	  inetd isn't well supported.
      
      PR:
      Obtained from:
      Submitted by:
      Reviewed by:
      
      
      git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@79758 13f79535-47bb-0310-9956-ffa450edef68
      4b319f37
  19. 21 Dec, 1997 1 commit
  20. 20 Dec, 1997 1 commit
    • dgaudet's avatar
      Lars says: · bcd48d69
      dgaudet authored
      some people are confused if they see the different naming conventions
      for language negotiated documents (e.g. foo.html.en vs. foo.en.html)
      and how a hyperlink to such a document should look like.
      There's a PR about it (#1559) and I've seen several questions on
      usenet about it.
      
      I tried to clarify this issue in an extra paragraph in the
      content-negotiation.html document (see attachment).
      
      PR:		1559
      Submitted by:	Lars Eilebrecht
      Reviewed by:	Dean Gaudet
      
      
      git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@79735 13f79535-47bb-0310-9956-ffa450edef68
      bcd48d69
  21. 18 Dec, 1997 1 commit