search

samuong / alpaca

A local HTTP proxy for command-line tools. Supports PAC scripts and NTLM authentication.
Apache License 2.0
184 stars 31 forks source link

Keep a list of non-responsive proxies and avoid using them for 5 minutes #62

Closed samuong closed 3 years ago

camh- commented 3 years ago

I wonder if this can or should be smarter? If all the proxies returned by the pac script are on the blocklist, alpaca will just do nothing for 5 minutes, for what may have been a brief blip in proxy reachability. Perhaps if all the proxies in a pac response are on the blocklist, ignore the blocklist?

samuong commented 3 years ago

I wonder if this can or should be smarter? If all the proxies returned by the pac script are on the blocklist, alpaca will just do nothing for 5 minutes, for what may have been a brief blip in proxy reachability. Perhaps if all the proxies in a pac response are on the blocklist, ignore the blocklist?

If all proxies are in the blocklist, we could:

  1. Ignore (for this request) or clear (for all requests) the blocklist and use the first proxy from the PAC file
  2. Not use a proxy and go direct
  3. Clear the blocklist and try to download the PAC file again

The first option handles a transient network failure well, but might not be so good at handling the case where Alpaca is stuck thinking it's connected to the PAC server when it isn't (see issue #8). The second option is the other way around.

If we try to download the PAC file again (i.e. we basically re-evaluate whether we've got network connectivity) this helps with #8 as well.

I'm thinking of doing option 2 for this PR, and option 3 in a subsequent one. What do you think?

camh- commented 3 years ago

I dont think going direct is going to help - if the pac file says to use a proxy, then i imagine it is unlikely to work without it.

I think if all proxies are on the block list, then you should just try the proxies as though they are not on the block list. If you are successful talking to a proxy, remove it from the block list.

A network change event should clear everything and the pac file gets refetched. I'm not sure I see the point of re-fetching the pac file when you have trouble talking to a proxy. If the network has not changed, then the pac file should still be valid.

samuong commented 3 years ago

The specific case I'm talking about is where Alpaca incorrectly thinks it has connectivity to the PAC server (and the proxies that the PAC file references). In this case, it'll fail to dial any of the proxies, and eventually all of them will be added to the blocklist.

If it then falls back to DIRECT, then the request will make its way out to the public internet without trying to go via an unreachable proxy. If it falls back to the first proxy (ignoring the blocklist) then it'll be stuck forever. So in this case, wouldn't it be better to fall back to DIRECT?

But it could also be due to a transient network error as you mentioned. In that case, it's better to fall back to the proxy list, otherwise we'll be stuck trying to go DIRECT for the next 5 minutes.

Rather than try to guess which situation we're in, I think it would be better to check our connectivity status by trying to download the PAC file again.

camh- commented 3 years ago

I dont understand this:

The specific case I'm talking about is where Alpaca incorrectly thinks it has connectivity to the PAC server (and the proxies that the PAC file references)

If you know the proxies that the PAC file references, then you have connectivity to the PAC server, else how else do you have a PAC file to execute?

I assume you would not use a proxy to fetch the PAC file.

So, if you cannot reach the PAC server, you will be stuck with DIRECT, as you have no PAC file to tell you otherwise. If you get the PAC file, but cannot talk to the proxies, then you should not fall back to DIRECT because the PAC file does not tell you to go direct, so presumably that would just fail anyway.

Perhaps if all the proxies fail, you clear the block list, clear the PAC file and go back to the start and try to fetch the PAC file. If that fails, you will end up in DIRECT mode, but in the absence of a network change event, it suggests that connectivity to the PAC server will come back at some point when you should try to re-fetch.

I think we may have a different model of network failure in mind and maybe we are talking past each other. Since I don't use alpaca any more, I'm happy for you to try what you think works. You'll know if it turns out not to :)

samuong commented 3 years ago

Ok so as discussed, I think the cases that I'm thinking of are too much of an edge case, so I'm happy to ignore them for now. I went with your option of temporarily ignoring the blocklist in the event that all proxies are blocked.

samuong commented 3 years ago

During my own use of this branch, I haven't noticed any problems, so I'm going to land this now.