The base config

[z12]

Siamesecat Wrote:Why would you want to do that? To where would you capture the data?

My thought was to capture these values into variables when the request was made, before any header filters kick in.

Siamesecat Wrote:If you had spoofed the user-agent, presumably you know about it, so what would be the point of looking up the original one? Same thing about the referer: if you are faking it, why record the real one somewhere?

You really can't presume too much.
With respect to the "framework", there's really no way to know what filters will be present in a config.

In regards to the user-agent, there's no way to know ahead of time what browser is currently being used.
I suppose you could have a filter that sets a variable that says I'm using browser X.
But if you switch browsers, you'd have to uncheck that filter and enable a different one for browser Y.

If the user-agent is spoofed and there's a web filter that was "browser dependent", examining the user-agent field would be useless.
All the web filter would see would be the spoofed user-agent.

I suppose a header filter that actually spoofed the user-agent could set a variable.
But then your back to setting a variable that could be named anything depending on who wrote the filter.
This would make it harder to share filters.

Pretty much the same logic applies to the Referer header.
Once it's spoofed, you run into the same issues that the user-agent header has.

Also, I can see where other header filters may need referer info before the referer header is processed.
You could end up with several header filters trying to determine if a request is off-site.
To avoid code duplication and redundancy it would be easier to do it just once, right off the bat.

Of course the problem with these variables is that they depend on the browser sending the correct values.
But I don't see a way around that other than document the fact that these headers shouldn't be spoofed by the browser.

z12