You can open a raw TCP connection to Redis with netcat, type `PING` followed by Enter, and get a reply — even though real clients send commands as length-prefixed arrays. What mechanism makes that work, and what are its limitations?

## Two request formats When Redis reads from a client socket it inspects the first byte of the pending request: - If it is `*`, the request is parsed as a **multibulk** (RESP array) request: an element count, then that many `$<len>\r\n<bytes>\r\n` bulk strings. This is what every client library sends. - If it is anything else, the request is treated as an **inline command**: read bytes until CRLF (or LF), then split the resulting line into arguments. That is the whole mechanism. There is no handshake and no mode switch — it is decided per request, by the first byte. ## Why it exists The protocol documentation is explicit: inline commands exist so you can send commands when you do not have a client library at hand — the classic case being `telnet` or `nc` to a server during an incident. Typing `PING` and getting `+PONG` proves the server is alive and reachable through whatever firewall, proxy, or TLS terminator sits between you and it. `INFO`, `CONFIG GET maxmemory`, `DBSIZE`, and a quick `GET key` are all reachable this way. It also means a health check can be as crude as a TCP connect plus writing `PING\r\n` — no Redis library needed in the checker. ## The parsing rules The line is split on whitespace with `sdssplitargs`-style rules, which support simple quoting: `SET greeting "hello world"` works, and `"\x41"` style escapes inside double quotes are honoured to a limited degree. But the model is fundamentally "a shell-ish line", not "a byte-exact argument vector". ## Limitations **Not binary safe.** There is no length prefix, so an argument cannot contain a raw newline, and anything with spaces depends on quoting the server-side splitter must interpret. A JPEG or a protobuf simply cannot be sent this way. This alone disqualifies it for client libraries, since Redis's headline property is binary-safe keys and values. **Bounded length.** The inline buffer is limited (64KB in the implementation). Exceed it and the server replies with a protocol error and closes the connection: `-ERR Protocol error: too big inline request`. Multibulk requests have their own, much larger limits (`proto-max-bulk-len`, default 512MB per bulk). **Error modes are confusing.** Because the format is chosen by the first byte, a client that emits a malformed multibulk request — say, a stray leading byte before `*` — has its data reinterpreted as inline text, producing errors like `Protocol error: unbalanced quotes in request` or `expected '$', got ...`. Debugging a broken client often means recognising that the server fell into the inline path. **No pipelining discipline.** You can type several lines, and each is a separate inline request, but there is no framing to help a tool match replies to requests beyond ordering. **Interactive tools mislead.** `redis-cli` looks like it is typing inline commands, but it is a real client and sends multibulk. Do not cite `redis-cli` as evidence about inline behaviour. ## When you will actually meet it 1. **Liveness checks** — a load balancer or a shell one-liner writing `PING\r\n`. 2. **Firewall/TLS path debugging** — proving the port is reachable and speaks Redis before blaming the application. (Note: against a TLS-enabled port you need `openssl s_client` rather than plain `nc`.) 3. **Reading protocol errors in logs** — recognising that `too big inline request` almost always means something wrote non-RESP bytes to the port: an HTTP request from a misconfigured probe, a port scanner, or an application pointing an HTTP client at 6379. That last case is worth knowing as a security signal too, since it is how cross-protocol probing of an exposed Redis shows up. ## The one-sentence takeaway Inline commands are a convenience path for humans with a raw socket; every real client sends multibulk arrays, because only length-prefixed bulk strings can carry arbitrary bytes.