some protocol weirdness

[Brad Fitzpatrick]

Allow me to repaste the documentation.  :-)


Retrieval command:
------------------

The retrieval command looks like this:

get <key>*\r\n

- <key>* means one or more key strings separated by whitespace.

After this command, the client expects zero or more items, each of
which is received as a text line followed by a data block. After all
the items have been transmitted, the server sends the string

"END\r\n"

to indicate the end of response.

Each item sent by the server looks like this:

VALUE <key> <flags> <bytes>\r\n
<data block>\r\n

- <key> is the key for the item being sent

- <flags> is the flags value set by the storage command

- <bytes> is the length of the data block to follow, *not* including
  its delimiting \r\n

- <data block> is the data for this item.

If some of the keys appearing in a retrieval request are not sent back
by the server in the item list this means that the server does not
hold items with such keys (because they were never stored, or stored
but deleted to make space for more items, or expired, or explicitly
deleted by a client).




On Thu, 8 Apr 2004, Antony Dovgal wrote:

> Hi all!
>
> Can somebody explain me why memcached server's response is so weird in this particular case:
> flush_all // <-- flushing the cache
> OK	  // <-- server says 'OK'
> get obj_key // <-- I'm trying to get an item
> END         // <-- server says 'END'
>
> I expected that this item already not exist, thus the server's response should be 'NOT_FOUND'.
> This is expected behaviour or some kind of bug ?
>
> ---
> WBR,
> Antony Dovgal aka tony2001
> tony2001@phpclub.net || antony@dovgal.com
>
>