Commit 14c89290 authored by brian's avatar brian
Browse files

Realized "misc" was better than "info" to describe this subdir. Yeah, I know, 

I apologize.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@77008 13f79535-47bb-0310-9956-ffa450edef68
parent 62401eea

docs/manual/developer/API.html

0 → 100644
+988 −0

File added.

Preview size limit exceeded, changes collapsed.

docs/manual/misc/API.html

0 → 100644
+988 −0

File added.

Preview size limit exceeded, changes collapsed.

docs/manual/misc/FAQ.html

0 → 100644
+162 −0
Original line number Diff line number Diff line 
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

<HTML>

<HEAD>

<TITLE>Apache server Frequently Asked Questions</TITLE>

</HEAD>



<BODY>

<IMG SRC="../images/apache_sub.gif" ALT="">

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



<H2>The Questions</H2>

<OL>

<LI><A HREF="#what">What is Apache ?</A>

<LI><A HREF="#why">Why was Apache created ?</A>

<LI><A HREF="#relate">How does the Apache group relate to other servers ?</A>

<LI><A HREF="#name">Why the name "Apache" ?</A>

<LI><A HREF="#compatible">How compatible is Apache with my existing NCSA 1.3 setup ?</A>

<LI><A HREF="#compare">OK, so how does Apache compare to other servers ?</A>

<LI><A HREF="#tested">How thoroughly tested is Apache?</A>

<LI><A HREF="#proxy">Does or will Apache act as a Proxy server?</A>

<LI><A HREF="#future">What are the future plans for Apache ?</A>

<LI><A HREF="#support">Who do I contact for support ?</A>

<LI><A HREF="#more">Is there any more information on Apache ?</A>

<LI><A HREF="#where">Where can get Apache ?</A>

</OL>



<HR>



<H2>The Answers</H2>

<OL>

<LI><A name="what">What is Apache ?</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>Since it began, it has been completely rewritten, and includes many new

features. Apache is, as of June 1996, the most popular WWW server on

the Internet, according to the <a

href="http://www.netcraft.com/Survey/">Netcraft Survey</a>.



</P>

<HR>

<LI><A name="relate">How does the Apache group relate to other

server efforts, such as NCSA's?</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

entitely independent venture.

</P>

<HR>



<LI><A name="why">Why was Apache created ?</A>

<P>to address concerns of a group of www providers and part time httpd

programmers, that httpd didn't behave as they wanted it

to. Apache is an entirely volunteer effort, completely funded by its

members, not by commercial sales.

</P>



<HR>



<LI><A name="name">Why the name "Apache" ?</A>

<P>A cute name which stuck. Apache is "<B>A PA</B>t<B>CH</B>y server". It was

    based on some existing code and a series of "patch files".

</P>

<HR>





<LI><A name="compatible">How compatible is Apache with my existing NCSA 1.3

setup ?</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>



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>



Friendly interaction between Apache and NCSA developers should ensure

that fundamental feature enhancments stay consistent between the two

servers for the foreseeable future.<p>



<HR>



<LI><A name="compare">OK, so how does Apache compare to other servers ?</A>

<P>

For an independent assessment, see <A HREF="http://www.webcompare.com/server-main.html">http://www.webcompare.com/server-main.html</A>

</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><A name="tested">How thoroughly tested is Apache?</A>



<p>Apache is run on over 100,000 Internet servers (as of July 1996). 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. When bugs do show up, we release patches and new

versions, as soon as they are available.</a>



<P>See <A HREF="../info/apache_users.html">http://www.apache.org/info/apache_users.html</A> for an incomplete list of sites running Apache.</P>



<hr>



<LI><A name="proxy">Does or will Apache act as a Proxy server?

<p>Apache version 1.1

and above will come with a proxy module. If compiled in, this will make

Apache act as a caching-proxy server

<p>

<HR>



<LI><A name="future">What are the future plans for Apache ?</A>

<P><UL>

<LI>to continue as a public domain HTTP server,

<LI>to keep up with advances in HTTP protocol and web developments in general

