Recensione di Heritrix: fedeltà WARC e costi operativi del crawling archivistico

Heritrix è il crawler archivistico open source di Internet Archive — la base software dietro alla Wayback Machine, in produzione da vent’anni. Il suo lavoro è catturare in modo fedele ciò che un sito ha pubblicato, salvandolo in file WARC che si possono riprodurre anche anni dopo. Sotto il cofano c’è un motore Java in cui ogni crawl è un grafo di bean Spring definito in XML, e l’intero ciclo di vita del job si gestisce tramite API REST. Non è uno scraper: niente sintassi di selezione, niente mapping dei campi, nessuna riga finale.

Ho testato la versione 3.16.0 su un fixture locale controllato e ho contato tutto ciò che scriveva, record per record. Quello che salta all’occhio è la completezza: venti URI recuperati hanno generato sessantuno record WARC, con un digest del payload e l’IP di cattura su ogni risposta, oltre a ogni richiesta collegata alla risposta di appartenenza; il tutto senza toccare alcuna impostazione di configurazione. L’esperienza opposta è quella operativa: 41 MB, 114 jar (lib/ contiene 142 file; gli altri 28 sono testi LICENSE e NOTICE inclusi), e un file di configurazione del job di circa 750 righe ancora prima del primo fetch — anche se qui ogni crawl è stato eseguito senza interfaccia grafica, interamente via curl.

Il risultato sullo storage ha messo in luce un default meno ovvio. Due URL del fixture restituivano contenuti identici byte per byte, e il profilo stock li ha recuperati e archiviati entrambi per intero: due record di risposta e zero record di revisit, pur assegnando a entrambe le risposte lo stesso digest del payload. La deduplica basata sul content digest funziona dopo l’aggiunta dei processori di history; nel profilo stock non è attiva e fa risparmiare spazio, non banda.

Che cosa è davvero Heritrix

L’archiviazione non è scraping, ed è proprio questa la confusione di categoria da chiarire. Heritrix non ti restituisce righe. Alla fine non c’è nessun CSV. Il suo output è la conversazione HTTP stessa — header, body e metadati di cattura — conservata in un formato pensato per la preservazione, ed è l’implementazione di riferimento per questa intera classe di lavoro. Chiedergli un elenco di prezzi dei prodotti è come chiedere a un cancelliere di tribunale un riassunto.

Dati aggiornati al 27 luglio 2026: il repository conta 3.285 stelle e 36 issue aperte, e 3.16.0 è l’ultima release, pubblicata il 2026-07-03. È esattamente la build che ho testato, quindi qui non si tratta di lamentele su una versione vecchia. La licenza ha una piccola particolarità: il file LICENSE è un normale Apache-2.0, ma il detector di GitHub segnala "Other" perché alcuni file di terze parti inclusi hanno condizioni proprie. Se Heritrix deve entrare in un prodotto commerciale, vale la pena che qualcuno del legale ci dedichi cinque minuti, non solo un’occhiata al badge laterale.

C’è un fatto strutturale che influenza tutto il resto: Heritrix non guida un browser. Effettua fetch via HTTP ed estrae i link dai byte ricevuti. Il suo omologo nel moderno archivismo, Browsertrix Crawler, fa il contrario — usa Chromium reale e registra ciò che il browser ha effettivamente fatto. Entrambi scrivono WARC, ma questa recensione ha misurato solo il percorso non-browser di Heritrix; non ha confrontato né scala né throughput dei due sistemi.

Catene, bean e SURT: come si costruisce davvero un crawl

Sotto il cofano, un job Heritrix è un application context Spring. Non "configurato con Spring" — è un grafo di bean Spring scritto in XML, e ogni parte del crawl è un bean sostituibile.

La frontier contiene la coda degli URI, partizionata per host. È questa partizione che rende possibile la politeness nel modo in cui funziona, e il punto torna utile più avanti.

Le catene di processor fanno il lavoro in tre fasi: una candidate chain (questa URI scoperta va pianificata?), una fetch chain (DNS, robots, fetch HTTP, estrazione dei link) e una disposition chain (scrittura in WARC, aggiornamento dello stato). Aggiungere una funzionalità a Heritrix significa di solito inserire un bean processor nel punto giusto della catena giusta, ed è esattamente così che ho attivato la deduplica.

