pypac
pypac copied to clipboard
carsonyl
When get_pac returns None, there is no way to tell if there is no PAC, or if error occurred
In download_pac, when an error occurs during an HTTP request, the error is ignored, and the next URL is attempted. At the end, if all URLs failed with error, the function returns None. It can be implied from this function that an error has occurred. If the list of URLs contained at least one URL, it should be expected that a response is available. However, it cannot be implied from get_pac, as perhaps PAC is not configured at all. Hence, either:
- get_pac raises an error if PAC is not configured (This way the user can imply whether to expect a PAC)
- get_pac evaluates if a PAC script was expected and raises an error otherwise
- download_pac collects all the errors that occured, and chooses one to raise
- download_pac collects all the errors and throws a new error type that contains the list of errors that occurred. (Leave it up to the user to figure out what error he cares about)
Today, I found there is a registry value from which one can infer what are the available proxy modes. Given this value, it could be evaluated whether the WPAD or the PAC URL should be evaluated at all. In case that they did, then one should expect one, hence failing of those request would deserve to be an exception:
https://stackoverflow.com/questions/1674119/what-key-in-windows-registry-disables-ie-connection-parameter-automatically-det
I implemented the suggestion above in our code base. I could contribute this here if the maintainers agree.
That stackoverflow post is a very good find. But I am not sure about the idea of get_pac() being changed to raise errors by default, due to compatibility. The original idea was that missing PAC should not raise an error because the operating system doesn't do it either.
How about adding an API function to help the user evaluate if PAC/wpad is configured to be used?
This could be used to determine whether a PAC script is to be expected as a return from get_pac