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

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

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

NWGNUsocachmem needs to find mod_status.h


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

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

https://tools.ietf.org/html/rfc7231#section-7.1.2

   The "Location" header field is used in some responses to refer to a
   specific resource in relation to the response.  The type of
   relationship is defined by the combination of request method and
   status code semantics.

     Location = URI-reference

   The field value consists of a single URI-reference.  When it has the
   form of a relative reference ([RFC3986], Section 4.2), the final
   value is computed by resolving it against the effective request URI
   ([RFC3986], Section 5).


There is even an example with no scheme:

     Location: /People.html#tim



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

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

This has changed a bit after the fix for PR 53555. Better wording is welcome.



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

from jim


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

Allow to use all slots up to ServerLimit. This makes 'scoreboard full'
errors much less likely.

And if ther is a situation where the scoreboard is full, don't make any
more processes finish gracefully due to reduced load until some old
processes have terminated. Otherwise, the situation would get worse once
the load increases again.

ap_daemon_limit is renamed to the more descriptive active_server_limit,
to make sure that all its uses are taken care of.

PR 53555



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

The behavior for terminate == 1 was documented but not implemented. Do
that now.




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

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

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

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

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

and simplify now that there isn't a log-only mode.

I believe this logic to be busted. Given this request;

GET http://distant-host.com/ HTTP/1.1
Host: proxy-host

we would now fail to evaluate the proxy-host virtual host rules.

This seems like a breaking change to our config. mod_proxy already
follows this rule of RFC7230 section 5.4;

   When a proxy receives a request with an absolute-form of
   request-target, the proxy MUST ignore the received Host header field
   (if any) and instead replace it with the host information of the
   request-target.  A proxy that forwards such a request MUST generate a
   new Host field-value based on the received request-target rather than
   forward the received Host field-value.

Section 5.5 of RFC7230 has this to say;

   Once the effective request URI has been constructed, an origin server
   needs to decide whether or not to provide service for that URI via
   the connection in which the request ...

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

This note has been added as a follow up of a stack overflow post
(thanks to Michael Allan for the research):

http://stackoverflow.com/questions/29398123/apache-2-4-set-mime-type-of-file-without-extension

After a chat in #httpd-dev it seems that the issue boils down to how %{CONTENT_TYPE}
is evaluated in util_expr_eval.c (r->content_type) vs how setifempty is (only a check
of the response headers). This particular behavior might be a bug or feature,
but it is worth to alert our users.





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

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

Removed some out of date references and re-wrote
some sections. Added also a banner at the top of
the page to warn the users about stale content.
The next step is to improve the accept() related
documentation introducing the latest changes made
for event (and how awesome event is).



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

    HTTP/x.x xxx Status xxx



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

</br> --> <br />

Couls also be <br> or <br/> but some (very) old clients don't like it.
httpd is not really consistent on it. (personnlaly <br> would be just fine for me but <br /> is the most commonly used form)

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

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

It allows a non httpd config file to be used as a marker directly in
httpd.conf without hiding logic in a script in front of apachectl
to do test -f and pass extra -D's.

This is something we've had in IBM's httpd distro for a little bit and
hadn't remembered to share. I've seen some questions/config files come
up in a few places lately that would benefit from this as an option.



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

It looks like this was the original intent. The provider
is not registered if apr-redis is missing.

It was previously failing to compile due to the dirconf being
hidden behind the #ifdef guard but not the routine module
code that used it.




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

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

Also changed terminology to be in sync with:
https://httpd.apache.org/docs/current/mod/directive-dict.html#Context

It was confusing in my opinion to read that ProxyPass wasn't supported
for the <Directory> context (since "directory" semantic is already
overloaded).


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

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

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

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

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

r1759984, r1760018 and r1752347 are all changes related
to a bug fixed for mod_proxy_fcgi.


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

  ASN1_OBJECT for X509_ALGOR_get0() for OpenSSL >= 1.1.0 per
  https://github.com/openssl/openssl/commit/ac4e257747075958d37665f327bdf685dd2478ab


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

Submitted by: Josef Radinger


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

mod_proxy_http2: Link header uris are reverse mapped


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

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

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

If other modules or libraries do not clear the OpenSSL error queue after
a failed operation, other code that relies on SSL_get_error() -- in
particular, code that deals with SSL_ERROR_WANT_READ/WRITE logic -- will
malfunction later on. To prevent this, explicitly clear the error queue
before calls like SSL_read/write/accept().

PR: 60223
Submitted by: Paul Spangler <paul.spangler ni.com>

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

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

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