Jason King wrote:
Please, using IE, hithttp://details.at <http://details.at/> and refresh a few times. You should see it is snappy and doesn't break.
OK, fired up my Windows VM and saw what you're seeing (not that I didn't believe you!). What I'm having a really difficult time understanding is what on earth IE would be doing that would cause this since all other browsers work.
Does IE have anything similar to the Live Headers plugin for firefox so you can see the get request IE makes and the raw response it gets back?
And I'm sure you did this as well, but if you view source on the white screen you can see there IS HTML in there.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content="text/html; charset=utf-8" http-equiv=Content-Type></HEAD> <BODY></BODY></HTML> HYes, it ends with the letter H for some reason. :-) At least the first time I got it. On subsequent attempts I got that same code as above but with charset=windows-1252 instead of utf-8, and no "H", which is quite bizarre.
And the REALLY weird thing is once IE gets the white screen, it'll get it every time, unless I clear my browsing history. Even if I do a shift-refresh I get the white screen.
Also, since the flash.jpg is the most visible sign of an issue, it's interesting that when you hit http://www.details.at/graphics/flash.jpg you get the same white screen with the source code above, with charset=windows-1252 yet http://details.at/graphics/flash.jpg works. (Not telling you anything you don't know, just poking around on this to see what I can find.)
I do notice that a cookie gets set when I hit your site. Can you try disabling session management for the application and see if that fixes the issue?
I answered my own question above Live Headers--I installed ieHTTPHeaders (http://www.blunck.se/iehttpheaders/iehttpheaders.html) to see what's going on.
It looks like the first thing it can't find is print.css--that throws a 404 even at http://details.at. Probably neither here nor there, just relaying what I'm seeing.
On the first hit to the www site, where you see the red X for the image but the page still comes up, there are some 404 as well as javascript errors that might be worth a look.
Javascript-wise, I'm seeing "cfform_submit_status is undefined" -- this could mean that if you're using cfform that based on how you have your hosts, etc. set up it can't find the javascript libraries.
Now I think I'm getting somewhere. If you hit: http://details.at/bluedragon/scripts/cfform.jsThat works. But if you put www before it, you get a white screen and the HTTP headers show a 413 response. I had to look that one up since I've never seen that before, and it's a "Request entity too large" error. Some interesting details here:
http://www.checkupdown.com/status/E413.htmlNow why the difference between www and no www, I unfortunately have no idea. Trying to browse to the OpenBD admin works without the www, but again when I add the www, I get a 413 error.
On your home page, the following errors occur: 404 - /print.css 413 - /bluedragon/scripts/cfform.js 413 - /bluedragon/scripts/mask.js 413 - /graphics/flash.jpg 413 - /favicon.icoThat's all I got at this point. :-) Hope that gives you a bit to go on, and when I get a chance later today I'll revisit this and see if I can figure out why www would cause the 413 issues. You might peruse the Jetty forums for that issue though and see if anything pops up.
Matt -- Matthew Woodward [email protected] http://www.mattwoodward.com/blogPlease do not send me proprietary file formats such as Word, PowerPoint, etc. as attachments.
http://www.gnu.org/philosophy/no-word-attachments.html
smime.p7s
Description: S/MIME Cryptographic Signature
