Possible non-return of proxy lookup functions on Windows

[JohnRusk]

Hi Mattn, we recently worked around an issue that we found. Sometimes, about 1 time in a million, looking up a proxy would lock up and never return, on Windows 10.

We put a workaround into AzCopy here: https://github.com/Azure/azure-storage-azcopy/blob/863222d2e2a2bc038f5c35c4faf825ee145c210e/common/ProxyLookupCache.go#L89 . In that code c.lookupMethod == ieproxy.GetProxyFunc(). The workaround calls go-ieproxy in a separate goroutine, so that it can impose a strict timeout with a select statement.

Currently, that workaround is combined with some caching code. It doesn't seem like the caching code would make sense in go-ieproxy. But maybe the workaround would be of interest to you, on its own. (Although, if used without caching, it would have a little more overhead because it uses the separate goroutine for every call).

I'm not sure of the best way to proceed - e.g. does it make sense to put any of this code into go-ieproxy? So at this stage I'm logging this issue rather than creating a PR.

What do you think?

cc @adreed-msft , @zezha-msft

[mattn]

I think that we should add ieproxy.GetProxyFuncContext to be possible to cancel request. And context.WithCancel(context.Backup()) to the argument of lookupMethod.

[JohnRusk]

I'm not familiar with context.Backup(). Can you explain a bit more about what you propose?

[mattn]

Sorry my typo. context.Background() is right.

[JohnRusk]

Just checking I've understood correctly: Would that involve moving/copying the cancellable routine that we currently have in AzCopy into go-ieproxy? That sounds good.

I'm a bit snowed under with work right now, so can't make a PR for it soon myself. I might have time later this month if you'd like me to do it. Or if you want to do it, go for it!