<LI>to collect suggestions for fixes/improvements from its users,

<LI>to respond to needs of large volume providers as well as occasional users.

</UL>

</P><HR>



<LI><A name="support">Who do I contact for support ?</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 via <A HREF="http://www.apache.org/bug_report.html">the bug report page.</A> 

Other questions should be directed to

<A HREF="news:comp.infosystems.www.servers.unix">comp.infosystems.www.servers.unix</A>, where some of the Apache team lurk,

in the company of many other httpd gurus who should be able

to help.

<p>

Commercial support for Apache is, however, available from a number

third parties.

</p>

<HR>



<LI><A name="more">Is there any more information on Apache ?</A>

<P>Indeed there is. See <A HREF="http://www.apache.org/">http://www.apache.org/</A>.

</P>

<HR>



<LI><A name="where">Where can get Apache ?</A>

<P>

You can find the source for Apache at <A HREF="http://www.apache.org/">http://www.apache.org/</A>.

</P>

<HR>

</OL>



<A HREF="../"><IMG SRC="../images/apache_home.gif" ALT="Home"></A>

<A HREF="./"><IMG SRC="../images/apache_index.gif" ALT="Index"></A>

</BODY>

</HTML>

docs/manual/misc/client_block_api.html

0 → 100644
+70 −0
Original line number Diff line number Diff line 
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

<HTML>

<HEAD>

<TITLE>Reading Client Input in Apache 1.2</TITLE>

</HEAD>



<BODY>

<IMG SRC="../images/apache_sub.gif" ALT="">

<H1>Reading Client Input in Apache 1.2</h1>



<hr>



<p>Apache 1.1 and earlier let modules handle POST and PUT requests by

themselves. The module would, on its own, determine whether the

request had an entity, how many bytes it was, and then called a

function (<code>read_client_block</code>) to get the data.



<p>However, HTTP/1.1 requires several things of POST and PUT request

handlers that did not fit into this module, and all existing modules

have to be rewritten. The API calls for handling this have been

furthur abstracted, so that future HTTP protocol changes can be

accomplished while remaining backwards-compatible.</p>



<hr>



<h3>The New API Functions</h3>



<pre>

   int setup_client_block (request_rec *);

   int should_client_block (request_rec *);

   long get_client_block (request_rec *, char *buffer, int buffer_size);

</pre>



<ol>

<li>Call <code>setup_client_block()</code> near the beginning of the request

    handler. This will set up all the neccessary properties, and

    will return either OK, or an error code. If the latter,

    the module should return that error code.



<li>When you are ready to possibly accept input, call

    <code>should_client_block()</code>.

    This will tell the module whether or not to read input. If it is 0,

    the module should assume that the input is of a non-entity type

    (e.g. a GET request). A nonzero response indicates that the module

    should proceed (to step 3).

    This step also sends a 100 Continue response

    to HTTP/1.1 clients, so should not be called until the module

    is *defenitely* ready to read content. (otherwise, the point of the

    100 response is defeated). Never call this function more than once.



<li>Finally, call <code>get_client_block</code> in a loop. Pass it a

    buffer and its 

    size. It will put data into the buffer (not neccessarily the full

    buffer, in the case of chunked inputs), and return the length of

    the input block. When it is done reading, it will return 0, and

    the module should proceed.



</ol>



<p>As an example, please look at the code in

<code>mod_cgi.c</code>. This is properly written to the new API

guidelines.</p>



<hr>



<A HREF="../"><IMG SRC="../images/apache_home.gif" ALT="Home"></A>

<A HREF="./"><IMG SRC="../images/apache_index.gif" ALT="Index"></A>



</BODY>

</HTML>

docs/manual/misc/compat_notes.html

0 → 100644
+108 −0
Original line number Diff line number Diff line 
<HTML><HEAD>

<TITLE>Apache HTTP Server: Compatibility Notes with NCSA's Server</TITLE>

</HEAD>

<BODY>

<IMG SRC="../images/apache_sub.gif" ALT="">

