Could you, when time allows, check if r1747550 in trunk now builds without 
problems?

I duplicated the necessary code - for now - into h2_proxy_util.c. While I think 
that
parts of it should migrate to core, I do not want to introduce new APIs right 
now.
With duplication, we have all options still open without messing with 
incompatible
changes. Should be also easier for back porting.

-Stefan

> Am 09.06.2016 um 06:41 schrieb William A Rowe Jr <wr...@rowe-clan.net>:
> 
> On Wed, Jun 8, 2016 at 9:08 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On Wed, Jun 8, 2016 at 7:19 PM,  <wr...@apache.org> wrote:
> Author: wrowe
> Date: Thu Jun  9 00:19:24 2016
> New Revision: 1747470
> 
> URL: http://svn.apache.org/viewvc?rev=1747470&view=rev
> Log:
> The answer to the question appears to be in 2.4.21, drop h2_casecmpstr fork
> 
> Modified:
>     httpd/httpd/trunk/modules/http2/NWGNUmod_http2
>     httpd/httpd/trunk/modules/http2/h2_util.c
>     httpd/httpd/trunk/modules/http2/h2_util.h
>     httpd/httpd/trunk/modules/http2/mod_proxy_http2.c
> 
> Modified: httpd/httpd/trunk/modules/http2/h2_util.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/h2_util.c?rev=1747470&r1=1747469&r2=1747470&view=diff
> ==============================================================================
> --- httpd/httpd/trunk/modules/http2/h2_util.c (original)
> +++ httpd/httpd/trunk/modules/http2/h2_util.c Thu Jun  9 00:19:24 2016
> @@ -1578,123 +1578,3 @@ void h2_push_policy_determine(struct h2_
>      req->push_policy = policy;
>  }
> 
> -/*******************************************************************************
> - * ap_cstr_casecmp, when will it be backported?
> - 
> ******************************************************************************/
> -#if !APR_CHARSET_EBCDIC
> -/*
> - * Provide our own known-fast implementation of str[n]casecmp()
> - * NOTE: Only ASCII alpha characters 41-5A are folded to 61-7A,
> - * other 8-bit latin alphabetics are never case-folded!
> - */
> -static const unsigned char ucharmap[] = {
> -    0x0,  0x1,  0x2,  0x3,  0x4,  0x5,  0x6,  0x7,
> -    0x8,  0x9,  0xa,  0xb,  0xc,  0xd,  0xe,  0xf,
> -    0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17,
> -    0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f,
> -    0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27,
> -    0x28, 0x29, 0x2a, 0x2b, 0x2c, 0x2d, 0x2e, 0x2f,
> -    0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37,
> -    0x38, 0x39, 0x3a, 0x3b, 0x3c, 0x3d, 0x3e, 0x3f,
> -    0x40,  'a',  'b',  'c',  'd',  'e',  'f',  'g',
> -     'h',  'i',  'j',  'k',  'l',  'm',  'n',  'o',
> -     'p',  'q',  'r',  's',  't',  'u',  'v',  'w',
> -     'x',  'y',  'z', 0x5b, 0x5c, 0x5d, 0x5e, 0x5f,
> -    0x60,  'a',  'b',  'c',  'd',  'e',  'f',  'g',
> -     'h',  'i',  'j',  'k',  'l',  'm',  'n',  'o',
> -     'p',  'q',  'r',  's',  't',  'u',  'v',  'w',
> -     'x',  'y',  'z', 0x7b, 0x7c, 0x7d, 0x7e, 0x7f,
> -    0x80, 0x81, 0x82, 0x83, 0x84, 0x85, 0x86, 0x87,
> -    0x88, 0x89, 0x8a, 0x8b, 0x8c, 0x8d, 0x8e, 0x8f,
> -    0x90, 0x91, 0x92, 0x93, 0x94, 0x95, 0x96, 0x97,
> -    0x98, 0x99, 0x9a, 0x9b, 0x9c, 0x9d, 0x9e, 0x9f,
> -    0xa0, 0xa1, 0xa2, 0xa3, 0xa4, 0xa5, 0xa6, 0xa7,
> -    0xa8, 0xa9, 0xaa, 0xab, 0xac, 0xad, 0xae, 0xaf,
> -    0xb0, 0xb1, 0xb2, 0xb3, 0xb4, 0xb5, 0xb6, 0xb7,
> -    0xb8, 0xb9, 0xba, 0xbb, 0xbc, 0xbd, 0xbe, 0xbf,
> -    0xc0, 0xc1, 0xc2, 0xc3, 0xc4, 0xc5, 0xc6, 0xc7,
> -    0xc8, 0xc9, 0xca, 0xcb, 0xcc, 0xcd, 0xce, 0xcf,
> -    0xd0, 0xd1, 0xd2, 0xd3, 0xd4, 0xd5, 0xd6, 0xd7,
> -    0xd8, 0xd9, 0xda, 0xdb, 0xdc, 0xdd, 0xde, 0xdf,
> -    0xe0, 0xe1, 0xe2, 0xe3, 0xe4, 0xe5, 0xe6, 0xe7,
> -    0xe8, 0xe9, 0xea, 0xeb, 0xec, 0xed, 0xee, 0xef,
> -    0xf0, 0xf1, 0xf2, 0xf3, 0xf4, 0xf5, 0xf6, 0xf7,
> -    0xf8, 0xf9, 0xfa, 0xfb, 0xfc, 0xfd, 0xfe, 0xff
> -};
> -
> -#else /* APR_CHARSET_EBCDIC */
> -/* Derived from apr-iconv/ccs/cp037.c for EBCDIC case comparison,
> -   provides unique identity of every char value (strict ISO-646
> -   conformance, arbitrary election of an ISO-8859-1 ordering, and
> -   very arbitrary control code assignments into C1 to achieve
> -   identity and a reversible mapping of code points),
> -   then folding the equivalences of ASCII 41-5A into 61-7A,
> -   presenting comparison results in a somewhat ISO/IEC 10646
> -   (ASCII-like) order, depending on the EBCDIC code page in use.
> - */
> -static const unsigned char ucharmap[] = {
> -       0x00, 0x01, 0x02, 0x03, 0x9C, 0x09, 0x86, 0x7F,
> -       0x97, 0x8D, 0x8E, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F,
> -       0x10, 0x11, 0x12, 0x13, 0x9D, 0x85, 0x08, 0x87,
> -       0x18, 0x19, 0x92, 0x8F, 0x1C, 0x1D, 0x1E, 0x1F,
> -       0x80, 0x81, 0x82, 0x83, 0x84, 0x0A, 0x17, 0x1B,
> -       0x88, 0x89, 0x8A, 0x8B, 0x8C, 0x05, 0x06, 0x07,
> -       0x90, 0x91, 0x16, 0x93, 0x94, 0x95, 0x96, 0x04,
> -       0x98, 0x99, 0x9A, 0x9B, 0x14, 0x15, 0x9E, 0x1A,
> -       0x20, 0xA0, 0xE2, 0xE4, 0xE0, 0xE1, 0xE3, 0xE5,
> -       0xE7, 0xF1, 0xA2, 0x2E, 0x3C, 0x28, 0x2B, 0x7C,
> -       0x26, 0xE9, 0xEA, 0xEB, 0xE8, 0xED, 0xEE, 0xEF,
> -       0xEC, 0xDF, 0x21, 0x24, 0x2A, 0x29, 0x3B, 0xAC,
> -       0x2D, 0x2F, 0xC2, 0xC4, 0xC0, 0xC1, 0xC3, 0xC5,
> -       0xC7, 0xD1, 0xA6, 0x2C, 0x25, 0x5F, 0x3E, 0x3F,
> -       0xF8, 0xC9, 0xCA, 0xCB, 0xC8, 0xCD, 0xCE, 0xCF,
> -       0xCC, 0x60, 0x3A, 0x23, 0x40, 0x27, 0x3D, 0x22,
> -       0xD8, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67,
> -       0x68, 0x69, 0xAB, 0xBB, 0xF0, 0xFD, 0xFE, 0xB1,
> -       0xB0, 0x6A, 0x6B, 0x6C, 0x6D, 0x6E, 0x6F, 0x70,
> -       0x71, 0x72, 0xAA, 0xBA, 0xE6, 0xB8, 0xC6, 0xA4,
> -       0xB5, 0x7E, 0x73, 0x74, 0x75, 0x76, 0x77, 0x78,
> -       0x79, 0x7A, 0xA1, 0xBF, 0xD0, 0xDD, 0xDE, 0xAE,
> -       0x5E, 0xA3, 0xA5, 0xB7, 0xA9, 0xA7, 0xB6, 0xBC,
> -       0xBD, 0xBE, 0x5B, 0x5D, 0xAF, 0xA8, 0xB4, 0xD7,
> -       0x7B, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67,
> -       0x68, 0x69, 0xAD, 0xF4, 0xF6, 0xF2, 0xF3, 0xF5,
> -       0x7D, 0x6A, 0x6B, 0x6C, 0x6D, 0x6E, 0x6F, 0x70,
> -       0x71, 0x72, 0xB9, 0xFB, 0xFC, 0xF9, 0xFA, 0xFF,
> -       0x5C, 0xF7, 0x73, 0x74, 0x75, 0x76, 0x77, 0x78,
> -       0x79, 0x7A, 0xB2, 0xD4, 0xD6, 0xD2, 0xD3, 0xD5,
> -       0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37,
> -       0x38, 0x39, 0xB3, 0xDB, 0xDC, 0xD9, 0xDA, 0x9F
> -};
> -#endif
> -
> -int h2_casecmpstr(const char *s1, const char *s2)
> -{
> -    const unsigned char *ps1 = (const unsigned char *) s1;
> -    const unsigned char *ps2 = (const unsigned char *) s2;
> -
> -    while (ucharmap[*ps1] == ucharmap[*ps2]) {
> -        if (*ps1++ == '\0') {
> -            return (0);
> -        }
> -        ps2++;
> -    }
> -    return (ucharmap[*ps1] - ucharmap[*ps2]);
> -}
> -
> -int h2_casecmpstrn(const char *s1, const char *s2, apr_size_t n)
> -{
> -    const unsigned char *ps1 = (const unsigned char *) s1;
> -    const unsigned char *ps2 = (const unsigned char *) s2;
> -    while (n--) {
> -        if (ucharmap[*ps1] != ucharmap[*ps2]) {
> -            return (ucharmap[*ps1] - ucharmap[*ps2]);
> -        }
> -        if (*ps1++ == '\0') {
> -            break;
> -        }
> -        ps2++;
> -    }
> -    return (0);
> -}
> -
>  
> Not specific to this patch, we seem to have a really convoluted build
> right now in the mod_proxy_http2.so world, and it doesn't seem ready
> to launch into httpd-2.4...
> 
> You really should not be including the same source files in two different
> modules, which we are with h2_util.c. It causes a mess on win32 from
> the source code browser/symbols and library control perspective, and
> on unix, you are dealing with a single-level namespace and generating
> oodles of collisions.
>  
> It likely also messes with ar/libtool, seeing as objects may disappear
> into the .a on the first pass, replaced by a noop stub.
> 
> There are a couple of ways we might deal with this...
> 
> * h2 utils become core
> 
> * h2 utils become a top-tier module loaded before their consumers,
>   mod_http2 and mod_proxy_http2
> 
> * h2 utils are copied and pasted into two separate source files with
>   different namespace scopes
> 
> And the fourth possibility;
> 
>  * h2 utils are part of mod_http2, mandatory for any user who wishes
>    to also load mod_proxy_http2
>  
> I expect the right answer is one, but you want to preserve the ability
> to load into older 2.4.x flavors, which suggests to me that we should
> probably pursue the second option, much like everything in the
> mod_proxy_* sphere requires mod_proxy loaded first, and similarly
> with mod_dav.

Reply via email to