rejetto forum
Software => HFS ~ HTTP File Server => Topic started by: LHK on January 09, 2004, 12:38:55 PM
-
Can you add the multi-upload function in Ver2 ?
This software is .................perfect! (If added the upload function.)
-
what is difference between multi-upload and upload?
-
what is difference between multi-upload and upload?
Upload: Upload one file each time. :(
Multi-upload: Each time can upload more than 1 file! B)
-
you would be for sure able to do it opening more browsers
but i will think about having more than one "file" fields in the form
-
Ok, I just noticed that it appears with rc 1.6 or whatever, maybe even with the older versions, a single file cannot be uploaded to multiple users in the same instant. EG: I host an mp3 with 1.6 rc10 which is passworded (havent tried not passworded), only ONE IP can download it at a time... any others attempting to download that same file at the same time, and it will return a page not found.
-
I dont recall having this problem with earlier versions, and I think this is what LHK is talking about.
-
i'm not sure he is talking about it
anyway, yes, there is such bug in 1.6
it has been introduced with new stream handling
i'm trying to fix it now
-
now fixed
-
LHK, what's right interpretation. mine or vip's one?
-
LHK, what's right interpretation. mine or vip's one?
rejetto,you are right. :D
"having more than one "file" fields in the form"<-that's what I mean.
-
LHK, what's right interpretation. mine or vip's one?
rejetto,you are right. :D
"having more than one "file" fields in the form"<-that's what I mean.
@LHK/rejetto -
I remember asking for getright browser support just to do the same thing for multiple downloads. It works. So, if you decide to do this multiple file support for upload (in ver 3 ?... ) may be add the same capability/form to the download form/page :?:
-
I can not find upload functions in this software. where is it?
-
I can not find upload functions in this software. where is it?
It is a future feature - for V2 ... wait and see...
-
I can not find upload functions in this software. where is it?
It is a future feature - for V2 ... wait and see...
COOL!!! I am waiting! :roll: :roll:
-
I can not find upload functions in this software. where is it?
It is a future feature - for V2 ... wait and see...
COOL!!! I am waiting! :roll: :roll:
But don't hold your breath... ;)
-
I see that you might add this feature in the next version
Is there a way to add a field on the form to upload an entire directory also?
-
i don't think browsers support such thing
-
i don't think browsers support such thing
Isn't it controllable by the uploading application ? for example - if the user selects multiple files (from a GUI you give him) or just mark/select a directory of tree, can't the application "help" in doing all the uploads for him at once?
-
uploading application = browser
i tested with simple forms and read the HTML specs, and found no way to get a multi-select for files
-
I'm no expert, but Yahoo-mail does it (you can upload 1-3 attachments in one form - multiple edit boxes) , my forum does it - http://www.fresh.co.il/scripts/upload.php
My 50free web hosting service does it...
I'm sure you can have optional check-boxes near each file/dir ...
But, maybe it is not standard HTML .[/i]
-
the question was
is there a way to add a field on the form to upload an entire directory also?
we were talking about multi-selections and folder-selections.
to have many fields was already discussed elsewhere and approved, but it is unhandy (you have to open the dialog for every file) and it does not support folder selection anyway.
-
we were talking about multi-selections and folder-selections.
As I suggeted - maybe do not use input fields al all, but some kind of optional checkboxes nere the files/directories names
Edit:
Since one picture is better then 1000 words, here is a sample interface of my web hosting service. It is intended for managing the remote site, and what I mean is use such interface on the local PC, to select multiple files/directories/tree.
This interface looks completely different from what we see in HFs, but if you ignore the bottom edit fields, it is almost the same with few extra checkboxes and control buttons, to give you management capability over the remote site file system (which is a nice feature for V3 of HFS...).
PS: I can email you the html source for this sample page if you like ...
(http://rafi_d.50free.net/file%20manager%20sample.jpg)
-
but that's for a remote file system.
we were talking about local (client-side) file system.
that system can't work locally. in facts your picture show as it is used only for the server-side, and for the local side you have only several input fields at bottom.
-
you are not reading my attached message-text... just 1 cm above the picture... "edit": etc.... ;) it's an example. why not use/activate this dialog style for selecting uploads from the local PC ... :?:
Edit: clarify
-
i read your whole message before replying.
i said "that system can't work locally", meaning that it can't be done. it would be good if it was possible, but it is not.
-
sorry... :#)
may be this article can help:
http://www.15seconds.com/issue/990723.htm
-
sadly not
submit files using the file transfer protocol (FTP)
-
sadly not
submit files using the file transfer protocol (FTP)
Yes I noticed that, but he is talking in this paragraph about an older project... may be not in this one 8O . And, BTW, ftp is not so bad...
-
I have an idea!
Since some Free Web Hosting providers are using it, I just wanted to point it out.
Would it be possible to have HFS decompress a ZIP when a zip file is uploaded? So that way when a user uploads a zip, they have the option of decompressing the contents of the zip to the current folder. That solves the issue of not being able to upload the whole folder onto the current directory.
1. User compresses folder to single zip file.
2. User visits /root.
3. User selects the zip file to upload and check the decompress checkbox so HFS will decompress it to the remote folder. (If the decompress checkbox is not checked, HFS will leave it as a zip file.)
If this "feature" is approved, then there should also be a option for the server admin to disable it. (For those whose want to save CPU.) and also another feature where the server admin could set a maximum size where HFS will only decompress zips under the maximum size limit.
-
I don't like it. Not natural , not standard, requires user preparation.
Ideally - I see the user either selecting files/directories, or dragging them to some pane, and selecting a destination. Then watching the progress. That should be it.
But I see no harm in starting with a single file and debugging the SW engine. Then multiple files version.
Also - FTP engine is not a "no-no"... Servers are free, and clients, are embedded inside every Windows/DOS . No need to invent the wheel!
Also, user's permissions should be available/selectable to either upload/download or both.
-
I don't like it. Not natural , not standard, requires user preparation.
Yes, it does require user preparation. But first, it saves bandwidth. Second, it solves the problem where a user will have to select many files to upload a folder if the folder contains many files. For example: 40 files.
But say, which will be faster? Selecting 40 files in the browser or zip it all up?
Ideally - I see the user either selecting files/directories, or dragging them to some pane, and selecting a destination. Then watching the progress. That should be it.
This is more like FTP you are talking about. HTTP doesn't do do it.
As rejetto said, the browser is the one which sends the POST command. There's no way to have it select a folder there.
But I see no harm in starting with a single file and debugging the SW engine. Then multiple files version.
Rejetto, if you are rushing to get 2.0 done, then I will agree with this.
Also - FTP engine is not a "no-no"... Servers are free, and clients, are embedded inside every Windows/DOS . No need to invent the wheel!
I don't get what you meant by that.
Also, user's permissions should be available/selectable to either upload/download or both.
Agreed!
-
Also - FTP engine is not a "no-no"... Servers are free, and clients, are embedded inside every Windows/DOS . No need to invent the wheel!
I don't get what you meant by that.
I meant roughly:
* server side: Interface & activate a small ftp server from inside the HFS server
* client side: have an upload button activating a dialog (like the one above or something else) that will use the external ftp command\function
and you are allmost done...
-
Maybe it's me. But I haven't seen such buttons?
-
Maybe it's me. But I haven't seen such buttons?
Right, it's in example I posted "above" on prevous page (#2) dated Sat Apr 10, 2004 9:39 am ;)
-
the unzip feature is interesting where you don't have the ability to unzip the file. in web hosting there's often no way to unzip a file.
HFS is thought for file swapping, you have users in both sides, there's no way to automatically extract an archive.
i think the best way is to implement an FTP server in HFS.
What will the H mean then... Hyper? :)
anyway, people, first 2.0 preview is very near. ;)
-
i think the best way is to implement an FTP server in HFS.
What will the H mean then... Hyper? :)
HFS => HTTP/FTP/Server... ;)
Just thought of something crazy - use HFS on both sides... so Upload=Download 8O + remote web viewer & download your files to the remote site :D ... probaby a bad idea...
-
rejetto, how I think the unzip feature should is like this:
1. User zips up files + folders.
2. User goes to HFS webpage and select zip file
3. User checks "Unzip this zip file" checkbox
4. User clicks Upload
5. HFS then interprets the POST command and if the "Unzip this zip file" checkbox is checked, HFS calls the unzip function in it's unzip engine. If not, HFS leaves the zip as a zip file.
So all this should take is a unzip engine and also some additional codes to call it up when the checkbox is checked.
FTP is sure nice, but:
1. Client needs a FTP client to connect (maybe IE will do? ;))
2. It causes NAT problems (Server and Client behind firewall / NAT etc.)
It think it's a nice idea to implement the unzip feature in HFS 2.0 because it makes sure that HFS is NAT friendly and User Friendly. It will be perfect if you could put them both in. :)
Nice name for HFS, Rafi! :D
--- HFS Reloaded :P
-
anon, i understand perfectly the way you intended it to work.
mind this while re-reading my reply :)
anyway, i think we should better think about an external script called on uploaded files. then the script could just check if the archive contains an "unzip me" comment, or an "unzip.me" file in it.
this let people do antivirus scan and anything they want to.
it would be better if i can (someway) pass non-file POST data to scripts, for easier interface.
ftp nat problems, in PASV mode, are same to http ones
"Http Ftp Server" is a good suggestion :)
-
I didn't understand what you said (except for the last line... ;) ) . In simple word, may be you can explain what are the 1-2-3... steps the user has to take to simply download say, 3 files or one full directory ?
-
anyway, i think we should better think about an external script called on uploaded files. then the script could just check if the archive contains an "unzip me" comment, or an "unzip.me" file in it.
Although I agree on the script part, I don't really agree on checking the zip comment for "unzip me", because it could cause conflicts such as if the zip comment contains "Unzip me if you want to run the app". Instead I came up with the HTML code below.
<form method="POST" enctype="multipart/form-data" action="http://localhost/upload.asp">
<p><font face="Arial">Upload File #1: <input type="file" name="file1">
<input type="checkbox" name="U1" value="U1"> Unzip This Zip File<br>
Upload File #2: <input type="file" name="file2">
<input type="checkbox" name="U2" value="U2"> Unzip This Zip File<br>
Upload File #3: <input type="file" name="file3">
<input type="checkbox" name="U3" value="U3"> Unzip This Zip File</font></p>
<p><input type="submit" value="Upload" name="button_upload"></p>
</form>
If the Unzip This File check box is checked for file "x", the browser will also send the U"x" section to HFS. Otherwise, the U"x" section won't be sent. All you will have to do is to send all the data to the script, and the script will store the file part of the POST command and also try to look for the U"x" section in the POST command. If the U"x" section exists for file "x", HFS will then try to decompress file "x" if possible. If the file extraction is successful, then HFS deletes the zip file and put the extracted contents into the current upload folder. But if the extraction process fails (ex. not a zip file), then HFS will leave it as it is.
--- Wonder if this is possible :)
ftp nat problems, in PASV mode, are same to http ones
Umm... FTP PASV mode uses random PASV ports as well as port 21, but HTTP only uses port 80. (Single fixed port)
"Http Ftp Server" is a good suggestion :)
I agree! ;)
Rafi: I didn't understand what you said (except for the last line... ;) )
We are talking about how HFS should handle the zip files and how HFS should decompress it.
Rafi: In simple word, may be you can explain what are the 1-2-3... steps the user has to take to simply download say, 3 files or one full directory ?
Go Here For My Example: http://swg.fg.bz/HFS/HFS.htm (Example Only, cannot actually upload! :lol: )
To upload one file: Click Browse, Select the file, click Upload.
To upload one or more file: Click Browse #1, select first file, click Browse #2, select second file, click Upload.
To upload a folder/directory: Zip the folder up into a zip file, click Browse, select the zip file, then click the "Unzip This Zip File" checkbox for that row, click Upload.
--- HFS Reloaded :P
-
anon, you did not get the point.
i think it is not useful to automatically unzip a file.
why should we want it?
you talked about servers were no-one will unzip files for you. you are acting with machines.
if you send a file to someone, he will unzip it as he wish to do it.
-
We are talking about how HFS should handle the zip files and how HFS should decompress it.
Well, I like very much to be opimistic and have Ver 2 RC001 include ALL the upload features possible, but I would be very happy to see three stages:
V 2.0 - support for single file upload. this will test the basic engine, and the security. Also - resuming uploads mechanism.
V 2.1 - add support for multiple files. This will test the final GUI, multiple file download, directory/tree or any combinations, and progress report/graph (client and server sides)
V 2.2 - the extras - such as zip/unzip
V 2.0 should be good for many people !
-
Well, I am not talking about "automatically unzipping a file", but instead asking HFS to unzip a folder when the checkbox is checked. The zip file uploaded is not for archiving but instead to speed up the upload process of a folder. (So that users do not have to select every single file in the folder + It saves some extra bandwidth because the zip file is compressed.)
you talked about servers were no-one will unzip files for you. you are acting with machines.
if you send a file to someone, he will unzip it as he wish to do it.
I don't get what you are saying but then this feature I am mentioning as I said before: not for archiving but instead to speed up the upload process of folders. And once the zip containing the folders has been extracted, HFS deletes the zip and the folder that is supposed to be upload is shown.
I hope you understand my point.
In other words, I am trying to point out that this feature is for people who want to upload folders faster, as the thread states earlier. I am not trying to request this feature so that users could "conveniently" unzip their files via HFS. I agree with you that it's no use just unzipping the zip files to it's directory if they could just unzip them their-selves. But what if the zip file is not for archival purposes? What if a user just want to upload a folder to HFS with speed? Then this feature will solve this problem. This feature also solves the problem with not being able to select a folder in the browser and upload it to HFS.
Goto http://www.1asphost.com/faqs.asp?q=15 if you want an example of what I am trying to point out.
-
I'm not sure, but I think that FTP may be incorporating internally a compression algorithm, per RFC 468.
-
we have 2 sides, hfs-side and browser-side.
on the browser-side, nothing changes, he can already do it. you already can zip, to send foders, to speed up and all things you said.
on the hfs-side. what do we need? do we need hfs unzipping our files automatically (on remote request) ? why should hfs unzip in place of me?
-
why should hfs unzip in place of me?
I agree with you, rejetto, but I think I understand the logic of the suggestion.
The answer - is "me"=the client user (uploader). Say he wants to send you a file x.txt of 100MB. The most efficiant way is to zip it (to 5M...) send it, and unzip it. He can do the zip, but cannot do the unzip, and do not want the server user to bother.
For example - this is a good procedure if you (the client) are hosting a site on the HFS server side. You take the whole site, zip the tree and send it over + unzip, and walla - you get a remote site...
Well, as I said- V 2.2 is good enough for that ... ;)
-
How are you going to send folders which contains for example 40 files in it? Because browsers (at least IE) could only browse and not upload folders, it will take really long for a user to select 40 files in different upload browse fields. At least I couldn't figure out a way to select a folder and upload it.
And to make this simpler and faster, unzipping a zip file will be convenient enough for users to upload 40 files at once. Because a zip file is only one file. And after HFS decompresses the file, the 40 files appears on HFS just as it were uploaded by different upload fields.
Do you get my point?
For example - this is a good procedure if you (the client) are hosting a site on the HFS server side. You take the whole site, zip the tree and send it over + unzip, and walla - you get a remote site...
EXACTLY! :) Same for other files as well... not just websites.
-
2 for the price of 1 ... :D
-
Thank you Rafi for expressing my point...
Maybe it's just my poor English :?
-
I'm not sure, but I think that FTP may be incorporating internally a compression algorithm, per RFC 468.
I have never heard of such thing. Hmm... :?
V 2.0 - support for single file upload. this will test the basic engine, and the security. Also - resuming uploads mechanism.
V 2.1 - add support for multiple files. This will test the final GUI, multiple file download, directory/tree or any combinations, and progress report/graph (client and server sides)
1. Would the resume mechanism be based on FTP?
2. I don't think multiple files upload will need stages because for multiple files to be uploaded, HFS will only have to store both POST data section into files.
3. What's multiple file download, directory/tree or any combinations?
4. Is progress report possible under HTTP without Java?
-
1. Would the resume mechanism be based on FTP?
the Q is for rejetto...
3. What's multiple file download, directory/tree or any combinations?
it's my mistake, I meant upload. but when you thing of it , just reverse sides, and it's for downloads too...
4. Is progress report possible under HTTP without Java?
And what if java IS needed?
Yes, look here for a live demo (#3)
http://www.aspupload.com/livedemo.html
by the way - lot's of nice stuff here : http://www.aspupload.com
BTW - maybe you have to think again , rejetto , on the FTP approach. It might reduce the attraction of the downloader since that if you use FTP, you might just want to use it for download as well. I know I said before "why invent the wheel" ... :?
-
For what I have known now, the HTTP protocol does not support resuming of files that are being uploaded. (However, it should be possible via a Java applet) Would be so grateful if someone were to be nice enough to write an open source Java applet for rejetto so that HFS uploading will support resuming. :)
In addition, I don't think progress reports are possible via HTTP because HFS cannot send a reply back before the POST command is completed. (Plus, HFS doesn't know the size of the file until the file has been uploaded or does the browser specify the size in the Boundary header?)
I agree with Rafi on the FTP part. Because HFS is designed as a HTTP server, adding a FTP server into it just makes users just the FTP part of the program instead. So what's the point of making a HTTP server if users are not using it? Maybe FTP File Server? ;)
The unzip upload capability will currently solve the issue of "multiple files" being uploaded.
-
Just two more comments -
1. upload will eventually need to be accompanied with a remote files manager, so the current HFS web-page design should be modified for it(see my screenshot above) .
2. I think we are going the worng way about the spec here. rejetto can post a short spec. of the main features he is proposing/going to put in ver 2. Others (like us...) can comment on that. That is if you like to ... rejetto... :D you can also surprise us all with a prototype... ;)
-
Just two more comments -
1. upload will eventually need to be accompanied with a remote files manager, so the current HFS web-page design should be modified for it(see my screenshot above) .
2. I think we are going the worng way about the spec here. rejjeto can post a short spec. of the main features he is proposing/going to put in ver 2. Others (like us...) can comment on that. That is if you like to ... rejjeto... :D you can also surprise us all with a prototype... ;)
1. Yes, I agree. But who is going to make that File Manager? And in what assembly language? rejetto have stated that he will need an open source Java applet in order for resuming of uploads to work. Although I am not sure on others features. (Such as progress reports etc.)
2. Good Idea!
3. Typo in "rejjeto", should be "rejetto". :lol:
-
3. Typo in "rejjeto", should be "rejetto". :lol:
Thanks, sorry about that :#)
it will be fixed in V2 RC127 ... ;)
-
1. HTTP may support file resuming on upload, via headers, but actually no client support it. useless.
2. Yes, i can't let client-side user know about progress on upload.
3. want to use HFS for web hosting? you fools :)
anyway, i think the unzip feature should be done by an external app, not by HFS, as already said, so you can use RAR as well.
4. the activex solution is to be used only on IE. and i don't use IE :). a java applet would be much better.
5. having access to files with multiple protocols is useful, IMO. the fact a user always uses FTP does not involve what other users do.
-
1. Yes, HTTP could resume if the client sends the Content-Range header in the POST command, but no browser does that because no browser knows the uploaded size of the file.
3. Ahem... In the other thread you said HFS will be meant to by a webserver. So what if a user wants to upload a folder where it has images and webpages and describes the content in HFS?
4. I agree. Since Java is cross-flatform.
5. Since you choose to implement a FTP server in HFS, what commands would it support? Would it be customizable / "disable"able? Would HFS users be able to choose the PASV range?
-
Another suggestion for unzip feature.
I think rejetto-s idea that there will be 3rd party programs
to do these things is good.
My suggestzion is that u don't have to chooose "extract me"
on upload but after uplading a file there would be a way to
unzip zipped files on the server (if u are the user who uploaded it)
A button or something.
I hope u understand me.
Sorry for my baad english.
TGeRi
-
(if u are the user who uploaded it)
Then should a new permission system be made?
IMO, it requires more work than just the classic "extract me" method.
-
hmm, i was thinking about a "call script on upload".
to fulfil tgeri's idea we need a "call script on request" (request = link).
hmmm....