XHTML page displays as source in WinME

[Quadibloc]

I have been working on my page at

http://www.quadibloc.com/math/ideint.htm

and after some effort, I managed to get the MathML to display properly
in Amaya 8.54; it had been created to work with Amaya 2.0. This
required changing the page to conform to XHTML rules.

To get it to display also in Internet Explorer with the DesignScience
MathPlayer plug-in and in Mozilla Firefox, which now supports MathML,
I had to go one step further, and rename the page to

http://www.quadibloc.com/math/ideint.xhtml

and this works when I'm booted into WinXP.

When I'm in Windows ME, IE works on my page. And Mozilla Firefox will
let me see

http://baruchel.free.fr/~thomas/notebook.xhtml

correctly, as well as Mozilla's own test page.

But when I try to look at *my* page with the .xhtml extension... I see
the page source, as if Firefox had never *heard* of xhtml! Doubtless,
I'm doing _something_ wrong...

John Savard

 

[Martin Honnen]

I had to go one step further, and rename the page to

http://www.quadibloc.com/math/ideint.xhtml

and this works when I'm booted into WinXP.

Firefox 2 on Windows XP shows me the source of that page and that
happens because the page is served as text/plain.
If you want to serve your .xhtml documents as XHTML then make sure you
configure you server to serve .xhtml documents as application/xhtml+xml.

 

[Quadibloc]

Firefox 2 on Windows XP shows me the source of that page and that
happens because the page is served as text/plain.
If you want to serve your .xhtml documents as XHTML then make sure you
configure you server to serve .xhtml documents as application/xhtml+xml.

Well, that's a design flaw in Firefox. Except for saving the file with
the extension .xhtml instead of .htm, to indicate that it's an XHTML
file, I have no control over things like that. It isn't "my" server.

Or, rather, it is "my" server, but it isn't my server.

The conventions for the Internet should be devised so that everything
works perfectly even in the usual model of a "personal web page"
hosted on an ISP, where one saves the pages of one's site as files in
the appropriate directory. Requiring people to run their own servers
so as to have privileged access to their workings... ought to be
limited to the really exotic stuff for which it is necessary.

In WinXP, at least I had different behavior when I looked at the page
as a local file - I didn't try accessing the site on the servers from
there, as I first noticed the problem in WinME looking at the local
file. Possibly XP does something extra locally then.

John Savard

 

[Andreas Prilop]

| Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) mod_fastcgi/2.2.12 mod_perl/1.26
| Content-Type: text/plain

Well, that's a design flaw in Firefox.

It's rather a flaw in your skills. If you don't even know about
HTTP headers and Content-Type, don't mess with XHTML.

Except for saving the file with
the extension .xhtml instead of .htm, to indicate that it's an XHTML
file, I have no control over things like that. It isn't "my" server.

Read http://httpd.apache.org/docs/1.3/mod/mod_mime.html .

 

[Martin Honnen]

Well, that's a design flaw in Firefox. Except for saving the file with
the extension .xhtml instead of .htm, to indicate that it's an XHTML
file, I have no control over things like that. It isn't "my" server.

Sorry, I completely disagree, if the server sends a resource with the
HTTP Content-Type header text/plain then Firefox is doing the right
thing by displaying the text sent. The suffix of a URL does not matter,
what matters is the Content-Type header sent.

 

[Quadibloc]

Sorry, I completely disagree, if the server sends a resource with the
HTTP Content-Type header text/plain then Firefox is doing the right
thing by displaying the text sent. The suffix of a URL does not matter,
what matters is the Content-Type header sent.

Well, I found the answer to my question.

I did *not* have to re-program the server, I just needed to put in a
meta tag, so I did have control over content-type from within the text
of my page.

It winds up that I needed *three* different versions of the page. One
that legacy browsers could display, one that shows the MathML in IE
with the DesignScience plug-in, and one that works in Mozilla Firefox.

John Savard

 

[Quadibloc]

It's rather a flaw in your skills. If you don't even know about
HTTP headers and Content-Type, don't mess with XHTML.

Turned out I can control the HTTP header with a meta tag.

I didn't really have a choice: Amaya can display MathML in a plain
HTTP page, but IE and Firefox both *insist* on XML at the least or
XHTML. And they like different flavors.

But I got it to work.

John Savard

 

[Richard Tobin]

I did *not* have to re-program the server, I just needed to put in a
meta tag

That *is* re-programming the server

-- Richard

 

[Quadibloc]

That *is* re-programming the server

It gives the server the information it needs, but it does not produce
a permanent change in the server's behavior that affects other pages.

John Savard

 

[Johannes Koch]

It gives the server the information it needs, but it does not produce
a permanent change in the server's behavior that affects other pages.

Which HTTP server reads HTML meta tags and then changes the Content-Type
header accordingly?

 

[Richard Tobin]

Which HTTP server reads HTML meta tags and then changes the Content-Type
header accordingly?

It certainly seems a bit odd... if the server thinks the document is
text/plain, what's it doing looking for <META> tags in it? It should
only interpret those if it thinks it's some form of HTML.

-- Richard

 

[Andreas Prilop]

Turned out I can control the HTTP header with a meta tag.

You are clueless.
http://www.unics.uni-hannover.de/nhtcapri/meta-http-equiv.1
http://www.unics.uni-hannover.de/nhtcapri/meta-http-equiv.2

 

[Quadibloc]

You are clueless.
 http://www.unics.uni-hannover.de/nhtcapri/meta-http-equiv.1
 http://www.unics.uni-hannover.de/nhtcapri/meta-http-equiv.2

Well, when I added the meta tag to my page source, it did something.
If my hosting provider had done something nonstandard with their
serving software, then indeed the "real" header might have differed
from what the meta tag asked for, and I wouldn't have solved the
problem. But that didn't happen.

John Savard

 

[Quadibloc]

It certainly seems a bit odd... if the server thinks the document is
text/plain, what's it doing looking for <META> tags in it?  It should
only interpret those if it thinks it's some form of HTML.

Well, what happened was this.

The browser thought the document was text/plain.

I added the <meta> tag, and then the browser thought it was xhtml.

I presume the server was undecided, and the meta tag helped it make up
its mind. And the browser just went by what the server told it. (This
is shared hosting, one tiny step up from your personal web page on an
ISP; I'm not the admin of the server.)

John Savard

 

[Quadibloc]

Well, what happened was this.

The browser thought the document was text/plain.

I added the <meta> tag, and then the browser thought it was xhtml.

I presume the server was undecided, and the meta tag helped it make up
its mind. And the browser just went by what the server told it. (This
is shared hosting, one tiny step up from your personal web page on an
ISP; I'm not the admin of the server.)

But with Firefox on another computer, it still displays as just text,
so you may well be right, and some other strange thing happened on my
computer.

John Savard

 

[Quadibloc]

That *is* re-programming the server

On another group, I found that I do have something I can do that comes
a bit *closer* to re-programming the server...

In a file named
..htaccess

put the line
AddType application/xhtml+xml .xhtml

and now it seems to work a bit better.

John Savard