If you aren't tech minded, or into problem solving madness, just skip this entry.
RECAP:
* [CLIENT] wanted something pretty simple: link to a particular blog in a new blogging site.
Complication: new blogging site sets a particular set of three domain-wide cookies that render our site utterly unusable.
Maddening factors at play:
* The cookies are inherited from the top-level domain, and there are several places where they might be obtained.
* We don't use any of the problem cookies within our site. It doesn't care whether they even exist. However, just having them in the collection of cookies rendered the entire set of cookies inaccessible, and threw server errors.
* Problem occurred no matter how we got to blog site -- even building a custom RSS reader caused browser to acquire the problem cookies.
* Problem only affects our site; myriad other technologies and code bases are in play elsewhere in Client's world.
* Because of how cookies work, the only place I can test is on client's servers.
So we knew precisely what cookies were the problem, but once they had been set, ANY interaction with the cookie collection caused an unrecoverable error. So we couldn't override the cookies, either.
Glimmer of hope:
* If we set local cookies with the same name BEFORE visiting the blog site, ASP saw those rather than the universal ones we didn't care about. So long as the visitor hit us first, there was no problem.
* Blog site confirmed that deleting those cookies would not harm interaction with their site at all -- they'd just be rewritten if needed.
So the problem became this: how can we kill a cookie that we can't see?
News from On High:
Blog site discovered that the cookies are written in a newer encoding standard, and classic ASP simply does not understand them at all. They confirmed with Microsoft that it was a known bug and that Microsoft had no plans AT ALL to fix it, as Classic ASP is effectively abandoned.
Well that's all well and good -- we've seen it coming for some time -- but we have a massive and complicated site that will take time to rebuild in .NET. Recoding for this is NOT an option.
The answer was this:
1. Before anything else is processed on the page, write local versions of those three cookies.
2. Surround the cookie-writing block with error handling; on error, bounce over to a cookie-killing ASP.NET page, and pass in the originally requested page with all the relevant info.
3. Cookie killer page overwrites the bad cookies, and sends back a page that immediately redirects the visitor to the originally requested page.
There was an issue in timing of writing the cookies and redirecting (I ended up using a meta refresh to handle that part, and writing the destination page with a message on the actual response page, so that if meta-refresh didn't work you could click the link), thanks to some finicky stuff about when cookies versus other information gets sent back to the browser.
It took hours of me tweaking the code, and probably 60 trips back and forth to the dedicated VPN box from my dev machine (about 90 feet each way), but eventually we got it loaded up and tested out.
In the end, it worked! So now visitors either get inoculated (with local cookies), or they hit a page that fixes the problem.
Caveat: Making it possible to click a link to a website and return later ....took 10 people two months and a LOT of hours to find out it was broken functionality on Microsoft's part, and then about 1 day to build an effective work-around.