### Redis Set Reply Example Source: https://github.com/redis/redis-specifications/blob/master/protocol/RESP3.md Illustrates the structure of a Redis Set reply, starting with '~' followed by the number of elements and then each element prefixed with '+'. It highlights the difference from Array replies and suggests client-side handling. ```redis-protocol ~5 +orange +apple #t :100 :999 ``` -------------------------------- ### EXISTS Inline Command Example Source: https://github.com/redis/redis-specifications/blob/master/protocol/RESP2.md Provides another example of an inline command, showing a client checking for a key's existence and the server returning an Integer reply. ```redis-protocol C: EXISTS somekey S: :0 ``` -------------------------------- ### Redis Attribute Reply Example with MGET Source: https://github.com/redis/redis-specifications/blob/master/protocol/RESP3.md Demonstrates how Attribute replies are used to augment main replies, using an MGET command as an example. It shows auxiliary data like key popularity associated with the main array reply. ```redis-protocol |1 +key-popularity %2 $1 a ,0.1923 $1 b ,0.0012 *2 :2039123 :9543892 ``` -------------------------------- ### PING Inline Command Example Source: https://github.com/redis/redis-specifications/blob/master/protocol/RESP2.md Demonstrates the use of inline commands for interactive sessions, showing a client sending PING and the server responding with PONG. ```redis-protocol C: PING S: +PONG ``` -------------------------------- ### LLEN Command Interaction Example Source: https://github.com/redis/redis-specifications/blob/master/protocol/RESP2.md Shows a typical client-server interaction where a client sends the LLEN command and the server replies with an Integer reply. ```redis-protocol C: *2\r\nC: $4\r\nC: LLEN\r\nC: $6\r\nC: mylist\r\n S: :48293\r\n ``` -------------------------------- ### RESP3 Streamed String (Chunked Encoding) Example Source: https://github.com/redis/redis-specifications/blob/master/protocol/RESP3.md Demonstrates the RESP3 chunked encoding for streamed strings, starting with '$?' to indicate unknown length, followed by data chunks prefixed with ';', and ending with ';0'. ```RESP $? ;4 Hell ;5 o wor ;1 d ;0 ``` -------------------------------- ### Redis Attribute Reply Example within an Array Source: https://github.com/redis/redis-specifications/blob/master/protocol/RESP3.md Shows an example where an Attribute reply is embedded within a main Array reply, providing auxiliary information for a specific element of the array. ```redis-protocol *3 :1 :2 |1 +ttl :3600 :3 ``` -------------------------------- ### Redis RESP3 Push Data Example Source: https://github.com/redis/redis-specifications/blob/master/protocol/RESP3.md Illustrates the RESP3 push data format for a Pub/Sub message. It shows the structure with the '>' prefix for arrays and the '+message' type identifier, followed by channel and message content. ```APIDOC >3 +message +somechannel +this is the message ``` -------------------------------- ### RESP Array Encoding Example Source: https://github.com/redis/redis-specifications/blob/master/protocol/RESP2.md Demonstrates how an array of two arrays is encoded in RESP, showcasing nested array structures and different data types within them. ```redis-protocol *2\r\n*3\r\n:1\r\n:2\r\n:3\r\n*2\r\n+Foo\r\n-Bar\r\n ``` -------------------------------- ### RESP Array with Null Element Example Source: https://github.com/redis/redis-specifications/blob/master/protocol/RESP2.md Illustrates an Array reply containing a Null element, typically used to signify missing values, such as with the SORT command's GET option. ```redis-protocol *3\r\n$3\r\nfoo\r\n$-1\r\n$3\r\nbar\r\n ``` -------------------------------- ### RESP Errors Source: https://github.com/redis/redis-specifications/blob/master/protocol/RESP2.md Error replies are similar to Simple Strings but start with a '-' character. Clients should treat these as exceptions with the string content as the error message. ```APIDOC Error Format: '-\r\n' Examples: '-ERR unknown command 'foobar'\r\n' '-WRONGTYPE Operation against a key holding the wrong kind of value\r\n' Clients should raise an exception upon receiving an Error Reply. ``` -------------------------------- ### RESP Simple Strings Source: https://github.com/redis/redis-specifications/blob/master/protocol/RESP2.md Simple Strings are used for non-binary safe strings with minimal overhead. They start with '+' and are terminated by CRLF. ```APIDOC Simple String Format: '+ ' Example: '+OK\r\n' Client libraries should return the string content excluding the '+' and '\r\n'. ``` -------------------------------- ### Redis HELLO Command and Connection Handshake Source: https://github.com/redis/redis-specifications/blob/master/protocol/RESP3.md Details the HELLO command used for initiating connections in RESP3. It allows for protocol version negotiation and authentication, providing server information upon successful handshake. ```APIDOC HELLO [AUTH ] Description: Initiates a connection with the Redis server using the specified protocol version and optionally authenticates the client. Parameters: - protocol-version: The desired RESP protocol version (e.g., 3). - AUTH : Optional authentication credentials. Use 'default' as username for password-protected servers without ACLs. Success Reply: A map containing server information, including: - server: Software name (e.g., "redis"). - version: Server version. - proto: Maximum supported RESP protocol version. - id: Client connection ID. - mode: Connection mode (e.g., "standalone", "cluster"). - role: Server role (e.g., "master", "replica"). - modules: List of loaded modules. Error Replies: - -NOPROTO: If the specified protocol version is not supported. - -ERR unknown command 'HELLO': If the server only supports RESP2. - -ERR invalid password: If authentication credentials are incorrect. Example: Client: HELLO 3 AUTH default mypassword Server: *6+server+redis+version+7.0.0+proto+3+id+1+mode+standalone+role+master ``` -------------------------------- ### Redis URI Scheme Details Source: https://github.com/redis/redis-specifications/blob/master/uri/redis.txt Details the structure and recommended usage of the redis: URI scheme, including specific fields and their implications. ```APIDOC Redis URI Scheme: Structure and Fields: - fragment: No known meaning or usage; omitting is advised. - userinfo: - username: Currently unused by Redis authentication, but may be used in the future. Producers should leave blank; consumers should be aware of potential future non-blank values. - password: Use with care, especially when a 'password' key is also present in the 'query' field, as semantics are undefined. - query: - Used for client-library-specific connection parameters; not portable. - Avoid using without knowledge of the specific client library. - Key 'db': If present alongside a 'db-number' in the path, semantics are undefined. - Key 'password': If present alongside a password in 'userinfo', semantics are undefined. - path: - Values conforming to 'db-number' grammar are used for Redis database numbers. - Non-conforming values have no known meaning or usage and should be avoided. Security Considerations: - General: Use with care. Security for RESP itself is beyond this document's scope. - Credentials: Avoid leaking credentials (in URIs) in logs or error messages. - Exposure: Do not expose redis: URIs on the internet or to untrusted clients. - Future Authentication: Potential for privilege escalation if username support is added and systems interpret URIs differently. - Passwords: Use strong, long passwords; be prepared to handle long URIs. - Domain Names: Subject to standard DNS security considerations (RFC 4033). - Protocol (RESP): Unencrypted, lacks confidentiality/integrity. RFC 3552 (BCP 72), Section 4.1.1 applies. Use additional security measures. - TLS (rediss:): - 'rediss:' scheme designates RESP over TLS. - Provides peer/host authentication, confidentiality, and data integrity. - Can potentially use client certificates for authentication instead of 'AUTH'. - Denial of Service: URIs may indirectly facilitate DoS attacks by simplifying communication of target server details. ``` -------------------------------- ### RESP3 Protocol Design Principles and Improvements Source: https://github.com/redis/redis-specifications/blob/master/protocol/RESP3.md This documentation block explains the design principles of the RESP3 protocol, emphasizing its human readability, efficiency, and simplicity. It also details the limitations of RESP2 and how RESP3 addresses them, including enhanced semantic power, support for new data types, and improved features. ```APIDOC RESP3 Protocol Design: Key Principles: - Human Readable: Simple to observe and debug. - Efficient: Comparable to binary protocols, often more compact for short messages. - Simple Design: Short and easy to understand specifications and implementations. Improvements over RESP2: - Enhanced Semantic Power: Clients can implicitly understand data type conversions, reducing command-specific logic. - New Data Types: Native support for floating-point numbers and boolean values. - Null Value Handling: Unified representation for null values, removing ambiguity. - Binary Safe Errors: Prevents newline injection issues in error messages. - Generic Push Mode: Supports out-of-band data and streaming of large strings with unknown lengths. - Attributes: Augments replies with additional metadata. ``` -------------------------------- ### Redis URI Scheme Syntax and Semantics Source: https://github.com/redis/redis-specifications/blob/master/uri/redis.txt Defines the syntax and semantics for the 'redis://' URI scheme, used by Redis client libraries. It specifies how to represent connection details like host, port, username, password, and database number within a URI. ```APIDOC Scheme name: redis Scheme syntax: Example: redis://user:secret@localhost:6379/0?foo=bar&qux=baz This scheme uses a profile of the RFC 3986 generic URI syntax. All URI fields after the scheme are optional. The "userinfo" field uses the traditional "user:password" format. Expressed using RFC 5234 ABNF, the "path" grammar production from RFC 3986 is overridden as follows: path = [ path-slashed ] ; path is optional path-slashed = "/" [ db-number ] ; exactly zero or one path segments db-number = "0" / nz-num ; nonnegative decimal integer with no leading zeros nz-num = NZDIGIT *DIGIT ; positive decimal integer with no leading zeros NZDIGIT = %x31-39 ; the digits 1-9 Scheme semantics: This scheme is used to designate Redis databases that may be accessed via RESP. URIs using this scheme are dereferenced by connecting to the designated Redis server via RESP and then issuing corresponding AUTH and/or SELECT commands if a password and/or database number (respectively) were specified. If absent, the default value of the "host" URI field is: "localhost" (or equivalent) If absent, the default value of the "port" URI field is: 6379 The database number to use for the Redis SELECT command comes from either the "db-number" portion of the URI (described in the previous section) or the value from the key-value pair from the "query" URI field with the key "db". If neither of these are present, the default database number is 0. The password to use for the Redis AUTH command comes from either the password portion of the "userinfo" URI field or the value from the key-value pair from the "query" URI field with the key "password". If neither of these are present, the client ought not to issue an initial AUTH command. If a future version of Redis adds support for multi-user authentication (e.g. if RCP1 gets accepted), it's suggested that the username to use when authenticating be obtained from the username portion of the "userinfo" URI field. The semantics of "query" URI field key-value pairs other than those previously mentioned are implementation-defined. ``` -------------------------------- ### Redis Specification TODOs Source: https://github.com/redis/redis-specifications/blob/master/protocol/RESP3.md This section lists outstanding items for documentation within the Redis specifications. It highlights areas that require further detail and explanation for a complete understanding of the protocol. ```APIDOC TODOs in Redis Specification: - Document the optional "inline" protocol. - Document pipelining. ``` -------------------------------- ### RESP3 Data Types Overview Source: https://github.com/redis/redis-specifications/blob/master/protocol/RESP3.md This section details the data types supported by the RESP3 protocol, categorizing them into those equivalent to RESP v2 and new types introduced in RESP3. ```APIDOC RESP3 Data Types: Types equivalent to RESP version 2: * Array: an ordered collection of N other types * Blob string: binary safe strings * Simple string: a space efficient non binary safe string * Simple error: a space efficient non binary safe error code and message * Number: an integer in the signed 64 bit range Types introduced by RESP3: * Null: a single null value replacing RESP v2 `*-1` and `$-1` null values. * Double: a floating point number * Boolean: true or false * Blob error: binary safe error code and message. * Verbatim string: a binary safe string that should be displayed to humans without any escaping or filtering. For instance the output of `LATENCY DOCTOR` in Redis. * Map: an unordered collection of key-value pairs. Keys and values can be any other RESP3 type. * Set: an unordered collection of N other types. * Attribute: Like the Map type, but the client should keep reading the reply ignoring the attribute type, and return it to the client as additional information. * Push: Out of band data. The format is like the Array type, but the client should just check the first string element, stating the type of the out of band data, and a callback if there is one registered for this specific type of push information. Push types are not related to replies, since they are information that the server may push at any time in the connection, so the client should keep reading if it is reading the reply of a command. * Hello: Like the Map type, but is sent only when the connection between the client and the server is established, in order to welcome the client with different information like the name of the server, its version, and so forth. * Big number: a large number non representable by the Number type ``` -------------------------------- ### RESP2 String Format Source: https://github.com/redis/redis-specifications/blob/master/protocol/RESP3.md Illustrates the standard RESP2 string format with a prefixed length, followed by the data and a carriage return/line feed. ```RESP $1234 .... 1234 bytes of data here ... ``` -------------------------------- ### RESP3 Protocol Versions History Source: https://github.com/redis/redis-specifications/blob/master/protocol/RESP3.md This section details the version history of the RESP3 protocol, outlining the dates and key changes introduced in each version. It highlights the evolution of the protocol from its initial draft to more recent updates. ```APIDOC RESP3 Protocol Versions: * 1.0, 2 May 2018: Initial draft for community feedback. * 1.1, 5 Nov 2018: CRLF as terminators, improved 'hello reply' section. * 1.2, 5 Nov 2018: Better specification of existing features based on developer feedback. * 1.3, 11 Mar 2019: Support for streamed strings and aggregated types. * 1.4, 8 Dec 2022: Normalization of NaN to 'nan', forbidding '-nan' (Effective since Redis 7.2). * 1.5, 5 Jan 2023: Map type marked as unordered (Effective since Redis 6.2). * 1.6, 9 March 2023: Allow doubles in scientific E notation (Effective since Redis 6.0). ``` -------------------------------- ### Redis Command Output Handling (C) Source: https://github.com/redis/redis-specifications/blob/master/protocol/RESP3.md This C code snippet demonstrates conditional logic within the redis-cli to determine if raw output should be used based on the command and its arguments. It checks for commands like 'info', 'latency graph', and 'latency doctor'. ```c output_raw = 0; if (!strcasecmp(command,"info") || ... [snip] ... (argc == 3 && !strcasecmp(command,"latency") && !strcasecmp(argv[1],"graph")) || (argc == 2 && !strcasecmp(command,"latency") && !strcasecmp(argv[1],"doctor"))) { output_raw = 1; } ``` -------------------------------- ### Interleaved Push and Command Replies Source: https://github.com/redis/redis-specifications/blob/master/protocol/RESP3.md Demonstrates how Redis push data can be interleaved with regular command replies. It shows two possible sequences: push data followed by a command reply, and a command reply followed by push data. ```APIDOC >3 +message +somechannel +this is the message $9 Get-Reply ``` ```APIDOC $9 Get-Reply >3 +message +somechannel +this is the message ``` -------------------------------- ### RESP Bulk Length Parsing in C Source: https://github.com/redis/redis-specifications/blob/master/protocol/RESP2.md A C code snippet demonstrating how to parse the length of a RESP Bulk String by iterating through characters until the CR delimiter is found. ```c #include int main(void) { unsigned char *p = "$123\r\n"; int len = 0; p++; while(*p != '\r') { len = (len*10)+(*p - '0'); p++; } /* Now p points at '\r', and the len is in bulk_len. */ printf("%d\n", len); return 0; } ``` -------------------------------- ### RESP3 Protocol Representation Conventions Source: https://github.com/redis/redis-specifications/blob/master/protocol/RESP3.md Illustrates how RESP3 protocol fragments are represented in documentation for clarity. It shows the use of `` for carriage return and line feed, and escaped characters like `` for special bytes. Indentation is used to represent nested data structures. ```APIDOC Example of a RESP3 array with a single string "A": *1 $1 A Nested structure example: *2 *2 :1 :2 #t ``` -------------------------------- ### RESP Bulk String Reply Format Source: https://github.com/redis/redis-specifications/blob/master/protocol/RESP2.md Describes the encoding for bulk strings, used for binary-safe strings up to 512MB. It includes the format for regular bulk strings and the special Null Bulk String representation. ```redis-protocol Bulk Strings: '$\r\n\r\n' Example: "$6\r\nfoobar\r\n" Empty Bulk String: "$0\r\n\r\n" Null Bulk String: "$-1\r\n" ``` -------------------------------- ### RESP3 Data Types Overview Source: https://github.com/redis/redis-specifications/blob/master/protocol/RESP3.md This section describes the RESP3 protocol's handling of Big Numbers, Arrays, and Maps. It explains their general format, encoding rules, and how client libraries should interpret them. ```APIDOC Big Number: Represents numbers outside the range of signed 64-bit integers. Format: '(\r\n' or escaped string. Example: "(3492890328409238509324850943850943825024385\r\n" Notes: Can be positive or negative, no decimal part. Client libraries should use native big number types or strings. Aggregate Data Types: General Format: '\r\n ... numelements other types ...' Array: Aggregate type char: '*' Represents ordered sequences of elements. Example: "*3\r\n:1\r\n:2\r\n:3\r\n" represents an array of three Numbers [1, 2, 3]. Nested Array Example: "*2\r\n*3\r\n:1\r\n$5\r\nhello\r\n:2\r\n#f\r\n" represents [[1,"hello",2],false]. Client libraries should return as native array/list types. Map: Aggregate type char: '%' Represents field-value pairs (dictionaries/hashes). Number of elements must be even (number of pairs). Example: "%2\r\n+first\r\n:1\r\n+second\r\n:2\r\n" represents {"first":1, "second":2}. Fields and values can be any RESP3 type. Client libraries should return as native dictionary/map types. ``` -------------------------------- ### RESP Array Reply Format Source: https://github.com/redis/redis-specifications/blob/master/protocol/RESP2.md Explains how arrays are encoded in RESP, used for commands and multi-element replies. It covers the format for arrays of various types and the special Null Array representation. ```redis-protocol Arrays start with a '*' byte, followed by the number of elements, and terminated by CRLF. Each element is a RESP type. Example (Array of two Bulk Strings): "*2\r\n$3\r\nfoo\r\n$3\r\nbar\r\n" Example (Array of three Integers): "*3\r\n:1\r\n:2\r\n:3\r\n" Empty Array: "*0\r\n" Null Array: "*-1\r\n" ``` -------------------------------- ### RESP Data Types Source: https://github.com/redis/redis-specifications/blob/master/protocol/README.md This section details the various data types supported by the Redis Serialization Protocol (RESP) and their corresponding formatting. It covers simple strings, errors, integers, bulk strings, and arrays, which are fundamental for Redis client-server communication. ```RESP +OK\r\n ``` ```RESP -Error message\r\n ``` ```RESP :1000\r\n ``` ```RESP $6\r\nfoobar\r\n ``` ```RESP *2\r\n$3\r\nfoo\r\n$3\r\nbar\r\n ``` ```RESP *3\r\n:1\r\n:2\r\n:3\r\n ``` ```RESP *2\r\n$3\r\nfoo\r\n*1\r\n$3\r\nbar\r\n ``` ```RESP $-1\r\n ``` -------------------------------- ### RESP Error Reply Format Source: https://github.com/redis/redis-specifications/blob/master/protocol/RESP2.md Explains the structure of error replies in RESP, including generic ERR and specific error prefixes like WRONGTYPE. It discusses how clients can interpret these errors. ```redis-protocol Error replies start with a '-' byte, followed by the error message, and terminated by CRLF. Example: "-ERR wrong number of arguments for 'set' command\r\n" ``` -------------------------------- ### Redis Protocol Specifications Source: https://github.com/redis/redis-specifications/blob/master/protocol/RESP3.md This section details the Redis protocol, focusing on the RESP3 line break and its implications for client implementation. It explains why the line break was not changed to a single character to maintain compatibility and simplify client parsing across RESP versions. ```APIDOC RESP3 Protocol Details: Line Break Handling: - The RESP3 line break was not changed to a single character. - Reason: Changing the line break would require clients to parse replies differently based on RESP version (v2 or v3). - Initial HELLO command uses CRLF even in RESP3 connections. - Parsing code is designed to accept different line breaks based on conditions. - Benefit of single byte saving is outweighed by increased client implementation complexity. - RESP3 is largely a superset of RESP2, minimizing changes needed for existing clients. ``` -------------------------------- ### RESP Data Type Prefixes Source: https://github.com/redis/redis-specifications/blob/master/protocol/RESP2.md RESP uses specific first-byte prefixes to denote different data types. This allows clients to easily parse incoming data from the Redis server. ```APIDOC RESP Data Types: * Simple Strings: '+' * Errors: '-' * Integers: ':' * Bulk Strings: '$' * Arrays: '*' All parts of the protocol are terminated with '\r\n' (CRLF). ``` -------------------------------- ### rediss URI Scheme Specification Source: https://github.com/redis/redis-specifications/blob/master/uri/rediss.txt Defines the syntax and semantics for the 'rediss' URI scheme, used for secure Redis connections over TLS. It mirrors the 'redis' scheme but mandates TLS encryption. ```APIDOC Scheme name: rediss Status: Provisional Scheme syntax: Example: rediss://user:secret@localhost:6379/0?foo=bar&qux=baz Other than the difference in scheme name, the rediss: scheme uses the same syntax as the redis: scheme. Scheme semantics: This scheme is used to designate Redis databases that may be accessed via RESP over TLS (RFC 5246). URIs using this scheme are dereferenced by connecting to the designated Redis server via RESP over TLS and then issuing corresponding AUTH and/or SELECT commands if a password and/or database number (respectively) were specified. Other than the usage of TLS, the rediss: scheme has the same semantics as the redis: scheme. Reserved URI fields: The following field names are reserved within the URI context. These are expressed using RGC 5234 ABNF, and are reserved as follows: protocol = DIGIT / "." ; this is optional, corresponding to the version of ; the RESP protocol requested. ; the digits 0-9, and a period Interoperability considerations: Some Redis client libraries (such as ServiceStack.Redis), instead of using the rediss: scheme, use the redis: URI scheme along with a query URI component key-value pair with the key "ssl" that controls the usage of TLS. The key-value pair's values are "true" and "false", which respectively enable or disable TLS. Example: redis://localhost/0?ssl=true Security considerations: In contrast to plain RESP, using RESP over TLS (RFC 5246) as mentioned in "Redis Encryption", along with public key certificates, can provide assurances of peer entity authentication (or merely host authentication if client certificates are not used), confidentiality, and data integrity. ``` -------------------------------- ### Redis RESP3 Simple Types Documentation Source: https://github.com/redis/redis-specifications/blob/master/protocol/RESP3.md This section details the RESP3 protocol's simple data types, which consist of a single typed element. It covers Blob String, Simple String, Simple Error, Number, Null, Double, Boolean, Blob Error, and Verbatim String, including their specific encoding formats and usage. ```APIDOC Blob string: Format: $\r\n\r\n Example: "hello world" -> $11\r\nhello world\r\n Empty string: $0\r\n\r\n Length limit: unsigned 64-bit integer. Simple string: Format: +\r\n Example: "hello world" -> +hello world\r\n Constraints: Cannot contain \r nor \n characters. Simple error: Format: -\r\n Example: "ERR this is the error description" -> -ERR this is the error description\r\n Structure: First word is uppercase error code, followed by error message. Number: Format: :\r\n Example: 1234 -> :1234\r\n Constraints: Signed 64-bit integer range. Larger numbers should use Big Number type. Null: Format: _\r\n Double: Format: ,\r\n Example: 1.23 -> ,1.23\r\n Components: Integral part, optional fractional part, optional exponent part. Special values: "inf", "-inf", "nan". Note: Prior to Redis 7.2, "-nan" was also valid. Boolean: Format: #t\r\n (true) or #f\r\n (false) Blob error: Format: !\r\n\r\n Example: "SYNTAX invalid syntax" -> !21\r\nSYNTAX invalid syntax\r\n Structure: Similar to Blob string, but first word is uppercase error code. Verbatim string: Format: =\r\n:\r\n Example: txt:Some string -> =15\r\ntxt:Some string\r\n Format specifiers: "txt" for plain text, "mkd" for markdown. Usage: Interactive clients may present without quoting. ``` -------------------------------- ### RESP Integer Reply Format Source: https://github.com/redis/redis-specifications/blob/master/protocol/RESP2.md Details the format for integer replies in RESP, which are CRLF-terminated strings prefixed by a ':' byte. It covers their usage for counts, timestamps, and boolean values (0 or 1). ```redis-protocol Integer replies start with a ':' byte, followed by the integer value, and terminated by CRLF. Example: ":1000\r\n" ``` -------------------------------- ### RESP3 Streamed Aggregated Data Types Source: https://github.com/redis/redis-specifications/blob/master/protocol/RESP3.md Demonstrates how RESP3 handles aggregated data types like Arrays, Sets, and Maps when the size is not known in advance. It uses a '?' to indicate an unknown length and a special END type ('.') to terminate the stream. ```redis-protocol Array: *? :1 :2 :3 . Set: ~? +a +b . Map: %? +a :1 +b :2 . ``` -------------------------------- ### RESP3 Streamed String Termination Source: https://github.com/redis/redis-specifications/blob/master/protocol/RESP3.md Shows the specific format used to signal the end of a RESP3 streamed string transfer, which is a zero-length chunk. ```RESP ;0 ``` -------------------------------- ### RESP3 Streamed String Chunk Format Source: https://github.com/redis/redis-specifications/blob/master/protocol/RESP3.md Details the format for individual chunks within a RESP3 streamed string transfer, consisting of a count prefix, the data, and a carriage return/line feed. ```RESP ; ... count bytes of data ... ``` === COMPLETE CONTENT === This response contains all available snippets from this library. No additional content exists. Do not make further requests.