Recenze Heritrix: věrnost WARC a provozní náklady archivního crawlování

Heritrix je open-source archivní crawler Internet Archive — softwarová linie za Wayback Machine, která je v provozu už dvě desetiletí. Jeho úkolem je co nejvěrněji zachytit to, co web skutečně doručil, a uložit to do souborů WARC, které lze přehrát klidně o mnoho let později. Uvnitř jde o Java engine, kde je každý crawl Spring bean graf zapsaný v XML a celý životní cyklus úlohy se řídí přes REST API. Není to scraper: žádná selektorová syntaxe, žádné mapování polí, žádné řádky na konci.

Otestoval jsem verzi 3.16.0 na kontrolovaném lokálním fixture a spočítal, co skutečně zapsala, záznam po záznamu. Nejvíc vyniká úplnost: dvacet načtených URI vytvořilo šedesát jedna WARC záznamů, s payload digestem i capture IP u každé odpovědi a s každým requestem propojeným zpět na odpověď, ke které patří — a to vše bez jediného zásahu do konfigurace. Provoz je ale přesný opak: 41 MB, 114 jarů (lib/ obsahuje 142 souborů; zbývajících 28 tvoří přibalené texty LICENSE a NOTICE) a zhruba 750 řádků job konfigurace ještě před prvním fetch — přesto všechny běhy tady proběhly headless přes curl, bez jakýchkoli kliknutí ve webovém rozhraní.

Výsledek ukládání odhalil méně zjevný výchozí stav. Dvě fixture URL vracely byte-identický obsah a stock profil stáhl i archivoval obě v plném rozsahu: dva response záznamy a žádné revisit záznamy, přestože obě odpovědi dostaly stejný payload digest. Deduplicace přes content digest funguje až po přidání history processorů; ve stock profilu zapnutá není a šetří úložiště, ne šířku pásma.

Co Heritrix vlastně je

Archivace není scraping a právě tohle je kategorie, kterou je potřeba vyjasnit. Heritrix vám nedodá řádky. Na konci neexistuje žádné CSV. Jeho výstupem je samotná HTTP konverzace — hlavičky, těla a metadata zachycení — uložená ve formátu určeném pro dlouhodobé uchování, a právě pro tuto oblast je referenční implementací. Požádat ho o seznam cen produktů je jako chtít po soudním zapisovateli shrnutí.

Aktuální čísla k 27. červenci 2026: repozitář má 3 285 hvězdiček a 36 otevřených issues a 3.16.0 je nejnovější release, vydaný 2026-07-03. Přesně tuhle sestavu jsem testoval, takže nejde o stížnost na nějakou starou verzi. U licence je jedna drobnost navíc: soubor LICENSE je čistě Apache-2.0, ale GitHub detekuje „Other“, protože některé přibalené soubory třetích stran mají vlastní podmínky. Pokud má Heritrix být součástí komerčního produktu, zaslouží si to pět minut pozornosti právníka, ne jen letmý pohled na odznak v sidebaru.

Jeden strukturální fakt ovlivňuje všechno ostatní: Heritrix neovládá prohlížeč. Stahuje přes HTTP a odkazy získává z bajtů, které se vrátily. Jeho současným příbuzným v moderní archivaci je Browsertrix Crawler, který dělá opak — používá skutečný Chromium a zaznamenává, co prohlížeč opravdu provedl. Oba zapisují WARC, ale tahle recenze měřila jen Heritrix bez prohlížeče; nešlo o benchmark jejich škálování ani propustnosti.

Chains, beans a SURT: jak je crawl ve skutečnosti sestavený

Uvnitř je job v Heritrixu Spring application context. Ne „nakonfigurovaný přes Spring“ — on je Spring bean graf zapsaný v XML a každá část crawlu je bean, kterou lze vyměnit.

Frontier drží frontu URI rozdělenou podle hostu. Právě tohle dělení určuje, jak funguje politeness, a ještě se k tomu vrátíme.

Processor chains dělají práci ve třech krocích: candidate chain (má se nově nalezené URI naplánovat?), fetch chain (DNS, robots, HTTP fetch, extrakce odkazů) a disposition chain (zápis do WARC, aktualizace stavu). Přidání schopnosti do Heritrixu obvykle znamená vložit processor bean na správné místo do správného chainu — přesně tak jsem zapnul dedup.