Lo scope è uno stack di DecideRule che opera su SURT — Sort-friendly URI Reordering Transform, che riscrive http://www.example.com/a in http://(com,example,www,)/a in modo che i prefissi degli host si ordinino in modo gerarchico. Lo scope predefinito viene generato dai prefissi SURT dei seed. Le regole accettano o rifiutano in sequenza; vince l’ultima corrispondenza.

Il writer WARC vive nella disposition chain, e la politeness risiede nella frontier come tre numeri: delayFactor, minDelayMs, maxDelayMs. L’osservanza di robots è una stringa di policy sul fetcher.

E tutto questo è gestibile via API REST, e si è rivelato molto più importante di quanto mi aspettassi.

La parte più pesante dell’esperienza è la configurazione iniziale

Quello che devi distribuire, prima del primo fetch:

Gran parte di quel file non la toccherai mai. Ma non puoi saltarla, e prima che il crawler possa fare qualsiasi fetch servono due campi obbligatori: il seed e metadata.operatorContactUrl. Il valore stock è un segnaposto, e non partirà finché non lo sostituisci con un URL reale che identifichi chi sta eseguendo il crawl.

Questo requisito crea un punto di responsabilità: l’operatore deve fornire un URL di contatto prima dell’avvio. Non dimostra che l’identità sia corretta, che il crawl sia autorizzato o che sia conforme alle regole applicabili, ma rende le informazioni di contatto parte del job e non una convenzione facoltativa.

Due aspetti del setup mi hanno sorpreso davvero.

Ha funzionato con un JDK più recente del minimo indicato nella documentazione. Le istruzioni Getting Started richiedono Java 17 o superiore. Heritrix 3.16.0 è partito, ha servito la sua API REST e ha completato ogni crawl in questo fixture su OpenJDK 26.0.1, senza --add-opens, --enable-preview né workaround per il Security Manager. È un risultato su macOS arm64, non una matrice di compatibilità, ma conferma che questa build testata non era limitata a JDK 17 su questa macchina.

Non devi mai toccare la web UI. L’intero ciclo di vita del job è via REST, e ho automatizzato tutto con curl: creare il job, fare PUT del file beans, build, launch, unpause, fare polling finché lo stato del controller non diventa FINISHED, terminare, teardown. Questa è la risposta reale alla domanda "Heritrix si può usare in pipeline?" — sì, senza interfaccia grafica e senza clic nel browser. Molti articoli mostrano screenshot della UI Jetty e lasciano intendere che sia l’interfaccia obbligatoria. È una comodità, non un requisito.

Una nota di deployment specifica dell’host: questo Mac usa un proxy HTTP di sistema tramite Surge. Il client Java di Heritrix ha ereditato quel proxy e ha instradato persino il traffico del fixture su 127.0.0.1 attraverso di esso, generando risposte 503 nonostante l’eccezione del sistema operativo e NO_PROXY. Avviare la JVM con -Djava.net.useSystemProxies=false ha cambiato l’esito da 2×503 a 18×200. Era un’interazione con l’ambiente, non un difetto di Heritrix; il flag è rilevante solo quando ereditare le impostazioni proxy di sistema non è desiderabile.

Cosa finisce davvero nell’archivio

Ho eseguito il profilo predefinito stock contro un fixture controllato — un server locale con un insieme noto di endpoint, comprese pagine HTML, una catena a tre livelli di profondità, robots.txt e sitemap, e route deliberate 404 e 500 — e poi ho analizzato il WARC risultante record per record invece di fidarmi di una riga di riepilogo.

Venti URI recuperati hanno prodotto sessantuno record:

Un rapporto pulito 1:1:1 tra response, request e metadata per URI, out of the box, senza alcuna configurazione da parte mia. E la completezza per record ha retto all’ispezione:

E lo stato HTTP è stato conservato alla lettera, compresi quelli brutti: 200 OK, 404 Not Found e 500 Internal Server Error compaiono come vere linee di status nelle response archiviate, invece di essere scartati come fallimenti.

Quest’ultimo punto separa l’archiviazione dallo scraping più nettamente di qualsiasi altro. Uno scraper considera un 500 un errore da riprovare o saltare. Un archivista lo tratta come ciò che il server ha detto in quel momento, un fatto che vale la pena conservare. La wiki Heritrix Output descrive questa struttura dei record; quello che non avevo visto da nessuna parte era la molteplicità misurata e il collegamento 20/20 su un insieme di endpoint noti. Funziona così.

Il risultato della deduplica, misurato in entrambi i modi

