On 01/02/2004, at 12:54 AM, Kurt Seemann 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.

Heath
--
 ________________________________________________
|   Heath Raftery                                |
|   [EMAIL PROTECTED]                       |
|   *He who knows others is wise;                |
|       he who knows himself is enlightened*     |
|                       - Lao-Tzu     _\|/_      |
|____________________________________m(. .)m_____|



Reply via email to