Scope je zásobník DecideRules pracujících nad SURT — Sort-friendly URI Reordering Transform, který přepisuje http://www.example.com/a na http://(com,example,www,)/a, aby se prefixy hostů řadily do hierarchie. Výchozí scope se generuje ze SURT prefixů vašich seedů. Pravidla postupně přijímají a odmítají, přičemž poslední shoda vyhrává.

WARC writer sedí v disposition chainu a politeness žije ve frontě jako tři čísla: delayFactor, minDelayMs, maxDelayMs. Dodržování robots je policy string na fetcheru.

A celé to lze ovládat přes REST API, což se ukázalo důležitější, než jsem čekal.

Nastavení je nejtěžší část celého zážitku

Co nasazujete ještě před prvním fetch:

Většinu téhle konfigurace nikdy nebudete měnit. Přesto ji přeskočit nelze a dvě pole jsou povinná ještě před tím, než crawler začne cokoli stahovat: váš seed a metadata.operatorContactUrl. Výchozí hodnota je jen placeholder a crawler se nespustí, dokud ji nenahradíte skutečnou URL, která identifikuje provozovatele crawlů.

Tenhle požadavek vytváří bod odpovědnosti: operátor musí před spuštěním zadat kontaktní URL. Neprokazuje to, že identita je správná, že crawl je oprávněný nebo že odpovídá platným pravidlům, ale dělá z kontaktních údajů součást jobu, ne jen volitelnou konvenci.

Dvě zjištění při setupu mě opravdu překvapila.

Běžel na novějším JDK, než uvádí minimum v dokumentaci. Getting Started docs požadují Java 17 nebo novější. Heritrix 3.16.0 nabootoval, zpřístupnil REST API a dokončil každý crawl v tomto fixture na OpenJDK 26.0.1, bez --add-opens, --enable-preview nebo obejití Security Manageru. Jde o výsledek na macOS arm64, ne o kompatibilitní matici, ale potvrzuje, že tato testovaná verze na tomto hostu nebyla omezená na JDK 17.

Nikdy nemusíte sáhnout na web UI. Celý životní cyklus jobu běží přes REST a já ho automatizoval celý pomocí curl: vytvořit job, PUTnout beans soubor, build, launch, unpause, pollovat, dokud controller state neukáže FINISHED, pak terminate a teardown. To je skutečná odpověď na otázku „lze Heritrix provozovat v pipeline“ — ano, headless, bez jediného kliknutí v prohlížeči. Většina textů ukazuje Jetty UI jako hlavní rozhraní. Je to jen pohodlí, ne nutnost.

Jedna poznámka k nasazení specifická pro tento stroj: tenhle Mac používá systémový HTTP proxy přes Surge. Java klient v Heritrixu zdědil tento proxy a posílal přes něj i fixture traffic na 127.0.0.1, což vedlo k odpovědím 503 navzdory výjimce v OS a NO_PROXY. Spuštění JVM s -Djava.net.useSystemProxies=false změnilo běh z 2×503 na 18×200. Nebyla to vada Heritrixu, ale interakce s prostředím; tenhle flag je relevantní jen tehdy, když je nežádoucí dědit systémové proxy nastavení.

Co skutečně skončí v archivu

Spustil jsem stock default profil proti kontrolovanému fixture — lokálnímu serveru se známou sadou endpointů, včetně HTML stránek, tříúrovňového depth chainu, robots.txt a sitemap, a záměrných tras 404 a 500 — a pak jsem výsledný WARC analyzoval záznam po záznamu místo toho, abych věřil souhrnné lince.

Dvacet načtených URI vytvořilo šedesát jedna záznamů:

Čistý poměr 1:1:1 response/request/metadata na URI už v základním stavu, bez jakékoli konfigurace z mé strany. A úplnost na úrovni jednotlivých záznamů obstála i při detailní kontrole:

A HTTP status zůstal zachován doslova, včetně nepříjemných případů: 200 OK, 404 Not Found i 500 Internal Server Error jsou ve uložených odpovědích přítomné jako skutečné status line, ne zahozané jako chyby.

Právě tenhle bod odděluje archivaci od scrapingu výrazněji než cokoli jiného. Scraper bere 500 jako chybu k opakování nebo přeskočení. Archivátor to bere jako to, co server v daném okamžiku řekl — a to je fakt, který stojí za uchování. Heritrix Output wiki popisuje strukturu těchto záznamů; co jsem ale nikde neviděl, byla změřená multiplicita a 20/20 propojení na známé sadě endpointů. Sedí to.

