Analysis and Solutions for Chrome Redirecting HTTP to HTTPS in Local Development Environment

Problem Phenomenon and Background

During Visual Studio project debugging, many developers encounter a perplexing issue: Chrome browser automatically redirects HTTP protocol localhost requests to HTTPS protocol, while Firefox and IE browsers behave normally. This phenomenon typically occurs in web projects without SSL enabled, where Chrome insists on using HTTPS connections even when HTTP start URLs are explicitly set.

From network inspection tools, the request URL shows as data:text/html,chromewebdata, with only provisional headers displayed in request headers, and no preview or response data available. This abnormal behavior significantly impacts development efficiency as developers need to frequently switch between HTTP and HTTPS.

Root Cause: HSTS Mechanism

The fundamental cause of this issue lies in the HTTP Strict Transport Security mechanism. HSTS is a web security policy mechanism that forces browsers to communicate with servers using HTTPS, preventing protocol downgrade attacks and cookie hijacking.

When a domain sends HSTS headers, for example: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload, the browser remembers this policy for the specified max-age duration. For special domains like localhost, if services sending HSTS headers were previously accessed, all subsequent requests will be forcibly upgraded to HTTPS.

Here's a code example simulating HSTS policy implementation:

// Simulating server sending HSTS headers
const http = require('http');

const server = http.createServer((req, res) => {
    // Set HSTS header with 1-year validity
    res.setHeader('Strict-Transport-Security', 'max-age=31536000; includeSubDomains');
    res.writeHead(200, { 'Content-Type': 'text/plain' });
    res.end('Hello World with HSTS');
});

server.listen(3000, () => {
    console.log('Server running with HSTS enabled');
});

Solution 1: Clear HSTS Policies

The most direct solution involves clearing localhost's HSTS policies through Chrome's internal tools. Specific steps include:

1. Type in Chrome address bar: chrome://net-internals/#hsts
2. Enter localhost in the "Query domain" textbox at the bottom of the page to verify if the browser has recorded HSTS policies for this domain
3. If present, use the "Delete domain security policies" function above to remove localhost
4. Revisit HTTP protocol localhost, and the issue should be resolved

It's important to note that Chrome moved this setting to the "Delete domain security policies" section in November 2017 updates, requiring developers to adjust operations based on Chrome versions.

Solution 2: Force Cache Refresh

If the problem persists after clearing HSTS policies, try forcing browser cache refresh:

1. Ensure the address bar uses HTTP protocol
2. Open Developer Tools panel
3. Click and hold the refresh icon, or right-click the refresh icon
4. Select "Empty Cache and Hard Reload" option
5. Repeat the operation several times if necessary to ensure complete clearance

This method thoroughly clears browser cache and forces reloading, resolving HSTS policy residue issues caused by caching.

Special Considerations for Chrome 63+

For users with Chrome 63 and above versions, if local development uses .dev domains, the situation becomes more complex. Starting from Chrome 63, the browser forces all .dev domains to use HTTPS through preloaded HSTS.

This means:

• .dev domains no longer support self-signed SSL certificates
• Valid signed SSL certificates must be used
• Previous solutions may not work

Recommended alternatives include:

• Using .test domains (reserved by IETF for testing purposes)
• Using .localhost domains for local development
• Avoiding top-level domains that may be forced to HTTPS

Preventive Measures and Best Practices

To prevent recurrence of similar issues, developers can adopt the following preventive measures:

1. Use HSTS headers cautiously in development environments, especially in testing scenarios
2. Use different local domains for different development projects
3. Regularly check and clean browser HSTS policies
4. Use dedicated development browsers, avoiding mixing with daily browsing

Here's a tool function example for checking HSTS status:

// Check if domain is in HSTS list
function checkHSTSStatus(domain) {
    // In actual environments, this requires browser extensions or specific APIs
    console.log(`Checking HSTS status for: ${domain}`);
    // Return simulated results
    return {
        domain: domain,
        hasHSTS: true,
        maxAge: 31536000,
        includesSubdomains: true
    };
}

// Usage example
const status = checkHSTSStatus('localhost');
if (status.hasHSTS) {
    console.log(`Warning: ${status.domain} has HSTS enabled`);
}

In-depth Technical Principle Analysis

The core of HSTS mechanism lies in a domain policy database maintained by browsers. When browsers first access websites sending HSTS headers, relevant information is stored locally. During the policy validity period, all HTTP requests to that domain are internally redirected to HTTPS.

For special domains like localhost, Chrome treats them as ordinary domains, thus equally affected by HSTS policies. While this design enhances security, it may cause inconvenience in development environments.

Understanding this mechanism helps developers better manage local development environments and avoid unnecessary redirection issues. Through proper configuration and regular maintenance, smooth development workflows can be ensured.