automatic configuration evaluation error

[bergmannm]

Hi,
I'm getting errors when evaluating PAC script.

Caused by: jdk.nashorn.internal.runtime.ParserException: :8:2 Expected an operand but found else
else return "PROXY proxy:3128";
^
at jdk.nashorn.internal.parser.AbstractParser.error(AbstractParser.java:294)
at jdk.nashorn.internal.parser.AbstractParser.error(AbstractParser.java:279)

It's caused by semicolons before else , nashorn scripting engine doesn't like that.

` function FindProxyForURL(url, host)
{
if (shExpMatch(host, "deploy.abc.eu") ||
shExpMatch(host, "asp.abc.eu")
)

        return "PROXY proxy:3128";

    else if (dnsDomainIs(host, "localhost") ||
             dnsDomainIs(host, "127.0.0.1"))
return "DIRECT";
    else
    return "PROXY proxy:3128";
}`

Rhino scripting engine ( https://mvnrepository.com/artifact/org.mozilla/rhino/1.7.10 ) can evaluate this script correctly, what do you think about using it instead of nashorn ?

[gschnepp]

This library has changed from Rhino to Nashorn with version 1.0.5 for a smaller footprint only:
- Fixed issue #40: Using delight-nashorn-sandbox to avoid dependency on rhino

I by myself have other problems with PAC script parsing, which may have to do with the same problem: Please see [issue #50 in closed issues]. Closed not because the base problem with PAC script parsing has been solved, but because of a better exception handling. The base problem results from a non-parsable PAC script which I was not able to get from customer to analyze this by myself. It may be their script is correct, but Nashorn engine in 1.0.5 is not willing to parse it as desired.

I definitely vote for a change back to Rhino, since you were able to drill this problem down to the inconsistent JavaScript parsing behavior of Nashorn. Thank you very much. Appreciate it!

Guido

[MarkusBernhardt]

Hi all, should we make that configurable? Default is ? Cheers, Markus From: gschnepp <notifications@github.com> Reply-To: MarkusBernhardt/proxy-vole <reply@reply.github.com> Date: Monday, 12 November 2018 at 12:04 To: MarkusBernhardt/proxy-vole <proxy-vole@noreply.github.com> Cc: Subscribed <subscribed@noreply.github.com> Subject: Re: [MarkusBernhardt/proxy-vole] automatic configuration evaluation error (#61) This library has changed from Rhino to Nashorn with version 1.0.5 for a smaller footprint: - Fixed issue #40: Using delight-nashorn-sandbox to avoid dependency on rhino I by myself have other problems with PAC script parsing, which may have to do with the same problem: Please see issue #50 in closed issues. Closed not because the base problem with PAC script parsing has been solved, but because of a better exception handling. The base problem results from a non-parsable PAC script which I was not able to get from customer to analyze this by myself. It may be, that their script is correct, but Nashorn engine in 1.0.5 is not willing to parse it correctly. I definitely vote for change back to Rhino, since you were able to drill this problem down to the inconsistent JavaScript parsing behavior of Nashorn. Thank you very much. Appreciate it! Guido — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[gschnepp]

How would you make that configurable since the decision of what java_delight_*-library is to be used is hardcoded in the POM? May be I just don't know how to achieve configurability here.

But Nashorn engine is deprecated or will be marked deprecated by Oracle shortly as announced months ago. So proxy-vole needs another Javascript engine the long run in any case. Oracle's favorite scripting engine is Graal-VM now, a very different approach.

Since Rhino was part of proxy-vole up to 1.0.4 without many problems I vote for a hard way back.

[bergmannm]

Actually, PAC script failing with nashorn is a bit longer than in previous post.

// Nashorn scripting engine fails to parse this script with
// jdk.nashorn.internal.runtime.ParserException: :8:2 Expected an operand but found else
// else return "PROXY proxy:3128";
function FindProxyForURL(url, host)
{
if (shExpMatch(host, "deploy.abc.eu"))

        return "PROXY proxy:3128";

    else if (isInNet(myIpAddress(), "10.25.48.0", "255.255.240.0"))

    return "PROXY dmzproxy:3128; PROXY proxy:3128; DIRECT";

    else if (isInNet(myIpAddress(), "10.26.128.0", "255.255.248.0"))

    return "PROXY proxy:3128; DIRECT";

    else if (isInNet(myIpAddress(), "10.25.0.0", "255.255.0.0") 
	)

    return "PROXY dmzproxy:3128; PROXY proxy:3128; DIRECT";

    else

    return "PROXY proxy.:3128; PROXY dmzproxy:3128";
}

If I make small change in script, for example delete one of else if ... return block or change
return "PROXY dmzproxy:3128; PROXY proxy:3128; DIRECT";
to
return "PROXY proxy:3128; DIRECT";
nashorn is able to evaluate it.

[bergmannm]

@gschnepp
Even though nashorn is deprecated, it's part of LTS JDK 11, that means it will be part of Java for at least next 5 years.

Maven supports optional dependencies .
https://stackoverflow.com/questions/14601607/correct-way-to-declare-multiple-scope-for-maven-dependency

[gschnepp]

@bergmannm: Changing your script may be OK for you, but using proxy-vole out in the wild requires to work with different/unknown Javascript sources from all over the world (in my case). And proxy pac script writers in any arbitrary bigger company are not under my control, unfortunately.

Guido