Výsledek dedupu, změřený oběma směry

Můj fixture servíroval /dup/one a /dup/two s byte-identickými těly. Různé URL, stejný obsah — přesně ten případ, který má content-digest dedup sloučit. Spustil jsem to dvakrát: jednou se stock profilem, jednou po vložení digest-history chainu (BdbContentDigestHistory plus ContentDigestHistoryLoader ve fetch chainu a ContentDigestHistoryStorer za WARC writerem).

Ve výchozím stavu dostaly obě odpovědi stejný digest, ale žádné history procesory na něj nereagovaly a oba payloady byly zapsány celé. Přidání chainu změnilo druhé zachycení na WARC revisit záznam odkazující na identický payload digest, což je chování, které pro revisits definuje specifikace WARC 1.1.

Nic z toho není tajemství. Stránka Duplication Reduction Processors říká, že skipIdenticalDigests má výchozí hodnotu false a že dedup nezávislý na URL potřebuje právě tyto loader a storer beany. Není to skrytá funkce, kterou jsem odhalil; stejně jako téměř vše ostatní měřené tady jde o zdokumentované chování Heritrixu s vlastním číslem. Propast je mezi dokumentací a tím, čemu lidé věří — a podle mých zkušeností zní to přesvědčení většinou jednoduše: „Heritrix dedupuje.“ Bez hvězdičky ohledně konfigurace.

Dva důsledky, které stojí za to si zapamatovat:

Dedup šetří při zápisu, ne na šířce pásma. Tohle je spíš mechanismus než něco, co bych měřil odděleně, ale plyne to přímo z toho, jak fungují content digests: digest můžete porovnat až poté, co bajty dorazily, takže druhá URL se z originu stáhne tak jako tak. Zapnutí chainu snižuje to, co ukládáte, ne to, co přenášíte, ani to, co musí cílový server doručit. Kdo si dedup počítá jako úsporu ohleduplnosti nebo bandwidth, má to obráceně.

Odhady úložiště založené na „však se to deduplikuje“ mohou být hodně mimo. Pokud archivujete web s výraznou šablonovou duplicitou — zrcadlené PDF, boilerplate landing pages, print verze stejných článků — a plánujete disky s předpokladem, že identická těla splynou, stock profil může spotřebovat výrazně víc úložiště, než takový odhad naznačuje. Dvou-URL fixture potvrzuje výchozí chování, ne jeho dopad ve škále milionu URI; ten závisí na míře duplicit, velikosti payloadu a designu recrawlu.

Scope a robots dělaly přesně to, co slibují

Slovo crawleru o tom, co nenačetl, má velmi malou hodnotu, takže obojí jsem měřil přes server-side hit counter — cílový server počítal requesty sám, nezávisle na tom, co Heritrix logoval.

Scope. In-scope host se mezitím procházel normálně, takže scope fungoval disciplinovaně a crawl nebyl rozbitý. Jedno upřesnění: tady jsem testoval jen větev s výchozím scope, ne pozitivní kontrolu s rozšířeným scopem, takže to berte jako potvrzení zdokumentovaného designu, ne jako oboustranný důkaz.

Robots. Odkaz byl pořád dosažitelný; potlačila ho pouze robots policy. Dodržování je reálné a existuje i úniková cesta, což je správné uspořádání — některé archivační mandáty robots oprávněně přebíjí a mělo by to vyžadovat vědomé napsání ignore do konfigurace.

Politeness: 57,7 sekundy na dvacet lokálních stránek

Jediné číslo rozhoduje, jestli se Heritrix hodí pro váš projekt.

Stejný fixture, stejné tři běhy, na jednom lokálním hostu s latencí pod milisekundu:

Skutečné zpoždění sedí přímo na hranici minDelayMs: u zdroje s podmilisekundovou odezvou je delayFactor × fetch-time zanedbatelný a minimum dominuje konstrukcí. Poměr mezi oběma řádky není moc užitečný, protože nulový politeness jmenovatel je jen v desítkách milisekund a mezi běhy kolísá. Stabilní je absolutní minimum: výchozí Heritrix čekal v tomto fixture asi tři sekundy mezi requesty na stejný host, takže dvacetistránkový crawl trval zhruba minutu.

