We previously rebased to a pre-1.8 version (accidentally)

Signed-off-by: Yehuda Sadeh <yehuda@redhat.com>

For 'target_include_directories" for the cmake object library
'civetweb_common_objs', change from PUBLIC to PRIVATE.  This doesn't
break anything, so it wasn't doing anything useful.  If it has it
any effect, it would be to cause everything that linked against this
"library" to also use the indictated include path.  Which would be great
except everything in ceph wants to include "civetweb/civetweb.h" and
not "civetweb.h".  We already make separate arrangements elsewhere for
that to work.  Additionally, static object libraries in cmake aren't
really libraries, so I'm not entirely sure this even does anything.
So: making this public is not useful, and could be harmful.  Making it
private makes this only take effect for building civetweb.c itself,
exactly the effect we we require, and no more.

Signed-off-by: Marcus Watts <mwatts@redhat.com>

If building with radosgw, always look for openssl library (even when
building with nss).  Then, use objdump to fetch SONAME from the copies
of libssl and libcrypto that were found.  When building civetweb; pass
the library soname values in as the libraries to load with "dlopen".

This is a problem that went away for a bit, but came back with some
changes for
http://tracker.ceph.com/issues/16535

Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1341775
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1258961

Fixes: http://tracker.ceph.com/issues/11239

Signed-off-by: Marcus Watts <mwatts@redhat.com>

This includes information on file format and configuration file syntax.

Signed-off-by: Marcus Watts <mwatts@redhat.com>

… mg_get_local_addr

The logic inside of radosgw that computes aws v4 signatures wants to know
what server port the client connected.  The patch to civetweb patch adds a
call mg_get_local_addr() which will permit that code to actually find out
on what address a connection was received, rather than merely guessing
based on configuration as it previously did.

Signed-off-by: Marcus Watts <mwatts@redhat.com>

Without https, only port is set.  With https, secure_port and port are
both set to the same value.  The previous logic looked at port first and
had overly simplified conditional logic which was liable to try to apply
both non-default cases.  The correct behavior is: look secure_port first,
and if secure_port is set, then only check to see if it's a non-default
port.

Signed-off-by: Marcus Watts <mwatts@redhat.com>

…ith civetweb.

For civetweb: accept a range of port numbers joined with '+'.
Port numbers may include an ipaddress: prefix and 's' suffix.
Additionally, use "mg_get_local_addr" to correctly deduce host port per
incoming connection.

civetweb can accept connections on multiple ports, some of which
might have SSL turned on and some not.  Both s3 and swift have various
authorization protocols in which the port number matters.  In the generic
radosgw frontend process, each frontend only has one port number, but
we should want to have both ssl and non-ssl connections managed within
one rgw frontend, because the thread pool is also per front-end, and
that *is* a scarce resource.

So, this patch enables the use of multiple ports with a single civetweb
frontend.  To indicate https: append an 's' to portno.  To use multiple
ports, use +.  So 80+443s indicates use of the usual default http ports.
The parsed port is not stored in the frontend structure,

So instead, this patch adds logic to use the results of
mg_get_local_addr() on a per-connection basis insetad of the generic
front-end port number.  This will affect "v4" s3 authorization, and also
affect swift pre-signed URLs.

mg_get_local_addr() is a new customization to civetweb; that submodule
was updated (in a temporary repository) by the previous commit to this.

Signed-off-by: Marcus Watts <mwatts@redhat.com>