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
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
situation, with no prior notice to me. Of course most of the time
Just Fine, but sometimes hairy problems arise.
Another shortcut is the oliver ftp frontend:
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
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
not using it. I have just dabbled with winSCP but it seems to solve
of the problems of ftp, except it needs a dedicated client exe
for windows users.. but then to get anything aproaching non-sucking
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
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
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
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
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!
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
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"
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
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
is just to help the user receive the file(s) ASAP.
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.
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
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!