Konkrétněji: představte si, že univerzitní knihovna musí archivovat vládní web o 50 000 stránkách, než bude zrušen, a vše je na jednom hostu. Při třísekundovém minimu na host to znamená 150 000 sekund nuceného čekání — zhruba 42 hodin, tedy asi den a tři čtvrtě, než započítáte samotný fetch. Je to výpočet z mnou změřené hodnoty 3 036 ms — 50 000 × 3,036 s = 151 800 s = 42,2 h; i při konfigurovaném minimu 3 000 ms je to 41,7 h, což se zaokrouhlí na 42, ne 41. Není to měřený crawl, ale je to aritmetika, kterou váš projektový plán potřebuje.

Poctivě řečeno, politeness v Heritrixu je na host, protože frontier fronty rozděluje podle hostu. Široký crawl napříč tisíci domén se přes tyto fronty paralelizuje a tenhle strop globálně nepřebírá. Můj fixture byl jeden host, což je pro toto číslo nejhorší možný případ. Pokud je vaším cílem jeden velký web, tenhle worst case je zároveň váš case.

A je to feature. Tohle zpoždění dělá z archivního crawleru nástroj, který vlastník webu spíš snese, než zablokuje. Snížit ho je rozhodnutí o serveru někoho jiného a nástroj to rozhodnutí dělá explicitní, místo aby automaticky sahal po agresivním chování.

Co jsem netestoval

Tato měření pokrývají kázeň crawlu na kontrolovaném fixture, nic širšího. Mimo jejich hranice zůstává:

• Dedup napříč crawly a recrawl. Měřil jsem jen content-digest dedup uvnitř jednoho crawlu. Udržování databáze historie URI napříč samostatnými crawly (FetchHistoryProcessor + PersistLog) je jiný mechanismus a ten jsem netestoval.
• Škála a dlouhodobá stabilita. Žádný frontier s milionem URI, žádný checkpoint-and-restore, žádný vícedenní běh. Můj fixture měří disciplínu, ne výdrž.
• Zachycení renderovaného JavaScriptem. Výchozí capture v Heritrixu není prohlížečové a právě to jsem měřil. Volitelné browser-based chování tady nebylo testováno.
• Politeness na pomalém zdroji. Lokální latence je pod milisekundu, takže minDelayMs dominoval konstrukcí. Jak delayFactor škáluje proti pomalému reálnému serveru, z mých dat nevyplývá.
• Přesnost sitemap. robots.txt byl požádán a sitemap direktiva byla následována, ale zvlášť jsem neověřoval zachycení každé <loc> položky.

Co si vyjasnit před prvním produkčním jobem

Stock profil je rozsáhlý, ale rozhodnutí, která mění význam archivu, jsou poměrně kompaktní. Začněte scope. Seedy generují výchozí SURT prefixy a DecideRules je mohou postupně rozšiřovat nebo zužovat. Zkontrolujte konečné pořadí pravidel na reprezentativních URL uvnitř i vně scope a pak to ověřte proti server-side trafficu nebo jinému nezávislému logu requestů. Samotný crawl report nedokáže prokázat, že vyloučený host nikdy nebyl kontaktován.

Pak rozhodněte, co pro sběr znamená robots policy a identita operátora. Testovaný default respektoval zakazující pravidlo ve fixture, zatímco změna robotsPolicyName na ignore způsobila stažení zablokované cesty. Tenhle přepínač je mechanicky jednoduchý a institucionálně významný. Zapište, kdo to schválil a proč, spolu s funkčním operatorContactUrl; povinná URL dává vlastníkovi webu cestu zpět k operátorovi, ale nedodává odůvodnění oprávnění.

Plánování úložiště potřebuje vlastní explicitní rozhodnutí. Pokud se z identických těles mají stát revisit záznamy, přidejte a zkontrolujte content-digest history procesory ještě před rozměřením archivu. Testovaný chain ovlivnil reprezentaci až po fetchi, takže traffic k originu je potřeba započítat pro obě URL. Deduplicace napříč crawly je samostatný mechanismus a z tohoto dvou-URL, jedno-crawl výsledku ji nelze odvozovat. Malý validační crawl se známými duplicitními těly je levný způsob, jak ověřit, že nasazený bean graf vytváří zamýšlené typy záznamů.

Nakonec berte politeness jako vstup do plánování, ne jako poslední dolaďovací páčku. Na lokálním single-host fixture dominoval celkovému času minDelayMs. Reálný projekt by měl dopočítat konfigurované minimum na host proti počtu cílových hostů a deadlinu sběru a pak to otestovat na reprezentativní latenci. Široké crawly a crawl jednoho webu zatěžují frontier rozdělený podle hostů odlišně; tahle recenze měřila jen ten druhý případ. Do runbooku patří i REST lifecycle: build, launch, unpause, poll, terminate a teardown jsou samostatné stavy, které má smysl v automatizaci sledovat.

