On Wed, Aug 26, 2015 at 8:37 AM, <ic...@apache.org> wrote: > Author: icing > Date: Wed Aug 26 13:37:18 2015 > New Revision: 1697931 > > URL: http://svn.apache.org/r1697931 > > + *) core/mod_ssl: add Protocols/ProtocolsHonorOrder directives and new > + protocols hooks to control Upgrade: and ALPN protocol switching. > + HTTP_MISDIRECTED_REQUEST addition and handling in mod_ssl > + trunk patch: http://svn.apache.org/r1697855 > + http://svn.apache.org/r1697339 > + http://svn.apache.org/r1696428 > + http://svn.apache.org/r1696266 > + http://svn.apache.org/r1696264 > + http://svn.apache.org/r1695874 > + http://svn.apache.org/r1695727 > + http://svn.apache.org/r1692516 > + http://svn.apache.org/r1692486 > + http://svn.apache.org/r1610674 (partial) > + http://svn.apache.org/r1685069 > + 2.4.x patch: > https://raw.githubusercontent.com/icing/mod_h2/master/sandbox/httpd/patches/core-protocols.patch
I can't see anything that introduces API breakage in this patch set. Well done! With the new API's, a minor MMN bump is necessary. One minor cleanup, a few excess blank lines in include/http_core.h. Looking at +/** + * Get the index of the string in the array or -1 if not found. + * @param array the array the check + * @param s the string to find + * @return index of string in array or -1 + */ +AP_DECLARE(int) ap_array_index(const apr_array_header_t *array, const char *s); with an eye toward apr_array_index, would it be better to start off with a third 'int start' argument (suggested value 0) so that the array is searched from the indicated elt, as arrays are unordered and not defined to contain unique values?
