On Sat, Jul 30, 2016 at 6:35 PM, Eric Covener <cove...@gmail.com> wrote:
> On Sat, Jul 30, 2016 at 12:28 PM, Yann Ylavic <ylavic....@gmail.com> wrote:
>> On Sat, Jul 30, 2016 at 5:37 PM, Yann Ylavic <ylavic....@gmail.com> wrote:
>>>
>>> (I'm a bit lost on where are/aren't EBCDIC octets here).
>>
>> Mostly, I understand that T_HTTP_TOKEN_STOP and T_HTTP_CTRLS should be
>> used with ascii chars because they come from test_isascii_equiv() (and
>> due to the fact they are called from ap_getline_core(), with network
>> bytes), but e.g. T_OS_ESCAPE_PATH must be used with native/EBCDIC
>> chars because it uses apr_isalnum() directly.
>>
>> That doesn't look consistent (at that level) to me, shouldn't
>> ap_getline_core() do the ap_xlate_proto_from_ascii() work (or we
>> provide both ascii and ebcdic versions of
>> ap_{get,scan}_http_{token,field_content}())...
>
> There is an ifdef'ed version of ap_rgetline_core called underneath
> ap_getline that does the a2e before anyone looks at the line. That's
> what allows all of the string literals
> to work without having EBCDIC stuff everywhere.
OK, that's fine (and fortunate :)
But I mean we pre-suppose in gen_test_char that for T_HTTP_TOKEN_STOP
and T_HTTP_CTRLS, TEST_CHAR (in util.c) will be called with ascii
bytes (because they come from the network in ap_getline_core(), not
from ap_getline() where a2e actually occurs).
We possibly should a2e in util.c (wherever/before we use
T_HTTP_TOKEN_STOP and T_HTTP_CTRLS) to keep gen_test_char consistent,
but that means we'd possibly have to provide both ascii and native
versions of all the corresponding functions for callers that'd want to
use them with either strings.
Since httpd only uses the ascii versions for now, we can save the
native versions until needed (if ever), but it looks more "sane" to me
to do the xlate_proto_from_ascii() in util.c and document that the
existing fonctions (needing TOKEN/CTRLS) work with ascii strings only.
Maybe I'm too peaky...
