78279 - FTP can't view empty directories

Status: VERIFIED INVALID

(Core Graveyard :: Networking: FTP, defect)

Description

[Bradley Baetz]

Checked with a nightly from about a week ago, and my current hacked-up debug
build.

When you try to visit an empty directory, mozilla doesn't display anything. It
appears that the OnStartRequest isn't being fired, so all you get is the
</table><hr></pre></body></html> at the end (from the OnStopRequest)

If you go directly to the above url (no, I have no idea why its empty - I was
looking for a publically available server with a dir without contents), then 
the page doesn't change at all - you're left with whatever page you were on.

Comment 1

[Doug Turner (:dougt)]

Hmm.  Sounds like two problems.  The first I fixed this morning.  Basically that 
problem is that the OnStopRequest is not being forwarded when the control socket 
could not make a connection  -  a regression.  This could have cause part of the 
problem...

As for going to an empty directory, I don't see how we could bypass the 
onStartRequest.  Can you get an socket transport and ftp protocol log of this 
problem?

Comment 2

[Bradley Baetz]

This appears to only be some directories that don't work, for some reason.

ftp://localhost/etc doesn't, but ftp://localhost/dir%20with%20spaces does.

My debug build has all my patches ATM, so I've not sure how reliable my logs
are. I haven't touched anything in netwerk/protocol though. (Can you verify that
ftp://ftp.slashdot.org/pub/mozilla/ doesn't show a result for you? bz on IRC saw
the same as me (ie if you type that url into the urlbar, nothing happens) with
an unpatched build, but I can try a clean tree if you want)

This is with a build from just after the carpool this morning, so if you checked
a fix in later, I haven't got it. I'll update tomrorrow.

I'm attaching a log with NSPR_LOG_MODULES=nsFtpProtocol:5,nsSocketTransport:5,
taken with my patched tree.

./TestProtocols shows the ending </table> stuff, but not the beginning, and a
printf in my version of nsFTPDirListingConv::OnStartRequest is never hit in
these cases. I have no idea when this broke - the xul viewer works fine without
an onstartrequest, because its response to an error is just to not display any
directory contents. Which is what we'd expect in this case. (It also doesn't
work when you use that url as your start page)

I should really unpatch my build before reporting bugs like this :)

Comment 3

[Bradley Baetz]

Attachment: log

Comment 4

[Doug Turner (:dougt)]

try this patch...

Comment 5

[Doug Turner (:dougt)]

Attachment: Forwards early onStopRequests to channel

Comment 6

[Doug Turner (:dougt)]

ftp://ftp.slashdot.org/pub/mozilla/ denies my connections.  The onStopRequest 
from the socket was being dropped.  The last patch makes sure that if a stream 
converter is not set on the dataforwarder, it defaults to send back to the 
channel.  this is probabably the best thing to do.  

It also includes some stuff like making the dataforwarder be a nsIFTPChannel (so 
that you can QI it), and fixes a bug with "#" in the path.

Let me know if this helps things.

Comment 7

[Bradley Baetz]

I'm building with the patch now, but:

[bbaetz@banana bbaetz]$ ncftp ftp.slashdot.org
NcFTP 3.0.1 (March 27, 2000) by Mike Gleason ([e-mail]).
Connecting to 216.136.171.201...                                               
SourceForge Projects FTP Server [project.sourceforge.net]
Logging in...                                                                   
 
 ******************************************************
 *        Welcome to ftp.sourceforge.net              *
 ******************************************************
 
 If you find that this server is slow please try our
 much faster httpd server @
                        http://download.sourceforge.net
 
 
Anonymous access granted, restrictions apply.
Logged in to ftp.slashdot.org.                                                 
ncftp / > cd pub/mozilla
ncftp /pub/mozilla > ls
ncftp /pub/mozilla > ls -ld .
drwxrwxr-x   2 ftp      1006         4096 Apr  4  2000 .
ncftp /pub/mozilla > 

works for me, (and in ns4 as well)

I'll let you know how the patch goes.

Comment 8

[Bradley Baetz]

OK, I've now reproduced this in a build without my patches, but with yours - it
doesn't help, unfortunately. I'll attach two logs - ftp://localhost/etc doesn't
work, ftp://localhost/etcc does. Both directories are empty. Standard rh7
wu-ftpd. These logs were done with TestProtocols.

In fact, all empty 3 letter directories don't work, (at least on localhost - I
also tried 127.0.0.1, and my dynamic hostname from my ISP, and those don't work
either). I can't find a remote server to test that on though.

The "started loading" output of TestProtocols doesn't appear for the first case,
but does for the second. Something is definately causing the OnStartRequest to
be lost.

Oh, and the #ifdef debug printf in your patch needs a .get().

Comment 9

[Bradley Baetz]

Attachment: ftp://localhost/etc - this doesn't work

Comment 10

[Bradley Baetz]

Attachment: ftp://localhost/etcc - this does work

Comment 11

[Doug Turner (:dougt)]

hmm.  Lets treat this as two seperate problems until we know that they are the
same.  First the ftp.slashdot.org problem, for whatever reason I can not connect
to that site.  netscape 4.x does not connect, and ncftp does not connect either:

Anonymous access granted, restrictions apply.
Logging in...                                                                  
                                                                               
                                                                               
                    
Logged in to ftp.slashdot.org.                                                 
                                                                               
                                                                               
                     
ncftp / > ls
ls

connect failed: Connection refused.
Falling back to PORT instead of PASV mode.


With my patch, you should be seeing a dialog that indicates this.
 

As for the localhost problem, you got me.  There was another bug I was reading
where localhost connects had problems.  I need to set up wu-ftp on my linux box
and take a look.  

Comment 12

[Bradley Baetz]

> connect failed: Connection refused.
> Falling back to PORT instead of PASV mode.

You're behind a firewall, aren't you? I can ls other directories, so thats not
the problem from my end. However, if I tell ncftp "set passive off" then it does
hang.

Oh, and the ftp://localhost stuff now Just Works. I'm not aware of doing
anything to the local directories, but I may have. As an aside, if you try to
ftp to a directory which you don't have permission for, you don't get an error -
you get the same symptoms I got before Maybe that was my problem originally, and
I accidentally deleted and recreated the directory?

Sigh. Feel free to close this out as INVALID, then, unless you want to morph it
into a bug for displaying an error in that case.

Comment 13

[Doug Turner (:dougt)]

okay

Comment 14

[benc]

VERIFIED:
opening empty directories is already in the testcases. Just let me know if there
are other situations you want tested as a result of the problems discussed here.