HTTP CONNECT and TRACE Methods

While GET, POST, PUT, and DELETE handle most web traffic, HTTP includes two specialized methods for edge cases: CONNECT for tunneling through proxies, and TRACE for diagnostic echo. One is essential infrastructure. The other is a security liability we've mostly turned off.

CONNECT: Making Proxies Invisible

CONNECT exists because HTTP wasn't designed for encrypted connections through intermediaries.

Here's the problem: you're behind a corporate proxy, and you want to visit https://bank.com. If the proxy handles this like a normal HTTP request, it would need to decrypt your traffic, read it, and re-encrypt it for the bank. That breaks end-to-end encryption entirely—the proxy would see your passwords, account numbers, everything.

CONNECT solves this by turning the proxy into a dumb pipe:

CONNECT bank.com:443 HTTP/1.1
Host: bank.com:443

This says to the proxy: "Open a TCP connection to bank.com on port 443. Then stop being an HTTP proxy. Just forward bytes in both directions without looking at them."

The proxy responds:

HTTP/1.1 200 Connection Established

Now the proxy is invisible. Your browser and the bank's server negotiate TLS directly through the tunnel. The proxy sees encrypted gibberish flowing through it—exactly as intended.

What Makes CONNECT Unusual

CONNECT requests look different from normal HTTP:

CONNECT server.example.com:443 HTTP/1.1
Host: server.example.com:443
Proxy-Authorization: Basic dXNlcjpwYXNzd29yZA==

The URI isn't a path—it's a host:port destination. And Proxy-Authorization authenticates to the proxy, not the destination server.

Why Proxies Restrict CONNECT

An unrestricted CONNECT is dangerous. If a proxy accepts CONNECT to any host and port, it becomes an open relay for attacks, spam, or bypassing network controls.

Most proxies defend themselves:

Port restrictions: Only allow CONNECT to port 443 (HTTPS). A request to port 22 (SSH) gets rejected:

CONNECT server.com:22 HTTP/1.1
→
HTTP/1.1 403 Forbidden

Authentication required: No anonymous tunneling.

Domain whitelisting: Some corporate proxies only tunnel to approved destinations.

Logging: Proxies can't see tunnel content, but they log who's tunneling where.

CONNECT Happens Automatically

You rarely see CONNECT directly. When your browser is configured with an HTTP proxy, it sends CONNECT automatically for HTTPS sites:

Browser visits https://secure-site.com
↓
Browser → Proxy: CONNECT secure-site.com:443
Proxy → Browser: 200 Connection Established
Browser ↔ Proxy ↔ Site: Encrypted traffic flows through the tunnel

WebSocket connections through proxies work the same way—CONNECT creates the tunnel, then the WebSocket upgrade happens inside it.

Building CONNECT Support

If you're implementing a proxy:

server.on('connect', (req, clientSocket, head) => {
  const { port, hostname } = new URL(`http://${req.url}`);
  
  // Security: only allow HTTPS port
  if (port !== '443') {
    clientSocket.write('HTTP/1.1 403 Forbidden\r\n\r\n');
    clientSocket.end();
    return;
  }
  
  const serverSocket = net.connect(port, hostname, () => {
    clientSocket.write('HTTP/1.1 200 Connection Established\r\n\r\n');
    serverSocket.pipe(clientSocket);
    clientSocket.pipe(serverSocket);
  });
  
  serverSocket.on('error', () => {
    clientSocket.write('HTTP/1.1 502 Bad Gateway\r\n\r\n');
    clientSocket.end();
  });
});

TRACE: Transparency That Backfired

TRACE was designed for debugging. Send a request, and the server echoes back exactly what it received:

TRACE /path HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0

Server responds:

HTTP/1.1 200 OK
Content-Type: message/http

TRACE /path HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
X-Forwarded-For: 192.168.1.100
Via: 1.1 proxy.example.com

Now you can see what headers proxies added along the way. Useful for diagnosing how intermediaries modify requests.

The Security Problem

TRACE's transparency became a vulnerability called Cross-Site Tracing (XST).

Browsers protect cookies with the HttpOnly flag—JavaScript can't read them. But TRACE echoes everything in the response body, including cookies and authorization headers:

// Attacker's script
fetch('https://victim-site.com/', { method: 'TRACE' })
  .then(r => r.text())
  .then(body => {
    // body contains:
    // Cookie: session=secret-session-id
    // Authorization: Bearer secret-token
  });

The cookies are HttpOnly, so the script can't read document.cookie. But TRACE returns them in plain text, bypassing the protection entirely.

TRACE Is Mostly Dead

Due to XST, TRACE is disabled by default on virtually all modern servers:

• Apache: TraceEnable Off
• Nginx: Doesn't support TRACE at all
• IIS: Filtered out by default

Most servers return 405 Method Not Allowed. Security scanners flag enabled TRACE as a vulnerability.

The Max-Forwards Header

TRACE supports Max-Forwards to trace through proxy chains:

TRACE / HTTP/1.1
Max-Forwards: 2

Each proxy decrements the counter. When it hits zero, that proxy responds instead of forwarding. This helps identify which proxy in a chain is causing problems.

In practice, nobody uses this because TRACE itself is disabled everywhere.

Different Fates

CONNECT remains essential. Every HTTPS connection through a proxy uses it. You don't see it, but it's there—the invisible infrastructure that makes encrypted web browsing work through corporate networks.

TRACE is a cautionary tale. A method designed for transparency became a weapon. Its legitimate uses have been replaced by better tools: browser DevTools, proxy interceptors like Charles or Fiddler, server-side logging, or custom debug endpoints:

app.all('/debug/echo', (req, res) => {
  res.json({
    method: req.method,
    headers: req.headers,
    ip: req.ip
  });
});

Same debugging capability, no security hole.