Re: Large file uploads via PHP - ftp limitations etc...
On Dec 7, 2006, at 6:58 AM, Duncan Robertson wrote:
Yes, ftp login banner has something along the lines of "ftp
problems? -
try filezilla" as pretty much the first comment, unfortunately the end
users may be "random" (as far as I am concerned) people in "random
locations" (as far as I am concerned) that may need to transfer a file
to one of my end users, and they could be in any country, in any
network
situation, with no prior notice to me. Of course most of the time
ftp is
Just Fine, but sometimes hairy problems arise.
Understand.
Another shortcut is the oliver ftp frontend:
http://oliver.sourceforge.net/
for simple ftp stuff, instantly all the messing about with firewall
issues goes away as long as http works, of course then you hit the
limits of the php upload etc, - if this was tweaked to upload in
chunks
rather than the entire file at once into RAM and then dump it into ftp
(the php ftp module?) it would be great.
Will have to check that out. Sounds nice.
Yes, thats what I mean, overcome the limitations of the ftp
protocol by
not using it. I have just dabbled with winSCP but it seems to solve
most
of the problems of ftp, except it needs a dedicated client exe
installed
for windows users.. but then to get anything aproaching non-sucking
ftp
you need to do this anyway. And yes some place broken for ftp may be
broken for ssh, but the single tcp connection over port 22 ssh uses
does
work heaps better in general.
Isn't that odd? I've seen it too -- strange network behavior out
there on some networks. I often wonder if it's just broken
"transparent" proxies... but like your situation I'm rarely able to
see what the person complaining is seeing.
Personally I rarely use ftp, I use rsync over ssh or scp it just seems
for some reason windows users are stuck with this old protocol to move
large files around more by intertia and I end up having to support
it as
a lowest common denominator kind of thing.
They made their bed... now they have to lie in it. :-)
Also from my research ftp cannot be reliably NATted if any of the
encrypted variants of ftp are
used, meaning you have a choice of telnet level security, or not
working
across nat/firewalls.
Ummm... I think that depends on various factors, but all add so much
complexity to the question that the average end-user's eyes will be
glazed over by the time you start the second sentence when explaining
it.
But if PASV FTP won't work, the chances of SCP/SFTP working are
pretty low. They're just on a horribly broken network. Ask them if
they're getting what they paid for and turn 'em loose on that admin
who's still recovering from the lobotomy... he needs the practice to
regain his skills.
And we could even start a legal debate about the SLA and TOS that the
other end have committed to while we are at it, under whatever legal
jurisdiction they happen to be in!
LOL!
Ok for example lets say I had a user in Laos.. can http reliably but
most other traffic controlled by state firewall. Or a random
netcafe/hotel-that-advertises-internet in (say..) Cambodia.. where
discussions about whether or not the network is broken or how leet
their
admins are won't get you far as the place is full of tourists who are
happy if hotmail works, and the staff just turn on "the internet"
at the
wall every morning and otherwise have no idea, or concern as long as
google and hotmail pops up. user in that location needs to upload a
file
urgently.. of course I can have a great time discussing (in Laos or
Khmer) how much the admin was paid to build the network or the
broken-ness of the network if ftp is failing, but really the job at
hand
is just to help the user receive the file(s) ASAP.
Hmmm... yeah.
Fixing the other end is good if I have time, but I'd also like to have
flexible tools available at my (server) end that can overcome the
brokenness I know I will encounter sooner or later at the other end.
Makes sense.
Something important came to mind while I was reading your reply, but
looking at my (almost devoid of content) reply above, it must have
slipped away... 1:18 AM... I guess that's to be expected... (GRIN).
Oh I remember now at least one funny thought that came to mind,
reading your comments about the PHP-based system delivering the file
in chunks... It made me laugh out loud and think of the "good old
days" of 1200 baud modems and BBS's. Various protocols for handling
file up/downloads in chunks were bandied about, but you know what
really worked... and there's code out there if anyone wanted to
tackle such a thing in the lrzsz package... the old X, Y, and Z modem
protocols.
They work flawlessly over dedicated bit pipes like our modern
Internet/Ethernet, albeit with lots of unnecessary overhead and error
correction added on. (slower)
I use Z-modem all the time (just out of habit) from within SecureCRT
on a Windows machine at work. Works from the Linux command line too,
actually... just a bit different syntax.
If the lrzsz package is loaded on the machine, a simple "sz filename"
in the shell on the host I'm logged into will initiate an auto-start
Z modem download within SecureCRT over whatever type of shell session
I'm on... pretty nifty trick. Same going the other way, "rz" will
pop a dialog box on SecureCRT asking what file I wanted to upload.
Old-school tools... maybe someone could hack lrzsz into a Java applet
that would load into a browser. (GRIN)... Yeah, kinda nuts... but
would be an interesting experiment!
Judging by your top-level domain, I believe the ethos of the phrase
"have a go" would capture the type of mentality it would take to give
it a try!
Cheers,
--
Nate Duehr
nate@natetech.com
Reply to: