search

djveremix / redis

Automatically exported from code.google.com/p/redis
0 stars 0 forks source link

Deviation in CRLF-handling in HGET, HMGET #275

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
HGET/HMGET seem to expect more than 1 CRLF, but as they are inline commands 
they should expect only a single one at the end of the string.

How to reproduce:
telnet localhost 6379

hset h1 f1 1
c
:1
hset h1 f2 1
d
:1
hgetall h1
*4
$2
f1
$1
c
$2
f2
$1
d
hget h1 f1

$-1
hmget h1 f1 f2

*2
$1
c
$-1

Notice additional newline after hget/hmget and also the return value, which is 
empty for hget h1 f1, while it should be "c" and only ["c" nil] for hmget h1 f1 
f2, although it should be ["c" "d"].

Interestingly, in redis-cli the behavior is correct, i.e. hget h1 f1 returns 
"c".

The behavior is observed in redis-2.0.0-rc2 on Linux.

Original issue reported on code.google.com by vselo...@gmail.com on 6 Jul 2010 at 11:55

GoogleCodeExporter commented 8 years ago 
The same applies to HEXISTS and HDEL.  So all commands, expecting hash fields 
are effected.

Original comment by vselo...@gmail.com on 6 Jul 2010 at 12:01

GoogleCodeExporter commented 8 years ago 
After some sniffing with tcpdump, I've discovered, that redis-cli sends all 
commands in "generic" multi-bulk format, i.e. as:
*3
$4
hget
$2
h1
$2
f1

That's why it works correctly.  I think, such possibility should be clearly 
stated i the docs.
Still I consider such deviation in H-functions to remain a bug.

Original comment by vselo...@gmail.com on 7 Jul 2010 at 4:30

GoogleCodeExporter commented 8 years ago 
This is caused by support for the old protocol, where the last argument for H* 
commands should be a bulk argument. Obviously, in H* commands more than only 
the last argument may be a bulk argument (such as the key itself, the fields 
and the values). When talking to Redis this way, Redis sees the inline commands 
and suspects only the last argument is a multi bulk. Previously, when the 
inline command had a last bulk argument, but the length was not properly 
specified, it just continued. This was fixed yesterday in issue #146 ( 
http://code.google.com/p/redis/issues/detail?id=146 ), so issuing the same 
commands as you mentioned in your issue report will result in an error.

Original comment by pcnoordh...@gmail.com on 25 Aug 2010 at 2:10