Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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 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.*" "*"] (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: ["" "*"] (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 ""? 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: