Heath, Thanks. I have since discovered that the recent access problems I had coincidently were due to server access issues which the IT support have fixed.
So for all readers, as normal, Heath's Authoxy was actually working just fine, but the 'other end', by freak coincidence, had the issues, not authoxy. On the matter of the CGI script I previously received the very short tech support reply that 'authoxy is not supported' and that the cgi script works just fine for windows. It seems the firewall has a culture too! Keep up the outstanding work Heath! Kurt .. on 3/2/04 8:04 PM, Heath Raftery at [EMAIL PROTECTED] wrote: >> Hi Heath, etal. >> >> Two things, >> >> ONE: >> I have noticed that since updating to authoxy 3, both on Panther >> 10.3.2 and >> Jaguar 10.2.8, some odd things happen. In Jaguar, Authoxy 3, when the >> daemon in running (127.0.0.1) it too often loses its port dropping to >> 'unknown'. This seems to cause failure to access the net, in my case >> via >> system prefs>softwareupdates. I noticed if I turn authoxy off then on >> again, it correctly establishes the port (8080) and I can then >> successfully >> execute the SWUpdate function. However, in Panther, using Authoxy >> 3.0, I >> seem to be able to do the SWUpdate, even when port unknown is shown. >> Is >> this issue known? I am thinking I may need to go back to v2.3 of >> authoxy >> for jaguar10.2.8. ??? > > This is, and always has been, by design! Looks like I need to revise > the interface there. The thing is, when the Preference Pane is used the > start the daemon, the PP knows the port number it used to start the > daemon with. After you close System Preferences and re-open it, there > is no way for the Preference Pane to know whether it started the > daemon, whether the port number has changed since, whether startAuthoxy > was used to restart the daemon, or whether the preferences has changed, > so to be safe it reports the port as "unknown". The daemon will > continue to run on the port you started it, completely independent of > the status reported in the Preference Pane. > > I realise this really should be made clearer. > >> TWO: >> I know I have mentioned it before, but my university technicians won't >> budge >> on the issue that our autoproxy script is correctly written and >> functioning >> just fine, eventhough its not compatible with Macs (perceived as >> another >> weak feature of macs I think). One technician reckons Mozilla and an >> old >> netscape version used to handle *.cgi autoproxy scripts, but that now >> both >> don't either on Macs. We use the following script: >> <http://config.scu.edu.au/cgi-bin/proxy.cgi> >> >> The position is that the *.cgi script is working just fine, they see no >> reason to move to *.pac. >> >> What is the difference between a *.pac and *.cgi auto proxy anyway? >> Can Authoxy be tweaked to specifically accommodate a *.cgi autoproxy >> script >> and/or a *.pac autoproxy script somehow? > > The difference is minimal. The .pac is a text file sitting on a server > ready to be parsed by the Javascript interpreter in Authoxy. The .cgi > is (usually) a Perl script sitting on a server ready to be executed by > the server, and returns a text file which is the pac file. This should > all happen behind the scenes. When you request a pac file from the > server, it should just return the pac file. When you request a cgi > script from the server, the server should execute the script and return > you the result. > > The problem with the cgi script, as we have both demonstrated in the > past, is that the server is unable to execute it. It returns a failure, > meaning the server can't execute it. Your admins need to understand > this: > > ***the problem lies on the server side*** > > You need to show them the output of any or all of the following: > > * Any browser navigating to http://config.scu.edu.au/cgi-bin/proxy.cgi > * % curl http://config.scu.edu.au/cgi-bin/proxy.cgi > * % telnet http://config.scu.edu.au 80 > % GET /cgi-bin/proxy.cgi HTTP/1.0 <control-V> <return> <return> > > Where % means "at the Terminal prompt". > > I believe we have already established that any of these methods will do > the same thing they do from my end - return a html page from the server > telling us that an internal error occured. Before Authoxy can do > anything at all, this needs to be fixed. If your admins don't > understand this, perhaps they should call me. Perhaps not too, I can be > pretty short-tempered if I think they are BS'ing their job. *************************************************** Dr Kurt Seemann Senior Lecturer Member: Curriculum Innovation and Learning Technology Research Course Co-ordinator for (BTechEd/Honours) School of Education Coffs Harbour Education Campus Southern Cross University Hogbin Dr, Coffs Harbour, NSW, 2457 Tel/VoiceMail: (+61-2) 6659-3627 Mobile: (040) 853-6309 Fax: (+61-2) 6659-3624 E-mail: [EMAIL PROTECTED] Web: <http://www.scu.edu.au/technologyeducation/> *************************************************** "Education is a progressive discovery of our own ignorance". Will Durant Notice: The information contained in this e-mail message and any attached files may be confidential information, and may also be the subject of legal professional privilege. If you are not the intended recipient any use, disclosure or copying of this e-mail is unauthorised. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and delete all copies of this transmission together with any attachments.
