Unexpected rule behavior

[streino]

Extract from proxy.pac loaded by Alpaca:

function FindProxyForURL(url, host) {
  if (shExpMatch(url, "*://" + host + ":*") && (!shExpMatch(url, "*://" + host + ":443/*"))) {
    return "DIRECT";
  }
  return "PROXY myproxy:3128";
}

curl https://raw.githubusercontent.com/samuong/alpaca/master/README.md going through Alpaca will give:

proxy.go:138: [1] Error dialling host raw.githubusercontent.com:443: dial tcp 185.199.109.133:443: connect: connection refused
proxyfinder.go:113: [2] CONNECT //raw.githubusercontent.com:443 via "DIRECT"

Where I would expect:

proxyfinder.go:135: [1] CONNECT //raw.githubusercontent.com:443 via "PROXY myproxy:3128"

Loading the same proxy.pac from Firefox/Chrome gives me the expected behavior.

I narrowed it down to the ":443/*" part of the rule matching in Chrome but not in Alpaca.

Here's what I think is happening: Alpaca strips the URL path before attempting to match the rules. The comment explains this is to match Firefox/Chrome behavior. However there seems to be a difference between Alpaca and Chrome when handling URLs with empty paths: Go's "net/url" won't add a trailing slash for an empty path, but Chrome does.

[samuong]

@streino thanks for reporting this. Looking through the Alpaca code, I don't think it's right to set the Path or Rawpath to an empty string, so I'll change this to / to match Chrome and others. Do you have the ability to test this pull request to see if there are still any other issues that Alpaca has with your PAC file?

[streino]

I confirm it works now with release 2.0.1. No other problem detected so far. Thanks @samuong!