[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: http://[user[:pass]@]host/ syntax (was: Re: svn merge fails in 0.15)

From: Benjamin Pflugmann <benjamin-svn-dev_at_pflugmann.de>
Date: 2002-11-18 23:00:36 CET

Hi.

On Mon 2002-11-18 at 13:46:44 -0800, Peter Davis wrote:
> On Monday 18 November 2002 13:41, Matt Quail wrote:
> > Allowing a super-set of the
> > http schema defined by RFC 1738 may still mean you are a valid 1738
> > parser...
>
> It's not as if Subversion doesn't already support a superset with support for
> http://host/path@REV syntax (as good or bad as that syntax might be).

That is a completely different issue. http://host/path@REV is allowed
by the standard. In the path, almost everything is allowed. Subversion
just has a special interpretation of the path. This was always up to
the server to decide and it is just an (unfortunate?) convention that
the path is often mapped directly to the filesystem (but there are
also many systems which already have other interpretations).

> In any case, it's definitely wrong to successfully parse the user@host URL and
> then completely ignore the "user@". Right now, if you specify such a URL,
> Subversion will not give an error and will just proceed as if you had not
> specified the user at all.
>
> Either it's valid syntax, or it's not. It should be supported, or else there
> should be an error saying the URL is not valid RFC 1738 (or at least a
> warning).

I agree. If it's been decided that user/password specification is not
supported, the parser should complain.

> > In any case, I definitely find the "username:password@" syntax useful!
>
> So would I :)

No comment. As I said, I just wanted to make the fact known.

Bye,

        Benjamin.

  • application/pgp-signature attachment: stored
Received on Mon Nov 18 23:01:22 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.