| 1:05 am on Jul 11, 2013 (gmt 0)|
Before anything else: look at your htaccess. Both at the root level, and in any directories on the (physical) path to the affected file. Whether or not you've personally put htaccess in those locations
Is the part you give as "error.html" something on your own site or an external link?
| 2:18 pm on Jul 11, 2013 (gmt 0)|
I don't see anything strange in the htaccess file in root and only other one is in the blog folder and that appears ok.
The affected page is in the root.
The error.html is the 404 page. When the affected page loads there is a link to the error page at bottom of the page.
BTW, there is only the one page affected. All other pages have the same set up with left side bar, etc.
| 3:30 pm on Jul 11, 2013 (gmt 0)|
FWIW, this line was either created manually or by a html software, perhaps even a template you used.
I have it on a few of my pages, however NOT on the majority.
Don't recall if it's something I added into the Meta tag headers or was a result of something I used.
Despite a few obscure browsers, Doc Type really isn't necessary these days (I'm sure others will dispute that). The SE's and most browsers will display almost any combination of HTML & CSS, and even deprecated uses of same in web pages.
| 4:03 pm on Jul 11, 2013 (gmt 0)|
I write code by hand and I don't use a template other than the one I made up when I designed the site and it doesn't have that code nor none of the includes either.
This page had been online for several months without being edited and it's the only one affected. If it was one of the includes that were affected all pages would have the same problem. So something is being directly inserted into this particular page. I see nothing in the htaccess file that could cause this.
Thanks for trying to help.
| 5:38 pm on Jul 11, 2013 (gmt 0)|
I sure wouldn't lose any sleep over it.
The presence of a specified Doc Type doesn't present any vulnerability, even if you didn't add it.
Are you using PHP?
PHP may inject headers, however that's another issue and forum.
| 6:04 pm on Jul 11, 2013 (gmt 0)|
The problem with this code being injected into the page is the page is not loading correctly. Only the header and left side bar. everything else on the page is blank except the link to the error page.
| 6:27 pm on Jul 11, 2013 (gmt 0)|
|The problem with this code being injected into the page is the page is not loading correctly. Only the header and left side bar. everything else on the page is blank except the link to the error page. |
With PHP it's possible to implement headers and/or meta tags.
It's NOT possible to implement meta tags via htaccess.
It's likely that this either an HTML, CSS or even a frames issue.
Go through the left, right, top, bottom and body frames to determine if there is something that you have missed that is causing the issue.
I use and OLD Frames html in two sections of one my sites and they don't insert any meta tags on their own. I do have a tag in place that limits viewing of the body frames pages alone.
Once again, nothing to do with htaccess.
| 8:06 pm on Jul 11, 2013 (gmt 0)|
I'm not using PHP.
I never said anything about meta tags.
I don't use frames.
| 8:25 pm on Jul 11, 2013 (gmt 0)|
Wait. Stop. Rewind.
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
That's not the actual DTD from your actual HTML files on your actual site is it? I had to go look it up: That really is the HTML 2 DTD. I can say with confidence that there is absolutely ZERO possibility that your pages are written in html 2, so browsers are simply ignoring the dtd altogether.
Wilderness, I suggested htaccess because you need to eliminate the possibility that a perfectly benign page or SSI (but not php include) is being rewritten to something else. If it isn't, then you can cross off this possibility.
| 8:32 pm on Jul 11, 2013 (gmt 0)|
Here are few random ideas...
Did you try to RENAME the offending page on the server and then upload the offending page from your PC to the server again. Try to view it in browser - does it still show incorrectly?
You said that the rest of the offending page is then blank. Is there more HTML beyond your example when you do "View Source" that is just plainly not showing on the rendered page? Or does the View Source HTML just ends up with </body></html> ?
What about any external js, are you loading these somewhere? Did you check these files that something was not inserted in there?
Have you tried "Fetch as googlebot" in WMT? What does the fetch show in HTML?
If nothing of the above gave any answers, what about trying the following:
- Upload the (good) page from your PC to the server under another filename (e.g. abc.html)
- Check that this new filename in your browser appears ok (or has it got the same problem?)
- if it shows ok (and offending page still shows incorrectly) then perhaps you can try to add a line to your .htaccess to rewrite the request for the offending page to that new filename you uploaded
- if you then request the offending page, does it show ok or it shows blank page again?
If it shows blank page again, there must be some detour in serving a different page somehow (this is why Lucy said to check all of your .htaccess carefully) or some caching problem.
Also, can you try to upload the page under the same name to another folder and try to view it in browser - what does it show?
Meta tags were mentioned because something somehow has inserted <title>302 Found</title> into the HTML. I gather your original page has a different title.
|I never said anything about meta tags. |
| 10:57 pm on Jul 11, 2013 (gmt 0)|
|Meta tags were mentioned because something somehow has inserted <title>302 Found</title> into the HTML. I gather your original page has a different title. |
Lorel was confused because that's a title *element* not a meta anything. If we want to understand each other we should at least use the proper terms.
| 11:21 pm on Jul 11, 2013 (gmt 0)|
^^^ True :) thanks on the correction!
| 4:29 pm on Jul 12, 2013 (gmt 0)|
The problem is fixed. I'm not sure what fixed it as I made so many tests/changes but it had something to do with one of the includes, even after it was deleted and the way this server (IPower) produces an error message when one of the includes are not working (showing the error message code and linking to the error page from within the content and breaking the page instead of just displaying an error message that the include didn't load within the page like other servers). I suspect the unusual code was produced by the server as the actual error page does not use DTD HTML 2.0 (the error page works fine when testing the url with a typo). I've never seen this problem before and I've been working with includes for about 14 years. I still don't know where it came from but it's working now so I'm dropping this discussion.
Thanks for everyone who tried to help.
| 4:40 pm on Jul 12, 2013 (gmt 0)|
what does your ErrorDocument directive look like?
| 4:49 pm on Jul 12, 2013 (gmt 0)|
I would browse through php.ini if you have one because error handling is an option that can be toggled via that file. I have found them as part of a default set of files on some hosting services. (and learned to keep a backup but never include it when moving a site)
| 6:10 pm on Jul 12, 2013 (gmt 0)|
I didn't copy off the error message but it was something like
"..... error. click here".
Here is the code that gets added to the page:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<p>The document has moved <a href="http://www.example.com/error.html">here</a>.</p>
| 6:11 pm on Jul 12, 2013 (gmt 0)|
I'm not using PHP
| 8:30 pm on Jul 12, 2013 (gmt 0)|
If not php, are you using vanilla SSIs? Do you have a
directive? The simplest form is
SSIErrorMsg "<!-- SSI error -->"
with comment tags, meaning that if you snoop into the code you can see where it went wrong, but nothing is visible to the naked eye. The default error message is something plainly visible in the body of the page.
You should also be able to find the problem in your error logs. The wording is "unable to include"; it should jump out from the surrounding "client denied by server configuration".
| 11:20 pm on Jul 12, 2013 (gmt 0)|
the ErrorDocument directive would be found in .htaccess or the server config file.