Open Bug 90695 Opened 23 years ago Updated 7 years ago

FTP/html - directory listing lacks welcome message

Categories

(SeaMonkey :: UI Design, defect)

defect
Not set
normal

Tracking

(Not tracked)

People

(Reporter: neil, Unassigned)

References

()

Details

(Keywords: embed, helpwanted)

Attachments

(2 files)

 
Attached file Mozilla's listing
Attached file 4.x listing
You are absolutely right
I am marking this one as an enhancement
Improving summary
Severity: normal → enhancement
OS: Windows 95 → All
Hardware: PC → All
Summary: FTP directory missing message and icons → [RFE] FTP listing lacks welcome message and icons
<rant type="No Clue Why I'm Even Doing This But...">
I don't intend to start any arguments here, and if I'm wrong, then that's fine.
 I've been wrong before and I'll be wrong again.  But I have been sort of
bothered by the RFE on this, Francisco.  With all due respect, I fail to see how
it is merely an enhancement.

First, it makes our rendering look bad even though it is not the case. The
current implementation is ugly.

Second, IE and 4.x provide for it and virtually every FTP server uses a .message
that we should be displaying.

Furthermore, the .message often contains useful information to convey to users.
 To an FTP admin, not displaying their .message is almost like not displaying a
license agreement upon install (maybe not that severe but you get the point).

And the icons, well they should be there too. If I remember correctly, older
versions of Mozilla used to have an Explorer-like tree view with icons.

