with this and a request line that goes on forever, I now get:

[Wed Oct 31 17:45:45 2001] [error] [client 127.0.0.1] request failed:
URI too long

...in the error log, and a 414 in the access log.


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

to an input line.  This is more like the 1.3 behavior which should help the
callers recognize this condition.


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

looks like the line may never end.

This lets ap_getline determine whether there's excessive bytes or not,
depending on the size of its caller's buffers.  If the buffer can accomodate
more bytes, ap_getline will continue to read.


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

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

The core input filter would happily consume all the data you gave it
in a header line, looking for that one LF. This patch limits that
"getline" functionality to HUGE_STRING_LEN (8192 bytes).


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

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

  Introduce an Apache mod_ssl initial configuration template
  (ssl.conf, generated from ssl-std.conf).  [Ralf S. Engelschall]

  Revised Cliff's intro paragraph to point folks at docs until
  docs are provided.  [Will Rowe]


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

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

PR: 8556


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

2.0.26 has been discarded.


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

and not just a zero-byte thingy.  :)


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

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

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

PR:
Obtained from:
Submitted by:
Reviewed by:


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

Without this, we see an extra socket read + timeout on POSTs.  If the client
sends in another request, we loop consuming memory.


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

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

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

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

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

conditions


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

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

can be very difficult to read. No logic was changed.


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

  Bring it up-to-date while I'm a'fixin


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

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

The routine that prints the Via: header now takes a length for
the port string.

Submitted by:	Zvi Har'El <rl@math.technion.ac.il>


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

    Use the _setn flavor which will avoid strdup'ing these strings, and
    skip the cleanups we don't need.

Submitted by: Brian Pane <bpane@pacbell.net>


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

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

couple notes to give hints to people running servers behind port-forwarding
firewalls.


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

(I'm not sure that this logic for copying DSOs will survive
in the libtool scheme; I'm putting this 1.3 fix in just in
case.)


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

in a 500 error.  Log the error so that it isn't so darn
mysterious.


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

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

Previously, we would segfault if no path is specified (case 1 below).
We would also ignore any host and scheme portion of the URL (which is
how we specify it on daedalus), so restore that capability.

The query strings will still not be escaped (standards cops can
determine if this is correct behavior).

The following directives now work as expected:
RedirectMatch /jakarta1(.*) http://jakarta.apache.org$1
RedirectMatch /jakarta2(.*) http://jakarta.apache.org/dist$1
RedirectMatch /jakarta3(.*) http://jakarta.apache.org/dist$1?bar=foo
RedirectMatch /jakarta4(.*) http://jakarta.apache.org/dist$1?bar=foo#spaz


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

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

	Bring forward checkgid helper from 1.3; checks runtime
	validity of httpd Group directive-style group identifiers.


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

the former generation, after a restart.  It happens mostly when the MPM has
threads.


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

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

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

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

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

 - Treat --enable-so=yes as "static" (this includes --enable-so, etc).
 - An explicit --enable-so=shared issues an error.

Put in a note about the last condition that I'm not as sure how to fix:
If the user doesn't explicitly request mod_so, but instead gives a
mass-enable parameter like --enable-modules=most or
--enable-mods-shared=most then it is still possible to enable a bunch
of modules while mod_so itself is not buildable (ie no APR_HAS_DSO or
other build dependency failure).


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