WIP to replace zig-async-io and std.http.Client with a custom client. #466
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The two main goals are:
1 - Have a single HTTP client that does both sync and async. This makes it easier
to add things like proxy support, and might help with things like cookies.
2 - Maintaining our own HTTP client isn't trivial, especially given that
we're likely to encounter non-conforming servers. But, this removes the need
to maintain zig-async-io, which is a fork of [a small part] of the stdlib and
tls.zig. This itself is non-trivial. Also, if we do run into weird server
behavior, we'd have to maintain that in std.http.Client unless we could get
a PR accepted.
What's currently missing
1 -
Redirect handling (critical to add this)2 -
Chunked encoding response (critical to add this)3 - Connection pooling (could be added after)
4 - Compression (could be added after)
If you try "fetch" or "serve" a page that doesn't do a direct and that doesn't
use chunked encoding, it should work. Puppeteer demo works.
This is built on the zig-0.14 branch. I initially started working against main
(Zig 0.13) but then I noticed that tls.zig has very useful support for a
generic async loop in its master. It's a pretty big game changer and makes the
integration with our event loop trivial (I'm currently pointing to my own fork,
but I'm hopeful that my PR (ianic/tls.zig#8)
will be accepted, and if not, it's a simple change to accommodate tls.zig as-is).
The async API is simpler, with as single callback. A simplified example:
Generally, the integration with browser an XMLHttpRequest was rushed. The focus
has been on
src/http/client.zig.Finally, I've added the tls.zig dependency as a Zig package (build.zig.zon)
rather than a submodule. I assume submodules were chosen back when Zig didn't
have a package manager.