HTTP Protocol URLs

HTTP (Hypertext Transfer Protocol) is the foundation of web communication. While HTTP URLs remain valid, HTTPS is now required for modern web security.

Understanding HTTP matters because it powers over 99% of web traffic and forms the basis for every browser request you make. Even though you should always use HTTPS in production, knowing HTTP helps you debug network issues, work with legacy systems, and understand why certain security measures exist.

"HTTP is a stateless application-level request/response protocol that uses extensible semantics and self-descriptive message payloads for flexible interaction with network-based hypertext information systems."

HTTP URL Structure

Every HTTP URL follows a specific structure with components that browsers and servers use to locate and retrieve resources. Understanding each part helps you construct URLs correctly, debug routing issues, and work with APIs.

# HTTP URL components
http://user:password@example.com:8080/path/page?query=value#fragment

# Components:
http://          - Scheme (protocol)
user:password@   - Credentials (deprecated, insecure)
example.com      - Host
:8080            - Port (80 is default, omitted if default)
/path/page       - Path
?query=value     - Query string
#fragment        - Fragment (not sent to server)

# Default port
http://example.com      # Port 80 (implicit)
http://example.com:80   # Port 80 (explicit, same as above)
http://example.com:8080 # Port 8080 (non-standard)

The example above breaks down each URL component. Notice that the port is typically omitted when using the default (80 for HTTP), and credentials in URLs are discouraged because they appear in browser history and server logs.

Now that you understand HTTP URL structure, let's compare HTTP with its secure counterpart to see why HTTPS has become the standard.

HTTP vs HTTPS

The differences between HTTP and HTTPS go beyond just adding an "S" to the protocol. The table below highlights the key distinctions that affect security, performance, and SEO.

With these differences in mind, let's dive deeper into the security vulnerabilities that make HTTP unsuitable for production use.

Security Concerns

HTTP traffic travels over the network in plain text, making it vulnerable to interception and modification. Any attacker on the same network (coffee shop WiFi, compromised router, ISP) can read and alter your data.

// HTTP vulnerabilities

// 1. Man-in-the-middle attacks
// Attacker can read all traffic
// http://bank.com/transfer?amount=1000&to=attacker

// 2. Session hijacking
// Cookies sent in plaintext
// Set-Cookie: session=abc123
// Attacker intercepts cookie, impersonates user

// 3. Content injection
// Attacker modifies HTML/JS in transit
// Inject malicious scripts, ads, or redirects

// 4. Credential theft
// Passwords sent in plaintext
// POST http://site.com/login
// Body: username=user&password=secret123

// Always redirect HTTP to HTTPS in production
app.use((req, res, next) => {
  if (!req.secure && process.env.NODE_ENV === 'production') {
    return res.redirect(`https://${req.hostname}${req.url}`);
  }
  next();
});

The code above illustrates the four main attack vectors: man-in-the-middle attacks, session hijacking, content injection, and credential theft. The Express.js middleware at the end shows the first line of defense—redirecting all HTTP traffic to HTTPS.

Once you understand these risks, the next step is implementing proper HTTP to HTTPS redirects across your infrastructure.

HTTP to HTTPS Redirects

Redirecting HTTP to HTTPS should happen at multiple levels—your web server, CDN, and application code. The examples below cover the most common configurations you'll encounter.

# Nginx redirect
server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

# Apache .htaccess
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# Cloudflare / CDN
# Enable "Always Use HTTPS" in dashboard

# Express.js
app.use((req, res, next) => {
  if (req.headers['x-forwarded-proto'] !== 'https' && process.env.NODE_ENV === 'production') {
    return res.redirect('https://' + req.hostname + req.url);
  }
  next();
});

Each configuration above sends a 301 (permanent) redirect from HTTP to HTTPS. The Nginx and Apache examples handle this at the server level, while the Express.js version uses the x-forwarded-proto header for apps behind load balancers or proxies.

While HTTPS is mandatory for production, HTTP still has a valid use case in local development environments.

Local Development

During local development, HTTP is perfectly acceptable—you're not transmitting data over the internet, and SSL certificates add complexity. However, testing with HTTPS locally can help catch mixed-content issues before deployment.

# HTTP is acceptable for local development
http://localhost:3000
http://127.0.0.1:8080
http://192.168.1.100:3000  # Local network

# Development servers typically use HTTP
npm run dev  # http://localhost:3000

# For testing HTTPS locally:
# 1. mkcert for local certificates
mkcert localhost
# Creates localhost.pem and localhost-key.pem

# 2. Use local certificates in dev server
const https = require('https');
const fs = require('fs');

https.createServer({
  key: fs.readFileSync('localhost-key.pem'),
  cert: fs.readFileSync('localhost.pem')
}, app).listen(3000);

The examples above show typical HTTP URLs for local development, and how to set up HTTPS locally using mkcert for certificate generation. This approach lets you test HTTPS-only features like service workers without deploying to a server.