AFAICT On z/OS, with default compiler flags for "cc" (=_XOPEN_SOURCE),
isascii() is the same as the APR fallback for isascii()
#define apr_isascii(c) (((c) & ~0x7f)==0).

Since these functions usually look at EBCDIC strings, I don't think it
does the right thing here by itself. But since it's just gen_test_char
a small static could
do apr_xlate_conv_byte(ap_hdrs_to_ascii...) then isascci to see if it
ended up -1, 7bit, or 8bit?


On Fri, Jul 29, 2016 at 11:35 AM,  <[email protected]> wrote:
> Author: wrowe
> Date: Fri Jul 29 15:35:56 2016
> New Revision: 1754538
>
> URL: http://svn.apache.org/viewvc?rev=1754538&view=rev
> Log:
> Correct T_HTTP_TOKEN_STOP per RFC2068 (2.2) - RFC7230 (3.2.6),
> which has always defined 'token' as CHAR or VCHAR - visible USASCII only.
>
> NUL char is also a stop, end of parsing.
>
>
> Modified:
>     httpd/httpd/trunk/server/gen_test_char.c
>
> Modified: httpd/httpd/trunk/server/gen_test_char.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/server/gen_test_char.c?rev=1754538&r1=1754537&r2=1754538&view=diff
> ==============================================================================
> --- httpd/httpd/trunk/server/gen_test_char.c (original)
> +++ httpd/httpd/trunk/server/gen_test_char.c Fri Jul 29 15:35:56 2016
> @@ -115,8 +115,13 @@ int main(int argc, char *argv[])
>              flags |= T_ESCAPE_URLENCODED;
>          }
>
> -        /* these are the "tspecials" (RFC2068) or "separators" (RFC2616) */
> -        if (c && (apr_iscntrl(c) || strchr(" \t()<>@,;:\\\"/[]?={}", c))) {
> +        /* Stop for any non-'token' character, including ctrls, obs-text,
> +         * and "tspecials" (RFC2068) a.k.a. "separators" (RFC2616)
> +         * XXX: With luck, isascii behaves sensibly on EBCDIC platforms
> +         *      and insists on chars that correspond to ASCII equivilants
> +         */
> +        if (apr_iscntrl(c) || strchr(" \t()<>@,;:\\\"/[]?={}", c))
> +                           || !apr_isascii(c)) {
>              flags |= T_HTTP_TOKEN_STOP;
>          }
>
>
>



-- 
Eric Covener
[email protected]

Reply via email to