Lately I haven't noticed this bug because I have been on contract and mainly use
FTP sites that I have regular accounts to with an FTP client or the nightly
builds area at (http://ftp.mozilla.org/pub/mozilla/nightly/) and never noticed
that the nightly builds were via http protocol instead of ftp.  Surely we can
list FTP sites the same way as we list HTTP directories such as the Mozilla
nightlies!

Can we mark this as severity: normal and not just an enhancement?  This should
already work. Maybe it's a little late to target for 0.9.3, but 0.9.4 would be
nice. In any case, I think this should definitely be fixed by Mozilla 1.0.
Imagine if M$ used this design for their directory listings.  Maybe I'm just
crazy for even bringing this up, but it's how I feel. It just totally shocked me
to see this marked as enhancement, but then again, maybe I'm just missing something.
</rant>
It does not matter if this is an enhancement or a normal bug
To you, it only matters if the developers are going to implement this
The bug is already opened so it does not matter. If the developers feel up to
it, they will increase the severity
Why is this an enhancement? Because we are taking a working feature and adding
more functionality
As i said, it does not matter. It only matters that the developers agree on this
Keywords: helpwanted
Target Milestone: --- → Future
+ qawanted: Is there documentation as to the types of files we should auto parse? 
If so, please outline what specific behaviors should be added. Please put them
in priority order.
Keywords: qawanted
I dont know if there is any known documentation, but we can investigate this by
just visiting some popular ftp sites and watching what files do they use to load
welcome messages
Also, this varies by the ftp server the site uses
Here is a list of icons that I know of.
It is not intended to be complete or authoratitive.

<dir>   internal-gopher-menu
.ai     internal-gopher-text
.au     internal-gopher-sound
.bat    internal-gopher-unknown
.bmp    internal-gopher-image
.eps    internal-gopher-text
.exe    internal-gopher-binary
.fif    internal-gopher-image
.gif    internal-gopher-image
.htm    internal-gopher-text
.html   internal-gopher-text
.jpe    internal-gopher-image
.jpeg   internal-gopher-image
.jpg    internal-gopher-image
.latex  internal-gopher-text
.mov    internal-gopher-movie
.mpe    internal-gopher-movie
.mpeg   internal-gopher-movie
.mpg    internal-gopher-movie
.mpv    internal-gopher-movie
.pbm    internal-gopher-image
.pcd    internal-gopher-image
.pdf    internal-gopher-text
.pgm    internal-gopher-image
.pl     internal-gopher-unknown
.png    internal-gopher-image
.ppm    internal-gopher-image
.ps     internal-gopher-text
.ra     internal-gopher-sound
.ram    internal-gopher-sound
.ras    internal-gopher-image
.rtf    internal-gopher-text
.tif    internal-gopher-image
.tiff   internal-gopher-image
.txt    internal-gopher-text
.vbs    internal-gopher-movie
.xbm    internal-gopher-image
.zip    internal-gopher-unknown
The closest to documentation I could come up with is RFC 1635
(http://www.faqs.org/rfcs/rfc1635.html), but that isn't much help.  It lists a
few suggestions for filenames in there, mainly README which is always a good
choice, or "something similar (00README.1ST, AAREAD.ME, INDEX, etc.)"

Also, many unix machines use either .message or .welcome.  And WU-FTPd uses
"banner.msg" or "welcome.msg".  The confusing part about this though is that in
both WuFTPd and ProFTPd (two popular free FTP servers on *nix) you can configure
your welcome message to be something totally wacky like "GOODBYE".  It seems
thus that there is some communication by the server.  I just don't know what it
is.  Maybe someone else has a better knowledge of this?
-qawanted b/c this bug has enough info to define the problem. (Thanks!)

Oddly, I think this is working in FTP-Proxy mode (bug 91610).

I'll create a test account on my ftp proxy if anyone in this bug wants to look.
Keywords: qawanted
Is this because FTP proxies do their own HTML directory conversion?
Good point. Probably what is happening. I need to read the ftp URL -> HTTP proxy
spec, but I've never been able to find it.
I am increasing severity to normal. Icons arent really that much functional but
the welcome messages are important. 
Adding 4xp since netscape does exactly what we need to implement here
How about we get this fixed for 0.9.4?
Severity: enhancement → normal
Keywords: 4xp, mozilla0.9.4
Summary: [RFE] FTP listing lacks welcome message and icons → FTP listing lacks welcome message and icons
It is not that easy.  What I would rather see is someone rewrite the directory
viewer so that it is quicker.  The current directory viewer (in Modern) already
has what you are asking about.  
ftp://metalab.unc.edu
Check that one, and you will just see the folder names , date, size, and type
(am and pm is too close to the type)

Now click on the readme file. 
"We're using wu-ftpd.  You can get tarred directories if you issue 
the following command: 

    get dirname.tar

  You can also get gzipped or compressed tarred directories by 
following the .tar with .gz or .Z, respectively. "

*Hint, Hint* fixing this would make the suggestion for that other bug easily done.
Doug, I have to agree.  Bug 60446 has a plan for improving the Directory Viewer
and to be honest, if we were to re-do the directory view, I would most like to
see the implementation be done the way 60446 suggests. Should we make this bug
dependent on 60446?

I still think that we should offer the ability to gain the FTP directory
messages by version 1.0 -- whether it's just searching for the file and adding
it to the top of the current listing or re-designing the directory view.  As I
mentioned earlier, it contains useful information and Francisco pointed out one
example.  Another one is ftp://ftp.suse.com/pub/suse/i386/7.2/suse - the index
tells you what to expect in each folder.  True you could just go randomly
searching, but that isn't efficient.  This is a small aesthetic change with a
big impact.  Icons are nice, but not critical to this bug.  The message is what
 I am clamoring for most.
we need to find an owner for these bugs.  maybe someone in xptoolkit - or maybe
someone taking some of my current workload so that I can hack this out.  Until
then, these are going to remain helpwanted :-( :-( :-(
I still dont see why this has helpwanted set in. Netscape developers already
have the code made in netscape 4.7x
We know what we need to do, and the ns guys working on mozilla have the code
BAD ASSUMPTION!!!!!  Mozilla netlib has been totally rewritten.  We can't just
slap the old stuff back in and have it work...
Well of course it can't be that easy or it would already have been fixed :)
At least is a headstart. Like i said i dont really care about the icons, i care
more about the welcome message in sites , then i care about text alignment (the
am and pm are too close to the type) and lastly icons
This really should be catfood for reasons already mentioned.  Nominating.
Keywords: nsCatFood
You know, we can't just grab the README file and display it's contents either. 
The server does variable substitution on these sometimes.  See
ftp://ftp.uky.edu/  --> welcome.msg
I meant to say we can't just display the message file above.

Anyway, I kind of agree with Francisco here.  Why should we re-invent the code?
 When Einstein found the theory of relativity, did Russia just ignore his work
and try to do it from scratch?  No.  They just translated it into Russian. 
Liekwise, we can port the existing code to Mozilla.  OK, lame example, but we
have an implementation that at the very least an algorithm can be constructed
from.  See what it's doing, and then with that idea, make it work in Mozilla. 
There's obviously issues here that if we just talk and decide what it needs to
do, there might be something left out.  Can someone at least post the algorithm
and leave that up for discussion/porting by others?
even if bug 60446 is fixed this bug is still valid. I think that users should
still be allowed to use HTML based ftp listing as an alternative to directory
viewer.
basic, I agree with you.  In html view, there should be icons and whatever text
message the server sends.  However, this is not a high priority for me.  

If anyone is interesting in hacking on this, let me know and I will outline what
needs to be done.
christopher:

you might find it amusing to know that Soviet history (not necessarily Russian)
promulgated a variety historical events where Soviet scientists and inventors
"invented" or "discovered" technology or science that was discovered in other
countries. I believe things like TV, the airplane, and radio were included here.

so, i guess the next logical step would be to 'invent' welcome messages and
icons.  ;-)
You could probably "discover" them in the original open source release of
Communicator. The point in regards to Doug was that it was non-trivial to make
it the same, and he (being a hardworking badged Netscape engineer) had a tight
schedule.

I don't think anyone would want to have someone reverse engineer the look and
feel when we just need to copy it.
Well I've looked up how the welcome message works in Classic.
When logging into a FTP server, and again when CWD to the folder,
the server MAY respond with an extended message response code "250-".
These lines get saved so that they can be used in the listing.
bryner, should this belong to you now?
Assignee: dougt → bryner
Component: Networking: FTP → XP Apps
QA Contact: tever → sairuh
Target Milestone: Future → ---
I'll take it. I have the icons working.

The welcome message for the XUL viewer may be harder, though, so I may pass on
that.
Assignee: bryner → bbaetz
Depends on: 78148
The icons are taken care of in my rewrite. A welcome message will need backend
ftp work, though.

-> 0.9.7, although I may bring this in a bit.
Priority: -- → P3
Summary: FTP listing lacks welcome message and icons → directory listing lacks welcome message
Target Milestone: --- → mozilla0.9.7
*** Bug 100691 has been marked as a duplicate of this bug. ***
changed summary to improve searchability.
Summary: directory listing lacks welcome message → FTP/html - directory listing lacks welcome message
The only message we will be displaying is what the server sends us, which is
usually the contents of welcome.msg, but depends on the server, and is probably
customisable. (ie comment 29 is correct. We will not be auto-parsing anything,
and I'd be really surprised if someone else does)
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.7 → mozilla0.9.9
-We need to know what files we are going to load. I dont know the protocol too 
much, but as said above, some servers may "suggest" what file we need to open, 
so we dont have to check for a specific listing (and this would be somewhat 
easy and fast)
-However, i am really sure that we can port some algorithms from netscape 4.x 
(the logic that makes the welcome message read possible)
-That variable substitution stuff is important. "you are user x of y, connected 
from %ip, with %hostname" stuff like that

Also, this is pretty offtopic, but will mozilla sometime be able to use active 
ftp instead of passive?
1) The server doesn't hint anything, and we don't open files - It sends the
response back as part of the response message.2) Thats what the mozilla classic
code does, so theres no algorithm to port
3) Thats the server's responsibilty - how are we meant to know how many users
are currently connected?

mozilla can't use active ftp until we support server sockets. search for an
INVALID bug with PORT in the title, < 10000, IIRC. When we support server
sockets, then maybe we'll do it. Its unlikely to be a high priority, though.
1) So what does exactly the "response message" look alike? Is the "welcome" 
text also sent in the ftp connection itself? I thought it was just a file read
2) If mozilla classic does it then why isnt this fixed already?
3) I agree that the server has the responsability, but as said highly above in 
comment #22, we cant just read the file
The welcome message is sent back from the server as the first response on the 
control connection. Here's a protcol log from Mac:

