Improve company productivity with a Business Account.Sign Up

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1398
  • Last Modified:

IE 10 not displaying my html

There are strange characters being inserted into the response html sent back to the client in my JSP pages. I cannot determine what is causing it. Here is a sample using this web site - http://www.rexswain.com/httpview.html
2000(CR)(LF)
<!DOCTYPE·html·PUBLIC·"-//W3C//DTD·HTML·4.01//EN"·"http://www.w3.org/TR/html4/strict.dtd">(LF)
(LF)
<html>(LF)
<head>(LF)

Open in new window

The 2000(CR)(LF) is getting inserted in there somehow. The inserted content varies from page to page.

It is causing IE10 to display a blank page.

Using Tomcat 6.0.29, Java 1.7, JSP 2.1, JSTL 1.2.

You can see it for yourself using this URL:
http://test1.calcxml.com/calculators/home-affordability?skn=504 

If you paste the above URL into http://www.rexswain.com/httpview.html, you will see this:

5a6(CR)(LF)
<!DOCTYPE·html·PUBLIC·"-//W3C//DTD·HTML·4.01//EN"·"http://www.w3.org/TR/html4/strict.dtd">(CR)(LF)
<html>(CR)(LF)

Open in new window

All other browsers seem to strip out the characters before the doctype declaration, but not IE10.

Anybody have any ideas on how to prevent this from being inserted in there?
0
brian-barnett
Asked:
brian-barnett
  • 17
  • 13
  • 12
  • +2
3 Solutions
 
Dave BaldwinFixer of ProblemsCommented:
In that viewer, (CR)(LF) is the 'carriage return / linefeed' that you would find in any text or HTML file for normal formatting.  It/they are ignored in web pages but they are included in the viewer for you information.  They are not showing up in the "View Source" for your page in Firefox or IE8.

When I put one of my own web pages in that viewer, I don't see anything before the DOCTYPE.
0
 
brian-barnettAuthor Commented:
Right, the (CR)(LF) do not show up in "View Source", nor does the number/hex code preceding the (CR)(LF). But why is "5a6(CR)(LF)" inserted before my DOCTYPE declaration? Hoping that someone has experienced this before with JSP, Tomcat, etc., and has figured out what causes this to be inserted. My JSP page begins with the DOCTYPTE declaration, so I don't know where it is coming from.
0
 
SStoryCommented:
I'm wondering if you might have some Apache prepend setting like this:

http://stackoverflow.com/questions/5038692/how-to-tell-apache-to-prepend-to-each-html-page-login-php
0
The 14th Annual Expert Award Winners

The results are in! Meet the top members of our 2017 Expert Awards. Congratulations to all who qualified!

 
brian-barnettAuthor Commented:
Apache is not part of it. This is a Tomcat-only web app.
0
 
Dave BaldwinFixer of ProblemsCommented:
Try creating the simplest possible JSP page and start from there.  I tried a few other JSP pages I found in that viewer and none of them had the problem.  Maybe Tomcat is putting it in there in your installation.
0
 
brian-barnettAuthor Commented:
I created a very simple JSP page. I am using Struts and Struts Tiles.

Template JSP page
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<%@ taglib prefix="tiles" uri="http://struts.apache.org/tags-tiles-el"%>
<%@ page contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<html>
<head>
	<meta http-equiv="Content-type" content="text/html;charset=UTF-8">
	<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate" />
	<meta http-equiv="Pragma" content="no-cache" />
	<meta http-equiv="Expires" content="0" />
</head>
<body>
	<tiles:insert attribute="primaryPanel" ignore="true" />
</body>
</html>

Open in new window

JSP page which is the primaryPanel for the tiles:insert above
<div id="formcontent">
<p>Hello World!</p>
</div>

Open in new window

If you run this through http://www.rexswain.com/httpview.html using this link - http://test1.calcxml.com/do/mytest, you will see three separate pieces of data that have "magically" been inserted into the response html, bolded below:

179(CR)(LF)
<!DOCTYPE·html·PUBLIC·"-//W3C//DTD·HTML·4.01//EN"·"http://www.w3.org/TR/html4/strict.dtd">(CR)(LF)

