inference/research
verifiedhigh · 0.90updated 2026-10-05

INDETERMINATE, NOT DEAD: the blocked-but-valid citation set in data/sources/ (intel.com 403, docs.vllm.ai 429, Enflame WAF, and the retailers), with the probe that failed and how

database

Fields

id
sources/w6s-unreachable-but-cited-2026-10-05
Publisher
compiled by this pass
Kind
database
Accessed
2026-10-05
notes
METHOD AND NEGATIVE RESULT. url is a representative BLOCKED endpoint, deliberately not a live one, because the whole point of this record is a set of URLs that cannot be fetched. THE ASYMMETRIC ERROR IS THE DANGEROUS ONE: a blocked source recorded as dead is a false death that deletes a valid vendor citation, and this repo has already paid that bill three times (rent-cerebras-api-token-pricing-negative, the five mlcommons repo roots, the v5.1/v6.1 Supermicro MLPerf log). Every entry below is INDETERMINATE - the probe failed, the source is not thereby disproven - and each names the probe that failed and what a different client would have to try. RULE, stated so the next pass does not have to relearn it: HTTP 403 and 429 are NOT dead. A 403 is a verdict about the CLIENT, not the document; a 429 is a rate limit; both return a body that is a block page, not a missing page. Only 404/410 on two independent clients with a content-level check of the body is dead. BLOCKED, 403 ANTI-BOT (intel.com): 20 source records cite intel.com hosts. Re-probed 2026-10-05: https://www.intel.com/content/www/us/en/products/sku/230019/intel-data-center-gpu-flex-170/specifications.html returns HTTP 403 with the literal Akamai body '<TITLE>Access Denied</TITLE> ... You don't have permission to access' - a block page, not a missing page, and NOT the intel.com product-page 404 template. Also 403: the Max-series product brief under content/dam/www/central-libraries/. DO NOT RE-PRONOUNCE ANY intel.com URL AS DEAD ON A 403. Importantly, the intel CDN is NOT uniformly blocked, which is the proof that 403 here is a WAF verdict and not a dead host: https://cdrdv2.intel.com/v1/dl/getContent/817486 (the Gaudi3 tech paper, cited by 7 records) and https://cdrdv2-public.intel.com/768797/intel-data-center-gpu-flex-series-product-brief-final.pdf both returned HTTP 200 with a real %PDF- header on the same probe run, same UA, same minute. So within intel.com's own estate the reachable and the blocked URLs sit side by side. A reader blocked by 403 should retry from a browser session or a different egress IP, not conclude the page is gone. BLOCKED, 429 RATE-LIMIT (docs.vllm.ai): 24 source records. Re-probed 2026-10-05: docs.vllm.ai/en/latest/features/quantization/gguf.html and /en/latest/usage/security/ both return HTTP 429 with a Cloudflare 'Just a moment...' interstitial. The prior triage counted 19; the set is now 24, so more vLLM doc citations have been added since. docs.vllm.ai is the vLLM project's own documentation and is not going anywhere - the fix is a slower probe rate, not a re-point. Records that need a figure from these pages should cite the equivalent source file in the vllm repo instead, which IS reachable (see the path-sweep records). BLOCKED, WAF WITH NO ARCHIVE (Enflame): the record w5a-enflame-s60-vendor-site-unreachable-waf-confirmed already documents this properly and I independently reproduced it rather than re-asserting it. Re-probed 2026-10-05: https://www.enflame-tech.com/product-technologies/s60 and https://support.enflame-tech.com/onlinedoc_hw/5-s6x/S60/product_manual/ both return 403 with a Chinese-language WAF interstitial, and the Wayback availability API returns archived_snapshots: {} for BOTH - so there is genuinely no archive for the S60 pages. One correction to a nearby claim, since I checked it: the statement that Enflame has no Wayback capture is true of the S60 product and doc-centre pages but NOT of the site root, which does have a 2023-07-04 capture (http://web.archive.org/web/20230704164420/https://www.enflame-tech.com/). Anyone re-trying the 'check the archive' route should know the root exists and the specific pages do not. The two third-party Enflame citations in the repo are NOT blocked and both returned 200 (techinsights.com floorplan analysis, mirrorfrog Ascend card docs) - so the S60 gap is a first-party gap, not an Enflame-wide one. ALSO IN THE BLOCKED SET, all left as-is because a retailer's bot policy says nothing about whether its product page exists: support.huawei.com (5), bhphotovideo (4), overclockers.co.uk (4), news.ycombinator.com (3, 419), microcenter.com (3), geizhals (5), doi.org (5, 202 = accepted-then-challenged), sec.gov (2), dl.acm.org (1). WHAT I DID NOT DO: I did not re-probe all 1507 distinct URLs, and I am not claiming a fresh census. This record is a correction to the blocked/dead boundary on the hosts that were actually in dispute, plus the instruction that makes the next pass cheaper. The 9 URLs that WERE genuinely dead or mis-pointed are repaired in their own records and are not repeated here.

