Shovel doesn't support vhost in AMQP 1.0

[twonky4]

Describe the bug

The Shovel plugin does not support specifying a vhost when using the AMQP 1.0 protocol. Attempting to connect with a URI that includes a vhost (e.g., amqp://my_host:9876/vhost) results in the following error:

path_segment_not_supported

Reproduction steps

1. Configure the Shovel plugin to use AMQP 1.0.
2. Attempt to connect using a URI with a vhost:

   amqp://my_host:9876/vhost
   
3. Observe the error message: path_segment_not_supported.

Expected behavior

It should be possible to specify a vhost in the connection URI.

Additional context

Looking at the source code [here](https://github.com/rabbitmq/rabbitmq-server/blob/main/deps/amqp10_client/src/amqp10_client.erl#L418), it seems the path can only be empty or a single /, which suggests that vhosts are not supported in AMQP 1.0 connections.

Questions

• Is there an alternative way to specify a vhost when using AMQP 1.0 with RabbitMQ?
• If not, would it be possible to add support for vhosts in AMQP 1.0?

Environment

• RabbitMQ version: 3.13.2 (but source is the same as in 4.0.7)
• Erlang version: 26.2.5.9
• OS: Docker image rabbitmq:3.13.2-management

[michaelklishin]

From the docs:

AMQP 1.0 URIs implement as subset of what is described in the AMQP URI reference.
There is no virtual host concept in AMQP 1.0, so URI path segments are not supported

This is nothing new and has been the case for as long as AMQP 1.0 Erlang client existed.

Just like MQTT, AMQP 1.0 support before 4.0 used a convention to extract the virtual host from the username.

[michaelklishin]

This very same limitation is documented in the server AMQP 1.0 support guide.

[michaelklishin]

@twonky4 questions belong to discussions, not issues.

RabbitMQ 3.13 is out of community support.

[michaelklishin]

amqp10_client:open_connection/1 uses the hostname field with a vhost:{value} convention.

AMQP 1.0 shovels (rabbit_amqp10_shovel:connect/7) take the configuration value from the URI parsed in amqp10_client:parse_uri/1, which based on the standard URI parser, uri_string:parse/1, and sets the hostname to the hostname portion of the URI.

hostname in the AMQP 1.0 client is not the same thing as address. Supporting hostname has a URI parameter won't be difficult but it will be really confusing (as much of AMQP 1.0 terminology is at first, since it tries to be very generic).

This has been the case since AMQP 1.0 support in shovels was introduced around 2020.

[michaelklishin]

@ansd @kjnilsson we could add support for one more query parameter to amqp10_client:parse_uri/1, named vhost and pass it on to hostname internally using the vhost:{value} convention

[michaelklishin]

A quick look at the code suggests that the hostname query parameter should work without any changes, it just looks really weird. To connect to a virtual host named abc, set it to vhost:abc.

[lukebakken]

@twonky4 - so, use this URI:

amqp://my_host:9876?hostname=vhost:YOUR_VHOST_NAME

Please report back!

[kjnilsson]

@ansd @kjnilsson we could add support for one more query parameter to amqp10_client:parse_uri/1, named vhost and pass it on to hostname internally using the vhost:{value} convention

I think that would be a little strange as there is no vhost in the AMQP spec and this client is meant to be a generic AMQP client, not a RabbitMQ specific client.

[michaelklishin]

@kjnilsson well, we don't have a different client to use within RabbitMQ. Passing in the virtual host is optional, if you don't pass anything in, nothing will change.

[twonky4]

@twonky4 - so, use this URI:

amqp://my_host:9876?hostname=vhost:YOUR_VHOST_NAME

Please report back!

Like this it's working 👍

[michaelklishin]

Two different options are proposed in #13661.

[twonky4]

Maybe the example URIs should be enhanced.