47(CR)(LF)
<div·id="formcontent">(CR)(LF)

</html>(CR)(LF)
(CR)(LF)
0(CR)(LF)
(CR)(LF)
0
 
CEHJCommented:
you will see three separate pieces of data that have "magically" been inserted into the response html, bolded below:
The viewer is telling you that the page contains CRLF pairs
0
 
Dave BaldwinFixer of ProblemsCommented:
By saving it from IE8, I was able to see that your page includes a BOM - Byte Order Mark - which Firefox understands but I don't know if IE does.  http://en.wikipedia.org/wiki/Byte_order_mark  Also, W3C says it's not needed for UTF-8.  http://www.w3.org/International/questions/qa-byte-order-mark.en.php

See if you can eliminate that and see if the other problems still exist.  An easy test would be to change 'UTF-8' to 'ISO-8859-1' in that page above.
0
 
brian-barnettAuthor Commented:
Changed to ISO-8859-1, but still getting the inserted characters. You can see it with the change to ISO-8859-1 at same link - http://test1.calcxml.com/do/mytest
0
 
CEHJCommented:
The encoding doesn't have anything to do with it. You'll find the CRLF pair have the same encoding in nearly all charsets. I'm not sure why you're worried about it - it won't show in any normal user agent
0
 
brian-barnettAuthor Commented:
I'm not sure why you're worried about it

1.

IE10 will not render the page

2.

Curious why Struts, Tiles, or Tomcat is injecting the BOM, or whatever they are, into my html prior to returning to client.

3.

w3c's validator doesn't validate it
0
 
CEHJCommented:
http://test1.calcxml.com/calculators/home-affordability?skn=504 doesn't have a BOM ...

"This document was successfully checked as HTML 4.01 Strict!
Result:       Passed "
0
 
Dave BaldwinFixer of ProblemsCommented:
With the ISO-8859-1 code, there is no BOM showing in IE or Firefox.  I don't know why the viewer is showing something.

The only reason your current test page (with ISO-8859-1) does not validate is because HTML 4.01 doesn't use the 'self-closing' tags with '/>' at the end, just '>'.

Does IE10 render the current test page?
0
 
brian-barnettAuthor Commented:
0
 
Dave BaldwinFixer of ProblemsCommented:
Interesting... on the viewer page, if I select HTTP/1.0, the extra data does not show.
0
 
Dave BaldwinFixer of ProblemsCommented:
If I paste http://test1.calcxml.com/calculators/home-affordability?skn=502 into the Direct Upload version of the W3C validator, it does validate.  The error you get from a link that says there was no content indicates that the validator and your server do not agree on how to communicate.
0
 
CEHJCommented:
The problem with that is in the area of validity - nothing to do with boms and the like
0
 
brian-barnettAuthor Commented:
I modified the test page so the meta tags did not self-close and also changed it back to UTF-8. I ran it through w3c validator successfully and then tested it on IE10. It rendered on IE10.

The viewer still shows inserted content though??
0
 
CEHJCommented:
inserted content
What kind of 'inserted content'?
0
 
brian-barnettAuthor Commented:
Why would HTTP/1.0 not cause the extra characters to get inserted??
0
 
Dave BaldwinFixer of ProblemsCommented:
Not if you select HTTP/1.0 instead of HTTP/1.1.  I suspect that you are seeing some code that a browser will ignore or at the least not show to you.  Since it is working in IE10 for you, you now have something to compare against.
0
 
brian-barnettAuthor Commented:
What kind of 'inserted content'?

Go here http://www.rexswain.com/httpview.html and use this link - http://test1.calcxml.com/do/mytest. Also choose HTTP/1.1

Here is the content as reported by the viewer:

Content (Length = 479):

