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 h2_utils duplicity
Date Thu, 09 Jun 2016 02:08:17 GMT
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.

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

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