Notes

METHOD AND NEGATIVE RESULT. url is a representative BLOCKED endpoint, deliberately not a live one, because the whole point of this record is a set of URLs that cannot be fetched. THE ASYMMETRIC ERROR IS THE DANGEROUS ONE: a blocked source recorded as dead is a false death that deletes a valid vendor citation, and this repo has already paid that bill three times (rent-cerebras-api-token-pricing-negative, the five mlcommons repo roots, the v5.1/v6.1 Supermicro MLPerf log). Every entry below is INDETERMINATE - the probe failed, the source is not thereby disproven - and each names the probe that failed and what a different client would have to try.

RULE, stated so the next pass does not have to relearn it: HTTP 403 and 429 are NOT dead. A 403 is a verdict about the CLIENT, not the document; a 429 is a rate limit; both return a body that is a block page, not a missing page. Only 404/410 on two independent clients with a content-level check of the body is dead.

BLOCKED, 403 ANTI-BOT (intel.com): 20 source records cite intel.com hosts. Re-probed 2026-10-05: https://www.intel.com/content/www/us/en/products/sku/230019/intel-data-center-gpu-flex-170/specifications.html returns HTTP 403 with the literal Akamai body '<TITLE>Access Denied</TITLE> ... You don't have permission to access' - a block page, not a missing page, and NOT the intel.com product-page 404 template. Also 403: the Max-series product brief under content/dam/www/central-libraries/. DO NOT RE-PRONOUNCE ANY intel.com URL AS DEAD ON A 403. Importantly, the intel CDN is NOT uniformly blocked, which is the proof that 403 here is a WAF verdict and not a dead host: https://cdrdv2.intel.com/v1/dl/getContent/817486 (the Gaudi3 tech paper, cited by 7 records) and https://cdrdv2-public.intel.com/768797/intel-data-center-gpu-flex-series-product-brief-final.pdf both returned HTTP 200 with a real %PDF- header on the same probe run, same UA, same minute. So within intel.com's own estate the reachable and the blocked URLs sit side by side. A reader blocked by 403 should retry from a browser session or a different egress IP, not conclude the page is gone.

BLOCKED, 429 RATE-LIMIT (docs.vllm.ai): 24 source records. Re-probed 2026-10-05: docs.vllm.ai/en/latest/features/quantization/gguf.html and /en/latest/usage/security/ both return HTTP 429 with a Cloudflare 'Just a moment...' interstitial. The prior triage counted 19; the set is now 24, so more vLLM doc citations have been added since. docs.vllm.ai is the vLLM project's own documentation and is not going anywhere - the fix is a slower probe rate, not a re-point. Records that need a figure from these pages should cite the equivalent source file in the vllm repo instead, which IS reachable (see the path-sweep records).

BLOCKED, WAF WITH NO ARCHIVE (Enflame): the record w5a-enflame-s60-vendor-site-unreachable-waf-confirmed already documents this properly and I independently reproduced it rather than re-asserting it. Re-probed 2026-10-05: https://www.enflame-tech.com/product-technologies/s60 and https://support.enflame-tech.com/onlinedoc_hw/5-s6x/S60/product_manual/ both return 403 with a Chinese-language WAF interstitial, and the Wayback availability API returns archived_snapshots: {} for BOTH - so there is genuinely no archive for the S60 pages. One correction to a nearby claim, since I checked it: the statement that Enflame has no Wayback capture is true of the S60 product and doc-centre pages but NOT of the site root, which does have a 2023-07-04 capture (http://web.archive.org/web/20230704164420/https://www.enflame-tech.com/). Anyone re-trying the 'check the archive' route should know the root exists and the specific pages do not. The two third-party Enflame citations in the repo are NOT blocked and both returned 200 (techinsights.com floorplan analysis, mirrorfrog Ascend card docs) - so the S60 gap is a first-party gap, not an Enflame-wide one.

ALSO IN THE BLOCKED SET, all left as-is because a retailer's bot policy says nothing about whether its product page exists: support.huawei.com (5), bhphotovideo (4), overclockers.co.uk (4), news.ycombinator.com (3, 419), microcenter.com (3), geizhals (5), doi.org (5, 202 = accepted-then-challenged), sec.gov (2), dl.acm.org (1).

WHAT I DID NOT DO: I did not re-probe all 1507 distinct URLs, and I am not claiming a fresh census. This record is a correction to the blocked/dead boundary on the hosts that were actually in dispute, plus the instruction that makes the next pass cheaper. The 9 URLs that WERE genuinely dead or mis-pointed are repaired in their own records and are not repeated here.

Cross-references

This record references no other records.