Skip to main content
Scramjet uses transport libraries to proxy HTTP requests and WebSocket connections. The primary transport system is bare-mux, which provides a pluggable architecture for different backend protocols.

Transport architecture

Scramjet’s transport layer consists of:
  1. BareClient - Main client interface from @mercuryworkshop/bare-mux
  2. Transport backends - Pluggable implementations (bare-server, epoxy, wisp, libcurl)
  3. BareMuxConnection - Worker-to-client communication bridge

bare-mux integration

bare-mux is Scramjet’s default transport multiplexer, allowing runtime transport switching.

Installation

Service worker setup

The service worker creates a BareClient instance:
BareClient provides a fetch()-like API that automatically routes requests through the configured transport.

Window/client setup

In the window context, Scramjet creates a separate BareClient:

Worker transport bridge

Workers need a MessagePort to communicate with the parent’s BareClient:
Workers cannot directly access the transport because:
  1. Isolation: Workers run in separate contexts without DOM access
  2. Shared state: Multiple workers need to share the same transport configuration
  3. Performance: Centralized transport reduces overhead
BareMuxConnection creates a MessageChannel that bridges the worker to the main context’s BareClient.

Transport backends

bare-server (default)

The standard Bare server protocol:
Client configuration:

epoxy-transport

Epoxy uses WebTransport for improved performance:
Setup:
Epoxy requires browser support for WebTransport API (Chromium-based browsers). Fallback to bare-server for compatibility.

wisp protocol

Wisp provides WebSocket-based proxying:
Configuration:
Wisp is particularly useful for:
  • Environments where HTTP proxying is restricted
  • Bypassing certain network filters
  • Multiplexing connections over a single WebSocket

libcurl-transport

Native performance using libcurl:
libcurl-transport requires native bindings and is primarily used in Electron or Node.js environments.

Setting the transport

Static configuration

Set transport during Scramjet initialization:

Dynamic transport switching

Users can switch transports at runtime:
Transport switching is seamless - existing connections continue using the old transport while new requests use the updated configuration.

WebSocket proxying

Scramjet uses bare-mux’s BareWebSocket class for WebSocket connections:

WebSocket protocol handling

Different transports handle WebSockets differently:
  • bare-server: Upgrades HTTP connection to WebSocket
  • wisp: Multiplexes over existing wisp WebSocket connection
  • epoxy: Uses WebTransport streams

Request/response flow

Standard fetch request

Header rewriting

BareClient handles header transformations:

Response types

BareClient returns a BareResponseFetch object:

Debugging transports

Check current transport

Monitor requests

Error handling

Advanced patterns

Custom transport implementation

You can implement custom transports by following the bare-mux protocol:

Transport fallback chain

Conditional transport selection

Common issues

Transport not initialized

Worker transport errors

CORS errors