Virtual Hosts and '/'

[Tomas Restrepo <to...@devdeo.com>]

I've been doing a bit of testing on the .NET and java clients, and got a bit
confused about the current behavior around virtual host names and connection
urls.

Basically, my question is this: When sending a connection.open command, does
a virtual host name of "/test" supposed to be interpreted exactly as "test"
(i.e. ignore the leading slash)?

I looked through the AMQP spec and didn't find anything that explicitly
stated anything to this effect (closest I found was the characters allowed
in a virtual host name, of which '/' is certainly one). What seems to me
that it's happening is this:

In both the Java and .NET Client, creating a connection from a connection
URL will always cause the virtual host to be specified with the leading '/'
(i.e. "/test"). As far as I can see, the Java broker, at least, treats
"/test" and "test" as if they meant the same (explicit check for this is
ConnectionOpenMethodHandler, line 65). However, other AMQP brokers certainly
do not (like RabbitMQ, for example).

So, if "/test" and "test" are not supposed to be treated as equivalent, then
we have two bugs here: one in the broker, that treats them the same, and one
in the client, that incorrectly parses connection URLs. If they are allowed
to be treated the same, then I'd still say the bug in the client still
exists. Any opinions?


Tomas Restrepo
http://www.winterdom.com/weblog/

Re: Virtual Hosts and '/'

[Gordon Sim <gs...@redhat.com>]

Martin Ritchie wrote:
> The java code is still using amqp-0.8 which as Gordon says requires a
> leading '/'. The java client url parsing requires the '/' for the url
> to be well formed. The java broker never enforced an initial '/' so
> when the vhost implementation was done it was done with out the '/'.
> Which made sense as it is a wasted byte in network traffic. So
> currently I believe the client code strips off the '/' after verifying
> the vhost before sending over the wire to save that extra byte.

Martin, Thanks for the clarification and correction. Looking at the 
latest spec, it *does* seem to still mandate a leading '/'. That rule is 
attached to the 'path' domain of which the virtual-host field value is 
an instance. I missed that on re-reading the spec, I suspect if other 
implementations don't honour that they have done the same.

RE: Virtual Hosts and '/'

[Tomas Restrepo <to...@devdeo.com>]

Hi Robert,

> I *think* that both sides ignore a leading / [I should really check
> this]...
> but that client might add one (for luck) on sending where one is not
> present.  As others have pointed out, AMQP0-8 (and indeed AMQP 0-9)
> mandates
> a leading /, which is a waste of a byte.  Those of us on the AMQP
> working
> group should probably aim for a clarification / simplification of the
> definition of vhost.
> 
> Currently it is defined as of domain "path" which means:
> 
> Must start with a slash "/" and continue with path names separated by
> slashes. A
> path name consists of any combination of at least one of [A-Za-z0-9]
> plus zero or more of [._+!=:].


Ahh, OK, I see. What confused me was that going through the spec, the
validation regexp for the virtual-host name doesn't mandate that (it's
currently "^[a-zA-Z0-9/-_]+$").

It does seem pretty weird to model a virtual-host name as a path, though,
but maybe that's just me. It would seem then, that the bug is in the .NET
client which doesn't ensure the virtual host name is sent with a "/" if the
user doesn't specify one.


Tomas Restrepo
http://www.winterdom.com/weblog/

Re: Virtual Hosts and '/'

[Martin Ritchie <ri...@apache.org>]

On 18/04/07, Tomas Restrepo <to...@devdeo.com> wrote:
> Hi Robert,
>
> > I *think* that both sides ignore a leading / [I should really check
> > this]...
> > but that client might add one (for luck) on sending where one is not
> > present.  As others have pointed out, AMQP0-8 (and indeed AMQP 0-9)
> > mandates
> > a leading /, which is a waste of a byte.  Those of us on the AMQP
> > working
> > group should probably aim for a clarification / simplification of the
> > definition of vhost.
> >
> > Currently it is defined as of domain "path" which means:
> >
> > Must start with a slash "/" and continue with path names separated by
> > slashes. A
> > path name consists of any combination of at least one of [A-Za-z0-9]
> > plus zero or more of [._+!=:].
>
>
> Ahh, OK, I see. What confused me was that going through the spec, the
> validation regexp for the virtual-host name doesn't mandate that (it's
> currently "^[a-zA-Z0-9/-_]+$").
>
> It does seem pretty weird to model a virtual-host name as a path, though,
> but maybe that's just me. It would seem then, that the bug is in the .NET
> client which doesn't ensure the virtual host name is sent with a "/" if the
> user doesn't specify one.

It is worse than that.. the spec can't agree if it is a virtual-path
or virtual-host. If it were a path then the '/' would make sence but
there is a large section comparing it to Apache httpd virtualhosts.

>
> Tomas Restrepo
> http://www.winterdom.com/weblog/
>
>
>
>
>


-- 
Martin Ritchie

Re: Virtual Hosts and '/'

[Robert Godfrey <ro...@gmail.com>]

I *think* that both sides ignore a leading / [I should really check this]...
but that client might add one (for luck) on sending where one is not
present.  As others have pointed out, AMQP0-8 (and indeed AMQP 0-9) mandates
a leading /, which is a waste of a byte.  Those of us on the AMQP working
group should probably aim for a clarification / simplification of the
definition of vhost.

Currently it is defined as of domain "path" which means:

Must start with a slash "/" and continue with path names separated by
slashes. A
path name consists of any combination of at least one of [A-Za-z0-9]
plus zero or more of [._+!=:].

-- Rob


On 18/04/07, Martin Ritchie <ri...@apache.org> wrote:
>
> The java code is still using amqp-0.8 which as Gordon says requires a
> leading '/'. The java client url parsing requires the '/' for the url
> to be well formed. The java broker never enforced an initial '/' so
> when the vhost implementation was done it was done with out the '/'.
> Which made sense as it is a wasted byte in network traffic. So
> currently I believe the client code strips off the '/' after verifying
> the vhost before sending over the wire to save that extra byte.
>
> On 18/04/07, Gordon Sim <gs...@redhat.com> wrote:
> > Tomas Restrepo wrote:
> > > I've been doing a bit of testing on the .NET and java clients, and got
> a bit
> > > confused about the current behavior around virtual host names and
> connection
> > > urls.
> > >
> > > Basically, my question is this: When sending a connection.opencommand, does
> > > a virtual host name of "/test" supposed to be interpreted exactly as
> "test"
> > > (i.e. ignore the leading slash)?
> >
> > That is I think for historical reasons. Previous versions of the spec
> > stated that the virtual host must start with a '/'. That rule has since
> > been relaxed, but I suspect no-one has been confident enough to alter
> > the code in case something unexpected breaks! I agree that we should fix
> > that.
> >
> >
>
>
> --
> Martin Ritchie
>

RE: Virtual Hosts and '/'

[Tomas Restrepo <to...@devdeo.com>]

Hi Martin,


> The java code is still using amqp-0.8 which as Gordon says requires a
> leading '/'. The java client url parsing requires the '/' for the url
> to be well formed. The java broker never enforced an initial '/' so
> when the vhost implementation was done it was done with out the '/'.
> Which made sense as it is a wasted byte in network traffic. So
> currently I believe the client code strips off the '/' after verifying
> the vhost before sending over the wire to save that extra byte.

Actually, it doesn't strip it; it adds it if it's missing. At least on the code in the trunk (haven't switched to M2). The .NET client then would have a bug; because unlike the Java code, it doesn't add a leading '/' to the virtual host path when creating a connection without a connection URL.


Tomas Restrepo
http://www.winterdom.com/weblog/

Re: Virtual Hosts and '/'

[Martin Ritchie <ri...@apache.org>]

The java code is still using amqp-0.8 which as Gordon says requires a
leading '/'. The java client url parsing requires the '/' for the url
to be well formed. The java broker never enforced an initial '/' so
when the vhost implementation was done it was done with out the '/'.
Which made sense as it is a wasted byte in network traffic. So
currently I believe the client code strips off the '/' after verifying
the vhost before sending over the wire to save that extra byte.

On 18/04/07, Gordon Sim <gs...@redhat.com> wrote:
> Tomas Restrepo wrote:
> > I've been doing a bit of testing on the .NET and java clients, and got a bit
> > confused about the current behavior around virtual host names and connection
> > urls.
> >
> > Basically, my question is this: When sending a connection.open command, does
> > a virtual host name of "/test" supposed to be interpreted exactly as "test"
> > (i.e. ignore the leading slash)?
>
> That is I think for historical reasons. Previous versions of the spec
> stated that the virtual host must start with a '/'. That rule has since
> been relaxed, but I suspect no-one has been confident enough to alter
> the code in case something unexpected breaks! I agree that we should fix
> that.
>
>


-- 
Martin Ritchie

Re: Virtual Hosts and '/'

[Gordon Sim <gs...@redhat.com>]

Tomas Restrepo wrote:
> I've been doing a bit of testing on the .NET and java clients, and got a bit
> confused about the current behavior around virtual host names and connection
> urls.
> 
> Basically, my question is this: When sending a connection.open command, does
> a virtual host name of "/test" supposed to be interpreted exactly as "test"
> (i.e. ignore the leading slash)?

That is I think for historical reasons. Previous versions of the spec 
stated that the virtual host must start with a '/'. That rule has since 
been relaxed, but I suspect no-one has been confident enough to alter 
the code in case something unexpected breaks! I agree that we should fix 
that.