DEV Community

SGTSanjay
SGTSanjay

Posted on

Apache Request Header Size Limit – RHEL 9 / Magento 2.4.7

#linux #devops #tutorial

When running Magento 2.4.7 on RHEL 9, you may suddenly see users reporting a blank page or a cryptic browser error saying:

"Your browser sent a request that this server could not understand – size of request header field exceeds the limit"

This article explains how to reproduce the issue, investigate it properly on RHEL 9, and apply safe fixes without masking deeper problems.

🔴 Error Symptoms

  • Frontend or Admin page loads as blank page
  • Browser shows 400 / 431 error

  • Happens more frequently after:

    • Enabling Magento Admin 2FA
    • Long-running admin sessions
    • CDN / WAF usage
    • Multiple store views

🔁 Recreate the Issue (Safe Test)

Open your browser console (F12) on your Magento site and paste:

// Source: https://stackoverflow.com/a/52000664
// Posted by Abraham, modified by community
// License: CC BY-SA 4.0
[...Array(5)].forEach((i, idx) => {
    document.cookie = `test_cookie${idx}=${'a'.repeat(4000)}`;
});
Enter fullscreen mode Exit fullscreen mode

Now refresh the page.

✅ If Apache rejects the request, you will see the error immediately.

🔍 Investigation Steps

1️⃣ Check Current Apache Limits 

# Dump active configuration
httpd -t -D DUMP_CONFIG | grep -i limitrequest

# Search configuration files
grep -r "LimitRequest" /etc/httpd/conf* /etc/httpd/conf.d/
Enter fullscreen mode Exit fullscreen mode

ℹ️ If nothing is returned, Apache is using default limits.

2️⃣ Check Logs (RHEL 9 Specific)

On RHEL 9, Apache often logs outside traditional error_log.

# Apache error log
tail -100 /var/log/httpd/error_log | grep -i "limit\|exceed\|431"

# Systemd journal (primary on RHEL 9)
journalctl -u httpd -n 100 --no-pager | grep -i "request\|limit"

# System messages
grep "httpd" /var/log/messages | tail -50
Enter fullscreen mode Exit fullscreen mode

3️⃣ Verify No Proxy / WAF is Involved 

# Reverse proxy check
grep -r "ProxyPass" /etc/httpd/conf.d/

# Listening services
ss -tulpn | grep -E ":80|:443"

# ModSecurity check
httpd -M | grep security
Enter fullscreen mode Exit fullscreen mode

⚠️ If you use ELB / ALB / Cloudflare / Akamai, check their header limits as well.

4️⃣ Test with Curl 

curl -v -H "Cookie: $(python3 -c 'print("x"*20000)')" https://yoursite.com/
Enter fullscreen mode Exit fullscreen mode

If Apache rejects it, you will see 400 / 431 immediately.

🛠 Fix Solutions

✅ Solution 1: Increase Apache Limits (Recommended)

Create a dedicated config file:

vi /etc/httpd/conf.d/increase-limits.conf
Enter fullscreen mode Exit fullscreen mode 
# Increase request header size limits
LimitRequestFieldSize 16384
LimitRequestFields 150
LimitRequestLine 16384
Enter fullscreen mode Exit fullscreen mode

Apply changes:

# Validate config
httpd -t

# Restart Apache
systemctl restart httpd
Enter fullscreen mode Exit fullscreen mode

✔ 16384 (16 KB) is a commonly accepted safe value for Magento.

⚠️ Solution 2: Custom Error Page (Optional UX Improvement) 

ErrorDocument 431 /errors/request-too-large.html
Enter fullscreen mode Exit fullscreen mode

Create the page:

<!DOCTYPE html>
<html>
<head><title>Request Too Large</title></head>
<body>
<h1>Request Too Large</h1>
<p>Your browser sent too much data. Please clear cookies.</p>
<button onclick="document.cookie.split(';').forEach(c =>
  document.cookie=c.split('=')[0]+'=;expires=Thu, 01 Jan 1970 00:00:00 UTC');
  location.reload();">Clear Cookies & Reload</button>