186(CR)(LF) <-- Why is this line here? I did not put it there.
<!DOCTYPE·html·PUBLIC·"-//W3C//DTD·HTML·4.01//EN"·"http://www.w3.org/TR/html4/strict.dtd">(CR)(LF)
(CR)(LF)
(CR)(LF)
<html>(CR)(LF)
<head>(CR)(LF)
(HT)<meta·http-equiv="Content-type"·content="text/html;·charset=UTF-8">(CR)(LF)
(HT)<meta·http-equiv="Cache-Control"·content="no-cache,·no-store,·must-revalidate">(CR)(LF)
(HT)<meta·http-equiv="Pragma"·content="no-cache">(CR)(LF)
(HT)<meta·http-equiv="Expires"·content="0">(CR)(LF)
(HT)<title></title>(CR)(LF)
</head>(CR)(LF)
<body>(CR)(LF)
(HT)(CR)(LF)
47(CR)(LF) <-- Why is this line here? I did not put it there.
<div·id="formcontent">(CR)(LF)
<p>Hello·World!</p>(CR)(LF)
</div>(CR)(LF)
</body>(CR)(LF)
</html>(CR)(LF)
(CR)(LF)  <-- Why is this line here? I did not put it there.
0(CR)(LF)  <-- Why is this line here? I did not put it there.
(CR)(LF)  <-- Why is this line here? I did not put it there.
0
 
Dave BaldwinFixer of ProblemsCommented:
I'm not sure why but I think you are seeing the 'chunk' encoding.  http://en.wikipedia.org/wiki/Chunked_transfer_encoding  Yes, that's what it is.  The only other page I could find quickly that used it is Amazon.com and it shows those extra numbers also.  And the reason it doesn't show with HTTP/1.0 is because it's only available with HTTP/1.1.

I guess it's obvious that what you do is often not the only thing being delivered with your web pages.  The viewer page also shows the headers for request and response that are generated.  Those exist for every request but they are not something that you write.  They are from the interaction of the browser and the server.
0
 
CEHJCommented:
<-- Why is this line here? I did not put it there.
As we've said several times - that's *not* content, it's just line separators, non-printing characters
0
 
brian-barnettAuthor Commented:
If those line separators/non-printing characters are "normal" or "okay", then not sure why w3c validator does not validate http://test1.calcxml.com/calculators/home-affordability?skn=502.

Also not sure why IE10 does not render this same page (except if you select "compatibility mode").

Problem is that we have clients complaining that our pages will not render for them and they are running IE10. Maybe I was chasing the wrong thing, but I thought it was the "extra content" I had mentioned.
0
 
brian-barnettAuthor Commented:
As we've said several times - that's *not* content, it's just line separators, non-printing characters

I realize the (CR)(LF) piece is line separators/non-printing, but what about the numbers which precede them?
0
 
CEHJCommented:
I realize the (CR)(LF) piece is line separators/non-printing, but what about the numbers which precede them?
Offset of their appearance?
0
 
CEHJCommented:
then not sure why w3c validator does not validate http://test1.calcxml.com/calculators/home-affordability?skn=502.
It does - IF you either upload the html or input it directly. Not sure why it doesn't perform when pointed at the url. As Dave said, the server might not like it for some reason
0
 
brian-barnettAuthor Commented:
My guess was IE10 failed to render for the same reason the w3c validator failed. Unfortunately, I don't have to ability to "either upload the html or input it directly" for our IE10 users.

It seems that every page which succeeds in the w3c validator succeeds to render in IE10.

Fails in both (with no helpful indication as to why it fails):
http://test1.calcxml.com/calculators/home-affordability?skn=502

Succeeds in both:
http://test1.calcxml.com/calculators/home-affordability?skn=504
0
 
Dave BaldwinFixer of ProblemsCommented:
The '502' version fails because it isn't being either sent or loaded, one of the two.  In the validator, the content is 0.  It does load in IE8.

How are you sending those files?  Obviously it's not a direct link.
0
 
brian-barnettAuthor Commented:
They are JSP pages, built with Struts Tiles, JSTL tags, etc., sent from Tomcat 6 servlet container. As you noted, it loads in IE8, and all other browsers I am aware of, except IE10.

There must be something about how Tomcat is passing the response?? or something about the html itself??

I'm at a loss right now...
0
 
Dave BaldwinFixer of ProblemsCommented:
I guess it's time for Wireshark to see what's being passed between the two.  http://www.wireshark.org/
0
 
