Re: Problems with FTP URL's

Gisle Aas (aas@bergen.sn.no)
Thu, 06 Jun 1996 15:25:21 +0200 

In message <yahybm1mfkk.fsf@twi.tudelft.nl>, Hans de Graaff writes:
> Ok, I think I found out why this happens. The 401 code is actually
> correct, because it indicates that authorization failed (but some
> textual message would be nice to augment it).

I agree.  This patch puts the message from the ftp server in the status line.

Index: ftp.pm
===================================================================
RCS file: /f/stovner/utvikling/CVSROOT/aas/perl/mods/libwww-perl/lib/LWP/Protocol/ftp.pm,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- ftp.pm      1996/05/08 16:25:58     1.13
+++ ftp.pm      1996/06/06 13:21:53     1.14
@@ -1,5 +1,5 @@
 #
-# $Id: ftp.pm,v 1.13 1996/05/08 16:25:58 aas Exp $
+# $Id: ftp.pm,v 1.14 1996/06/06 13:21:53 aas Exp $
 
 # Implementation of the ftp protocol (RFC 959). We let the Net::FTP
 # package do all the dirty work.
@@ -96,9 +96,8 @@
     LWP::Debug::debug("Logging in as $user (password $password)...");
     unless ($ftp->login($user, $password, $acct)) {
        # Unauthorized.  Let's fake a RC_UNAUTHORIZED response
-       my $res =  new HTTP::Response &HTTP::Status::RC_UNAUTHORIZED, $@;
+       my $res =  new HTTP::Response &HTTP::Status::RC_UNAUTHORIZED, $ftp->message;
        $res->header("WWW-Authenticate", qq(Basic Realm="FTP login"));
-       $res->content($ftp->message);
        return $res;
     }
     LWP::Debug::debug($ftp->message);


> No, why does authorization fail for me, but not for Gisle? Well, I'm
> on a Solaris 2.x machine... Consider the extended debugging output of
> HEAD below:
> 
> LWP::Protocol::ftp::request: ()
> LWP::Protocol::ftp::request: cygnus FTP server (Version wu-2.4(1) Fri Apr 15 
16:06:24 MET DST 1994) ready.
> LWP::Protocol::ftp::request: Logging in as anonymous (password graaff@dutifp)
...
> LWP::UserAgent::request: Simple result: Unauthorized
> Enter username for FTP login at ftp.lspace.org: ^C
> 
> See the password? It's not a fqdn. When I changed ftp.pm to return
> graaff@dutifp.twi.tudelft.nl (by directly hacking this into the code,
> Ugh), things worked much smoother.

The right place to hack is in the URI::URL::ftp::password routine.
Currently it uses the Sys::Hostname module to find something suitable
to put after the "@" in the anonymous ftp password.  The code in
question looks like this:

BEGIN {
    $whoami = undef;
    $fqdn   = undef;
}

sub password
{
    my($self, @val) = @_;
    my $old = $self->SUPER::password(@val);
    unless (defined $old) {
	my $user = $self->user;
	if ($user eq 'anonymous' || $user eq 'ftp') {
	    # anonymous ftp login password
	    unless (defined $fqdn) {
		require Sys::Hostname;
		$fqdn = Sys::Hostname::hostname();
	    }
	    unless (defined $whoami) {
		$whoami = $ENV{USER} || $ENV{LOGNAME};
		unless ($whoami) {
		    chomp($whoami = `whoami`);
		}
	    }
	    $old = "$whoami\@$fqdn";
	} else {
	    $old = "";
	}
    }
    $old;
}

If everything else fails, perhaps you could assign to
$URI::URL::ftp::fqdn before you run your queries?

Regards,
Gisle