The only way around that would be to take advantage of bugs in their parser. HTTP is a moronic spec, and it allows inane things. For instance, these are valid HTTP headers:
X-LineWrap: Hi my name is
Header Boy
The value of X-LineWrap should be "Hi my name is Header Boy". Edit: Actually I'm not sure if the space before the comment counts or not. Terrible text protocol formats FTW.
X-Comment: This is the value (but this is a comment!)
The value of X-Comment should be "This is the value".
X-MoreFun: I don't recall (offhand) how
this header value should
(really, the spec is a mess)
be interpreted.
The value of X-MoreFun should be (I think): "I don't recall how this header value should be interpreted.".
So, you might get lucky if they have a non-compliant parser and the target site has a compliant parser. In that case:
X-UIDH: garbage1
garbage2
Might get turned into:
X-UIDH: verizontrackingvalue
garbage2
In which case, a compliant HTTP parser would read the value as "verizontrackingvalue garbage2", which might be enough to mess up their tracking.
Also, HTTP has special handling of headers that are "comma separated lists". This should only apply to special-cased built-in headers. But you could try sending multiple X-UIDH headers, with commas in the values, to trick an overly ambitious parser. Maybe.
Anyways, this all depends on bugs in HTTP parsers, which probably exist. (Can you tell I despise the HTTP format?) But if exploited enough to matter, they'd simply patch them.
The only way around that would be to take advantage of bugs in their parser. HTTP is a moronic spec, and it allows inane things. For instance, these are valid HTTP headers:
The value of X-LineWrap should be "Hi my name is Header Boy". Edit: Actually I'm not sure if the space before the comment counts or not. Terrible text protocol formats FTW. The value of X-Comment should be "This is the value". The value of X-MoreFun should be (I think): "I don't recall how this header value should be interpreted.".So, you might get lucky if they have a non-compliant parser and the target site has a compliant parser. In that case:
Might get turned into: In which case, a compliant HTTP parser would read the value as "verizontrackingvalue garbage2", which might be enough to mess up their tracking.Also, HTTP has special handling of headers that are "comma separated lists". This should only apply to special-cased built-in headers. But you could try sending multiple X-UIDH headers, with commas in the values, to trick an overly ambitious parser. Maybe.
Anyways, this all depends on bugs in HTTP parsers, which probably exist. (Can you tell I despise the HTTP format?) But if exploited enough to matter, they'd simply patch them.