Klady a zápory

Klady

• Výchozí úplnost archivu je výborná: 20/20 odpovědí s payload digestem, capture IP a plným request↔response propojením bez nutnosti konfigurace.
• Zachovává chybové odpovědi jako fakta — status line 200, 404 i 500 se ukládají doslova.
• Disciplína scope byla potvrzena server-side čítačem: žádné fetches mimo scope, zatímco in-scope host se crawloval normálně.
• Dodržování robots skutečně potlačí fetch, s vědomou únikovou cestou ignore pro mandatorní archivaci.
• Plně headless přes REST — vytvořit, buildnout, spustit, pollovat, teardown, vše přes curl, bez klikání v UI.
• Na OpenJDK 26.0.1 běží čistě bez JVM flagů, což je lepší moderní Java hygiena, než mívá většina dvacetiletých codebase.
• Povinná kontaktní URL operátora znamená, že crawler nemůže běžet anonymně.
• Každá část crawl procesu je vyměnitelná bean, takže zapnutí dedupu znamenalo tři vložené beany, ne fork.

Zápory

• Content-digest dedup je ve výchozím stavu vypnutý a identické payloady zapisuje celé — reálná past při plánování úložiště.
• Nasazení je těžké: distribuce 41 MB, 114 jarů, Java engine plus Jetty a zhruba 750řádková Spring job konfigurace.
• Výchozí politeness ukládá asi třísekundové minimum na host; crawl 20 URI na jednom hostu trval 57,7 s.
• Ve výchozí cestě není JavaScript rendering, takže obsah vykreslovaný jen na klientovi se nezachytí.
• Konfigurační plocha odměňuje zkušenost a trestá příležitostné použití; neexistuje pětiminutová cesta k prvnímu crawlu.
• Ve výstupu nejsou žádná strukturovaná data. Vytáhnout pole z WARC je samostatný projekt.

Kdo by ho měl používat a kdo by se mu měl vyhnout

Heritrix je pro instituce a týmy, jejichž výstupem je samotný archiv. Knihovny, národní archivy, právní a compliance archivace, výzkumné týmy zachycující web jako primární zdroj, kdokoli, kdo potřebuje po pěti letech prokázat, co konkrétní URL zobrazovala v určitý den. Pokud už ve vaší slovní zásobě jsou pojmy „WARC“, „replay“ a „provenance“, je to nástroj, kolem kterého je postaven zbytek ekosystému — a jeho hmotnost je cenou za tu interoperabilitu.

Jeho frontier rozdělený podle hostů a dlouhé využití v webové archivaci z něj dělají rozumného kandidáta pro široké crawly napříč mnoha doménami. To je ale architektonická a historická úvaha, ne výsledek škálování z tohoto fixture; dlouhodobá propustnost, obnova checkpointu a chování na milionu URI tu zůstávají netestované.

Vyhněte se mu, pokud chcete data, ne archiv. Pokud je vaším cílem tabulka produktů, nabídek nebo kontaktů, Heritrix dokonale zachytí stránky, které pak budete muset v samostatné pipeline parsovat — a za tuhle službu jste zaplatili Java enginem, Spring konfigurací a třísekundovým politeness minimem. Vyhněte se mu také, pokud míříte na client-rendered single-page apps, kde non-browser fetcher zachytí jen shell a ne obsah; tam je správným nástrojem browserový archivátor. A vyhněte se mu, pokud potřebujete první výsledek ještě dnes, protože křivka nastavení je reálná.

Alternativy a kde dává smysl řízené API

V archivaci je přímým moderním protějškem Browsertrix Crawler — browserový archivátor, který ovládá Chromium a zaznamenává, co prohlížeč udělal. Umí zachytit obsah vzniklý JavaScriptem, který v základním HTTP výstupu Heritrixu chybí, za cenu většího nasazovacího i provozního overheadu. Tahle recenze neprováděla head-to-head benchmark, takže rozhodování začíná požadavkem na zachycení: browserem generovaný stav patří k browser archivátoru, běžné HTTP zdroje zůstávají nativní cestou Heritrixu.

Související recenze: recenze Browsertrix Crawler.

