documented anywhere.
Submitted by:	Daniel Lopez
Reviewed by:	Rich Bowen


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

Submitted by: Shantonu Sen <ssen@apple.com>


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

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

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

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

Submitted by: johannes m. richter


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

Submitted by: Johannes m. richter


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

during initialization and configuration of the main Apache process.


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

the similar Tru64 symptom must have been caused by
something else since it went away


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

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

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

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

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

properly for virtual hosts.


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

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

hi ho the merrio .. a vetoing I will go.
;-0


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

Keeping apachectl simple seems desirable.  The tasks listed for httpd.sh
seem reasonable too.


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

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

1. Add a <relative-path href="whatever"/> element to the manualpage
DTD.  This should give the path from the location of the page to
the root of the manual directory.  It is necessary for proper linking
to directives, etc.

2. Add the stuff to common.xsl necessary to transform a <manualpage>.
This is basically the minimum.  It creates something VERY similar to
what we had before (with the exception of a little css here and
there).  I very much hope that this will be improved soon to look
nicer.

3. Add configuring.xml, which was written by Astrid Kessler.  I made only
a very few small changes to bring it in line with the current DTD.

I have not yet committed the corresponding configuring.html.en, since I
want to give people a little opporunity to comment on this stuff.

My appologies, but I am committing a few style changes to common.xsl
along with the substantial changes.  That file is really hard to
work with, and should probably be broken up.


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

they aren't.

If the config directive's syntax changed, Apache will tell
you which one changed, and the docs are a better place to go for details
then the default config files.  BTW, the syntax of a directive hasn't
changed for a VERY long time.

If the semantics changed, then nobody will ever know that they need to
look in the default config files to determine that they semantics changed,
because there is no error message.

The argument that you want to be able to get the defaults back doesn't
hold water, because 99.9% of all admins backup their files before
modifying them.  If you aren't backing them up, then that is your problem.

The argument that you may not have a full config directory also doesn't
hold water, because the assumption is that the conf/ directory is coming
from a working server.


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

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

Abstaining for now on where they should live.  It would be work to move them.
Is it worth it?  dunno


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

I do consider it useful to have an updated httpd-std.conf with a new version.
Some docs-project people would like to have a directory to dump all sorts
of sample configurations.


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

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

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

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

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

Submitted by: lolo32@altavista.fr
Reviewed by: Joshua Slive (my french is far from perfect, but I don't
think this is too far off)


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

This still needs considerable attention.

Submitted by: Chris Herbst <chris@herbst.com>, Joshua Slive


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

that Port is gone.

PR: 11041


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

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

to the pool after being used.
PR:
Obtained from:
Submitted by:	Scott Lamb <slamb@slamb.org>
Reviewed by:


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

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

because we couldn't work out the copyright issues.  Instead, it is based on
Ralf's work on the SSL glossary plus my own additions.

More entries are very welcome.  I tried to make this an "index" of the docs as
well as a glossary -- I included links to other places in the docs with more
information wherever possible.


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

It redefines the document root, so it should only be used if no other mapper wants
the request.  I haven't made that change here; I've simply put explict ordering
to make sure we get

mod_alias -> mod_userdir -> mod_vhost_alias

I can't compile apache at the moment for other reasons, so this is untested,
but it looks right to me.

PR: 8853


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

  A half hour to waste waiting for builds... this is what you get.
  mod_isapi will build and run on OSX... presume others as well unless
  I choose some awful errno values for portability.

PR:
Obtained from:
Submitted by:
Reviewed by:


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

  Cut-n-paste error


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

  Until we are building loadable iconv modules, the core iconv will always
  be carried around with aprutil.


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

  Unless I'm missing something obvious, apr-iconv never needs to be it's
  own .dll/.so library.  In the case of libapriconv, we need to anticipate
  that the library will be incorporated into libaprutil and exposed through
  the apr_xlate_() API.  In the case of the aprutil we can use the same
  approach.

  After this patch, one never includes the libapriconv or apriconv in any
  application.  Including libaprutil or aprutil is sufficient.


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

Submitted by:	Karl Fogel
Reviewed by:	Greg Ames


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