Il mio fixture serviva /dup/one e /dup/two con body identici byte per byte. URL diversi, stesso contenuto — il caso esatto per cui esiste la deduplica basata sul content digest. Ho eseguito il test due volte: una con il profilo stock, una dopo aver inserito la catena digest-history (BdbContentDigestHistory, più un ContentDigestHistoryLoader nella fetch chain e un ContentDigestHistoryStorer dopo il writer WARC).

Out of the box, entrambe le response hanno ricevuto lo stesso digest, ma nessun processore di history ha agito su quel dato e i due payload sono stati scritti per intero. Aggiungendo la catena, la seconda cattura è stata convertita in un record WARC revisit che punta al digest del payload identico, esattamente il comportamento che la specifica WARC 1.1 definisce per i revisit.

Non c’è nulla di nascosto. La pagina wiki Duplication Reduction Processors dice che skipIdenticalDigests ha valore predefinito false e che la deduplica agnostica rispetto all’URL richiede quei bean loader e storer. Non si tratta di un comportamento occulto scoperto per caso; come quasi tutto ciò che ho misurato qui, è comportamento documentato di Heritrix con un numero misurato in prima persona. Il divario è tra la documentazione e ciò che la gente crede, e nella mia esperienza la convinzione è di solito "Heritrix deduplica", punto, senza asterischi sulla configurazione.

Due conseguenze da tenere bene a mente:

La deduplica avviene al momento della scrittura, non sulla banda. Questo è un aspetto meccanico più che qualcosa che abbia misurato separatamente, ma segue direttamente da come funzionano i digest del contenuto: il digest si può confrontare solo dopo che i byte sono arrivati, quindi il secondo URL viene comunque fetchato dall’origine. Abilitare la catena riduce ciò che memorizzi, non ciò che trasferisci né ciò che il server di destinazione deve servire. Chi pianifica la deduplica come vantaggio di cortesia o di banda ha invertito il problema.

Le stime di storage basate su "tanto deduplica" possono essere molto sbagliate. Se stai archiviando un sito con forti duplicazioni di template — PDF specchiati, landing page standard, versioni print delle stesse pagine — e dimensioni i dischi assumendo che i body identici si comprimano automaticamente, il profilo stock può consumare molto più spazio di quanto previsto. Il fixture a due URL stabilisce il comportamento predefinito, non il suo effetto a scala di milioni di URI; quell’effetto dipende dal tasso di duplicazione, dalla dimensione dei payload e dal design dei recrawl.

Scope e robots hanno fatto esattamente ciò che promettono

La parola di un crawler su ciò che non ha fetchato vale poco, quindi entrambe le verifiche sono state fatte con un contatore lato server — il server di destinazione che conta le richieste da solo, indipendentemente da qualsiasi log di Heritrix.

Scope. Nel frattempo, l’host dentro scope è stato crawled normalmente, quindi lo scope era effettivamente applicato e non c’era un malfunzionamento generale del crawl. Una precisazione importante: qui ho eseguito solo il ramo con scope predefinito, non un controllo positivo con scope ampliato; quindi leggi questo come conferma del design documentato, non come prova bilaterale.

Robots. Il link era sempre raggiungibile; solo la policy robots lo ha soppresso. L’obbedienza è reale, ma lo è anche l’escape hatch, ed è l’assetto giusto — alcuni mandati di archiviazione legittimamente superano robots, e questo dovrebbe richiedere di scrivere intenzionalmente ignore in un file di configurazione.

Politeness: 57,7 secondi per crawllare venti pagine locali

C’è un numero che decide se Heritrix è adatto al tuo progetto.

Stesso fixture, stesso trattamento in tre run, su un singolo host locale con latenza inferiore al millisecondo:

Il ritardo effettivo si appoggia proprio al pavimento di minDelayMs: su un’origine con latenza inferiore al millisecondo, delayFactor × fetch-time è trascurabile e il minimo domina per costruzione. Il rapporto tra le due righe non è particolarmente utile perché il denominatore della configurazione senza politeness è di soli millisecondi e oscilla da una run all’altra. Il dato stabile è il pavimento assoluto: il Heritrix predefinito ha aspettato circa tre secondi tra le richieste allo stesso host in questo fixture, trasformando un crawl da venti pagine in circa un minuto di tempo reale.

