Repository navigation
@dlb http_archive fetch fails with HTTP 202 from downloadmirror.intel.com, blocking all builds of //contrib/exe:envoy-static #45491
Description
@dlb http_archive fetch fails with HTTP 202 from downloadmirror.intel.com, blocking all builds of //contrib/exe:envoy-static
Description
The Bazel external repository @dlb (registered in bazel/repositories.bzl) is
pinned to:
# bazel/repository_locations.bzl
dlb = dict(
version = "8.8.0",
sha256 = "564534254ef32bfed56e0a464c53fca0907e446b30929c253210e2c3d6de58b9",
urls = ["https://downloadmirror.intel.com/819078/dlb_linux_src_release_8.8.0.txz"],
),downloadmirror.intel.com is currently returning HTTP 202 Accepted to
requests for this asset (no body). Bazel's HTTP downloader treats any non-2xx
OK status as fatal:
WARNING: Download from https://downloadmirror.intel.com/819078/dlb_linux_src_release_8.8.0.txz failed:
class com.google.devtools.build.lib.bazel.repository.downloader.UnrecoverableHttpException
GET returned 202 Accepted
ERROR: An error occurred during the fetch of repository 'dlb':
Error in download_and_extract: java.io.IOException: Error downloading
[https://downloadmirror.intel.com/819078/dlb_linux_src_release_8.8.0.txz]: GET returned 202 Accepted
ERROR: no such package '@@dlb//': ... GET returned 202 Accepted
ERROR: //contrib/dlb/source:dlb depends on @@dlb//:libdlb in repository @@dlb which failed to fetch.
ERROR: Analysis of target '//contrib/exe:envoy-static' failed; build aborted: Analysis failed
This breaks any build that pulls in //contrib/exe:envoy-static (and
presumably any release pipeline producing the contrib variant).
Affected versions
Reproduced on v1.38.0 and v1.38.1 (the DLB pin is unchanged between
them and across many prior releases). Likely affects all Envoy versions back
to when DLB was added to contrib.
Steps to reproduce
git clone https://github.com/envoyproxy/envoy
cd envoy
git checkout v1.38.1
bazel build //contrib/exe:envoy-staticOr, isolating the failing fetch:
$ for i in $(seq 1 20); do
curl -s -o /dev/null -w "attempt %02d: %{http_code} %{time_total}s\n" -I -L \
"https://downloadmirror.intel.com/819078/dlb_linux_src_release_8.8.0.txz"
sleep 5
done
attempt 01: 202 1.015s
attempt 02: 202 1.002s
attempt 03: 202 1.152s
... (20 / 20 returned 202 over ~100s, response times all ~1s)Direct TLS verification confirms the response is genuinely from Intel
(certificate subject O=Intel Corporation, CN=downloadmirror.intel.com,
issuer Sectigo) — no corporate proxy interception involved:
subject: C=US; ST=California; O=Intel Corporation; CN=downloadmirror.intel.com
issuer: C=GB; O=Sectigo Limited; CN=Sectigo Public Server Authentication CA OV R36
SSL certificate verify ok.
Impact
- All builders behind proxies, in CI, or hitting cold edge-CDN POPs will see
this fail. - The dependency is required transitively by
//contrib/exe:envoy-static
because ofcontrib/contrib_build_config.bzl's entry
"envoy.network.connection_balance.dlb": "//contrib/dlb/source:connection_balancer".
Excluding the contrib build is the only way to avoid@dlb. - The 202 has been observed both as transient (a few 202s then 200) and as
persistent (20 / 20 over ~100s), suggesting the upstream behaviour is not
just CDN warm-up -downloadmirror.intel.commay have changed its
asset-serving semantics for this URL.
Environment
| Envoy version | v1.38.1 (and v1.38.0) |
| Bazel | 7.7.1 (per .bazelversion) |
| OS | Linux x86_64 |
Activity
agrawroh commentedon Jun 7, 2026
I'm seeing the same issue and had to disable this extension to get past it.
cc @phlax as well.
phlax commentedon Jun 7, 2026
yeah - i think we might have to disable this for now - not sure what usage is like
bmv126 commentedon Jun 8, 2026
Quick work around will be to download the tgz locally and then provide the path via --distdir option to bazel
izanami-01 commentedon Jun 8, 2026
Workaround A: disable
envoy.network.connection_balance.dlb(no DLB needed)Workaround B: vendor the tarball in-tree, feed Bazel via
--distdirbazel/repository_locations.bzl'sdlbblock and save the .txzsha256sum dlb_linux_src_release_8.8.0.txz -> EXPECTED_TXZ == EXPECTED_SHA--distdir=distfilesKBaichoo commentedon Jun 9, 2026
I think the issue here is that there's now an AWS WAF infront that our mechanism doesn't work with.
Given that we don't ship any other tarball in the codebase I think the solution is either:
cc @phlax WDYT?
phlax commentedon Jun 10, 2026
as said offline - i think we need to disable this extension as a first step
then open an issue - and invite either the intel devs or any users to pipe up
if we can capture the bin and host it before next release we could reenable - but honestly this feels like abandonware
Disable DLB. (#45568)
Disable DLB. (envoyproxy#45568)
repo: Release v1.35.13
repo: Release v1.35.13
repo: Release v1.36.9
repo: Release v1.37.5
repo: Release v1.38.3