dayamn.com

After persuading my client to use explicit SSL I ran into another very curious issue that I would like to share with you and maybe it will help you solve a similar problem.

When testing the solution I had to download the files inside a specific path of an FTP location. After downloading the files, I told my client that the solution was working fine but he replied telling me that the files were still in the path. I checked the path using my solution and the files weren’t there! All the files were downloaded to the destination folder and I could see them clearly.

Always blaming the user – as we engineers usually do – I asked my client to share his desktop so that I could see the folder he was looking at and make sure he was looking at the right path. What was my surprise when I saw the “same” folder I was looking at in my computer with a bunch of files pending to be downloaded.

After a couple of minutes scratching my head I realized that we were looking at two different folders using a similar path structure. But how was this possible? I hope I can make it clear enough for you.

Actually, my FTP solution was downloading the files from a relative path. As an example, I was told that after logging to the FTP location, I needed to go to the path “example1/download” to download the files. When I logged in using using my solution I didn’t realize that I was actually being redirected to a folder created for the credentials I was using when logging to the FTP location. As a result, I thought I was accessing the path

ftp://ftplocation.com/example1/download

when I was actually accessing the path

ftp://ftplocation.com/user1/example1/download

because of the automatic redirection to the user folder depending on the credentials used to access the FTP location.

I was having the problem because unfortunately, the FTP location happened to have both paths available – go figure! – and my client was looking at the absolute path – in the example above ftp://ftplocation.com/example1/download.

If you’re having the same problem you need to tell the FTPWebRequest instance that you will be using and absolute path. As the FTWebRequest class has its foundations in the HTTPWebRequest class you are not capable of controlling your FTP session, so you won’t be able to redirect to the root folder – in the example above ftp://ftplocation.com- and redirect to your specific path from there. Fortunately, the geniuses at Microsoft thought of a workaround to tell the FTPWebRequest class you will be using and absolute path instead of your default redirection or relative path.

The following code shows how to do that:

I know “%2f” is an escaped “/” but that’s how the class can tell if it will be using an absolute path instead of a relative one.

It’s simple right? Just add “%2f” before the specific path and you will make sure you are accessing the absolute path. Sometimes you will need  to use a relative path so it’s better if you make that option configurable – maybe a checkbox where you can choose between relative or absolute paths.

Ok, another workaround for the FTPWebRequest class that could save you some trouble.

Cheers!

Some time ago I had to develop a web FTP solution for a client and as a client’s choice, I had to use ASP.NET 3.5 to do it. I never liked Visual Basic.NET that much so I always use C# when I need to develop .NET applications.

I thought of using the FTPWebRequest class to develop the solution and everything was going fine until I had to use the solution to create a connection to an FTP location that was secured using implicit SSL.

I googled and googled about it and finally I found out that our friends at Microsoft decided NOT to support implicit SSL for the FTPWebRequest class. This is another reason that makes me want to meet the guy who designed this class and slap him in the face. This and the fact that the FTPWebRequest class is based on the HTTPWebRequest class without taking in account that FTP and HTTP are protocols that work in a completely different way, hence, the FTPWebRequest class lacks of a lot of features that could make it a powerful FTP tool.

Having said that, using FTPWebRequest makes it easy to create FTP solutions once you make sure you WON’T need to connect to FTP locations that are secured by implicit SSL. If you are one of the unfortunate souls that need to support this type of security, I’m sorry to say it but you will need to use – as primitive as it sounds – sockets so don’t even bother using FTPWebRequest since you would be doing the work twice.

FTPWebRequest does support explicit SSL so if you  can persuade your client to use explicit SSL in his FTP locations, go for FTPWebRequest since it’s very easy to use.

Cheers!