嘿，这个思路完全可行啊！我之前在项目里也试过类似的玩法——用自定义HTTP Header替代URL查询参数来做路由重写，虽然公开资料不多，但实操起来没什么障碍。咱们就用你说的example.org来拆解具体怎么实现吧！

正常情况下，我们会用URL查询参数传递信息，比如 example.org/api?user=123&action=edit。现在换成自定义Header的话，就是把参数放到类似 X-Rewrite-Params: user=123&action=edit 的请求头里，然后让服务器端读取这个Header，解析参数后内部重写路由或者直接用参数处理业务逻辑。

Nginx 反向代理场景（最常用） #

如果你的项目用Nginx做前端代理，直接在配置里加规则就能实现：

server {
    listen 80;
    server_name example.org;

    location /api {
        # 读取自定义Header的值
        set $rewrite_params $http_x_rewrite_params;
        
        # 如果Header存在，内部重写URL（浏览器地址栏不会变化）
        if ($rewrite_params) {
            rewrite ^/api$ /api?$rewrite_params last;
        }
        
        # 转发到后端服务
        proxy_pass http://your-backend-service;
        proxy_set_header Host $host;
    }
}

简单解释下：当请求example.org/api且带有X-Rewrite-Params Header时，Nginx会悄悄把URL重写成带查询参数的版本，再转发给后端——后端完全不用改代码，还是像处理普通查询参数一样处理就行。

Apache 代理场景 #

如果用Apache，需要启用mod_rewrite和mod_proxy模块，配置如下：

<VirtualHost *:80>
    ServerName example.org

    RewriteEngine On
    # 检查自定义Header是否存在且不为空
    RewriteCond %{HTTP:X-Rewrite-Params} !^$
    # 把Header内容拼到查询参数里，然后代理到后端
    RewriteRule ^/api$ /api?%{HTTP:X-Rewrite-Params} [L,P]

    ProxyPass /api http://your-backend-service/api
    ProxyPassReverse /api http://your-backend-service/api
</VirtualHost>

自定义后端服务（以Node.js/Express为例） #

如果是你自己写后端服务，不用依赖代理，直接读取Header解析就行，灵活性更高：

const express = require('express');
const app = express();

app.get('/api', (req, res) => {
    // 读取自定义Header（注意Node.js里Header名会被转成小写）
    const rewriteParams = req.headers['x-rewrite-params'];
    
    if (rewriteParams) {
        // 用URLSearchParams解析参数，和处理req.query逻辑一致
        const params = new URLSearchParams(rewriteParams);
        const userId = params.get('user');
        const actionType = params.get('action');
        
        // 这里直接用参数处理业务逻辑
        res.send(`处理用户 ${userId} 的 ${actionType} 请求`);
    } else {
        res.send('未提供重写参数');
    }
});

app.listen(3000, () => {
    console.log('服务运行在3000端口');
});

• Header命名规范：建议用X-前缀（比如X-Rewrite-Params），虽然现在RFC不强制，但兼容性更好，避免和标准HTTP Header冲突。
• 参数编码：和查询参数一样，Header里的参数要做URL编码（比如空格用%20，特殊字符转义），否则解析会出错。
• 安全校验：别放松安全！Header里的参数和查询参数一样可能被篡改，必须做合法性校验，防止注入攻击。
• 兼容性测试：有些客户端或者中间代理可能会过滤自定义Header，如果是公开API要提前测试；内部服务调用的话基本没问题。

内容的提问来源于stack exchange，提问作者nnx0r