WebOne: a man in the middle proxy that puts Web 1.0 browsers back on the modern web

An adapter between old software and the modern web, run on a modern PC

WebOne is an HTTP 1.x proxy server whose stated purpose is to make old web browsers, media players and messengers usable again. The project describes it as an adapter between the modern web and old software, and the deployment shape follows from that: it is designed to run on a modern PC in the same network as the older computers, not on the old machines themselves.

That is the key architectural decision. A machine running Netscape Navigator 3 cannot be given a modern TLS stack or a current JavaScript engine, but a machine on the same LAN can be given a .NET runtime, ImageMagick and ffmpeg. The proxy does the hard work on the capable side and hands the old client something it can parse.

The project is written in C# and needs the .NET 8.0 Runtime, on Windows 8 or later or Windows Server 2012 or later, Linux, or macOS. The Russian section of the README is unusually explicit about the working principle, calling it a MITM proxy, and lists the core operations: removing HTTPS encryption, converting between HTTPS 1.1 and HTTP 1.0 in both directions, re-encoding responses into any charset including transliteration, substituting individual files, patching parts of the text traffic such as JavaScript, XML, CDF or RSS, converting and recompressing graphics and video on the fly with external converters, redirecting non-existent addresses to the Web Archive, downloading and converting YouTube video, and providing an FTP client so a browser can reach FTP servers.

Three ways to point an old browser at it, and one that works when nothing else does

The configuration story is the part that decides whether the old machine can be coaxed into working at all, and there are three routes.

The normal one is to set the IP address or hostname of the PC running WebOne as the HTTP, HTTPS and FTP proxy server in the old browser's settings. The default port is 8080 and the proxy type is HTTP 1.0, and the documentation states it is compatible even with Netscape Navigator 3. There is also an automatic configuration route, where you point the browser at http://proxyhost:port/auto.pac as the automatic proxy configuration URL, which is useful when the same machine is also used for modern browsing.

The third route is the fallback for browsers that cannot work with proxies at all, where you type the URL directly in the address bar in the form http://proxyhost:port/http://domain/filename.ext. The extra prefix is the whole URL, embedded in the path.

Whichever route you use, you can check that the server is alive by opening http://proxyhost:port/ in a modern browser, which returns the info page. The repository carries the sources for that, InfoPage.cs and RedirectorInfoPage.cs, alongside a large set of other root level C# files that map out the internal structure, including several HTTP server implementations, an FTP client with its own directory listing types, the transit managers that handle the MITM path, and the Web Archive request handler.

Running it: a Windows executable, a Linux service, and a macOS binary

The three platforms differ in how you start the thing, and the macOS case has the most options because the app is not signed for developer verification.

On Windows you simply run webone.exe and then open port 8080 in the Windows Firewall settings. On Linux the proxy installs as a service and is driven with the ordinary service management commands.

	$ sudo service webone start
	or
	$ sudo systemctl start webone

The other service verbs, start, stop, restart, status, enable and disable, work in the same way. On macOS you launch webone from Terminal.

	$ ./webone				(simply)
	$ ./webone 5170				(start on specific port, e.g. 5170)
	$ sudo ./webone 80			(if port is less than 1024, root rights are need)
	$ ./webone /some/folder/myconfig.conf	(to use specific configuration file instead of default)
	$ dotnet webone.dll			(alternative way, armv6 only)

Those same commands work on Linux when the systemd service is disabled, which is the situation on many retro machine setups. The port argument and the config file argument are the two that matter in practice, since a second proxy on the same machine is common and a per-instance config file is how you keep two configurations apart.

Configuration lives in webone.conf, and there is a place to put your own copy

