Hoffman Web Seeding BEP 17 vs BEP 19 Explained

This article explores the mechanics of the BitTorrent Hoffman-style web seeding specification (BEP 17) and compares it with the GetRight-style web seeding specification (BEP 19). Web seeding allows BitTorrent clients to download piece data from traditional HTTP or FTP servers alongside regular peer-to-peer swarms. While both BEP 17 and BEP 19 fulfill the goal of integrating web servers as fallback seeders, they diverge significantly in how requests are structured, server-side requirements, and multi-file handling.

Understanding BEP 17 (Hoffman Style)

BEP 17, created by John Hoffman for BitTornado, defines a web seeding protocol where the client interacts with specialized scripts on an HTTP server rather than requesting static files directly.

In BEP 17, the .torrent metadata includes an httpseeds key containing a list of URLs pointing to backend scripts or redirectors. When a BitTorrent client requires specific pieces of a torrent, it sends standard HTTP GET requests appended with query parameters detailing the swarm’s info-hash, the requested piece index, and the byte ranges within that piece.

A typical BEP 17 request looks like:

http://example.com/seed.php?info_hash=HASH&piece=INDEX&ranges=START-END

Because the server receives specific piece parameters, it must execute server-side logic (e.g., via PHP, Python, or a custom daemon) to parse the request, extract the appropriate byte offset from the target file or archive, and return the raw binary payload to the client.

Understanding BEP 19 (GetRight Style)

BEP 19, formulated by Michael Burford of GetRight, is the more widely implemented alternative to BEP 17. Instead of relying on server-side processing scripts, BEP 19 allows BitTorrent clients to download from standard, unmodified HTTP 1.1 servers.

In BEP 19, the .torrent file contains an url-list key with URLs pointing directly to static file locations. The client calculates the exact byte offsets corresponding to the pieces it needs and issues standard HTTP GET requests using the standard Range: header (e.g., Range: bytes=0-16383). The web server merely serves the byte ranges as it would for any standard resumable download.

Key Differences Between BEP 17 and BEP 19

1. Server Configuration and Requirements

• BEP 17: Requires active server-side execution. The hosting provider must run custom scripts capable of reading torrent metadata and slicing data on demand.
• BEP 19: Requires only a standard HTTP 1.1 server (such as Apache, Nginx, or AWS S3) that supports standard byte-range requests. No custom scripting is required.

2. Multi-File Torrents

• BEP 17: The server-side script abstracts the internal file hierarchy of the torrent. The client simply requests piece numbers, and the script handles mapping those pieces across multiple files.
• BEP 19: The client must map torrent pieces to specific file paths. In multi-file torrents, the root URL provided in the url-list must mirror the folder structure defined in the torrent metadata, and pieces spanning boundaries between two files require multiple HTTP requests to different endpoints.

3. URL Structure and Request Protocol

• BEP 17: Uses URL query string parameters (info_hash, piece, ranges) to convey BitTorrent-specific concepts to the server.
• BEP 19: Uses standard HTTP paths pointing to raw files, combined with standard HTTP Range request headers.

4. Adoption and Compatibility

Due to the simplicity of serving static assets without executing backend code, BEP 19 gained broad support across almost all modern BitTorrent clients (such as libtorrent-based clients, qBittorrent, and Transmission) and content delivery networks. BEP 17 remains a legacy specification, primarily used in custom or specialized environments where on-the-fly piece generation is necessary.