support of "amqp" and "amqps" URI scheme about amqprs

[jacobmiller22]

Hi gftea, is this still available to implement? If so, were you thinking an additional function within OpenConnectionArguments such as from_uri(uri: &str) -> Self or changing the new function to only accepting a uri str? Additionally, given 2nd point of the design philosophy, are you against using something like rust-url (crate is url) to help with the implementation?

[gftea]

Hi,

Yes, it is available. I have not yet started working on this. Would you like to work on this?

Because not all arguments in OpenConnectionArguments can be expressed in URI spec, such as connection_name and heartbeat, etc, I think we need to consider URI as a combined aguments as part of OpenConnectionArguments

1. To distinguish URI argument and non URI arguments, we may need to have new API like below
   pub fn new(host: &str, port: &str, username: &str, password: &str) -> Self

2. change uri method's implementation to accept URI spec, instead of supporting only ip_addr:port

3. as your suggestion, support something like from_uri(uri: &str) -> Self by implementing trait From or TryFrom, but because user may give incorrect URI, so I think we should implement TryFrom.

The client library only deal with amqp/amqps, does not need generic URL handling, so I think prefer to impelemnt our own parsing, and it should not be too difficult to implement.

[gftea]

I am a bit naive at first thinking, it looks dealing with URL characters are not a trival task. maybe, as you suggest, we can use rust-url crate

[jacobmiller22]

Hi @gftea, after spending some time on it, I agree its not super trivial. I do have an implementation that correctly parses all of the edge cases listed in the amqp uri spec however, the implementation does not url decode nor am I confident that it will successfully fail if given completely wrong uri's or even more edge cases pertaining to things like query parameters, which I believe are used to control things like the heartbeat.

I do have question about the uri() function in general. What is it's purpose? Additionally, the uri field in struct OpenConnectionArguments currently only pertains to the host and port where the URI spec (RFC 3986) can be used to (almost if not completely) define the values in struct OpenConnectionArguments. Like the new function arguments you mentioned before, shouldn't the struct also change to be as verbose as possible and contain a separate host and port field and we can keep the uri field to store the user provided uri str. If the point of uri() is to change all fields in the struct to conform to the URI spec, why support this when the user can simply call from_uri or new and receive the same result but as a new object? Is the cost of allocating a new OpenConnectionArguments too expensive considering that users aren't likely to open hundreds to hundreds of thousands OpenConnectionArguments in any single producer/consumer?

TLDR;

• I have an implementation, but I think its too flawed to handle URIs that are "too incorrect", so I will switch to the rust-url crate. There is also the uriparse crate, which seems to be much less mature than rust-url but is ~22% lighter in total package size.
• uri() function changes the OpenConnectionArguments object it is called on in such a significant way that it seems viable to rely on a from_uri(uri: &str) or the new(...args) function.

[gftea]

Hi,

You have a good point about uri(), I agree we should deprecate it, and update the OpenConnectionArguments to have separate fields for host and port. Also we need to add new chainable APIs, host() and port().

I take a quick look both rust-url and uriparse, I would prefer rust-url which is more reliable, good maintainence, and has been used in servo browser engine also.

I would prefer to consider support of URL spec as optional feature, disabled by default. User can choose to enable.

[jacobmiller22]

Hi gftea, I will continue working on the feature with these guidelines! Thank you for your additional clarification.

[jacobmiller22]

Hi @gftea,

I have two different implementations ready for review. The first implementation uses the crate url (aka rust-url). I found that this crate is specific to the URL Standard, and NOT the URI Standard outlined in RFC3986. The Rabbit MQ very closely adheres to RFC3986 (based on its many references to the document) and as a result, the rust-url implementation fails to parse some urls that are said to be correct on the Rabbit MQ uri spec. I created a second implementation using uriparse to test its behavior, it successfully handles the cases mentioned prior.

The cases where the rust-url fails I found to be mostly from the result of the uri having a zero-length host, which is reasonable to assume would be incorrect, however the RabbitMQ uri spec states it is correct.

Which implementation would you prefer?

[gftea]

Good findings! I am OK to go with uriparse solution. Thanks!