container: Be able to specify interceptOutboundHttp with hostname globs, and make sure that interceptAllOutboundHttp can intercept all hostname globs

[gabivlj]

How this works is that we will start resolving DNS queries for the user in local dev. When they intercept HTTP, they will be able to specify which hostnames they want to receive traffic from. With interceptAllOutboundHttp, they are specifying they want to receive all traffic, even non existent domains, to their Worker.

The user can decide which domains they want to intercept by just using interceptOutboundHttp before it hits their worker.

[ask-bonk]

I'm Bonk, and I've done a quick review of your PR.

This PR adds hostname glob matching to interceptOutboundHttp and teaches interceptAllOutboundHttp to intercept hostname-based traffic via DNS resolution in the sidecar. Changes span the Cap'n Proto schema, sidecar command-line args, egress mapping logic, and the sidecar API payload.

Findings (highest severity first):

1. [HIGH] status() still calls updateSidecarEgressPort (old method) instead of updateSidecarEgressConfig at container-client.c++:995. On workerd restart recovery, the sidecar won't receive DNS allow-hostnames or internet config. This line is outside the diff so I've posted a separate comment.
2. [LOW] EgressMapping uses two separate Maybe fields (cidr, hostnameGlob) for a mutually-exclusive value — a kj::OneOf would enforce the invariant at the type level.

---

This review was generated by an AI assistant and may contain inaccuracies. Please verify suggestions before applying.

[ask-bonk]

[HIGH] status() at src/workerd/server/container-client.c++:995 still calls updateSidecarEgressPort (the old method) instead of updateSidecarEgressConfig.

When workerd restarts and recovers a running container+sidecar, the sidecar will only receive the egress port — it will not get the DNS allow-hostnames list or the internet-enabled config. This means hostname-glob intercepts and internet settings will not survive a workerd restart.

This line is outside the diff so I cannot post an inline suggestion, but the fix is:

// container-client.c++:995
co_await updateSidecarEgressConfig(sidecar.ingressHostPort, egressListenerPort);

(replacing updateSidecarEgressPort)

---

This comment was generated by an AI assistant and may contain inaccuracies.

[ask-bonk]

Review posted on PR #6320. Summary of findings:

1. [HIGH] status() at container-client.c++:995 still calls updateSidecarEgressPort instead of the new updateSidecarEgressConfig. On workerd restart recovery, the sidecar won't receive DNS allow-hostnames or internet config, so hostname-glob intercepts won't survive restarts. Posted as a standalone PR comment since the line is outside the diff.

2. [LOW] EgressMapping uses two separate Maybe fields for a mutually-exclusive invariant — posted as inline suggestion to consider kj::OneOf.

The rest of the PR (capnp schema additions, glob matching logic, test coverage, BUILD.bazel dep) looked correct. The capnp schema changes are additive (new fields with new ordinals), the hostname glob matching algorithm is a standard *-wildcard matcher, and the tests cover both internet-enabled and no-internet scenarios with hostname interception.

github run

[gabivlj]

Review posted on PR #6320. Summary of findings:

1. [HIGH] status() at container-client.c++:995 still calls updateSidecarEgressPort instead of the new updateSidecarEgressConfig. On workerd restart recovery, the sidecar won't receive DNS allow-hostnames or internet config, so hostname-glob intercepts won't survive restarts. Posted as a standalone PR comment since the line is outside the diff.
2. [LOW] EgressMapping uses two separate Maybe fields for a mutually-exclusive invariant — posted as inline suggestion to consider kj::OneOf.

The rest of the PR (capnp schema additions, glob matching logic, test coverage, BUILD.bazel dep) looked correct. The capnp schema changes are additive (new fields with new ordinals), the hostname glob matching algorithm is a standard *-wildcard matcher, and the tests cover both internet-enabled and no-internet scenarios with hostname interception.

github run

I think I disagree because when we recover, we don't have the data in the class. The hostname data still lives in egress interception and we will process requests normally in workerd. The user will call intercept outboudn again and it will refresh teh outbound mappings in the class

[codecov-commenter]

Codecov Report

❌ Patch coverage is 0% with 167 lines in your changes missing coverage. Please review.
✅ Project coverage is 70.71%. Comparing base (04c6588) to head (f445db7).
⚠️ Report is 10 commits behind head on main.

Files with missing lines	Patch %	Lines
src/workerd/server/container-client.c++	0.00%	167 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6320      +/-   ##
==========================================
- Coverage   70.80%   70.71%   -0.10%     
==========================================
  Files         422      422              
  Lines      112347   112497     +150     
  Branches    18411    18445      +34     
==========================================
  Hits        79547    79547              
- Misses      21806    21956     +150     
  Partials    10994    10994              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.