views:

1325

answers:

11

I have an ASP.NET site that was working fine running on Windows Server 2003 / IIS6.

I moved it to Windows Server 2008 / IIS7 and the aspx page output now includes gibberish text.

For example:

p����

�����

The majority of the page renders properly, but there is gibberish here and there. I have checked the event logs and there is nothing.

Any idea what's going on here? How can I fix this?

I have noticed that this issue shows up when I include multiple Server.Execute statements in the aspx code:

<% Server.Execute("/inc/top.inc"); %>

<% Server.Execute("/inc/footer.inc"); %>


The .inc files above contain just html. It appears that the files have to be of a significant length to cause the error. Here is the sample html I've been testing with:

<div class="logo">
  <a href="/">
    <img src="/logo.png" alt="logo" width="31" height="29" class="logoimg" />
  </a>
</div>
<div class="logo">
  <a href="/">
    <img src="/logo.png" alt="logo" width="31" height="29" class="logoimg" />
  </a>
</div>
<div class="logo">
  <a href="/">
    <img src="/logo.png" alt="logo" width="31" height="29" class="logoimg" />
  </a>
</div>
<div class="logo">
  <a href="/">
    <img src="/logo.png" alt="logo" width="31" height="29" class="logoimg" />
  </a>
</div>
<div class="logo">
  <a href="/">
    <img src="/logo.png" alt="logo" width="31" height="29" class="logoimg" />
  </a>
</div>
<div class="logo">
  <a href="/">
    <img src="/logo.png" alt="logo" width="31" height="29" class="logoimg" />
  </a>
</div>


Also, the gibberish characters appear inconsistently. If I ctrl+F5 the pages, the gibberish characters change and occasionally don't appear at all.

A: 

Try setting charset parameter.

<% Page ContentType="text/html; charset=utf-8"%>
TheVillageIdiot
This did not fix the issue.
frankadelic
A: 

This is a bit of a stab, but try setting your pipeline mode to "classic" in IIS.

smercer
the code is already running in "classic" pipeline mode.
frankadelic
A: 

You are probably sending a different encoding than the encoding of the .inc files.

Check the encodings of your .aspx and .inc files, and check the charset parameter of the content-type header being sent to the browser.

EDIT: Since the server is sending UTF-8, you should convert your .inc files to UTF-8.

To do that, open the file in Visual Studio, click File, Advanced Save Options, and select Unicode (UTF-8 without signature) - Codepage 65001. (Near the bottom of the list)

