What is a valid key?
aaron at serendipity.cx
Thu Dec 20 17:22:33 UTC 2007
Just thinking about how I would document this, and I realized that IETF
documents switched to talking about "octets" long ago. When an RFC says
"characters" it almost always means orthographic characters in some
encoding that may not map 1-1 from characters - octets.
Proposal for current docs =~ s/bytes/octets/g
On Thu, 2007-12-20 at 08:53 -0800, Dustin Sallings wrote:
> Understood. The same problem you mentioned (inconsistent encoding
> by not specifying a charset) applies to the key as well.
> The problem that prompted this question, though is a bug where I
> assume the length of the string is the same as the number of bytes
> that will be in it on the wire. I'd always assumed keys to be ascii,
> so that's true for all my use cases, but it's not true in general.
> I asked this question to know whether to consider multibyte
> characters an error or a valid use case. Sounds like it's valid, so
> I'll make it work.
> Dustin Sallings (mobile)
> On Dec 20, 2007, at 8:42, "Rakesh Rajan" <rakeshxp at gmail.com> wrote:
> > Dustin, just to clarify the bug report that I emailed you, the
> > problem was with the "value" and not the "key".
> > Since you bought up the key issue with UTF8, I think that it is
> > acceptable to force users to use ASCII as key, but allow values to
> > be UTF8.
> > -Rakesh
> > On Dec 20, 2007 9:15 AM, Steven Grimm <sgrimm at facebook.com> wrote:
> > On Dec 19, 2007, at 7:43 PM, Dustin Sallings wrote:
> > >> For the binary protocol I think none of this should
> > matter at all.
> > >> A key has a key length, so the question of valid
> > characters should
> > >> not be relevant.
> > >
> > > That's true, but it'd be really nice to not have
> > different rules
> > > based on protocol.
> > In particular, I think it's unacceptable to be able to set a
> > key/value
> > pair with the binary protocol that you can't retrieve with
> > the text
> > protocol.
> > -Steve
More information about the memcached