<H3>Compatibility Notes with NCSA's Server</H3>



<HR>



While Apache 0.8.x and beyond are for the most part a drop-in

replacement for NCSA's httpd and earlier versions of Apache, there are

a couple gotcha's to watch out for.  These are mostly due to the fact

that the parser for config and access control files was rewritten from

scratch, so certain liberties the earlier servers took may not be

available here.  These are all easily fixable.  If you know of other

non-fatal problems that belong here, <a

href="mailto:apache-bugs@apache.org">let us know.</a>



<P>Please also check the <A HREF="known_bugs.html">known bugs</A> page.







<OL>



<LI><CODE>AddType</CODE> only accepts one file extension per line, without

any dots (<code>.</code>) in the extension, and does not take full filenames.

If you need multiple extensions per type, use multiple lines, e.g.

<blockquote><code>

AddType application/foo foo<br>

AddType application/foo bar

</code></blockquote>

To map <code>.foo</code> and <code>.bar</code> to <code>application/foo</code>

<p>







  <LI><P>If you follow the NCSA guidelines for setting up access restrictions

  based on client domain, you may well have added entries for,

  <CODE>AuthType, AuthName, AuthUserFile</CODE> or <CODE>AuthGroupFile</CODE>.

  <B>None</B> of these are needed (or appropriate) for restricting access

  based on client domain.



  <P>When Apache sees <CODE>AuthType</CODE> it (reasonably) assumes you

  are using some authorization type based on username and password.



  <P>Please remove <CODE>AuthType</CODE>, it's unnecessary even for NCSA.



  <P>



  <LI><CODE>AuthUserFile</CODE> requires a full pathname. In earlier

      versions of NCSA httpd and Apache, you could use a filename

      relative to the .htaccess file. This could be a major security hole,

      as it made it trivially easy to make a ".htpass" file in the a 

      directory easily accessable by the world. We recommend you store

      your passwords outside your document tree.



  <P>



  <LI><CODE>OldScriptAlias</CODE> is no longer supported.



  <P>



  <LI><CODE>exec cgi=""</CODE> produces reasonable <B>malformed header</B>

  responses when used to invoke non-CGI scripts.<BR>

  The NCSA code ignores the missing header. (bad idea)<BR>

  Solution: write CGI to the CGI spec or use <CODE>exec cmd=""</CODE> instead.

  <P>We might add <CODE>virtual</CODE> support to <CODE>exec cmd</CODE> to

  make up for this difference.



  <P>



  <LI>&lt;Limit&gt; sillyness - in the old Apache 0.6.5, a

   directive of &lt;Limit GET&gt; would also restrict POST methods - Apache 0.8.8's new

   core is correct in not presuming a limit on a GET is the same limit on a POST,

   so if you are relying on that behavior you need to change your access configurations

   to reflect that.



  <P>



  <LI>Icons for FancyIndexing broken - well, no, they're not broken, we've just upgraded the

  icons from flat .xbm files to pretty and much smaller .gif files, courtesy of 

<a href="mailto:kevinh@eit.com">Kevin Hughes</a> at

<a href="http://www.eit.com">EIT</a>.

  If you are using the same srm.conf from an old distribution, make sure you add the new

  AddIcon, AddIconByType, and DefaultIcon commands.



  <P>



  <LI>Under IRIX, the "Group" directive in httpd.conf needs to be a valid group name 

  (i.e. "nogroup") not the numeric group ID.  The distribution httpd.conf, and earlier 

  ones, had the default Group be "#-1", which was causing silent exits at startup.<p>



<li><code>.asis</code> files: Apache 0.6.5 did not require a Status header;

it added one automatically if the .asis file contained a Location header.

0.8.14 requires a Status header. <p>



</OL>



More to come when we notice them....





<hr>



<A HREF="../"><IMG SRC="../images/apache_home.gif" ALT="Home"></A>

<A HREF="./"><IMG SRC="../images/apache_index.gif" ALT="Index"></A>



</BODY>

</HTML>