ASP page works in IIS6, fails in IIS7 - only last half of page output is sent

I have a search page for one of my web apps that works fine on IIS6 with any amount of search results. In IIS7, when there are a lot of search results (no exact numbers yet), the page that gets returned to the browser is only the last half of the page - the entire <head> section and most of the <body> is missing. If there are fewer search results, the page is sent whole. This makes me think it's a response buffer issue, but the information I'm finding about IIS7 response buffers is that the default setting is something like 4MB, and this page is nowhere near that large. Also, it seems weird that the first half of the page is being truncated, rather than the last half. It would seem that if a buffer was full, you'd get the contents of the buffer up to the point that it was filled, and the rest would be truncated. Maybe that's not how HTTP buffers work? Anyway, any ideas on what this might be, and what I can check? Thanks.
LVL 13
jmundsackAsked:
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

x
 
Paul MacDonaldConnect With a Mentor Director, Information SystemsCommented:
"...the entire <head> section and most of the <body> is missing..."
I notice in your sample you have an opening head tag, but no closing head tag.  Is that a result of your editing too?
0
 
Paul MacDonaldDirector, Information SystemsCommented:
I don't see the problem, as long as they paid for a seat.
0
 
Paul MacDonaldDirector, Information SystemsCommented:
Belay that.  Wrong thread.
0
Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

 
rg20Commented:
Do you get any error messages in the ASP Page? top half
Are you dealing with frames that might show the second half first?

Are you using ajax to display into labels or anything?
What happens if you remove the bottom half, and try to display the top?

Try putting a response.end in the beginning and see where it errors out.

Without code or html source, I can't be much more help, I am also thinking if you upgraded IE to a newer version where errors might get trapped better.
0
 
jmundsackAuthor Commented:
No error messages appear in the response.

There are no frames involved.

This is a pretty simple output-data-from-a-recordset page (code attached) - no frames.

It's not that I can remove the top or bottom - the problem is that the loop that is outputting the response but the response only contains data starting from the middle of the loop.

We're on IE 7 and I am not in control of the browser platform.

<%
' ASP code to copy recordset to array "mData" used below
' Also "PadR" function to right-pad a string
%>

<html>
<head>
<title>Search Inquiry Records</title>
<body>
<% If Not IsEmpty(mData) Then %>
<p class=title><% =mStatus %></p>
<table cellspacing=0 cellpadding=0><tr><td>
<p style="font-family: monospace;">&nbsp;
<% 
	Response.Write PadR("User", 10) & "|"
	Response.Write PadR("Last Name", 17) & "|"
	Response.Write PadR("First Name", 10) & "|"
	Response.Write PadR("SSN", 11) & "|"
	Response.Write PadR("CAN", 9) & "|"
	Response.Write PadR("Case#", 10) & "|"
	Response.Write PadR("Reg#", 6) & "|"
	Response.Write PadR("Date", 10)
%></p>
<select id=lstMatches size=10 style="font-family: monospace;">
<% 

' SOMEWHERE IN THE MIDDLE OF THE FOLLOWING LOOP, 
' PAGE IS TRUNCATED GOING BACKWARDS FROM THE END

