The attached message may be the one Daniel referred to. It shows what I
did to coerce SpiderMonkey into processing proxy-autoconfig files to
determine if I had to use a proxy or not. It worked at the time, but I
haven't hardly used it since - the need went away with a networking
change...

Even though it's from Mozilla, I don't know if it would do a good job of
processing html/javascript. It seems like it's just the javascript
engine, and significant other stuff has to be wrapped around it to
integrate it with a browser. Sounds like:

        http://bfilter.sourceforge.net/

may be a better way to go.

Ralph Mitchell

Dan Fandrich wrote:

>On Mon, Aug 16, 2004 at 04:33:06PM +0200, Alexander Lazic wrote:
>
>
>>On Mon 16.08.2004 16:06, Daniel Stenberg wrote:
>>
>>
>>>[*] = They call it Spidermonkey: http://www.mozilla.org/js/spidermonkey/
>>>
>>>
>>You can also find an nice js-handling in the
>>http://bfilter.sourceforge.net/.
>>
>>The nice part, for me, is how this SW handle the browserspecific objects
>>such as document, window, ... .
>>
>>al ;-))
>>
>>
>
>The NJS JavaScript Interpreter is LGPL and designed for embedding:
>http://www.njs-javascript.org//
>
>
>
>>>>Dan
>>>>
>>>>

attached mail follows:

Anybody that wants to try it on their own .pac scripts:

    1) Fetch the javascript interpreter from Mozilla.org
(ftp://ftp.mozilla.org/pub/js). the current version is js-1.5-rc4a.tar.gz.

    2) Unpack the tar file, go into the js/src directory and build the
standalone javascript interpreter with: gmake -f Makefile.ref

    3) You'll find the interpreter under a subdirectory named like your platform
type (I guess). On my RedHat Linux box the path to it is:
js/src/Linux_All_DBG.OBJ/js

    4) The tricky part was finding the 12 builtin scripts. The file they're in
is called nsProxyAutoConfig.js, and it's somewhere in the Mozilla.org tree.
Sorry, I can't be more helpful with that - I found it via the search engine...
Approximately halfway down the file you'll find "var pacUtils =" followed by the
builtins. I extracted them to another file and removed the extraneous quotes
and \n"+ characters.

    5) Add your .pac file to the end of the builtins, add a further line that
looks something like this:

            print (FindProxyForURL("http://curl.haxx.se/", "curl.haxx.se"));

    6) Push the whole mess through the javascript interpreter:

            js/src/Linux_All_DBG.OBJ/js myproxy.pac

Depending on the URl you paste on the end, you should get "DIRECT", or
"PROXY proxy.yourdomain.com:80" or something similar.

OK, this is not the greatest hack in the world, but it kinda sorta works...
Something along the lines of:

    #!/bin/ksh

    curl -o proxy.pac http://proxy.mydomain.com/proxy.pac
    proxyornot=`echo "print (FindProxyForURL(\"http://curl.haxx.se/\",
\"curl.haxx.se\"));" | \
        cat builtins.pac proxy.pac - | js`

    if [ "$proxyornot" = "DIRECT" ]; then
        curl ......
    else
        # some other stuff to extract the proxy name from the variable and paste
it into
        # the curl call...

will tell you if you need to use your proxy or not. Of course, it would be
really nice to see this embedded in cURL... :) That's going to take some
effort, I think, though there are notes on Mozilla.org regarding embedding the
javascript interpreter into an application. I just haven't had time to pursue
that yet.

Ralph Mitchell

Daniel Stenberg wrote:

> [snip...] I guess the next step would be you telling us how to proceed to
> build this
> test setup you used to verify this. Then we need to incorporate this into
> libcurl in a suitable fashion.
>
> It would basicly be a little libcurl-using client within the library itself,
> that would fetch the .pac first, and pass it through SpiderMonkey to figure
> out the correct proxy setting and the proceed. The .pac file would then
> probably be cached internally and the proxy gets re-evaluated whenever a new
> URL is used.
>
> --
> Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/

-------------------------------------------------------
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer for OSDN members!
JabConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn
Received on 2004-08-17