Routing glossary
What Referrer Filtering Can Tell a Router
Referrer filtering evaluates the referring-page information supplied with a request and applies policy to its presence or value.
Referrer data comes from the client path
Browsers may send a Referer request header containing all or part of the previous page URL. The spelling of that header is historically fixed, while application code often uses the correctly spelled word referrer for the concept.
Valid journeys may omit or shorten it
Privacy settings, referrer policy, application handoffs, redirects, HTTPS boundaries, and direct navigation can remove detail or suppress the header. A missing value therefore does not automatically mean that a campaign visit is fabricated.
The value is supporting evidence
Non-browser clients can forge headers, and an allowed hostname does not prove that the user clicked a particular advertisement. Stable campaign parameters and tracker context can complement referrer data when source attribution matters.
Model exact, absent, and unexpected cases
Normalize hostnames carefully, distinguish subdomains, and decide whether path-level matching is actually necessary. Define separate outcomes for a recognized source, no referrer, and a contradictory value instead of treating every mismatch alike.
Replay the real source journey
Test in-app, external-browser, redirected, copied-link, and direct paths for each important source. Inspect the request context and decision record after every hop so the rule reflects observable behavior rather than an assumed header.