Receive data (24 bytes).
>00000000> 220-ftp.idsoftware.com  

Receive data (421 bytes).
>00000018> 220------------------------------  
>0000003B> 220-Welcome to ftp.idsoftware.com  
>0000005E> 220------------------------------  
>00000081> 220-  
>00000087> 220-Connection from 64.236.139.254 logged  
>000000B2> 220-You are user 113 of 225 available connections.  
>000000E6> 220-  
>000000EC> 220-Average throughput for this server is 1197.611 KBps.  
>00000126> 220-40997 people have visited this site in the last 24 
>0000015D> hours.  
>00000165> 220-  
>0000016B> 220-Please e-mail xian@idsoftware.com if you encounter 
>000001A2> any problems.  
>000001B1> 220-  
>000001B7> 220   

Send data (16 bytes).
<00000000< USER anonymous  

Receive data (70 bytes).
>000001BD> 331 User name okay, please send complete E-mail address 
>000001F5> as password.  

My guess is that the FTP protocol currently throws that data on the floor.
We keep it, we just don't do anything with it.

This bug is my most-likely-to-fall-back-into-0.9.7 bug, if I get time.
-> 1.0
Target Milestone: mozilla0.9.9 → mozilla1.0
feature, -> 1.1
Target Milestone: mozilla1.0 → mozilla1.1alpha
+nsbeta1, topembed
Keywords: nsbeta1, topembed
benc: If NS wants this, then someone else will have to work on it; I'm unlikley
to hgave much time for the next few months.
Understood.
Keywords: topembedembed
Keywords: mozilla1.3
Note my configured welcome message "Welcome, you are connecting from %IP"
It shows up in the 230 message.


