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:[EMAIL PROTECTED]/
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:[EMAIL PROTECTED]/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-
[EMAIL PROTECTED] wrote:
>
> On Mon, Sep 25, 2000 at 04:20:10PM -0500, [EMAIL PROTECTED] wrote:
> > Thanks, Michal...
> >
> > But I believe the services on the host(s) are correct.
> >
> > It seems that I get a similar message whenever I try to connect from
> > REBOL (either on the HP-UX box or my desktop box running Linux)
> > to ANY ftp server.
>
> It looks like you have configured a generic proxy server for REBOL,
> and that server may no longer exist or may not be working correctly.
> That also explains why all FTP connections appear to be based on
> HTTP.
>
> Please check the set-net call in your user.r file and, if you don't
> need a proxy server, change "generic" to "none".
>
> --
> Holger Kruse
> [EMAIL PROTECTED]