Un modo concreto per percepirlo. Immagina che una biblioteca universitaria debba archiviare un sito governativo da 50.000 pagine prima della dismissione, tutto su un unico host. Con un pavimento di 3 secondi per host, significa 150.000 secondi di attesa forzata — circa 42 ore, cioè un giorno e tre quarti, prima ancora di considerare il tempo di fetch. È aritmetica ricavata dal mio pavimento misurato di 3.036 ms — 50.000 x 3,036 s = 151.800 s = 42,2 h; persino con il minimo configurato di 3.000 ms si arriva a 41,7 h, che arrotonda a 42, non a 41. Non è un crawl misurato, ma è l’aritmetica che serve al tuo piano di progetto.

Per correttezza, la politeness di Heritrix è per host, perché la frontier mette in coda per host. Un crawl ampio su migliaia di domini si parallelizza su quelle code e non eredita globalmente questo tetto. Il mio fixture era un singolo host, cioè il caso peggiore per questo numero. Se il tuo obiettivo di archiviazione è un sito enorme su un solo dominio, quel caso peggiore è il tuo caso.

E questa è una feature. Il delay è ciò che rende un crawler archivistico qualcosa che un sito tollera invece di bloccare. Ridurlo è una decisione che riguarda il server di qualcun altro, e lo strumento rende la scelta esplicita invece di defaultare sull’aggressività.

Cosa non ho testato

Queste misurazioni coprono la disciplina del crawl su un fixture controllato, e nient’altro. Oltre quel perimetro:

• Deduplica tra crawl e recrawl. Ho misurato solo la deduplica content-digest all’interno di un singolo crawl. Mantenere un database di history degli URI tra crawl separati (FetchHistoryProcessor + PersistLog) è un meccanismo diverso e non l’ho esercitato.
• Scala e stabilità a lungo termine. Nessuna frontier da un milione di URI, nessun checkpoint e restore, nessuna esecuzione di più giorni. Il fixture misura la disciplina, non la resistenza.
• Cattura di JavaScript. La cattura predefinita di Heritrix è non-browser ed è quella che ho misurato. I comportamenti opzionali basati su browser non sono stati testati qui.
• Politeness su un’origine ad alta latenza. La latenza locale è sotto il millisecondo, quindi minDelayMs domina per costruzione. Non ho isolato nei dati come delayFactor si comporti su un server reale lento.
• Recupero da sitemap. robots.txt è stato richiesto e la direttiva sitemap è stata seguita, ma non ho verificato separatamente il recupero di ogni voce <loc>.

Cosa rendere esplicito prima del primo job in produzione

Il profilo stock è lungo, ma le decisioni che cambiano il significato di un archivio sono abbastanza compatte. Parti dallo scope. I seed generano prefissi SURT predefiniti, e le DecideRule possono allargarli o restringerli in sequenza. Rivedi l’ordine finale delle regole con URL rappresentativi dentro e fuori scope, poi verifica il risultato con il traffico lato server o con un altro log indipendente delle richieste. Un solo report di crawl non può dimostrare che un host escluso non sia mai stato contattato.

Poi decidi cosa significano la policy robots e l’identità dell’operatore per la raccolta. Il default testato ha rispettato la regola di disallow del fixture, mentre cambiando robotsPolicyName in ignore il percorso bloccato è stato fetchato. È un interruttore semplice dal punto di vista meccanico, ma molto rilevante dal punto di vista istituzionale. Registra chi lo ha approvato e perché, insieme a un operatorContactUrl funzionante; l’URL richiesto offre al proprietario del sito una via di ritorno verso l’operatore, ma non fornisce la giustificazione dell’autorizzazione.

La pianificazione dello storage richiede una scelta esplicita a parte. Se i body identici devono diventare record di revisit, aggiungi e verifica i processori di history del content digest prima di dimensionare l’archivio. La catena testata ha influenzato la rappresentazione dopo il fetch, quindi il traffico verso l’origine va comunque previsto per entrambi gli URL. La deduplica tra crawl è un meccanismo separato e non dovrebbe essere dedotta da questo risultato su due URL in un solo crawl. Un piccolo crawl di validazione con body duplicati noti è un modo economico per verificare che il grafo di bean distribuito produca i tipi di record desiderati.

Infine, tratta la politeness come un input di scheduling, non come una manopola da rifinire all’ultimo minuto. Nel fixture locale a host singolo, minDelayMs ha dominato il tempo totale. Un progetto reale dovrebbe calcolare il pavimento per-host configurato in base al numero di host target e alla scadenza della raccolta, poi testarlo su una latenza rappresentativa. Crawl ampi e crawl su singolo sito stressano in modo diverso la frontier partizionata per host; questa recensione ha misurato solo il secondo caso. Tieni nel runbook anche il ciclo di vita REST: build, launch, unpause, poll, terminate e teardown sono stati separati che vale la pena osservare nell’automazione.

