>> * Michael McLagan <[EMAIL PROTECTED]> [2002-09-21 11:45]:
>> > There is a bug in Apache::Cookie. It doesn't handle a cookie with
>> > zero bytes in it!
>
>> This is because Apache::Cookie is implemented in C, and C uses NULL as
>> the end of string terminator.
>
>No quite accurate. C has no concept of a string. There are a number of
>library functions for string handling that use '\0' as the string
>terminator.
>
>If somebody rewrites Apache::Cookie to replace those functions, it will
>be able to handle such cookies.
>
>> This is probably something that needs to be done in Perl, since I doubt
>> there's a way to check for "embedded" NULLs in a string in C...
>
>/* We assume there will always a '\0' to be found. */
>char *
>find_nul(char *str)
>{
> while (*str) {
> str++;
> }
>
> return str;
>}
>
>What interests me much more is *why* a cookie should be able to contain
>*any* control character. If you want binary data in a cookie, you should
>encode it somehow.
>
>If the '\0' was a '\n', things would be much more interesting ...
>
>Lupe Christoph
hmmm... that's not really to point. Apache::Cookie is supposed to be
modeled on and replace CGI::Cookie. If you examine the code in CGI::Cookie
you see that when the "values" are extracted from the input hash, they are
escaped and then placed into the string format used for a cookie. There is
no limitation at all on what characters may be place in the "values" that
are submitted for XXX::Cookie->new($r,%hash). The present situation really
is a bug in implementation due to the nature of the C lib used to process
the "value" portion of the cookie string. I suspect the same is true about
the cookie "name" since it is processed in a similar way in CGI::Cookie.
We're not discussing what is allowable in the cookie itself, only the
compatibility of the Apache::Cookie vs CGI::Cookie implementation on which
it is patterned.
Michael
