amqp-rs/amq-protocol

AMQP specifications

amq-protocol

Features

• codegen: force code generation (default to pregenerated sources)
• vendored-openssl: use a vendored openssl version instead of the system one (when using openssl backend)
• verbose-errors: enable more verbose errors in the AMQP parser

TLS backends

• native-tls
• openssl
• rustls (default)

Rustls certificates store

• rustls-native-certs (default)
• rustls-webpki-roots-certs

Warning about crypto backends for rustls

A crypto implementation must be enabled in rustls using feature flags. We mimic what rustls does, providing one feature flag per implementation and enabling the same as rustls by default. Available options are:

• rustls--aws_lc_rs (default)
• rustls--ring

amq-protocol's Issues

Is the `types::LongString` really only supposed to contain a valid UTF-8 data?

According to the AMQP-0.9.1 4.2.5.3, "long strings can contain any data".

AMQP strings are variable length and represented by an integer length followed by zero or more octets of data. AMQP defines two native string types:

• Short strings, stored as an 8-bit unsigned integer length followed by zero or more octets of data. Short strings can carry up to 255 octets of UTF-8 data, but may not contain binary zero octets.
• Long strings, stored as a 32-bit unsigned integer length followed by zero or more octets of data. Long strings can contain any data.

Therefore according to the standard, the following fields may contain whichever data some particular authentication method sees fit:

• in protocol::connection::Secure, field challenge: LongString;
• in protocol::connection::SecureOk, field response: LongString.

The existing API makes little sense:

• it provides an opportunity to construct an instance of LongString from a valid UTF-8 string only (impl From<Stiring> for LongString and impl From<&str> for LongString);
• the protocol parser (types::parsing::parse_long_string) uses String::from_utf8_lossy;
• in order to get a string value from a LongString one should use as_bytes(&self) -> &[u8], and then do the std::str gymnastics, making sure the returned bytes are okay to be used as a string.

TL;DR;
Would it hurt much if the LongString would be constructed from anything that is Into<Vec<u8>> ?

-
-impl From<String> for LongString {
-    fn from(s: String) -> Self {
-        Self(s.into_bytes())
-    }
-}
-
-impl From<&str> for LongString {
-    fn from(s: &str) -> Self {
-        s.to_owned().into()
-      }
-}
+ 
+impl<B> From<B> for LongString where B: Into<Vec<u8>> {
+    fn from(bytes: B) -> Self {
+        Self(bytes.into())
+     }
+}

Certificate based authentication

Fedora uses AMQP for its messaging system. It looks like it authenticates via SSL certificates. Does this map to SASLMechanism::External?

impl Error for AMQPError

WASM Compatibility

Hi @Keruspe,
Thank you for this library.

I was wondering if you are interested in making this library WASM compatible.
At the moment it does not compile for wasm due to the openssl dependency.

I already did it here: https://github.com/Gsantomaggio/amq-protocol/tree/amq-protocol-wasm

git clone  https://github.com/Gsantomaggio/amq-protocol/ .
git checkout amq-protocol-wasm
rustup target add wasm32-unknown-unknown
cargo build --target wasm32-unknown-unknown --release

So the idea would be to split the repository in two repos:

• Pure AMQP protocol/types/uri
• TCP part ( that I removed here )

Panic when parse uri

Hello.

Panic this line:
https://github.com/sozu-proxy/amq-protocol/blob/master/uri/src/lib.rs#L110

ver. uri crate 3.1.0.

if set uri string
amqp://127.0.0.1:5672

but not panic if set
amqp://127.0.0.1:5672/%2f

Eq for AMQPUri?

Is there any reason that AMQPUri is only PartialEq at the moment? The whole tree only seems to contain ints, strings and enums at the moment, all of which are exactly comparable.

Feature request: Impl From<_> for AMQPValue

From my experience with laptin, it's pretty common to build headers of (String, AMQPValue) pairs that is sent with message. I found it cumbersome to write AMQPValue::ShortInt(10). Suppose we can implement From<_> traits for common types, that we can simply write 10.into(). That would give us a bit of convenience.

codegen should add Copy where plausible

The codegen for types ends up with Clone types with nothing but Booleans in them. Codegen should keep track if any non-Copy type was used and add it if it can.

Who to get value from a FieldTable

Hi !

Thanks for developing the library ! it's awesome job !
I'm currently taking a look to get headers properties - like x-count on messages.
I cannot achieve it, the FieldTable does not implement BTreeMap ?

Thanks
Marc-Antoine

AMQPType Deserialize impl should be smarter

Right now, trying to deserialize a JSON document into a FieldTable ends up with serde complaining that the enum AMQPType needs annotation. This type should probably manually impl Deserialize so that it can ask the types and just stuff them into the right container.

Parser fails for LongString values containing invalid UTF-8

This seems to be emitted by RabbitMQ's AMQP 1.0 plugin for one.

The RabbitMQ GUI handles this by showing Base64-encoded encodings instead for these properties.