- From: Richard Kaye <R.W.Kaye@bham.ac.uk>
- Date: Wed, 30 May 2007 10:54:20 +0100 (BST)
- To: "Chris Chiasson" <chris@chiasson.name>
- Cc: r.w.kaye@bham.ac.uk, www-math@w3.org
Thanks Chris. I didn't know about this! I may be going off topic now... apologies if so. I guess what is being tested in http://jigsaw.w3.org/HTTP/CL/ is a relative link which should be relative to the Content-Location header when present, but is in most browsers is relative to the actual URI. All the browsers I have right now (IE7, Firefox 2.0.0.3, and an older mozilla clone) return the same result on this test: "Your browser does NOT compute the base URI of the document per Section 14.14 of rfc2616", presumably meaning that they don't conform to this slightly obscure test. What I was suspecting in my earler post is that IE is doing mime-type sniffing based on the Content-Location header. I really don't see how to set up a test for this at the server end. Richard > There are demo pages on the internet that can test (some aspects of) > whether or not the browser is using the content-location header. > > For instance: > http://jigsaw.w3.org/HTTP/CL/ > > On 5/29/07, Richard Kaye <R.W.Kaye@bham.ac.uk> wrote: >> >> Dear all >> >> I have made a few small discoveries. >> >> Most importantly, that the mimetypes text/xml and >> application/xhtml+xml behave quite differently in >> IE7 in at least two different ways. >> >> If I serve a document with extension .xml and >> Content-type: text/xml; charset=utf-8 >> then Mathplayer is triggered correctly provided >> I have the appropriate key in ../PROTOCOLS/Filter/ >> with name "text/xml; charset=utf-8". If the same >> file is served with >> Content-type: text/xml;charset=utf-8 >> (no space) then all is OK but only provided I >> rename the registry key, removing the space. >> >> Do the same for "application/xhtml+xml; charset=..." with a >> file still with .xml extension and I get a readable >> web page, but no MathML and MathPlayer is not started. >> (that's even after checking all the registry keys etc >> are correct). In all the experiments I have done, if the >> extension is .xhtml and there is a charset spec in the >> Content-Type then the IE always displays the xml tree. >> >> I was able to display MathML-enabled XHTML correctly, when >> served from a tomcat servlet (where there was no >> file or file extension) but only after changing the >> mimetype to "text/xml;charset=utf-8" and tweaking the >> registry on the client accordingly. I can't verify >> Robert's idea that it is somehow the way the document is >> served, though clearly IE uses an extension (.xml, .xhtml) >> if one is available. >> >> So it seems to me that: (1) it seems that IE makes an effort to >> display html when the extension is ".xml" irrespective of >> the mimetype; and (2) fiddling with the registry keys works >> for text/xml but not for application/xhtml+xml. It's getting >> late over here and I am tired. I may be jumping to false >> conclusions over here, so if you are interested you had better >> double-check this yourself. >> >> This does not yet provide me with a workaround for my blog >> server since the Tomcat I have insists on removing the space >> in the "; charset=..." even when I deliberately put it there, >> and therefore a registry tweak would be needed on all >> client machines. (That's because MathPlayer installs with >> the "text/xml; charset=utf-8" key but not the >> "text/xml;charset=utf-8" key. If only one is provided then that >> is probably the right way round as my Apache actually inserts >> a space in ";charset=..." even when I deliberately omit it...) >> >> A couple of other things: >> >> 1. I did try the effect of adding a BOM a long time ago, with >> no effect on the documents giving me XML trees. >> >> 2. I have also used URLs with no extension (the correct >> document provided by content negotiation) successfully before. >> I didn't think the client knew the full name of the file in >> such cases, but now I look at it I have noticed a >> Content-Location: <filename> >> HTTP header which might explain a lot. Does IE use this? >> >> 3. I had never thought about using text/xml until now. I seem to >> remember reading reasons why text/xml is a Bad Thing, but can't >> remember them. Anyone else know? >> >> Richard >> >> >> On Tue, 2007-05-29 at 08:48 -0700, Robert Miner wrote: >> > Hi Jacques, >> > >> > There isn't a direct connection between the charset and the XML tree. >> > But just as IE doesn't seem to always follow the rules for determining >> > the encoding, it also does not play by the rules for determining the >> > MIME type (as I'm sure you know). >> > >> > The XML tree shows up when IE doesn't believe the http header's >> > declaration that the MIME type is application/xhtml+xml and doesn't >> > start up MathPlayer. Somewhere later on, it must realize the document >> > is XML at least, since it displays the tree. But at the point it is >> > supposed to invoke MathPlayer if the MIME type is >> application/xhtml+xml, >> > the call never comes, at least as far as I can determine by setting a >> > breakpoint in the relevant routine in the debugger. >> > >> > We had been experimenting with the charset parameter, on the >> hypothesis >> > that somehow that might be preventing IE from recognizing the MIME >> > declaration in the http header. But it doesn't seem to. Mostly it >> seems >> > like if the document is dynamically generated, so there isn't a file >> > name in the http header, IE just sniffs the content and get's it wrong >> > for purposes of firing off MathPlayer. At least that is what the >> > experimental evidence seems to suggest to me. >> > >> > I thought perhaps Richard's comment about the BOM meant that if there >> > was a BOM, suddenly IE's sniffer did the right thing and recognized >> the >> > content as application/xhtml+xml and fired up MathPlayer. But I guess >> > not. >> > >> > --Robert >> > >> > Robert Miner >> > Director, New Product Development >> > >> > Design Science, Inc. >> > 140 Pine Avenue, 4th Floor >> > Long Beach, California 90802 >> > USA >> > Tel: (651) 223-2883 >> > Fax: (651) 292-0014 >> > robertm@dessci.com >> > www.dessci.com >> > ~ Makers of MathType, MathFlow, MathPlayer, WebEQ, Equation Editor, >> > TexAide ~ >> > >> > >> > > -----Original Message----- >> > > From: Jacques Distler [mailto:distler@golem.ph.utexas.edu] >> > > Sent: Tuesday, May 29, 2007 10:19 AM >> > > To: Robert Miner >> > > Cc: R.W.Kaye@bham.ac.uk; www-math@w3.org; William F. Hammond >> > > Subject: Re: MathML won't display (or: what triggers mathplayer >> > > behaviour?) >> > > >> > > -----BEGIN PGP SIGNED MESSAGE----- >> > > Hash: SHA1 >> > > >> > > >> > > On May 29, 2007, at 9:33 AM, Robert Miner wrote: >> > > >> > > > So does the byte order mark solve the problem in all the >> situations >> > > > you know of? It would be great if it really was that simple? >> > > >> > > Depends on what "the problem" is. >> > > >> > > MSIE (both 6 and 7) does not, under some circumstances, respect the >> > > established rules for setting the encoding of the document. Instead, >> > > it tries to sniff the encoding, a procedure that probably does not >> > > play well with the MathPlayer plugin. See, e.g. this discussion: >> > > >> > > http://annevankesteren.nl/2005/02/charset#comment-3167 >> > > >> > > That, as far as I can tell, does not have anything to do with the >> "IE7 >> > > +MathPlayer shows an XML document tree" problem. >> > > >> > > Or, if it does, no one has explained the connection to me. >> > > -----BEGIN PGP SIGNATURE----- >> > > Version: GnuPG v1.4.3 (Darwin) >> > > Comment: PGP Key - http://golem.ph.utexas.edu/~distler/distler.asc >> > > >> > > iD8DBQFGXERwnyqPIXpYcjcRAhfDAKCSA4L/MunLbgzFDUoTpsLzJJV5KACgy1oS >> > > UqriwBgMkVIKJZx8J17n5zA= >> > > =lDK+ >> > > -----END PGP SIGNATURE----- >> > >> > >> >> >> > > > -- > http://chris.chiasson.name/ >
Received on Wednesday, 30 May 2007 09:55:00 UTC