</body>
</html>
Enter fullscreen mode Exit fullscreen mode

🧠 Solution 3: Optimize Magento Cookie Usage

Magento can generate large cookies, especially for Admin users.

Ensure sessions are stored in Redis instead of cookies:

// app/etc/env.php
'session' => [
    'save' => 'redis',
    'redis' => [
        'host' => '127.0.0.1',
        'port' => '6379',
        'database' => '2'
    ]
],
Enter fullscreen mode Exit fullscreen mode

Also consider:

  • Reducing admin session lifetime
  • Clearing stale cookies after upgrades

✅ Verify the Fix 

# Confirm active limits
httpd -t -D DUMP_CONFIG | grep LimitRequest

# Re-test with curl
curl -v -H "Cookie: $(python3 -c 'print("x"*20000)')" https://yoursite.com/
Enter fullscreen mode Exit fullscreen mode

Clear test cookies in browser:

document.cookie.split(';').forEach(c =>
  document.cookie=c.split('=')[0]+'=;expires=Thu, 01 Jan 1970 00:00:00 UTC');
Enter fullscreen mode Exit fullscreen mode

❓ Why Are There Sometimes No Logs?

Apache rejects oversized headers at the protocol parsing stage, before:

  • VirtualHost matching
  • Access logs
  • Standard error_log handlers

👉 On RHEL 9, always check:

journalctl -u httpd
Enter fullscreen mode Exit fullscreen mode

🧩 Final Notes

  • Increasing Apache limits fixes the symptom
  • Reducing cookie size fixes the root cause
  • Always validate CDN / Load Balancer header limits

This problem is extremely common on Magento 2.4.x, especially after enabling Admin 2FA or running long-lived admin sessions.

📊 Where the Request Fails (Diagram) 

Browser
  │
  │  HTTP Request (Cookies, Headers)
  ▼
Apache Protocol Parser
  │  ❌ Rejects request here if header too large
  │     (Before vhost, access_log, PHP, Magento)
  ▼
VirtualHost / PHP-FPM
  ▼
Magento Application
Enter fullscreen mode Exit fullscreen mode

This explains why no access logs are sometimes generated.

📋 Header Size Limits by Layer (Quick Reference)

Layer Default Limit Configurable Notes
Apache ~8 KB ✅ Yes LimitRequestFieldSize
AWS ALB 16 KB ❌ No Hard limit
Nginx 8 KB ✅ Yes large_client_header_buffers
Cloudflare ~32 KB ❌ No Includes all headers
Browser Varies ❌ No Cookie bloat common

🧪 5‑Minute Runbook (TL;DR) 

# 1. Reproduce
curl -H "Cookie: $(python3 -c 'print("x"*20000)')" https://site

# 2. Inspect
journalctl -u httpd | grep -i limit

# 3. Fix
vi /etc/httpd/conf.d/increase-limits.conf

# 4. Validate
httpd -t && systemctl restart httpd
Enter fullscreen mode Exit fullscreen mode

🧾 Production SOP / RCA Template

Incident: Apache Request Header Size Exceeded
Severity: Medium (Frontend/Admin inaccessible)
Affected: Magento 2.4.x on RHEL 9

Timeline

  • T0: Monitoring alert / user report
  • T+5m: Blank page / 431 confirmed
  • T+10m: Reproduced via curl
  • T+15m: Root cause identified (header size)
  • T+20m: Apache limits increased
  • T+25m: Service restored

Root Cause

Excessive request headers caused by accumulated cookies (Admin sessions + 2FA).

Resolution

Increased Apache request header limits to 16 KB and validated via curl.

Preventive Actions

  • Monitor cookie growth
  • Review CDN / LB header limits
  • Periodic admin cookie cleanup

Top comments (0)