When I "view source" (using cmd-I )of google.com/robots.txt in Safari, Chrome or Firefox on a Mac, I see:
<html>
<head></head>
<body>
<pre style="word-wrap: break-word; white-space: pre-wrap;">…</pre>
</body>
</html>
Where is the HTML coming from?
Google's robots file is just an example -- I get the same results for all text files, in all browsers.
I am asking because I am writing a Python program to generate robots.txt and sitemap.txt files, and I wanted to make sure the correct headers were sent.
Seeing HTML in the source code made me worry that my headers were incorrect.
The fact that Google's robots.txt file has the same HTML reassures me that it's normal, but I would like to know why this is the case.
I have been building web sites since 1995 and do not remember ever noticing this behavior.
The HTML is generated in your Browser for viewing it. It's not sent this way (use e.g. curl to see it or the network analysis function of your Browser).
E.g. in Chrome: Menu -> More Tools -> Developer Tools. Then click on the tab "Network" and refresh the page.
Im using netbeans and the framework GWT. Due to the GWT structure, on my browser i can't see the html code with the simple "View Source". How can I see this? Im using Google Chrome.
Bye
View Source only shows you the HTML page that was downloaded (i.e., not much). Try using Chrome's Developer Tools to see the DOM structure after GWT's loaded. You can also use it to see network traffic from the page, and see JS errors if there are any.
I was faced with exactly the same situation. I use the Firefox extension Web Developer: on the "View Source" menu there is an option "View Generated Source".
Is there a way for nesting an image in an HTML page *inline* in IE7?
I can't use external resource, all because of a particular server configuration (it's a web dispatcher in maintenance mode that redirects all requests to a single .html page).
So I can't afford using the classical embedding by using the following:
<html>
<img src="mypic.jpg" />
</html>
When looking for a solution, I found these:
Using inline SVG within an XHTML file # => I can't use XHTML extension in my case the page has the .html extension (and I can't change it)
Using base64 encoding # => It works pretty well with Firefox & Chrome, but not in IE7
None of which seem to be working in my configuration.
The more I seek the less I hope. Any ideas?
The only option, as far as I know, for embedded image in an HTML document for current versions of Internet Explorer is VML (which isn't supported by anything other than Internet Explorer).
You could use something like Raphaël to abstract the VML or SVG into a single JS script (but that would add a dependency on JavaScript).
That easiest option would probably be to reference a normal image on an external URI … on a different server.
For the svg solution, your page doesn't need to end in .xhtml. In fact, it can end in whatever extension is handled by your web server.
The page being in xhtml is defined by its doctype definition. Put the doctype definition of xhtml 1.0 (strict or transitional) or even better xhtml1.1 and embed svg in the page.
As an alternate solution, you could try to output the image directly with an .html extension, keeping its original mime (image/jpeg for instance) but I'm not sure it would work.
Instead of redirecting to a single .html page, you could redirect to a single image and put your text on the image. This has obvious drawbacks, but how important is the image?
What you meant by base 64 encoded?
I just tried viewing my website http://www.logmytime.de/ in Opera (version 10.50) it gives me an "xml parsing failed error" and refuses to display the web page.
I can choose to "Reparse the document as HTML" and then the page works fine, but that's hardly a solution to my problem.
The weird thing is that the error still occurs after setting a HTML (instead of XTHML) doctype:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
I checked the source output from the browser to make sure I did not make any mistake with the Doctype I even viewed the same web page in Firebug and it shows a Content-Type of text/html; .
So, why does Opera still try to parse my web page as XML?
Thanks,
Adrian
Edit: Just to clarify: I am not asking what the error on my web page is. I understand why this is not valid XHTML. However, I am also using the javascript micro templating engine, and it's templates are never valid XML, which is why I need the browser to parse my entire web site as HTML, not XHTML. In order to demonstrate this, I just inserted an example template into the web page.
<script type="text/html" id="StopWatchTemplate" >
<h1><#=currentlyRunning?"Aktueller":"Letzter"#> Stoppuhr-Zeiteintrag</h1>
<%-- Stoppuhr - Ende--%>
</script>
When opening the page in Opera, you can see that the template now produces XML parsing errors even though the doctype for the page is still HTML.
Edit 2:: Just to make this even clearer: I am not asking why my web page is not valid XHTML. I am asking why Opera tries to parse it as XHTML despite the HTML doctype.
Edit3:: Please do not post any more answers, I have found the cause of this and documented it below.
Your document is not a valid HTML document. So, the browser should reject it. Unfortunately, due to a historic accident, most browsers do not reject invalid documents, but rather try to fix them (usually with pretty crappy results), so that the authro never even notices that his document is broken.
Thankfully, with XHTML, the browser vendors decided to fix that, and actually reject invalid documents. In your case, you are delivering your document as XHTML with the application/xhtml+xml MIME type:# curl --head http://www.logmytime.de/
HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 12529
Content-Type: application/xhtml+xml; charset=utf-8
^^^^^^^^^^^^^^^^^^^^^
Server: Microsoft-IIS/7.5
X-AspNetMvc-Version: 2.0
X-AspNet-Version: 2.0.50727
Set-Cookie: Referrer=None; path=/
X-Powered-By: ASP.NET
Date: Tue, 04 May 2010 16:08:40 GMTSo, the browser rejects your document (as it should). When you switch over to HTML, then it tries to fix your broken HTML.
Now, you have changed your DOCTYPE to HTML 4.01, but you are still delivering it as XHTML. All you have achieved now is that there are two reasons for the browser to reject your document: it's still invalid because you haven't fixed the actual bug and the DOCTYPE and the MIME type don't match up.
Instead of mucking around with DOCTYPEs and MIME types in order to get the browser to parse your broken document, the correct way to solve this problem would be to simply fix the invalid markup and remove the extraneous class attribute on line 172. [BTW: who wrote that document? The indentation and formatting is awful.]
You have the "class" attribute specified two times.
From Well-formedness constraint: Unique Att Spec:
An attribute name MUST NOT appear more than once in the same start-tag or empty-element tag.
You got the correct answer (HTTP content-type header mandating XML parsing) and it seems it's fixed. I'll just add a minor hint on how you can figure out what's wrong from within Opera itself. Two possible ways:
1) Info panel
This is not visible by default, but if you open the panel bar on the left (press F4 to toggle if you don't see it), then click the small plus sign at the bottom, you can enable "Info" in the menu.
The info panel shows some assorted information about the page currently open, including encoding and MIME type.
2) Opera Dragonfly
Press Ctrl-Shift-I to open developer tools (or go through menus to Tools > Advanced > Opera Dragonfly)
Go to "Network" tab, then re-load site. You will see the request and can review the headers. Comparing this with corresponding information from Firebug would have shown you the difference in Content-type headers. (Here you will also see that Opera sends an "Accept" header that contains "application/xhtml+xml". This means "Hi server, if you happen to have this file in real XHTML format I would understand that just fine.". Perhaps your server-side framework saw that header and wrongly responded with the XHTML content-type even though the content was invalid?)
In case someone else has the same problem: As suggested by DeveloperArt it can be fixed with a simple ContentType="text/html" attribute in the page element.
Edit: The problem was in fact caused by a bug with the mobile.Browser file I am using in my web project. The workaround above works, but it is not really necessary in my case. See this answer for more details.
It seems like the server is serving a different mime types to different user-agents. Firefox is getting text/html but Opera (and curl according to Jörg W Mittag) is getting application/xhtml+xml. Do you have any content-negotiation code for your site?
Try from another PC to make sure that you're not hitting a cache issue.
The page code is cached in your browser, which is why you are continuing to see the error. You originally saw the error, because your code is likely not valid.
It is because you've kind of told it to...
<html xmlns="http://www.w3.org/1999/xhtml">
application/xhtml+xml
If the server sends the page as application/xhtml+xml, the browser parses it as XML as required by specification. When parsing as XML, the first XML well-formedness mistake will stop the parsing and the client (browser) usually displays an error message.
text/html
The parsers for text/html are more tolerant (due to the history of html development).
Changing the mime type
To change the content type sent by the server, you have to override the HTTP header value: Content-Type. This can be done through scripting language on the server side or sometimes in the configuration of the server such as Apache for example. I do not know how Microsoft-IIS/7.5 can specify on a URI base.
Content-Type: application/xhtml+xml; charset=utf-8
or
Content-Type: text/html; charset=utf-8
This mostly occurs with ASP.NET as it sets content type for opera as application/xhtml+xml. In order to over come this issue. You need to set content type to text/html. The best way to fix this issue is to add following code to .browser config file for opera in App_Browser file.
<capability name="preferredRenderingMime" value="text/html" />
<capability name="preferredRenderingType" value="html32" />
<capability name="SupportsXhtmlRendering" value="false" />
I lookong for some IE or Firefox extension, which allows to browse html source, corresponding to data, shown in browser window right now.
I have large web application with alot of code, generated by JavaScript. I need to extract real HTML code, which I see in browser window right now (View source function shows only code loaded from server, not generated by JS). Most of JavaScript debuggers can show DOM model from browser memory, but I'am need something more friendly, like printable HTML. Does anybody know tools or plugins for IE (preferred) or Firefox?
Firefox's Web Developer extension will allow you to do this. After you install it, just select View Source->View Generated Source.
FireBug for Firefox will display the HTML corresponding to what you see in the browser window right now (that is including any modifications made in JavaScript).
You can use
javascript:document.write("<xmp>"+document.documentElement.innerHTML+"</xmp>");
in IE to view the generated source.
Paste the above and execute in address bar of IE.