Pro e contro

Pro

• Completezza dell’archivio eccellente già di default: 20/20 response con digest del payload, IP di cattura e collegamento completo request↔response, senza configurazione.
• Conserva le risposte di errore come fatti — le linee di status 200, 404 e 500 sono tutte archiviate alla lettera.
• Disciplina dello scope verificata con un contatore lato server: nessun fetch fuori scope mentre l’host dentro scope veniva crawled normalmente.
• L’obbedienza a robots sopprime davvero il fetch, con un escape hatch ignore intenzionale per archiviazioni imposte.
• Completamente headless via REST — create, build, launch, poll, teardown, tutto via curl, nessun clic nella UI.
• Funziona pulitamente su OpenJDK 26.0.1 senza flag JVM, cosa che, per un codice di vent’anni, è una igiene Java migliore di quella di molti codebase coevi.
• L’URL di contatto dell’operatore obbligatorio impedisce al crawler di funzionare anonimamente.
• Ogni parte del crawl è un bean sostituibile, ed è per questo che abilitare la deduplica è costato tre inserimenti di bean e non un fork.

Contro

• La deduplica basata sul content digest è disattivata di default e scrive per intero i payload identici — una trappola reale per la pianificazione dello storage.
• Il deployment è pesante: distribuzione da 41 MB, 114 jar, motore Java più Jetty, e una configurazione Spring del job di circa 750 righe.
• La politeness predefinita impone un pavimento di circa 3 secondi per host; un crawl da 20 URI su un singolo host ha richiesto 57,7 secondi.
• Nessun rendering JavaScript nel percorso predefinito, quindi i contenuti generati solo dal client non vengono catturati.
• La superficie di configurazione premia l’esperienza e punisce l’uso casuale; non esiste un percorso da cinque minuti al primo crawl.
• Nell’output non c’è alcun dato strutturato. Estrarre campi da un WARC è un progetto separato.

Chi dovrebbe usarlo e chi dovrebbe lasciar perdere

Heritrix è pensato per istituzioni e team il cui deliverable è l’archivio stesso. Biblioteche, archivi nazionali, conservazione per fini legali e di compliance, gruppi di ricerca che catturano il web come fonte primaria, chiunque debba dimostrare tra cinque anni cosa serviva un URL in un certo giorno. Se nel tuo vocabolario ci sono già le parole "WARC", "replay" e "provenance", questo è lo strumento attorno a cui è stato costruito il resto del tuo ecosistema, e il suo peso è il prezzo dell’interoperabilità.

La frontier partizionata per host e il lungo uso nel web archiving lo rendono un candidato plausibile per crawl ampi su molti domini. Questa è una considerazione architetturale e di storia del progetto, non un risultato di scala ottenuto da questo fixture; throughput a lungo termine, recovery da checkpoint e comportamento su un milione di URI restano qui non testati.

Lascia perdere se vuoi dati, non un archivio. Se il tuo obiettivo è ottenere un foglio di calcolo con prodotti, annunci o contatti, Heritrix farà un lavoro impeccabile nel catturare pagine che poi dovrai far passare in una pipeline separata per estrarre i dati — e avrai pagato un motore Java, una configurazione Spring e un pavimento di politeness di 3 secondi per il privilegio. Lascia perdere anche se i tuoi target sono single-page app renderizzate lato client, dove un fetcher non-browser cattura la shell ma non il contenuto; in quel caso lo strumento giusto è un archiviatore basato su browser. E lascia perdere se ti serve un primo risultato oggi, perché la curva di setup è reale.

Alternative e dove si inserisce un’API gestita

Nel mondo dell’archiviazione, l’alternativa moderna diretta è Browsertrix Crawler — un archiviatore basato su browser che guida Chromium e registra ciò che il browser ha fatto. Può catturare contenuti generati da JavaScript che mancano nelle risposte HTTP predefinite di Heritrix, ma introduce overhead di deployment e runtime del browser. Questa recensione non ha eseguito un benchmark testa a testa, quindi la decisione parte dai requisiti di cattura: se il contenuto nasce nel browser, serve un archiviatore browser-based; per le risorse HTTP convenzionali, Heritrix resta il percorso nativo.

Recensione correlata: recensione di Browsertrix Crawler.

