What is a valid key?

[Aaron Stone]

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.
>> 
> 
> 

--