HTTrack Website Copier 3.50.2 (32-bit)

What's new in this version:

HTTrack Website Copier 3.50.2 (32-bit)
New:
- a running mirror can be stopped or paused by writing hts-abort.lock or hts-stop.lock into the output directory, and a stop keeps the work done so far. The man page documents the four lock files
- the lock files work on every platform. They matter most on Windows, which has no signal to send
- --enable-ipv6 and --disable-ipv6 pin IPv6 support. It used to follow whatever the build machine had, and it changes the layout of an installed struct, so two builds of the same source disagreed without saying so
- --disable-ipv6 failed to build, and on an IPv4-only build -@i2 exited 255
- --disable-auto-features stops the build machine from deciding which optional codings and libraries are compiled in, so a packager gets the same binary from the same recipe. --enable-backtrace=yes/no/auto and --with-iconv[=DIR] pin two more of those choices
- an embedding application can ask hts_mirror_completed() whether the last mirror reached the end of its crawl. The return code of hts_main2() cannot answer that, because a mirror the user stopped returns 0 just like a finished one
- each front end needs a change of its own before it can tell a mirror the user stopped from a completed one
- an embedding application can wrap each engine worker thread in its own crash handler with hts_set_thread_runner(), and --disable-crash-test compiles out the -#c crash test, which such an application used to ship as a deliberate crash reachable from its command line
- hts_findgetsize64() returns the size of a file past 2 GB
- hts_findgetsize() reported a 5 GB file as 1 GB, so a program sizing a buffer from it got a short one. It now returns -1 past 2 GB rather than a wrong number
- the shipped changecontent example plugin takes an own mode, written as --wrapper mycallback,own,OLD=NEW. The plugin then answers with a buffer of its own, so the new text may be longer than the text it replaces. html/plug.html describes both kinds of reply
- --help prints the [compiled: ...] platform line again, missing since 2012 and useful in a bug report

