What is a valid key?

[J J]

memcached.c:

if (*e == ' ') {

Aaron Stone wrote:
> Looks like a space, or is actually ASCII character 32?
>
> On Thu, Dec 20, 2007, dormando <dormando at rydia.net> 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: memcached-bounces at lists.danga.com
>>> [mailto:memcached-bounces at lists.danga.com] On Behalf Of Dustin Sallings
>>> Sent: 20 December 2007 17:58
>>> To: a.
>>> Cc: memcached at lists.danga.com
>>> 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.
>>>
>>>       
>>     
>
>