Zig Package Manager and http.Client broken with https proxy?

Greetings, are any of you successfully using zig build to fetch a dependency specified in the .zon file (i.e. with zig fetch --save) on a machine behind an http_proxy? With a recent 0.14.0-dev?

I ask because our docker build is failing with an error.EndOfStream on such a host, and I see several still-open issues in the zig repo relating to this. But looking at the zig source code for zig build, it seems to correctly use initDefaultProxies. Other commands during the build (e.g. apt-get update) are successfully using the proxy, but zig fails.

The zig error occurs right at the start of the build and cites the line in build.zig.zon which points to a github tarball.

Does this suggest a problem internal to zig, or a problem with the proxy? For instance, the proxy could block github… I don’t personally have access to the build host unfortunately, and the person who does is not familiar with zig, so… I’m just trying to figure out what to suggest to chase down this problem.

Thanks for any advice!

Maybe this issue and the comments are about the same problem?

1 Like

This unfortunately suggests that std.http.Client is broken on hosts which tunnel https requests through an http proxy. I hope the pull request that claims to correct the bug can be reviewed and merged sooner than the 0.16.0 milestone attached to the older bug, because the workarounds: don’t use Zig Package Manager and don’t use std.http.Client, are significant inconveniences.

(The alternative, replace the IT professionals who require the use of proxy servers on university hardware, and who adamantly refuse to compromise, is a bit more complicated.)