✨ Support LITERAL+ and LITERAL- non-synchronizing literals (RFC7888)#649
Merged
✨ Support LITERAL+ and LITERAL- non-synchronizing literals (RFC7888)#649
LITERAL+ and LITERAL- non-synchronizing literals (RFC7888)#649Conversation
This tests literal sending a lot more thoroughly. Most importantly, this tests both continuation rejection and continuation request. Added `literal_acceptor` proc to FakeServer, which returns if server accepts specific literal continuation, and can be varied per test.
This is internal only, for now. It is only used by `Literal` and `Literal8`, and only when `non_synchronizing` is _explicitly_ set to `true` or `false`. `CommandData` only has a single `#data` attr, so this updates `Literal` to no longer inherit from `CommandData`. `non_synchronizing` is optional. The intent is to make it tri-state: * `true` -> force non-synchronizing `LITERAL+`/`LITERAL-` behavior * `false` -> force normal synchronizing literal behavior * `nil` -> dynamic behavior, based on capabilities and literal size The `nil` behavior will be implemented in a separate commit.
I thought rdoc had fixed their endless method definition bugs with the upgrade to using prism?
This also adds a new config attribute: `max_non_synchronizing_literal`. By default, it is set rather conservatively to 16 KiB. But servers are much more likely to support `LITERAL-` than `LITERAL+`, so the practical limit will be 4096.
nevans
added
enhancement
This was referenced Apr 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Non-synchronizing literals avoid the latency of waiting for the server to allow continuation. Non-synchronizing literals are only sent when the server's capabilities have been already been cached and include either
LITERAL+[RFC7888],LITERAL-[RFC7888], orIMAP4rev2[RFC9051].However, if a client sends a non-synchronizing literal that is too large for the server, the server may need to close the connection. Because
LITERAL+does not directly indicate the server's limits, it's best to avoid sending very large non-synchronized literals. This also addsConfig#max_non_synchronizing_literal: the maximum bytesize for non-synchronizing literals. To disable non-synchronizing literals, set the value to-1.For
LITERAL+,config.max_non_synchronizing_literalis the only limit on whether a literal value is sent as a non-synchronizing literal. ForLITERAL-andIMAP4rev2, non-synchronizing literals must also be smaller than4096bytes.By default,
config.max_non_synchronizing_literalis set to 16 KiB. But servers are much more likely to supportLITERAL-thanLITERAL+, so the practical limit will be 4096.