In the code below \r\n¹ are already ruled out by the read logic that
collects bytes until it sees \r?\n¹
I don¹t see a problem limiting the proscribed set to just these three
values. It¹s easier to document and implement.
On 12/20/07 11:34 AM, "dormando" <[EMAIL PROTECTED]> wrote:
> Apologies if this doesn't paste right:
>
> for (s = e = command; ntokens < max_tokens - 1; ++e) {
> if (*e == ' ') {
> if (s != e) {
> tokens[ntokens].value = s;
> tokens[ntokens].length = e - s;
> ntokens++;
> *e = '\0';
> }
> s = e + 1;
> }
> else if (*e == '\0') {
> if (s != e) {
> tokens[ntokens].value = s;
> tokens[ntokens].length = e - s;
> ntokens++;
> }
>
> break; /* string end */
> }
> }
>
> Looks like a ... space ... to me :)
>
> -Dormando
>
> Aaron Stone wrote:
>> > Looks like a space, or is actually ASCII character 32?
>> >
>> > On Thu, Dec 20, 2007, dormando <[EMAIL PROTECTED]> said:
>> >
>>> >> Any independent byte (... octet) that looks like a space will be treated
>>> >> as a command token separator in the text protocol. In the binary
>>> >> protocol it's just a length.
>>> >>
>>> >> So if you have a utf8 character that's a valid non-space high byte for
>>> >> the first byte, but the second byte is a space, it'd break. I'm not even
>>> >> sure if that happens though.
>>> >>
>>> >> We're trying not to promote people get into situations where their keys
>>> >> will work with just one protocol or another, but we certainly can't stop
>>> >> people...
>>> >>
>>> >> -Dormando
>>> >>
>>> >> Kieran Benton wrote:
>>>> >>> No I don't think so :)
>>>> >>>
>>>> >>> But it is very convenient to just have to not worry about falling foul
>>>> >>> of not supported characters in keys. Its obviously an easy matter if
you
>>>> >>> are building a site that is for use with memcached from the start, but
>>>> >>> if you are moving to memcached from another cache system (as I am) then
>>>> >>> it is a bit of a worry if delimiters you have previously been using
>>>> >>> might now be treated as erroneous.
>>>> >>>
>>>> >>> Are we saying that as long as you use UTF-8 for the key, and that it is
>>>> >>> not longer that 250 bytes, then all is fine with both text and binary
>>>> >>> protocols? If so then I think we should update the docs to say so and
be
>>>> >>> happy :)
>>>> >>>
>>>> >>> - Kieran
>>>> >>>
>>>> >>> -----Original Message-----
>>>> >>> From: [EMAIL PROTECTED]
>>>> >>> [mailto:[EMAIL PROTECTED] On Behalf Of Dustin Sallings
>>>> >>> Sent: 20 December 2007 17:58
>>>> >>> To: a.
>>>> >>> Cc: [email protected]
>>>> >>> Subject: Re: What is a valid key?
>>>> >>>
>>>> >>>
>>>> >>> On Dec 20, 2007, at 8:57, a. wrote:
>>>> >>>
>>>>> >>>> I haven't seen the server from inside (I only wrote a client), so
>>>>> >>>> maybe it's anoob question, but
>>>>> >>>>
>>>>> >>>> why do we have to treat the key as a "string"? Cannot be just
>>>>> >>>> treated as an array of bytes (whihc cannot contain some values
>>>>> >>>> listed earlier)? So we do not have to care about codepages and
>>>>> >>>> encodings and such?
>>>> >>>
>>>> >>> You could do that in the server using the binary protocol, but
>>>> >>> the
>>>> >>> text protocol wouldn't be able to deal with it. It'd be good to
>>>> >>> remain limited to the lowest common denominator.
>>>> >>>
>>>> >>> I don't think anyone *really* cares about being able to use a
>>>> >>> jpeg as
>>>> >>> a key.
>>>> >>>
>>> >>
>> >
>