C:\>ftp myhost
Connected to myhost.
220-FTP Server ready ...
220 Welcome to myhost FTP server, 
User (myhost:(none)): ftp
331 User name okay, please send complete E-mail address as password.
Password:
230-Welcome, you are connecting from 192.168.0.1
230 User logged in, proceed.
ftp> ls -l
200 PORT Command successful.
150 Opening ASCII mode data connection for /bin/ls.
adt: nsbeta1-
Keywords: nsbeta1nsbeta1-
ProFTP server configuration has options to send login and chdir messages, so I'm
sure 220 is the .welcome before login and 230 is the .welcome after login (this
is also a server config option). I can experiment to see if this is actually the
case.
As for directory .messages it's 250-
----
CWD A-Folder
250- This is just a test
250-This message displays when you change to this directory
250-
250 CWD command successful.
PWD
257 "/A-Folder" is current directory.
PORT 66,43,14,164,5,39
200 PORT command successful
LIST 
150 Opening ASCII mode data connection for file list
Received 65 bytes in 0.1 secs, (650.00 Bps), transfer succeeded
226-Transfer complete.
226 Quotas on: using 316.87 of 51200.00 kilobytes
----
You certainly can't search for messages and display them because they are often
hidden files. They are only there so that the server knows what message to send,
and the message file name is defined in the server config.
*** Bug 235980 has been marked as a duplicate of this bug. ***
Product: Core → Mozilla Application Suite
Assignee: bbaetz → jag
Status: ASSIGNED → NEW
Priority: P3 → --
QA Contact: bugzilla
Target Milestone: mozilla1.1alpha → ---
Assignee: jag-mozilla → nobody
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: