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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
