A series of attempts to read directory listings from FTP servers. This is
all Rev 1.1, on MacOS 9.1, on TiPB G4. Simple script, a button with a
mouseUp script that assigns an ftp URL to a variable 'theURL', and then does
put theURL into fld 1
put url theURL into fld 1
get the result
answer "Result:" && it & return & "URLstatus:" && URLStatus(theURL)
a) Attempting to read a directory listing with the wrong username and
password: value is empty, and result is empty.
It would be an upgrade if "the result" was set to something like "530 Login
incorrect" in this case.
... ah - since originally writing this, I note that URLstatus returns
"error-Password incorrect" in this case. I thought that URLstatus only
worked for URLs in the cache. Is there any reason why the blocking commands
(ie "put URL xxx") shouldn't set "the result", which would seem more
natural? If nothing else, the documentation needs changing if this
situation is not changed, since it describes URlstatus as applying to URLs
started with the "load" command.
b) on the same server, with the right password, Making the request for a
listing never returns. (It's a bit odd: the IDE is not frozen, but the
script never gets to the statement following "put URL xx into yy". Editing
this script brings back the watch cursor, but otherwise the IDE seems
generally normal.) I've done this repeatedly while watching traffic with
interarchy; in each case Revolution opens three streams. It succesfully
logs in, requests a directory listing, and gets it. It sends an orderly
release, and then an unbind request for the third stream, and gets an ok
acknowledgement; sends an unbind request for the second stream, and gets an
ok acknowledgement; then sends an orderly release request for the first
stream - and that's it. This is with a request to the top level. If I dig
a directory name out of the listing that I can see in the traffic watch, but
which was never returned by Rev, this returns. That is:
put URL "ftp://user:[EMAIL PROTECTED]/"; -- never returns
put URL "ftp://user:[EMAIL PROTECTED]/subdir/"; -- works fine
(At one point it seemed as if I could get a result by typing command-M),
which would 'magically' unblock the first case. I can sometimes, but not
always, repeat this trick.)
A second server returns a listing of both root directory and sub-directory
fine.
A third server I tried returned a listing of the root directory fine, but
when I tried for a listing of the sub-directory, the URLstatus returned
"requested", and Interarchy's traffic watch reveals that the server returned
550 /subdir: The system cannot find the file specified.
(and I double checked: my request did have a final "/" after the
sub-directory name).
(I can supply stream transcripts for these if that would be useful.)
c) a question: does the FTP library use 'passive' mode or not? Or is there
some way to configure this - I couldn't detect it in the documentation? I
know that I recently found a problem with BBEdit's 'edit from FTP' facility,
which on certain servers went into an endless loop (didn't actually freeze,
but couldn't be cancelled) - this was avoided when I told BBEdit to use
passive mode.
d) On another server, the password I've been given, and have no direct way
to change, includes an "@" symbol! I appreciate that
"ftp://user:password@server"; is a standard convention; but it would be an
upgrade if the URL library would apply URLdecode to the username and
password. Normal passwords would not be URLencoded, but would pass straight
through anyway; but that would allow strange passwords such as this one to
be used succesfully. And come to think of it, isn't the original netiquette
convention for anonymous FTP access to pass username as "anonymous" and your
email address as password? In this case, anyone wanting to be polite would
need to be able to pass a password containing "@" (an email address) to the
URl library.
Please let me know if you need more information on these experiences - or if
you can help me work round them!
Ben Rubinstein | Email: [EMAIL PROTECTED]
Cognitive Applications Ltd | Phone: +44 (0)1273-821600
http://www.cogapp.com | Fax : +44 (0)1273-728866
