Extracting path from URL?
-
System.IO.Path class offers several static functions that work on both file system paths as well as URLs. The one that addresses your question is: "http://samplesite.com/account" == Path.GetDirectoryName("http://samplesite.com/account/myaccount.aspx");
-
This is how it will will be done. Dim strFolder as String strFolder = Left(Request.Url.AbsoluteUri, InStrRev(Request.Url.AbsoluteUri, "/")) Enjoy .. Follow your goals, Means will follow you ---Gandhi---
Curious, what was wrong with the previous answer?
-
Curious, what was wrong with the previous answer?
I think the functions in this class are mainly for Windows File System. It was returning "http:samplesite.comaccount". For handling URL's, I would prefer the way I did. Request.Url is meant to for such URL parsing. Follow your goals, Means will follow you ---Gandhi---
-
Curious, what was wrong with the previous answer?
I think the functions in this class are mainly for Windows File System. It was returning "http:samplesite.comaccount". For handling URL's, I would prefer the way I did. Request.Url is meant for such URL parsing. Follow your goals, Means will follow you ---Gandhi---
-
I think the functions in this class are mainly for Windows File System. It was returning "http:samplesite.comaccount". For handling URL's, I would prefer the way I did. Request.Url is meant to for such URL parsing. Follow your goals, Means will follow you ---Gandhi---
Correct they are for Windows File Systems and unless I'm missing something that is what you are using. Using your method is inherently dangerous. Are you checking for valid uri before getting it or just hoping it is valid when parsed? The previous method uses built in exception handling of the class. What's the point of having a tool if you're not going to use it?
-
This is how it will will be done. Dim strFolder as String strFolder = Left(Request.Url.AbsoluteUri, InStrRev(Request.Url.AbsoluteUri, "/")) Enjoy .. Follow your goals, Means will follow you ---Gandhi---
You need to use AbsolutePath instead of AbsoluteUri. Try the perfectly valid "http://foo.com/bar.htm?baz=x/y" as an test case to see the difference. -Blake
-
Correct they are for Windows File Systems and unless I'm missing something that is what you are using. Using your method is inherently dangerous. Are you checking for valid uri before getting it or just hoping it is valid when parsed? The previous method uses built in exception handling of the class. What's the point of having a tool if you're not going to use it?
Mark Nischalke wrote: Correct they are for Windows File Systems and unless I'm missing something that is what you are using. Yes, you are missing something. mittalpa is correct. He is parsing a URL, not a file system path. They are not the same and code for one will not handle the other correctly. Mark Nischalke wrote: Using your method is inherently dangerous. Are you checking for valid uri before getting it or just hoping it is valid when parsed? The previous method uses built in exception handling of the class. What's the point of having a tool if you're not going to use it? No, his method is not dangerous. He is parsing the uri from the Request object, not some arbitrary one passed in from elsewhere, so yes, it has already been canonicalized and validated. (His code wouldn't be running if it weren't.) -Blake
-
You need to use AbsolutePath instead of AbsoluteUri. Try the perfectly valid "http://foo.com/bar.htm?baz=x/y" as an test case to see the difference. -Blake
This proves my point from above. No checks were made for this possibility whereas the System.IO method ignores the query string.
-
Mark Nischalke wrote: Correct they are for Windows File Systems and unless I'm missing something that is what you are using. Yes, you are missing something. mittalpa is correct. He is parsing a URL, not a file system path. They are not the same and code for one will not handle the other correctly. Mark Nischalke wrote: Using your method is inherently dangerous. Are you checking for valid uri before getting it or just hoping it is valid when parsed? The previous method uses built in exception handling of the class. What's the point of having a tool if you're not going to use it? No, his method is not dangerous. He is parsing the uri from the Request object, not some arbitrary one passed in from elsewhere, so yes, it has already been canonicalized and validated. (His code wouldn't be running if it weren't.) -Blake
Add a couple of slashes to the address used to get here. Still gets you here but may not parse correctly if you are only expecting one. Blake Coverett wrote: They are not the same and code for one will not handle the other correctly System.IO.Path does handle it.
-
You need to use AbsolutePath instead of AbsoluteUri. Try the perfectly valid "http://foo.com/bar.htm?baz=x/y" as an test case to see the difference. -Blake
you broke my code Blake..:(( "http://samplesite.com/account/myaccount.aspx?abc=x/y" anywho.. if I use AbsolutePath instead of AbsoluteUri, I get "/account/myaccount.aspx". What about "http://samplesite.com" ? How do get that? Follow your goals, Means will follow you ---Gandhi---
-
Add a couple of slashes to the address used to get here. Still gets you here but may not parse correctly if you are only expecting one. Blake Coverett wrote: They are not the same and code for one will not handle the other correctly System.IO.Path does handle it.
Mark Nischalke wrote: Add a couple of slashes to the address used to get here. Still gets you here but may not parse correctly if you are only expecting one. Wrong. Try it and you will see for yourself. As I already told you, System.Uri class canonicalized the URL. If I use http://foo.com/bar///test.aspx, yes I will get the same page as http://foo.com/bar/test.aspx, but the value of Request.Url.AbsolutePath will be /bar/test.aspx with the extra slashes removed in both cases. Mark Nischalke wrote: System.IO.Path does handle it. System.IO.Path is for file system paths not URI paths. The two are not the same. Valid instances of one are not always valid instances of the other. In particular, System.IO.Path knows nothing about query strings or fragment identifiers. If you pass a valid Uri containing those into System.IO.Path you will end up with either an exception or the wrong result. Check your facts before you spout off next time. -Blake
-
Add a couple of slashes to the address used to get here. Still gets you here but may not parse correctly if you are only expecting one. Blake Coverett wrote: They are not the same and code for one will not handle the other correctly System.IO.Path does handle it.
using System;
class AClueForMark {
static void Main() {
Console.WriteLine(
Path.GetDirectoryName("http://foo.com/bar/baz.htm?x/y"));
}
}Quick quiz - what does it print? -Blake
-
you broke my code Blake..:(( "http://samplesite.com/account/myaccount.aspx?abc=x/y" anywho.. if I use AbsolutePath instead of AbsoluteUri, I get "/account/myaccount.aspx". What about "http://samplesite.com" ? How do get that? Follow your goals, Means will follow you ---Gandhi---
Sorry, I forgot you wanted the site on the front too, better to use Request.Url.GetLeftPart(UriPartial.Path) instead of Request.Url.AbsolutePath. That gets you everything from the scheme through the path, not just the path. -Blake
-
Mark Nischalke wrote: Add a couple of slashes to the address used to get here. Still gets you here but may not parse correctly if you are only expecting one. Wrong. Try it and you will see for yourself. As I already told you, System.Uri class canonicalized the URL. If I use http://foo.com/bar///test.aspx, yes I will get the same page as http://foo.com/bar/test.aspx, but the value of Request.Url.AbsolutePath will be /bar/test.aspx with the extra slashes removed in both cases. Mark Nischalke wrote: System.IO.Path does handle it. System.IO.Path is for file system paths not URI paths. The two are not the same. Valid instances of one are not always valid instances of the other. In particular, System.IO.Path knows nothing about query strings or fragment identifiers. If you pass a valid Uri containing those into System.IO.Path you will end up with either an exception or the wrong result. Check your facts before you spout off next time. -Blake
Blake Coverett wrote: In particular, System.IO.Path knows nothing about query strings or fragment identifiers. Given the criteria of finding the base folder for a page, then query strings on the url make no difference. Blake Coverett wrote: If you pass a valid Uri containing those into System.IO.Path you will end up with either an exception or the wrong result.
string strURL = "http://mytest.com/subfolder/default.ass?id=clue"; string str = System.IO.Path.GetDirectoryName(strURL);Still waiting for the exception. Wait maybe thisSystem.UriBuilder uri = new UriBuilder("http://mytest.com/subfolder/default.ass?id=blake"); string str = System.IO.Path.GetDirectoryName(uri.Uri.ToString());Nope, still no exception.:confused: -
Blake Coverett wrote: In particular, System.IO.Path knows nothing about query strings or fragment identifiers. Given the criteria of finding the base folder for a page, then query strings on the url make no difference. Blake Coverett wrote: If you pass a valid Uri containing those into System.IO.Path you will end up with either an exception or the wrong result.
string strURL = "http://mytest.com/subfolder/default.ass?id=clue"; string str = System.IO.Path.GetDirectoryName(strURL);Still waiting for the exception. Wait maybe thisSystem.UriBuilder uri = new UriBuilder("http://mytest.com/subfolder/default.ass?id=blake"); string str = System.IO.Path.GetDirectoryName(uri.Uri.ToString());Nope, still no exception.:confused:Tsk, tsk, tsk. Are you actively trying to look more stupid here? Mark Nischalke wrote: Given the criteria of finding the base folder for a page, then query strings on the url make no difference. Incorrect, the Request.Url includes the query string and the fragment identifier. Any attempt to extract the base folder needs to take that into consideration. Mark Nischalke wrote: Still waiting for the exception. Read what I said, you will get either an exception or the wrong result. Either/or, that's one of those tricky English phrases, it means you will get one of them. 1) When the query string or fragment identifier contains a '/' or '\' you get the wrong result. 2) When the query string or fragment identifier contains a '|' or '>' or '<' etc an exception is thrown. All of these characters are perfectly legal in that part of a Uri.
using System;
using System.IO;
class MarkIsEvenMoreStupidThanIThought {
static void Main() {
Uri wrongResult = new Uri("http://foo.com/bar/baz.htm?x/y");
Uri exceptionThrown = new Uri("http://foo.com/bar/baz.htm?x>y");
Console.WriteLine(
Path.GetDirectoryName(wrongResult.ToString()));
Console.WriteLine(
Path.GetDirectoryName(exceptionThrown.ToString()));
}
}So, are we completely clear now? System.IO.Path fails to properly parse perfectly legal URLs, giving either the wrong value or throwing an exception. I don't have a problem with people who don't know things, after all there's lots I don't know, but I have no tolerance for aggressively stupid people who won't learn when taught. -Blake
-
Sorry, I forgot you wanted the site on the front too, better to use Request.Url.GetLeftPart(UriPartial.Path) instead of Request.Url.AbsolutePath. That gets you everything from the scheme through the path, not just the path. -Blake