Fixed:
- a crafted page could kill the crawler outright on an ordinary httrack http://host/ -O dir run. Five buffers whose width the page decides reached a helper that aborts rather than truncates
- the five buffers were reached through a charset that turns one byte into three, an applet codebase, URL userinfo, a stored credential prefix and a punycode host
- two out-of-memory paths killed the crawler where the rest of the engine only fails the page, and an unallocatable table of connection slots crashed instead of reporting itself
- a crawled page could name a local file with >postfile:, and the engine opened that file and sent it to the server that served the page
- a >postfile: request read past the end of its buffer, so bytes of the program's own stack went out on the wire
- a crafted size header in httrack's own hts-cache backlog ready table wrapped the allocation that reads it to zero, so the engine wrote a guard byte outside that allocation
- a response of 2 GB or more was loaded into memory although the code that reads it indexes with an int, and a file of exactly 4 GB read back for parsing was divided by a length that the same cast turned into zero
- with --single-file, a page whose first byte opened a url() reference made the parser read one byte in front of the response body
- a status line of "HTTP/1.1 4294967496 OK" wrapped to 200, so the page was mirrored as a successful fetch, and a reason phrase carrying a bare CR was written into hts-log.txt where it read as a line the engine wrote
- about 40 KB of request headers killed the -#P URL catcher. The catcher binds to the address the host name resolves to, so another machine can reach it
- the -#P URL catcher dropped a request header line longer than its buffer without a word, so it lost the cookie it was opened to capture
- twenty -%X header lines killed the crawl, because nothing summed the parts of a request against the 16 KB buffer it is built in
- a postprocess plugin reporting a wrong size made HTTrack save an empty page with no message, or copy heap memory past the page into the mirrored file
- the shipped changecontent example plugin read past the end of the page buffer, and the plugin documentation gave preprocess's buffer rule to postprocess, which does not own its reply
- ProxyTrack served one client another page's headers and body when an .arc record declared a length reaching into the record stored after it
- ProxyTrack sent the uninitialised tail of its own buffer when a cache entry named a file shorter than its declared size
- on a 32-bit build ProxyTrack wrote a string terminator outside an allocation sized from a forged X-Size field, and a truncated or corrupt legacy .ndx or .dat cache aborted it instead of being refused
- long crawls leaked memory in four places. The parser's output buffer leaked on every bailout, and so did the cookie jar's basic-auth list, the built-in server's 32 KB request buffer, and a ZIP member record when writing the cache failed
- cookies exported from a browser were ignored or sent to the wrong host. HTTrack stored them under the host with its port still attached, so a mirror of a site on :8080 lost the session
- a cookies.txt domain field written with a capital letter was never sent
- an IPv6 host with a zone id kept its %25 escape in the cookie jar and was dropped with no message
- a cookie set for example.com was also sent to wwwexample.com, and a jar entry with an empty domain went to every host
- a mirror that stopped early threw away what a resume needs. A front end's Stop button ended it as if it had finished, and --max-size and --max-time erased the byte ranges of the files left half written
- a first ^C kept the partial files but deleted the data that would have resumed them. A later re-crawl then asked for a range past the end of a restored copy, got a 416 and deleted the complete file
- after an aborted mirror the message told the user to erase the cache that a --continue resume needs, and the engine kept the smaller of the two cache generations, so a crawl stopped halfway lost the complete one on its next run
- an hts-stop.lock left in a reused output directory paused the next mirror on its first poll, and a stop or pause written during the mirror's first second was ignored for the rest of the run
- HTTrack rewrote text in a script that was never a link. new URL(x) matched the CSS url( token, so a mirrored bundle stopped parsing
- a JavaScript string ending in a slash counted as a link, so split("/") became split("index-2.html"). A script link such as "/#top" is still rewritten, so it still resolves under file://
- a URL rewritten inside a script or a stylesheet was HTML-escaped, and neither JavaScript nor CSS decodes an entity, so the mirrored page broke in the browser
- a consumed base element was saved with an empty attribute list, which stops an Angular application starting
- a base element whose href is relative, such as "./", was read as a host name, so none of the page's own assets were fetched and the crawl still reported a clean mirror
- with --replace-external, every image but .gif, .jpg and .xbm got the HTML placeholder instead of external.gif, so the browser drew a broken image. .jpeg was one of the misses, although it sits in the default filter set the GUI ships
- a cached page whose stored CRC did not match went into the mirror without a word
- on an update crawl --sizehack decided from the cache index alone, so a page was kept whenever its recorded length matched, and a mirrored file edited by hand was dropped and never fetched again
- a mirror interrupted on one machine and resumed on another read its own resume state with the wrong word size and byte order. That state is now written in a portable form
- an old hts-cache/ref file is refused rather than converted, so a mirror interrupted under 3.50.1 or earlier restarts those transfers from zero after the upgrade
- httrack -#C printed "No cache entry found" over any cache, because it read a new.ndx index that nothing has written since 3.31
- running httrack with no arguments and nothing on stdin never stopped asking for a project name, printing 12674 prompts and 204 MB of help text in twelve seconds. Windows was worst, because there the wizard runs even with redirected input
- three long options reached the option next to the one they name. --extract-cache listed the cache instead of extracting it, --autotest mirrored the site instead of running the autocheck, and --debug-testfilters named an option that no longer exists and mirrored its two filter arguments as URLs
- --updatehttrack printed the usage, mirrored nothing and exited 0
- --help and the man page documented defaults the engine does not use. The -C default is C1 and not C2, and -R and the log mode starred the wrong entry
- --fast-engine and --debug-overflows promised to do something and have no effect. The alias table was the only place that described them, so nothing else could correct it
- the -@ options reported an unknown option under the wrong prefix, so -@z answered "invalid option %z"
- the guide page html/fcguide.html still answered "Not yet!" to the SOCKS question years after SOCKS5 and CONNECT shipped. The FAQ page was already right
- a build without dlopen still told the WebHTTrack interface that plugin loading was available, so the interface offered what the build could not do
- in a build without OpenSSL an https link was rewritten against the page's own host and fetched over plain HTTP, and --enable-https=auto failed to build at all when OpenSSL was absent
- in a build without iconv, a page declaring charset=windows-1252 was never decoded, because the built-in tables only knew the name cp1252, and a body starting with a NUL byte crashed the same decoder
- --with-brotli=DIR and --with-zstd=DIR looked only in DIR/lib, so a lib64 prefix was ignored and configure silently used a system copy instead
- none of --with-brotli=DIR, --with-zstd=DIR and --with-zlib=DIR looked under a multiarch triplet, so on Debian and Ubuntu both --with-brotli=/usr and --with-zlib=/usr failed with a hard error
- on FreeBSD, NetBSD and DragonFly the engine could not find its own binary path and fell back to argv[0]
- building the engine sources without running configure failed on the first file, because htsglobal.h always included the generated htsfeatures.h
- a plugin including only httrack-library.h did not compile, because CHAIN_FUNCTION() needs types that header did not declare, and libhttrack.pc now names the OpenSSL include directory where the compiler cannot find it alone
- the Windows build pinned an OpenSSL carrying three moderate advisories, CVE-2026-18798, CVE-2026-63072 and CVE-2026-63076

Changed:
- the WebHTTrack interface installs under $(datadir)/httrack/html/server rather than the documentation directory, which packagers strip
- with the wizard on, which is the default, a link whose address and path together exceed HTS_URLMAXSIZE*2 is refused instead of aborting the mirror. The refusal reaches the log at debug level only, so a very long URL that used to be crawled is now dropped in silence
- the second parameter of hts_request_stop() is now keep_resume. It was called force and was ignored. Pass true to keep the resume data of a mirror you stop
- the signature of hts_request_stop() does not move, so an embedding application that keeps passing HTS_FALSE loses that resume data and gets no compiler warning
- the language catalogs ship with LF line endings. They were pinned to CRLF for readers outside this tree, and both of those readers, WinHTTrack and httrack-android, strip the CR anyway
- the catalogs drop two messages WinHTTrack no longer shows, LANG_F22b and LANG_F24, and gain LANG_F22s for a mirror the user stopped. The change reaches lang.def and all 30 catalogs, so translators and the other front ends see it
- html/library.html lists the headers that are actually installed, gives the pkg-config line and points at the libtest examples, instead of pointing at a source file nobody can build outside the tree
- a program built against these headers now accepts a libhttrack whose option structure has grown, where the check demanded an exact size match and refused it. The check is compiled into the program, so it helps programs built from 3.50.2 on rather than ones already installed
- the mismatch message now names the two sizes. It used to print version strings while it compared sizes, one taken from the library at run time and one from the caller at compile time
- WebHTTrack refuses to start against a library it cannot use, where it printed "** CRITICAL:" and went on serving. HTTRACK_INCOMPATIBLE_VERSIONID is deleted
- multiple internal test, build and CI improvements


HTTrack Website Copier 3.50.0 (32-bit)
New:
- this is the engine the Windows and Android front ends ship on. WinHTTrack had not been released since 3.49-2 in May 2017, so a Windows user coming from it gets everything listed under 3.49-3 to 3.49-25 below in one step. The largest of those: HTTPS against modern servers, SOCKS5 and CONNECT proxies, Brotli and Zstandard, files past 2 GB, Windows paths past 260 characters, accented and non-Latin project names and paths, WARC output, --sitemap, --single-file, --changes and --host-alias, and an --update that keeps a good local copy when the server answers with an error
- --disable-example-libs skips the ten example plugins four distributions used to un-install by hand

Changed:
- the compiled-in /etc, /usr/bin and /usr/lib follow the configure directories, so a build with its own --prefix reads its own httrack.conf
- the installed headers no longer include autoconf's config.h, which collided with a consumer's own. The switches they read come from a generated htsfeatures.h
- --htmldir defaults to $(docdir)/html, so the manual's links to the release notes, the licence and the greetings resolve where it is installed
- shipped text files carry LF, so rpm packagers no longer dos2unix them
- multiple internal documentation, test and build improvements

Fixed:
- an Android or Termux build no longer needs hand-patching for backtrace() and a sys/timeb.h that bionic dropped
- --with-zlib=DIR looked for the library in DIR/lib and nowhere else
- three configure option checks truncated their error message at a comma


WinHTTrack Website Copier 3.49.2 (32-bit)
- Fixed: Buffer overflow in output option commandline argument
- Minor fixes


WinHTTrack Website Copier 3.49.1 (32-bit)
- Engine fixes (keep-alive, redirects, new hashtables, unit tests)


WinHTTrack Website Copier 3.48.22 (32-bit)
- Fixed: Google RPMs use /usr/bin/google-chrome as program location
- Fixed: Fixed htsserver not dying (immediately) on quit
- New: Updated WIN32 OpenSSL to 1.0.1j
- Fixed: injection-proof templates
- Fixed: htshash.c:330 assertion failure ("error invalidating hash entry")
- Fixed: Windows 2000 regression (fantozzi.usenet)
- Fixed: code cleanup (aliasing issues, const correctness, safe strings)
- New: handle --advanced-maxlinks=0 to disable maximum link limits
- New: updated ZIP routines (zlib 1.2.8)
- Fixed: fixed infamous "hashtable internal error: cuckoo/stash collision" errors


New in WinHTTrack Website Copier 3.48.20 (32-bit)
- Fixed: webhttrack incompatibility with Chrome