追蹤之戰：為什麼一位開發者禁止使用查詢字串
追蹤之戰：為什麼一位開發者禁止使用查詢字串
在數位監控無孔不入的時代，URL 已不僅僅是一個地址，它已成為追蹤的載體。從 utm_source 到 fbclid，許多平台會自動在傳出的連結中附加長串的追蹤參數，且通常未經目標網站或使用者的同意。
最近，開發者 Chris Morgan 透過在其個人網站上全面禁止未經授權的查詢字串，引發了一場技術與哲學上的辯論。透過將伺服器配置為拒絕任何包含他未明確定義之查詢字串的請求，Morgan 正對「URL 竄改 (URL munging)」採取強硬立場。此舉引發了關於誰擁有 URL 的根本問題，以及伺服器自主權與網路互操作性之間的界限在哪裡。
反對濫用查詢字串的理由
Morgan 的主要動機是拒絕未經請求的追蹤。當第三方網站將 ?ref=example.com 或複雜的 UTM 參數附加到指向他網站的連結時，他們本質上是在利用他自己的基礎設施來促進他們的追蹤工作。
正如 Morgan 所言：
"I don’t like people adding tracking stuff to URLs. Still less do I like people adding tracking stuff to my URLs... UTM parameters are for me to use, not you."
對於許多人來說，這是一個「超文本禮儀」的問題。附加追蹤 ID 的做法會產生「怪獸級 URL」——長達數千個字元的 URL，使其難以分享、閱讀或信任。使用者往往發現自己必須在聊天或論壇分享連結之前，手動清除這些參數，以避免傳遞追蹤權杖 (tokens)。
技術實作與 414 回應
在技術層面上，Morgan 透過他的 Caddyfile（Caddy web server 的配置檔）實作了此項禁令。有趣的是，他選擇以 414 URI Too Long 錯誤來回應這些請求。雖然對於非預期的參數，使用 404 Not Found 或 400 Bad Request 可能在語義上更準確，但 Morgan 承認選擇 414 部分是為了幽默感。
此實作突顯了一個關鍵技術點：伺服器對於如何處理傳入的請求擁有絕對控制權。如果伺服器被配置為忽略查詢字串，它通常只是將其捨棄。然而，透過主動拒絕它們，網站所有者將一種被動的漠不關心轉化為一種積極的抗議。
大辯論：強健性 vs. 嚴格性
禁止查詢字串的決定引發了開發者社群的兩極分化，核心圍繞著兩種主要的思維模式：
支持寬容度的觀點
有些人認為，網路的成功建立在「放任主義」的方法之上。在這種觀點下，URL 是「無需許可的超語言」，且連結到某個網站的人應該有權限根據自己的需求來構建 URL。
批評禁令的人認為，以錯誤頁面來懲罰使用者是適得其反的。如果使用者點擊了一個由企業平台附加了追蹤參數的連結，受苦的是點擊連結的使用者，而非添加追蹤碼的公司。一位評論者建議，與其顯示錯誤，網站可以顯示警告，或者實作一個工作量證明 (Proof-of-Work, PoW) 阻礙機制，以在允許人類使用者存取內容的同時，阻礙機器人。
支持伺服器主權的觀點
相反地，其他開發者認為，操縱 URL 而未經伺服器所有者同意是一種對協定的違反。從這個角度來看，查詢字串是 URL 的一部分，與路徑 (path) 一樣重要；在路徑中添加隨機參數會被認為是「未定義行為」，因此在查詢字串中添加參數也應被同等看待。
實務上的影響與替代方案
對於那些覺得追蹤 URL 的「怪獸級」狀態令人沮喪，但尚未準備好實施強硬禁令的開發者來說，有折衷方案：
- Referrer Policy: 使用嚴格的
Referrer-Policy（例如strict-origin-when-cross-origin）允許網站所有者在尊重使用者隱私設定的同時，於主機層級查看流量來源，而無需使用查詢字串。 - Client-Side Stripping: 一些使用者使用書籤腳本 (bookmarklets) 來清除查詢參數。其中一個建議的程式碼片段是：
(()=>navigator.clipboard.writeText(location.origin+location.pathname))(); - Selective Validation: 與其採取全面禁令，一些開發者會驗證特定的已知參數，並僅在提供無效或惡意值時發出
40x錯誤。
結論
無論是被視為對隱私的勇敢捍衛，還是被視為一種「愚蠢的古板」，禁止查詢字串的做法都提醒了人們，在開放、鬆散耦合的網路特性與個人對其數位空間的主權渴望之間存在的緊張關係。隨著追蹤變得越來越激進，想要「竄改」URL 的人與想要保持其乾淨的人之間的衝突很可能會加劇。