CEHJCommented:
Can you locate an xhtml test page please - one that renders correctly in IE10? We can then start examining the source
0
 
mrcoffee365Commented:
I'm surprised that more people haven't seen this.  I think it's just IE10 applying more security rules which is making it a problem for the asker.

For example, here's a hex dump of the header of a saved html files generated by a tomcat 6 jsp page:
od -xc fragment.html

0000000 683c 6d74 206c 6d78 6e6c 3d73 6822 7474
          <   h   t   m   l       x   m   l   n   s   =   "   h   t   t
0000020 3a70 2f2f 7777 2e77 3377 6f2e 6772 312f
          p   :   /   /   w   w   w   .   w   3   .   o   r   g   /   1
0000040 3939 2f39 6878 6d74 226c e23e 8b80 80e2
          9   9   9   /   x   h   t   m   l   "   > 342 200 213 342 200
0000060 e28b 8b80 80e2 e28b 8b80 683c 6165 3e64
        213 342 200 213 342 200 213 342 200 213   <   h   e   a   d   >
0000100 0a0a 0a0a 0a0a 0a0a 0a0a
         \n  \n  \n  \n  \n  \n  \n  \n  \n  \n

Notice the unprintable characters between xhtml"> and <head> .  I've spent some time tracking this down as well, and I think it's generated by Tomcat as it renders the html from the jsp.  Which is why there isn't any code to find in the jsp itself to cause this.
0
 
Dave BaldwinFixer of ProblemsCommented:
That could be.  But a direct download of those two files shows no sign of unexpected non-printing characters in a hex viewer, just a lot of extra white space.
0
 
mrcoffee365Commented:
DaveBaldwin - you're right -- no unprintable chars in the link to the "always fails" html given above.

Either that's not the problem, or the asker didn't get a good source of the generated page.
0
 
Dave BaldwinFixer of ProblemsCommented:
I'm of the opinion that there is a problem in the delivery of that file.  The W3C validator also reports no content.  With '?skn=502' at the end (being the only difference from a working file), it is not being delivered directly.  So I believe there is a flaw in the process with that file.
0
 
CEHJCommented:
Notice the unprintable characters between xhtml"> and <head> .
I find that illegible i'm afraid - can you please use xxd instead of od? ;)
0
 
brian-barnettAuthor Commented:
Made some progress today, but need to go to bed. Found a handful of skn=XXX numbers that all failed. Tried to figure out what was similar among them and found that they all have a setting in our database to execute our mobile device detection code. We use WURFL 2.3.3 file and API to do this. I found that with the WURFL code we are using, that the Validator and IE10 both are identified as wireless devices, i.e., is_wireless_device = true in the WURFL code.

So, this has shown me that I need to check out our "mobile-friendly" html code that gets returned and make sure it is compliant. It also shows me that I need to try to figure out why Validator and IE10 are being identified as wireless devices by WURFL.
0
 
Dave BaldwinFixer of ProblemsCommented:
That is some serious progress.  Let us know what you find.
0
 
CEHJCommented:
the Validator and IE10 both are identified as wireless devices
That would probably break it, yes ;) Sounds like you need to look at the User-Agent database
0
 
brian-barnettAuthor Commented:
Anybody know how I can change the title of this question? I'd like it to be more descriptive of the actual problem we finally identified. Maybe something like "IE10 not displaying my html" or something like that, and maybe modify the tags a bit too.
0
 
brian-barnettAuthor Commented:
The problem is WURFL. Their user-agent library is incorrectly identifying IE10 as a wireless device. Also, the Validator is identified as a wireless device, although the Validator is not passing in a user-agent. Not sure why?? Thanks for all of your helpful suggestions along the way here.
0
 
CEHJCommented:
If WURFL is designed properly, it should allow extension of its 'database' plus, with luck, overriding of its heuristics. You ought to be able to correct those glitches. It probably hasn't been touched since the appearance of IE10 ;)
0
 
brian-barnettAuthor Commented:
I was able to identify the cause of the problem, but was able to use the suggestions of the experts along the way to lead me there.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 17
  • 13
  • 12
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now