U úplně jiného typu úlohy — nechcete archiv, ale strukturovaná data z webových stránek — porovnávejte Heritrix s extrakčními systémy podle výstupu, ne jako ekvivalentní crawlery. Heritrix je zdarma a self-hosted: provozujete JVM, vlastníte beans file, dimenzujete disky a ladíte politeness. Ten model sedí, když je deliverable samotné uchování.

Upozornění: Thunderbit je produkt vydavatele a v tomto fixture pro Heritrix nebyl testován. Patří do kategorie řízené extrakce: jeho výstupem je obsah stránek nebo strukturované záznamy, ne WARC soubory v archivní kvalitě. Zvolte archivátor, když potřebujete přehratelné zachycení a provenance; zvažte službu pro extrakci, když výstupem mají být řádky nebo text dokumentu a vyhovuje vám řízený provoz.

Archivace s sebou nese vlastní otázku oprávnění a není to totéž co u scrapingu. Heritrix ve výchozím nastavení respektuje robots.txt a před stažením bajtu od vás vyžaduje identifikaci, což je dobrý základ — ale crawl v souladu s robots automaticky neznamená crawl oprávněný. Nad tím vším stojí autorská práva, podmínky použití, osobní údaje a mandát vaší instituce, a policy ignore existuje pro organizace s právním základem, ne jako pohodlný přepínač. Pokud rozjíždíte archivační program, ujasněte si oprávnění dřív, než se zaplní disky, a pokud je to nové téma, přečtěte si i právní stránku web scrapingu a archivace.

Vyzkoušejte Thunderbit pro extrakci webových dat

Verdikt

Měli byste Heritrix používat? Ano — pokud je vaším výstupem archiv a máte někoho, kdo se chce naučit Spring beany.

Fixture dává jasnou odpověď: stock profil konzistentně zachovával response, request i capture metadata; scope a robots kontrola ovlivňovaly server-side fetches přesně podle konfigurace; a celý životní cyklus jobu běžel přes REST. To jsou užitečné vlastnosti pro archivační pipeline, alespoň v rámci malého single-host rozsahu, který byl testován.

Provozní náklady jsou stejně jasné: Java distribuce a velká Spring konfigurace, nastavené per-host zpoždění, které v tomto lokálním crawlu dominovalo, a content-digest dedup, který vyžaduje další history procesory. Týmy, které potřebují WARC věrnost, tyto náklady mohou přijmout; týmy, které potřebují extrahovaná pole, by měly začít v jiné kategorii.

Před produkčním crawlem ověřte dedup chain, politeness nastavení, scope, robots policy, identitu operátora a předpoklady pro úložiště proti skutečné konfiguraci jobu. Stock profil je výchozí bod, ne implicitní vyjádření těchto provozních rozhodnutí.

Vyzkoušejte Thunderbit pro extrakci webových dat Get Started Free

Časté dotazy

Znamená operatorContactUrl, že je crawl oprávněný? Ne. Vynucuje, aby job obsahoval kontaktní URL, která dává provozovateli webu cestu k odpovědné osobě, ale nestanovuje povolení, správnost identity, autorský status ani soulad s regulací. To vše zůstává rozhodnutím při nasazení mimo crawler.

Snižuje content-digest dedup počet requestů k originu? Ne v konfiguraci, která byla testována tady. Obě URL byly staženy ještě předtím, než bylo možné jejich payload digests porovnat. History chain změnil to, jak byl druhý payload reprezentován v WARC úložišti; nezměnil druhou URL na přeskočený síťový request.

Lze Heritrix spustit bez web UI? Ano. Testovaný životní cyklus — vytvoření, nahrání konfigurace, build, launch, unpause, polling, terminate a teardown — běžel přes REST API pomocí curl. Vestavěné Jetty UI nebylo potřeba.

Deduplikuje stock profil Heritrix identické payloady? Ne v této konfiguraci fixture. Stock profil uložil obě identické odpovědi jako plné response záznamy. Přidání content-digest history chainu změnilo druhé zachycení na revisit záznam, takže deduplicace je volba pipeline, kterou musíte nakonfigurovat a ověřit, ne automatický default.

Jak mám zvolit politeness delay? Ber­te místní časy tady jako kontrolu mechanismu, ne jako produkční doporučení. Nastavte zpoždění podle pravidel cílového webu, dohody s provozovatelem, kapacity serveru, účelu crawlů a vlastní politiky retry a concurrency, a pak potvrďte skutečné mezery mezi requesty na stejný host v logách.