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