For i = LBound(mData, 2) To UBound(mData, 2)
	Response.Write "<option value=""" 
	Response.Write mData(0, i) & "|"
	Response.Write mData(9, i) & "|"
	Response.Write mData(10, i)
	Response.Write """>"
	Response.Write PadR(mData(1, i), 10) & "|"
	Response.Write PadR(mData(2, i), 17) & "|"
	Response.Write PadR(mData(3, i), 10) & "|"
	Response.Write PadR(mData(4, i), 11) & "|"
	Response.Write PadR(mData(5, i), 9) & "|"
	Response.Write PadR(mData(6, i), 10) & "|"
	Response.Write PadR(mData(7, i), 6) & "|"
	Response.Write PadR(FormatDateTime(mData(8, i), 2), 10)
	Response.Write "</option>"
Next 
%>
</select>
</body>
</html>

Open in new window

0
 
rg20Commented:
Are you building a partial table here?

<table cellspacing=0 cellpadding=0><tr><td>

I've seen wierd things happen like this.
0
 
jmundsackAuthor Commented:
Well... You could be onto something about a partial table, but that particular instance was a result of poor code editing before posting.  I was trying to take out all non-essential code and leave just the loop.  The thing that I find troubling is that on our current Windows Server 2003 / IIS6 box, the page is output intact in its entirety.  It's only on the new Windows Server 2008 / IIS7 box that I get the truncated page.  So, I was operating under the assumption that there's some new default setting in IIS7 that would cause something like this.
0
 
rg20Connect With a Mentor Commented:
No I believe that IE 5.5 and 6 were very forgiving for errors like that, but IE7 may enforce it more.

The problem is not with the server, if you were to open the original page with IE 7 on the server 2003 box, would it display properly?
0
 
rg20Commented:
you might want to try turning on script errors in IE options as well as setting the errors in IIS to default where it will tell you everything.
0
 
jmundsackAuthor Commented:
That's just it: I can open the same page, using the same browser, and Windows Server 2003 / IIS6 serves me the whole page, while Windows Server 2008 / IIS7 serves me the last half of the page.

No script errors occur in IE on the partial page.  I've saved the page source for the whole page (served by 2003) and the partial page (served by 2008) and this is what I observed:

2003 page size: 7,626 KB
2008 page size: 3,530 KB

Neither one seems like it should be too large to output.  I have examined, in the whole file, the markup that immediately precedes the start of the broken file, and found nothing unusual about it.

I'm stumped.
0
 
rg20Commented:
Can I make the assumption that the connection to the database is working and you are able to query the data on other pages?

If not we need to look at where the database is located in reference to the server, same server? same path? remote?
0
 
rg20Commented:
Paul,

Thanks for the help and nice catch.  

as a learning experience for me as well.
Would IIS6 serve that up any differently than IIS7?  
0
 
Paul MacDonaldDirector, Information SystemsCommented:
I can't say.  I would hope not, but there are significant differences between IIS 6 & 7 so anything is possible.  It's certainly worth looking into.
0
 
jmundsackAuthor Commented:
Son of a gun!  That was it - there is no .  So - we can theorize that IIS6 would somehow correct this, but IIS7 is less forgiving.  I can't believe it's something this easy.  (Also note, my HTML has improved greatly since this particular page was developed - just had to say that to save face.)

I'm awarding 400 points to paulmacd FTW, but I have to give some points to rg20 because he put in such an effort. Thanks guys!
0
 
rg20Commented:
That is incredible that it loaded "properly" under IIS6

Im floored by that,

Congrats on getting it running
0
 
RobinTheBraveCommented:
Really??  I can't believe anyone involved in this discussion bought "missing </head> tag" as the answer.  It's not hard to verify that the head tag had nothing to do with it.

A) To start with, the Author claimed the head tag got dropped accidentally while he was trying to narrow down the problem.  If that's the case, pretty hard for it to be the root cause.

B) The page loaded fine with less data under IIS7.  Viewing the source in the browser at this point would have revealed that the missing tag was still missing, and demonstrated that the browser was able to get by just fine without it.

C) The page loaded fine with large amounts of data under IIS6.  Viewing source in the browser here would have again shown that the tag was still missing and the browser still didn't care.

D) Finally, the notion of a web server that validates (and corrects or rejects) your dynamically created HTML on the fly is just crazy science fiction.  The server doesn't care.  It just pushes it out.  It's up to the browser to figure out whether or not it makes sense and what to do with it.  In this case, it was clearly not a browser issue because the HTML NEVER REACHED THE BROWSER.  

The Author actually answered his own question in a follow-up comment without realizing it.  THE REAL PROBLEM is the ASP "Response Buffering Limit" in IIS7.  The Author correctly points out that the default value is around 4MB.  He then mentions that the full page he is trying to load is around 7.6MB.  I'm guessing at some point he increased the buffer limit while poking around, and just didn't make the connection.

I had this exact same problem when moving from IIS6 to IIS7.  When requesting a large-ish dataset (4.15MB of resulting HTML), IIS7 would only give me the last portion of the HTML.  Increasing the "Response Buffering Limit" very repeatably solves the problem.  Decreasing the limit very repeatably makes it appear again.  The note in IIS Manager makes it sound like this limit is the amount the response buffer will cache before it starts flushing data out to the client.  In practice, it behaves more like a circular queue.  You can write to it all you want, but IIS is only sending out the last n bytes, where "n" is the value of the Response Buffering Limit.

Hope this helps someone.
0
All Courses

From novice to tech pro — start learning today.