Converting HTTP to FTP URL
jimaultwins at yahoo.com
Mon Aug 8 01:32:47 EDT 2011
--- On Sun, 8/7/11, J. Landman Gay <jacque at hyperactivesw.com> wrote:
From: J. Landman Gay <jacque at hyperactivesw.com>
Subject: Re: Converting HTTP to FTP URL
To: "How to use LiveCode" <use-livecode at lists.runrev.com>
Date: Sunday, August 7, 2011, 8:49 PM
On 8/7/11 10:05 PM, Jeffrey Massung wrote:
> So, the only way you can begin to solve this issue is if you have direct
> access to the web server and know how it's routing and serving static
I'll answer you and Mark Weider at the same time. I'm trying to add auto-upload to AirLaunch. It mostly works. I can only upload via ftp (http isn't usually accepted, I don't think, even if you provide a name and password. At least, it doesn't work on my hosted account.) There is already a place in the stack for the user to enter the http URL where their installation files will be downloaded from. That URL is required for setting up the wi-fi installation, so AirLaunch already has that.
I could ask the user for a separate FTP upload URL but I'd rather not if I don't have to. What would be better is to take their HTTP URL and convert it to a valid FTP URL which will only be used internally by AirLaunch to get their files onto their server.
On both my main hosted server and at my site on on-rev, changing the htpp URL works if I add "www" after the domain part of the path. That allows an ftp upload to resolve the www alias, and the rest of the path is the same as the http URL. Easy, and no hassle for the user.
But when testing with a subdomain, that method creates a new "www" folder inside the subdomain, which isn't what's wanted. So I'd like a generic way to create a valid FTP path from a known HTTP path, one that works with primary domains as well as subdomains.
It sounds like I may have to ask the user to provide both paths. But that makes everything more complex because the two paths are slightly different, the user needs to know the distinction between web-relative paths and absolute paths and what their web root folder is called, and I'd rather avoid the support issues around that if I can.
........and now, Jaque, we are back to the begining of the circle of confusion
If subdomains are allowed on a server, then each should logically have every nested folder with separate permissions, such as
cgi-bin/ www/ public_ftp/ private_ftp/ public_html/
(on my server, the cgi-bin/ folder is created when I create the subdomain, but it is the only one)
One question is "If a subdomain is specified, why would you want to give access to the root domain folders (that should have different permissions)?
You can have a blog root at www.GreatLcAdventures.com/blog/
Although the subdomain folder appears in the directory tree for the root administrator as just a folder, the server sees it as a special permissions starting point. This means that a user that has access to only the subdomain will be restricted to that portion of the tree (of course, special tricks can change that)
As admin, if you give a user a login and passwd for the subdomain, they should only have ftp access to that folder tree.
If they have the root admin login and passwd, then they only have to keep the path names orgainized correctly.
Most of the time, ftp access for users of a subdomain has to be enabled by the admin, which will include login/passwd setup. Assuming you only want to use the admin root access, this won't be necessary.
One answer to your quest may be that
if a subdomain is detected,
either you move that name to the folder path just after the domain.com
or disregard this if you are uploading to the root ftp folder (and allowing access by all subdomains, even though the folder is outside the normal subdomain tree)
My apache servers are using /public_html/ and ftp.domain.com/
so rather than let the server resolve the path,
I will define my explicit path as (in my case)
(note that my server does not auto-create 'www/' for subdomains)
When you do find the answer that works for your server, document this with several examples of working and non-working strings so you can figure it out next time. My trick is to keep all the strings that don't work, label them as such, put them into one block. It is very easy to test the same string multiple times and lose track of the subtle differences.
I hope this does not confuse you. The rules of the road for different servers can be tricky.
More information about the Use-livecode