[wmil]

> Allowing ANY headers from the user except a whitelisted subset also seems like an accident waiting to happen.

I'm going to disagree on this. Browsers and ISPs have a long history of adding random headers, a website can't possibly function while throwing an error for any unknown header. That's just the way HTTP works.

This is clearly a case of the Next devs being silly. At a minimum they should have gone with something like `-vercel-` as the prefix instead of the standard `x-` so that firewalls could easily filter out the requests with a wildcard.

[masklinn]

Even if they had to make things go through headers (a bad idea in and of itself, in-band signalling always causes issues), the smart move would have been to make it a non-string, such that clients would not be able to pass in a valid value.

[ratorx]

Well, there’s 2 possibilities:

1) Plain HTTP, go wild with headers. No system should have any authenticated services on this.

2) HTTP with integrity provided by a transport layer (so HTTPS, but also HTTP over Wireguard etc for example). All headers are untrusted input, accept only a whitelisted subset.

With this framing, I don’t think it’s an unreasonable for a given service to make the determination of which behaviour to allow.

I guess browser headers are still a problem. But you can get most of the way by dropping them at the request boundary before forwarding the request.