Per un problema di natura diversa — non vuoi un archivio, vuoi dati strutturati dalle pagine — confronta Heritrix con i sistemi di estrazione in base all’output, invece di trattarli come crawler equivalenti. Heritrix è gratuito e self-hosted: esegui la JVM, gestisci il file dei bean, dimensioni i dischi e regoli la politeness. Questo modello funziona quando il deliverable è la conservazione.

Disclosure: Thunderbit è il prodotto dell’editore e non è stato testato in questo fixture Heritrix. Appartiene alla categoria di estrazione gestita: il suo output è il contenuto della pagina o record strutturati, non file WARC di livello archivistico. Scegli un archiviatore quando servono cattura riproducibile e provenienza; considera un servizio di estrazione quando il deliverable sono righe o testo di documenti e la gestione in modalità service è accettabile.

L’archiviazione porta con sé una questione di autorizzazioni, e non è la stessa cosa dello scraping. Heritrix rispetta robots.txt di default e richiede che tu ti identifichi prima di prelevare un byte, il che è una buona base — ma un crawl conforme a robots non è automaticamente autorizzato. Copyright, termini di servizio, dati personali e il mandato della tua istituzione si sovrappongono tutti a questo livello, e la policy ignore esiste per le organizzazioni che hanno una base legale per usarla, non come semplice toggle di comodità. Se stai avviando un programma di archiviazione, chiarisci prima l’ambito delle autorizzazioni e, se è un territorio nuovo, leggi la parte legale di web scraping e archiviazione.

Prova Thunderbit per l’estrazione di dati dal web

Verdetto

Conviene usare Heritrix? Sì — se il tuo output è un archivio e hai qualcuno disposto a imparare i bean Spring.

Il fixture porta a una decisione chiara: il profilo stock ha preservato in modo coerente response, request e metadati di cattura; i controlli di scope e robots hanno influenzato i fetch lato server così come configurato; e l’intero ciclo di vita del job è stato eseguito via REST. Sono proprietà utili per una pipeline di archiviazione, entro il piccolo perimetro a host singolo testato qui.

I costi operativi sono altrettanto chiari: una distribuzione Java e una grande configurazione Spring, un delay per host configurato che ha dominato questo crawl locale, e una deduplica basata sul content digest che richiede processori di history aggiuntivi. I team che hanno bisogno di fedeltà WARC possono accettare questi costi; chi ha bisogno di campi estratti dovrebbe partire da un’altra categoria.

Prima di un crawl in produzione, verifica la catena di deduplica, le impostazioni di politeness, lo scope, la policy robots, l’identità dell’operatore e le assunzioni sullo storage rispetto alla configurazione reale del job. Il profilo stock è un punto di partenza, non una dichiarazione implicita di queste scelte operative.

Prova Thunderbit per l’estrazione di dati dal web Get Started Free

FAQ

operatorContactUrl rende autorizzato un crawl? No. Impone che il job includa un URL di contatto, offrendo ai gestori del sito un canale di responsabilità, ma non stabilisce permesso, correttezza dell’identità, stato del copyright o conformità normativa. Questi restano aspetti di deployment esterni al crawler.

La deduplica content-digest riduce le richieste verso l’origine? Non nella configurazione testata qui. Entrambi gli URL sono stati fetchati prima che i rispettivi digest del payload potessero essere confrontati. La catena di history ha cambiato il modo in cui il secondo payload è stato rappresentato nello storage WARC; non ha trasformato il secondo URL in una richiesta di rete saltata.

Heritrix può funzionare senza la web UI? Sì. Il ciclo di vita testato — creazione, upload della configurazione, build, launch, unpause, polling, terminazione e teardown — è stato eseguito tramite API REST con curl. La UI Jetty incorporata non era necessaria.

Il profilo stock di Heritrix deduplica i payload identici? Non nel fixture così configurato. Il profilo stock ha memorizzato entrambe le risposte identiche come record response completi. Aggiungendo la catena di history del content digest, la seconda cattura è diventata un record revisit, quindi la deduplica è una scelta di pipeline da configurare e verificare, non un default automatico.

Come scelgo un delay di politeness? Tratta i tempi locali qui come una verifica del meccanismo, non come una raccomandazione di produzione. Imposta il delay in base alle regole del sito target, all’accordo con l’operatore, alla capacità del server, allo scopo del crawl e alla tua policy di retry/concorrenza, poi conferma nei log i reali gap tra richieste allo stesso host.