Bug in System.Uri constructor?

Tuesday, September 4. 2007

I'm using the System.Uri class to clean up some the URLs we're passing around, e.g. compacting http://hostname//somefolder//somefile to http://hostname/somefolder/somefile.

The documentation clearly states that the Uri constructor takes care of this: MSDN.

This works fine on my machine. However, when I try this on our server box (Win 2003), I just get back the string I passed to the constructor.

I've checked the .NET versions and the assembly versions on both the target machine and my workstation. They match.

Here's the code:

CODE:

using System;

namespace sandpit
{
    class Program
    {
        public static void Main(string[] args)
        {
            Type type = typeof(Uri);
            Console.WriteLine(type.ToString());
            Console.WriteLine(type.Assembly);
            Console.WriteLine(type.AssemblyQualifiedName);
            Console.WriteLine(type.UnderlyingSystemType);
            Uri uri = new Uri(args.Length == 0 ? "http://hostname///
somefile.txt" : args[0]);
            Console.WriteLine(uri.ToString());
        }
    }

}

I've posted this on Google Groups but so far, to no avail.

Posted by Misha in Development at 14:09 | Comment (1) | Trackbacks (0)

Trackbacks

Trackback specific URI for this entry

No Trackbacks

Comments

Display comments as (Linear | Threaded)

Well, it's been over a week since I've run into this bug. I haven't been able to find anything regarding this behaviour on the net, but a colleague was able to confirm the same behaviour occuring on their side. They also pointed out that such peculiarities are are not uncommon in the .NET world. Anyway, since I'm pressed to come up with a solution, I'm opting for scrubbing the URLs manually.

On a slightly more positive note, I've actually noticed that canonicalisation works for other instances of URL crust (such as repetitions of ./). Also, it doesn't seem to be a problem on Windows XP. For me, it occurs on a box Windows Server 2003 R2 (with Service Pack 2 installed). I haven't bothered testing other OS and SP combinations -- I've got better things to do with my time.

Finally, in case anybody is wondering why I'm being so pedantic about adjacent slashes in URLs -- it's not for me, it's for SharePoint. While adjacent slashes are perfectly legal URL syntax, methods in the SharePoint object model aren't able to interpret them correctly.

#1 Misha (Homepage) on 2007-09-13 10:06 (Reply)

Add Comment

Name
Email
Homepage
In reply to
Comment	To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly. Enter the string from the spam-prevention image above: BBCode format allowed Standard emoticons like :-) and ;-) are converted to images.
	Remember Information? Subscribe to this entry