61f5150358
RFC 2046[1] is somewhat ambiguous on whether or not it's valid to omit the preceding CRLF for the first boundary. The prose on page 19 suggests that it is not: > The boundary delimiter MUST occur at the beginning of a line, i.e., > following a CRLF, and the initial CRLF is considered to be attached > to the boundary delimiter line rather than part of the preceding > part. The boundary may be followed by zero or more characters of > linear whitespace. It is then terminated by either another CRLF and > the header fields for the next part, or by two CRLFs, in which case > there are no header fields for the next part. If no Content-Type > field is present it is assumed to be "message/rfc822" in a > "multipart/digest" and "text/plain" otherwise. > > NOTE: The CRLF preceding the boundary delimiter line is conceptually > attached to the boundary so that it is possible to have a part that > does not end with a CRLF (line break). Body parts that must be > considered to end with line breaks, therefore, must have two CRLFs > preceding the boundary delimiter line, the first of which is part of > the preceding body part, and the second of which is part of the > encapsulation boundary. But the BNF on page 22 suggests that it is, as long as there is no preamble: > dash-boundary := "--" boundary > ; boundary taken from the value of > ; boundary parameter of the > ; Content-Type field. > > multipart-body := [preamble CRLF] > dash-boundary transport-padding CRLF > body-part *encapsulation > close-delimiter transport-padding > [CRLF epilogue] Dendrite currently generates multipart responses without a preceding CRLF for the first boundary[2], which were rejected by the previous ruma parsing logic. [1]: https://datatracker.ietf.org/doc/html/rfc2046 [2]: https://github.com/matrix-org/dendrite/issues/3414
Ruma – Your home in Matrix.
A set of Rust crates (libraries) for interacting with the Matrix chat network.
website • chat • documentation (unstable)
Getting started
If you want to build a Matrix client or bot, have a look at matrix-rust-sdk. It builds on Ruma and includes handling of state storage, end-to-end encryption and many other useful things.
For homeservers, bridges and harder-to-categorize software that works with
Matrix, you're at the right place. To get started, add ruma to your
dependencies:
# crates.io release
ruma = { version = "0.10.0", features = ["..."] }
# git dependency
ruma = { git = "https://github.com/ruma/ruma", branch = "main", features = ["..."] }
ruma re-exports all of the other crates, so you don't have to worry about
them as a user. Check out the documentation on docs.rs (or on
docs.ruma.dev if you use use the git dependency).
You can also find a small number of examples in our dedicated examples repository.
Status
Ruma 0.10.0 supports all events and REST endpoints of Matrix 1.10.
Various changes from in-progress or finished MSCs are also implemented, gated
behind the unstable-mscXXXX (where XXXX is the MSC number) Cargo features.
A few less formalized things are gated behind the unstable-unspecified Cargo
feature.
Contributing
See CONTRIBUTING.md.
Minimum Rust version
Ruma currently requires Rust 1.75. In general, we will never require beta or nightly for crates.io releases of our crates, and we will try to avoid releasing crates that depend on features that were only just stabilized.
ruma-signatures is an exception: It uses cryptographic libraries that often
use relatively new features and that we don't want to use outdated versions of.
It is guaranteed to work with whatever is the latest stable version though.