A SET command
What a client puts on the socket: an array of bulk strings, length prefixed
*3\r\n$3\r\nSET\r\n$5\r\nmykey\r\n$7\r\nmyvalue\r\n
Paste a RESP capture and get the decoded structure with byte offsets. Both protocol versions are supported, and error replies are explained rather than merely displayed. Escaped \\r\\n from a log or a blog post is accepted as well as real CRLF.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Decode. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
What a client puts on the socket: an array of bulk strings, length prefixed
*3\r\n$3\r\nSET\r\n$5\r\nmykey\r\n$7\r\nmyvalue\r\n
An error reply decoded and explained, rather than merely displayed
-WRONGTYPE Operation against a key holding the wrong kind of value\r\n
A bulk string whose length prefix disagrees with the bytes that follow, located to the byte
*2\r\n$3\r\nfoo\r\n$10\r\nshort\r\n
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
It counts BYTES. A value holding `é` is `$2` and one holding an emoji is `$4`. A decoder using string length works until the first non-ASCII value, then desynchronises the whole stream.
Instead:Encode to UTF-8 first and count the bytes.
RESP terminates every part with CRLF. A capture that lost its CR will decode in a lenient parser and be rejected by a real client, so the lenient parser hides the actual bug.
Instead:Treat a bare LF as an error and report where it is, which is what this tool does.
There is nothing to escape. Bulk strings are length prefixed, so any byte is legal inside them including CR, LF and NUL.
Instead:Send the bytes as they are and set the length correctly.
The protocol is deliberately trivial to parse: every part is either terminated by CRLF or prefixed with its length. That simplicity is why a decoder can be exact, and why the interesting failures are all about bytes rather than grammar.
A leading + is a simple string, - an error, : an integer, $ a bulk string with a byte-length prefix, and * an array with an element count. That is the entire protocol. $-1 is a null bulk string and *-1 a null array, which are distinct from an empty string and an empty array and mean the key was absent.
Redis 6 added _ null, # boolean, , double, ( big number, ! blob error, = verbatim string, % map, ~ set, > push and | attribute. A connection speaks RESP2 until the client sends HELLO 3, because changing reply shapes underneath an existing client would break it. The practical difference is that a map arrives as a real map rather than a flat array the client has to pair up.
This is the single most common decoder bug. $5 means five bytes, not five characters, so a bulk string holding é is $2 and one holding an emoji is $4. Any implementation that used a string length instead works perfectly until the first non-ASCII value and then desynchronises the whole stream.
Because it is length-prefixed, there is nothing to escape. A value containing carriage returns, newlines or null bytes is transmitted literally. This is also why clients never use the inline command form, which is whitespace-delimited and cannot carry such a value.
It decodes bytes and does not know which command produced them, so it cannot tell you that an array of three bulk strings was an XRANGE result rather than an LRANGE one. It also cannot tell a RESP2 stream that happens to use no RESP3 types from a RESP3 connection, because on the wire they are identical until one appears.