HTTP Headers

Introduction

The DeviceHub HTTP Headers tool is a free online request echo that calls GET /api/echo-headers on DeviceHub’s Cloudflare deployment and displays sanitized request headers as the edge received them from your browser, optional Cloudflare cf metadata fields when present, and select response headers from the echo itself, without acting as a general-purpose proxy for arbitrary third-party URLs and without replaying sensitive credentials back to the page. Front-end developers debugging Client Hints and Accept-Language values, CDN engineers comparing cf-ray and colo fields, support staff teaching what a browser actually sends on fetch, and students learning difference between request and response header sections all click Fetch once and read sorted pairs. DeviceHub states limits plainly: HTTP headers via /api/echo-headers with cookies and authorization stripped server-side before echo, do not use this page to verify Cookie or Authorization forwarding because those sensitive names are removed on purpose. Local astro preview without Pages Functions shows API unavailable. Pair with IP Address when tickets also need public egress IP and ASN context. Pair with HTTPS Reachability Check when outbound HTTPS to another hostname is the question rather than inbound echo to DeviceHub. Pair with Connection Information when Network Information API hints add client-side context Chromium exposes. This is not a security scanner and not a header injection attack tool, responsible educational use only. Technical writers documenting CDN integration paste cf-ray beside colo from IP Address in the same runbook. OAuth debugging teams must remember Authorization never echoes, use server-side logging for bearer tokens instead. Internationalization QA compares Accept-Language echoed here against hreflang bugs on unrelated origins by understanding this echo is DeviceHub-specific. Workshop instructors demo stripped Cookie rows side-by-side with Browser Cookie Test so students learn echo sanitization is server-side policy not browser omission. Fetch failures from missing Functions should not be confused with empty header objects, 404 paths show deploy guidance instead. CDN support engineers attach echo screenshots beside IP Address colo when opening Cloudflare tickets so both client fetch headers and egress metadata align in one thread.

What this tool does

Fetch issues GET /api/echo-headers with cache no-store; JSON response includes headers object and optional cf object; UI renders request headers echoed, Cloudflare metadata section when non-empty, and echo response headers such as content-type, cache-control, cf-ray, and server. Sanitization removes cookie and authorization headers before serialization so session secrets do not round-trip to the DOM. It does not echo headers from unrelated websites you visit, only this DeviceHub endpoint. Copy-friendly layout aids tickets. Failures show deploy-to-Cloudflare guidance on 404. Permissions stay none. Header count and cf-ray sync to diagnostic rows. Sec-CH-UA and Sec-Fetch-* headers when sent by Chromium appear in echo, useful for Client Hints migration tickets. User-Agent reduction may show frozen tokens here exactly as other sites see on fetch, pair with Browser User Agent tool for string disputes. Custom headers added by enterprise proxies sometimes appear, note proxy presence when values look nonstandard. DevTools Network panel on unrelated sites shows different header sets than this echo, teach that DeviceHub echo reflects fetch to /api/echo-headers only. gzip and br Accept-Encoding values help CDN cache key disputes when Accept varies by browser.

When to use it

Use HTTP Headers when teaching what browsers send on fetch to DeviceHub, when verifying Accept-Language or User-Agent on the DeviceHub path, when capturing cf-ray for Cloudflare support tickets, and after Client Hints policy changes. Prefer IP Address for public IP alone. Prefer HTTPS Reachability Check for probing external host HTTPS. Avoid expecting Cookie echo, stripped by design. Run on production DeviceHub when local lacks Functions. Run beside DNS Privacy Check when comparing DoH success with inbound header context. Run after deploying new Worker routes to confirm browsers still reach echo-headers without unexpected middleware stripping. Run in classroom demos showing difference between request and response header sections, students often conflate the two on first pass. Run when debugging why DeviceHub IP tool colo disagrees with cf metadata here, both come from Cloudflare context but different endpoints. Run before CDN cutovers to snapshot baseline Accept-Encoding and User-Agent the edge will see post-migration. Capture echo after VPN connect when support disputes whether the tunnel rewrites User-Agent or Accept-Language on fetches to DeviceHub specifically.

How it works

Browser fetch to same-origin /api/echo-headers carries browser-generated request headers; Pages Function reads request, strips cookie and authorization case-insensitively, copies remaining headers into JSON, attaches cf fields from Cloudflare request context when available, returns JSON with appropriate response headers. CORS same-origin avoids preflight complexity for simple GET. No Permissions API. Stripping protects users from accidentally displaying session cookies on screen during demos. cf metadata may include colo, country, or connecting IP fields depending on deployment, parallel honesty to /api/client-ip family. Accept, Accept-Encoding, and Cache-Control on the inbound fetch reflect browser defaults for same-origin GET, not for form POST you might imagine. HTTP/2 and HTTP/3 negotiation details may appear in cf metadata or response server lines depending on Cloudflare version, treat as hints. Echo response cache-control no-store matches fetch options, repeat Fetch always hits origin function rather than browser disk cache for stale header drills.

Step-by-step instructions

1. Deploy DeviceHub to Cloudflare Pages if echo-headers returns unavailable in local preview.
2. Open HTTP Headers and click Fetch to invoke GET /api/echo-headers from your current browser profile.
3. Review echoed request headers separately from Cloudflare metadata and echo response headers.
4. Remember cookies and authorization are stripped, absence is intentional sanitization, not a bug.
5. Copy cf-ray and colo fields into CDN tickets when correlating with IP Address rows from the same session.
6. Do not paste echoed headers into public forums if remaining values include internal tokens you added manually via extensions.
7. Compare User-Agent echoed here with Browser User Agent tool when CDN rules disagree about reduced tokens on the DeviceHub path.

Common problems

Users expect Authorization echo for OAuth debugging, stripped by design. Comparing echo to curl against a different host mislearns scope, this endpoint only reflects DeviceHub fetch. API 404 means missing Functions. Empty cf section on non-Cloudflare dev hosts is expected. Confusing response headers with request headers, UI labels sections to reduce mistakes. Extensions modifying request headers appear in echo, note extension state. Missing Referer on same-origin fetch is normal for privacy-preserving browser defaults, do not treat absence as DeviceHub stripping. Large header sets from experimental Client Hints may wrap in UI, copy full values from ticket exports when needed. Preflight OPTIONS requests are not what this tool performs, only simple GET echo, so CORS preflight debugging needs other tools. IPv6-only clients echo the same sanitized header policy as IPv4, family does not change strip rules for Cookie and Authorization.

Privacy explanation

Echo displays headers your browser sent to DeviceHub minus cookies and authorization. Cloudflare edge processes the request and may log operational metadata per account policy. DeviceHub does not use echo for ad profiling. Permissions none. Do not add secrets to custom headers expecting them back, they are stripped. cf-ray correlates requests in Cloudflare support, handle according to org policy. Closing tab clears displayed headers. Echo never returns Set-Cookie from your session because inbound Cookie was stripped before echo construction, do not confuse response Set-Cookie on echo API with your site's login cookies. Operational teams correlating cf-ray across tools should capture timestamp in tickets because ray IDs age out of support lookups. Compare Sec-Fetch-Site on echo with documentation for same-origin fetch expectations when training junior CDN engineers on header semantics. DeviceHub strips cookie and authorization server-side, never expect those names in echoed JSON even when your browser sent them on the wire before sanitization at the edge function.