'

Question

So, this is weird.

We have a 2008 R2 server and Win 7x64 dev workstations running Classic ASP.

One page in the site, at exactly carat position 98301, a </div is being inserted into the source. Notice it's not a fully closing div (</div>) tag. Just </div .

So, all sorts of things are breaking since it moves around, based on other things that modify the page (user permissions, querystring values, etc). But always exactly at position 98301 in the code. And always only on this one page.

I've never seen this before and have no idea where to figure out what's doing it. We have many other pages with hundreds of thousands of characters that are fine. We have shorter pages, too. All the IIS settings are the same for all pages and include a 4Mb response buffer and both static and dynamic compression enabled (which I togged both ways without change). We also have 3 source control branches and this is happening in them all, only on this one page.

We are using 2 Win7x64 dev workstations, 1 Win2008R2 local test server and 1 Win2008R2 prod server, and they all do exactly the same thing.

I've moved around the code some, cut out functions, added new code in there to loop Hello World, and no matter what I do, it always inserts just </div at exactly carat position 98301.

I can't think of anything else to test. All suggestions are welcome! Thank you!

Answer 1

Turns out it was the combination of htmlEncode() and htmlDecode() being on the page, and was only a problem in Chrome (currently v39.x). Firefox and IE worked fine. On our page we had about a 600 line script block, and htmlEncode() and htmlDecode() were close to the top of the block. By moving them to immediately before the </script> tag everything worked and </div was not being injected. While I was not the author of that page, I can see the htmlEncode() and htmlDecode() functions were sourced from here: HTML-encoding lost when attribute read from input field

Additionally, we have both Prototype (1.7.1) and jQuery (1.11.x) loaded, and jQuery loading as var $j = jQuery.noConflict(); before Prototype. Changing return $('<div/>').... to return $j('<div/>').... and even return jQuery('<div/>').... had absolutely no affect on the situation.

I still do not know WHY this was happening, but it has been resolved (for now, anyway) by moving the functions to the bottom of the script tag.