[REBOL] FTP problems -- mystery. Re:(4)
From: joel:neely:fedex at: 25-Sep-2000 19:43
I'm passing this status report back to the list in case someone
else gets bitten by a similar problem.
SHORT VERSION: I have enough of a clue to get a workaround going,
but still have concerns about how well REBOL and
the corporate proxy server (Squid) are getting along. I also have
what appears to be a bug in REBOL's handling of .../proxy/bypass
entries.
LONG VERSION:
That thunderous CLICK! you heard a while ago was the light going on...
I tracked this down with RickM, our intrepid sysadmin, looking over my
shoulder (credit where credit is due).
As Holger suspected, I did have a generic proxy server configured.
This had been working since mid-April, and was necessary to get 'net
traffic through our firewall (little useful things like 'upgrade!)
The server software (Squid/2.3.STABLE2) and/or its configuration
have changed in a way that is no longer compatible with REBOL. I can
still hit the desired ftp server from within Netscape by using a URL
of the form
ftp://userid:[password--1--2--3--4]/
and get a listing of the top-level ftp directory space. If I use
only the URL
ftp://1.2.3.4/
I get an error message from Squid stating (correctly) that the server
in question does not allow anonymous connections. Squid's error
message, of course, is returned as HTML.
If I disable proxy configuration for REBOL (comment out the set-net
call in user.r) the ftp connection works. Re-enabling the proxy
setting (de-commenting set-net and restarting REBOL) gets me the
timeout again.
Soooo...
Turning to Carl's draft version of REBOL Network Protocols, I tried
adding to user.r (after the set-net call) the line
system/schemes/default/proxy/bypass: ["1.2.*" "*.fedex.com"]
(where the "1.2." was actually the prefix of the class B network in
which the long-sought ftp server lives). Relaunching REBOL and
attempting the same read ftp://... command as before now gets me
a response of
>> foo: read ftp://xxuseridxx:[password--1--2--3--4]/path/file.txt
** Script Error: Cannot use write on this type port.
** Where: write-io sub-port #{05020002} 4
read-io
>>
Hmmm... So maybe wild-carding doesn't work on dotted quads???
Next attempt: Go back to user.r and insert the lines
system/schemes/ftp/proxy/host: false
system/schemes/ftp/proxy/port-id: false
system/schemes/ftp/proxy/type: false
after the set-net call. Try to run script. IT WORKS!
Next attempt: Assuming that my earlier problem was trying to use
a wildcard in a dotted-quad host identifier, I commented out the
three lines above and changed the proxy bypass setting per
system/schemes/default/proxy/bypass: ["1.2.3.4" "*.fedex.com"]
(where, of course, the read address appeared instead of the bogus
class A address above). Again, I get a response of
** Script Error: Cannot use write on this type port.
** Where: write-io sub-port #{05020002} 4
read-io
So, I'm now inclined to conclude that dotted quat host identifiers
(as string data) are not acceptable in the .../proxy/bypass list.
After re-inserting the .../ftp/proxy/... lines above (between the
set-net call and the .../proxy/bypass: setting) I get the transfer
to work correctly.
All of the above experimentation has been done on the HP-UX box.
After inserting the .../ftp/proxy/...: false lines into user.r
on my desktop Linux box, it too is able to connect to the ftp
server that is the object of my afflictions.
QUESTIONS: I'm still concerned about some things here:
1) Why does a URL of the form ftp://user:[pass--host]/path/file.ext
work for Netscape, but not for REBOL?
I'll try to track down some SquidVolk on our side and find out
what they changed before following up on this question.
2) Is "1.2.*" supposed to work in a .../proxy/bypass list? What about
"1.2.3.4"? I know it's lame that the sysadmin of the ftp server
gave me a dotted quad instead of a host name, but that IS a valid way
to identify a host. These strike me as legimate bugs, unless someone
can point out something dumb that I did (or should have done).
Thanks!
-jn-
[holger--rebol--com] wrote: