httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: h2_utils duplicity
Date Thu, 09 Jun 2016 04:41:39 GMT
On Wed, Jun 8, 2016 at 9:08 PM, William A Rowe Jr <wrowe@rowe-clan.net>
wrote:

> On Wed, Jun 8, 2016 at 7:19 PM, <wrowe@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.
>
>
>

Mime
View raw message