Settings are held in the webone.conf file, and the documentation notes that any other file name can be used instead. The Russian section lists the full set of locations that are searched, which is a more complete answer than the English section gives. Besides the program directory, there is /etc/webone.conf with a /etc/webone.conf.d/*.conf directory, the per user paths ~/.config/webone/webone.conf and the macOS equivalents under ~/Library/Application Support/WebOne and /Library/Application Support/WebOne, and the Windows paths under the roaming AppData and ProgramData directories. A file named on the command line takes precedence over all of them.

The /etc/webone.conf.d/ directory is the tip worth taking. Configuration placed there overrides the webone.conf settings and is not overwritten on package updates, which means you can keep your own settings across an upgrade instead of losing them to a new default file.

The log file follows the same portability logic, with webone.log written to /var/log/webone.log, to the Windows roaming AppData path, or to ~/Library/Logs/webone.log, and a webone.logrotate file at the repository root for the Linux case. The repository root also carries a codepage.conf and an escargot.conf alongside the shipped webone.conf defaults.

Image and video conversion is delegated to ImageMagick, ffmpeg and yt-dlp

The conversions that make an old machine viable are not implemented in the proxy. Picture format conversion is performed with the convert utility from ImageMagick, which is bundled with WebOne, and for watching YouTube videos through the proxy you need ffmpeg together with yt-dlp. On Windows those are included in the win-x64.full zips, and on Linux and macOS they can be installed manually.

The repository shows how that is laid out, with Win32-all/ and Win32-full/ directories for the packaged Windows builds, where the full variant is the one with the extra converters, and the Converter.cs and WebVideoConverter.cs files at the root for the conversion logic. The WebVideoPlayer.cs file is the player side, and the Russian description spells out the scope of the feature list, covering on-the-fly conversion or recompression of graphics and video files using external converters, and downloading and converting YouTube video for playback in a browser on an old PC.

This is the pragmatic engineering choice of the project. Reimplementing image transcoding or a video codec in C# would be a large project with no relation to the actual problem, and the topic list on the repository carries archiveorg, escargot, yt-dlp, retrocomputing and http1-0 alongside the http-proxy tags, which is a fairly complete summary of what the project is trying to be.

Building from source, and the project's own warning about security

The source is on the master and dev branches of the Git repository, and the build uses the Microsoft .NET 8.0 SDK together with the dotnet-packaging add-on. With those in place, the build is the same everywhere: use dotnet publish, then dotnet deb, dotnet rpm or dotnet zip. Windows developers can use the build.bat script for cross platform building, and build.sh does the same job for Linux and macOS, with a separate build-armv6.sh for the ARMv6 target that matches the dotnet webone.dll alternative way of starting the app.

The security note in the README is the most important sentence in the document for anyone planning a deployment. The app is not intended for daily use, because removing encryption from web traffic and the use of a really old and unsupported browser may cause security problems. The server can be started even on public hosts, but you must enable password protection in the config file to stop the proxy being public.

The project also says who maintains it. It is maintained mostly by a single person, Alexander Tauenis, with thanks to contributors who made pull requests and bug reports. The licence is the one GitHub cannot classify, with a LICENSE.txt at the root, so read that file rather than assuming a standard licence. The help comes from a VOGONS thread, a phantom.sannata.ru thread, and the GitHub issues and discussions tabs, and the project explicitly welcomes forks, pull requests and bug reports, and points out that HTML, CSS and JavaScript skills are useful too, because the web traffic edits are written in those languages.

Editorial conclusion

Adopt WebOne if you have a genuine need to drive period software such as an old browser, a legacy media player or a classic messenger against today's web, because no amount of configuration on the old machine will make a 1990s client negotiate modern TLS. Do not adopt it as a general browsing proxy or expose it to an untrusted network, since the project states plainly that removing encryption from web traffic and using unsupported browsers creates security problems and asks you to enable password protection before running it anywhere public. Before you deploy it, read the wiki pages for your platform, plan the ImageMagick and ffmpeg dependencies, and keep your own settings in the configuration override directory so package updates do not overwrite them.

Frequently asked questions

Official sources

1. atauenis/webone on GitHub
2. Issues
3. README
4. Releases