SLaks
I opened both the ASPX files and the INC files in Notepad++. For both of these, they were listed as ANSI.
frankadelic
What is the content-type being sent to the browser? (Check in Fiddler, http://www.fiddler2.com)
SLaks
Content-Type: text/html; charset=utf-8
frankadelic
Convert the .inc files to UTF8, no BOM. (You can do this in Notepad++ or Visual Studio)
SLaks
.inc files were already saved as (UTF-8 without signature) - Codepage 65001. I re-saved the aspx file to match this. It did not fix the problem.I also changed aspx file and inc file as UTF8 without BOM (using notepad++). This did not fix the issue either.
frankadelic
Look at the response bytes in Fiddler
SLaks
The first response bytes are 00 00 00 00 00 00 00 00.
frankadelic
+1  A: 

Hi Frank - http://forums.asp.net/p/329153/330330.aspx contains a discussion of a similar issue, I wonder if it's the same problem you're seeing. Here's an excerpt from rox.scott's answer:

if you are transfering execution of the page after Response.Type, etc., is set then the resulting Response will have the Response.Type and encoding set by the initial page -- which might not be compatible with characters on the second page. solution: make sure you are correctly specifying Response type and encoding on BOTH pages.

Want to try this and see if it works?

If that doesn't work, http://msdn.microsoft.com/en-us/library/39d1w2xf.aspx has an interesting discussion of various configuration options you can try to force consistent encodings throughout your site. You may want to try some of those. Also, that MSDN article does not use the ContentType directive but instead recommends this:

<%@ Page RequestEncoding="utf-8" ResponseEncoding="utf-8" %>

Not sure if that will generate equivalent results as adjusting ContentType, but it's easy enough to try.

Justin Grant
Thanks, but this does not help. Note the forum posting was from 2003. My issue is specific to Windows Server 2008.
frankadelic
hmmm. let me check assumptions about the problem. Are all of below accurate?1) problem occurs only in HTML from Server.Execute (not in the main page's content)2) include files contain non-ASCII chars that are replaced by gibberish chars in HTML3) problem is not intermittent-- it always happens for a given URL4) setting ResponseEncoding of both main page and INC files to UTF8 doesn't fix the problemAlso, can you narrow the problem to a simple repro case (e.g. one page with 2 Server.Execute's of INC files with one line of text each). If so, could you post the code?
Justin Grant
1) The issue occurs throughout the rendered page. The first 4 chars of the DOCTYPE declaration are missing.2) Include files contain standard ASCII characters. The gibberish is placed in variable locations when I refresh the page.3) Occasionally the problem goes away. I refresh the page and perhaps every 5 refreshes, the page looks ok.4) I have tried saving both files as UTF-8. It does not help.... I posted the .inc contents above. Note the .inc has to be of sufficient length for the problem to occur. A one-line .inc file does not produce the error.
frankadelic
Also, Page does not have an attribute RequestEncoding. ResponseEncoding didn't help.
frankadelic
Hmmm. Given ASCII-only text in both INC and parent page, it doesn't sound like a an encoding issue after all. Since the symptom is mangling of HTML in between your rendering and the browser, I'd be suspicious of any code running after yours in the IIS pipeline. Can you try turning off any ISAPI filters and HTTPModules to see if the problem still reproes? Especially any custom/3rd-party filters or modules, as well as HTTP Compression and Output Caching.
Justin Grant
Justin Grant
Finally, could you include a hex dump of what the bogus chars look like? For example, what are the bytes corresponding to p����? If the hex is familiar (e.g. the unicode Byte Order Mark, see http://codeclimber.net.nz/archive/2007/09/07/Beware-the-Unicode-Byte-Order-Mark-when-merging-files.aspx) then that may point closer to the culprit.
Justin Grant
The first characters are NULL. If I look at it in hex view in Fiddler, it looks like "........CTYPE html PUBLIC" etc... The beginning of the DOCTYPE declaration is overwritten with nulls.Other gibberish interspersed in the page includes (hex): "EF BB BF".Please note the results aren't consistent. I have to refresh the page multiple times to get the effect.
frankadelic
Replacing Server.Execute with ReadAllText fixes the problem. The issue appears to be specific to Server.Execute.
frankadelic
I have an answer to at least one of these problems. Server.Execute has a bug (which I was just able to repro) which causes UTF-8 files with a Byte Order Mark (aka BOM, see http://www.w3.org/International/questions/qa-utf8-bom) to emit that BOM into the response stream. Some browsers may show a BOM as gibberish characters. Here's a solution: open the INC files in Notepad, choose Save As, and choose "ANSI" from the encoding dropdown box. This will give you the same file, but with the BOM stripped out. The gibberish in the middle of the page should go away.
Justin Grant
As for the nulls at the start of the file, that has me stumped. Does it still happen after you remove the BOM issue with your INC files? BTW, one workaround may be to insert a bunch of spaces before your doctype.
Justin Grant
Hi Frank - any luck solving this problem?
Justin Grant
Was never able to solve this... we just avoided Server.Execute() because it seems to be buggy.
frankadelic
A: 

Also you can check globalization element in web.config
It must be in system.web section:

<globalization
    requestEncoding="utf-8"
    responseEncoding="utf-8"
    fileEncoding="utf-8"
    responseHeaderEncoding="utf-8" 
/>
x2
this did not fix the issue
frankadelic
+1  A: 

Pop in to Firefox and try manually switching the page encoding (maybe to Windows-1252 first), see if the gibberish clears up. If it's suddenly readable, then at least you will know it's an encoding problem.

I'd also suggest looking at the output in a hex editor to see what you're actually getting. That could also give you a clue where to look. Might also try turning off gzip encoding or page compression.

Seth
Yep, also check the defined encoding type declared in the page - if you're declaring XHTML it's possible that IIS 7 now correctly returns this as an XML type rather than text/HTML (I've not checked), in which case more notice is taken of the page encoding.
Zhaph - Ben Duguid
+1  A: 

this has nothing to do with encoding. This is IIS not knowing how to handle error messages if you are using it in combination with a virtual directory. My guess is that if you run this site in local debug on a machine, the error messages show up fine. Try that, if so, then you can start to infer where the actual error is.

Jason M
A: 

In the Windows Event Viewer you most probably will be able to find the real cause of the error. That way you can fix it.

Unfortunately you require RPD / physical access to the server, and it's only solving the error. Not the cause of the error not appearing.

Gabriël
A: 

did you ever get this resolved, i am having a similar issue

Ross
A: 

Did you ever get this solved please? I have the same problem and I'm searching for hours now.

Jürgen
A: 

I have the same problem with classic asp application migrated from iis 6 to iis 7. In some parts of the page that are returned from an SQL server some greek characters appears as ??

Alec