Gran Paradiso
The RewriteCond instructions in this article will be out of date with the release of Firefox 3.0.
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept: text/html,application/xhtml+xml;q=0.9,application/xml;q=0.8,*/*;q=0.7
For those who want to build it from source:
sudo apt-get build-dep mozilla-firefox cvs -d :pserver:anonymous:anonymous@cvs-mirror.mozilla.org:/cvsroot co mozilla gedit ~/.mozconfig cd mozilla make -f client.mk build killall firefox-bin ff-opt-static/dist/bin/firefox
First impression: fonts need work.
Looking at the rewrite rules, it seems like the just do a regular expression match against the contents of the Accept header, checking to see if it contains “application/xhtml+xml”.
Regarding how such a request should be handled, if you have text/html and application/xhtml+xml representations of your document with equal fidelity it makes sense to give the browser whichever it prefers. However, if you’re using XHTML specific technologies such as a SVG, MathML, RDDL, etc then serving as application/xhtml+xml to any client which can accept it makes more sense. Of course, some agents include */* but can’t actually handle XHTML, complicating matters.
If Mozilla wants to avoid user complaints regarding the Yellow Screen of Death, switching to prefer text/html and thus the non-draconian parser is the way to go.
Looking at the rewrite rules, it seems like the just do a regular expression match against the contents of the Accept header, checking to see if it contains “application/xhtml+xml”.
The issue isn’t the first RewriteCond, but the second one.
The rationale for the change is discussed in bug 309438; comment 16 is particularly enlightening. Bug 361892 requests that a/x+x be restored after incremental XML reflow is implemented.
Posted by Peter J. at
Just so you don’t think I’m flaming unfairly, I’m going to find out which XML freaks imposed the text type nonsense in Firefox’s Accept...
I’m partial to bug 240493, comment 75.
Posted by Robert Sayre atJustin his suggestion doesn’t take into account
q values. I know at least one person who has application/xhtml+xml;q=0 in his Accept header.
Posted by Anne van Kesteren at
Anne: the second RewriteCond attempts to do exactly that:
RewriteCond %{HTTP_ACCEPT} !application/xhtml\+xml\s*;\s*q=0
Unfortunately, it also matches the fractional q value send by Gran Paradiso / Minefield. A better check would be:
RewriteCond %{HTTP_ACCEPT} !application/xhtml\+xml\s*;\s*q=0\.?\0*(,|$)
Posted by Sam Ruby
at
You’ve got a stray backslash there (in front of the zero), and the pattern doesn’t account for cases like 000., should they be permitted, or for additional whitespace separating the q value from the next MIME type or from end-of-line/-string.
RewriteCond %{HTTP_ACCEPT} !application/xhtml\+xml\s*;\s*q=0+\.?0*(\s|,|$)
Posted by Aristotle Pagaltzis
at
You’ve got a stray backslash there (in front of the zero)
Thanks!
and the pattern doesn’t account for cases like 000., should they be permitted
They are not
or for additional whitespace separating the q value from the next MIME type or from end-of-line/-string.
One could also legally have whitespace around the = sign.
They are not
Fair enough. (I couldn’t be bothered to look it up.) So going by the spec leaves us with this:
RewriteCond %{HTTP_ACCEPT} !application/xhtml\+xml\s*;\s*q\s*=\s*0(\.0{1,3})?\s*(,|$)
Posted by Aristotle Pagaltzis
at
I can’t find fault with Aristotle’s latest regex after 15 minutes of trying.
However, isn’t it beside the point, given the Accept header that Gran Paradiso is sending? The client is telling the server that it prefers text/html over application/xhtml+xml. Sam, I know your server is perfectly capable of sending text/html content. Why aren’t you doing so?
Posted by Mark atShould I start sending Gran Paradiso
text/html content, too (thus screwing up the MathML)? Perhaps, in light of this bug (this one?), that would be advisable.
Posted by Jacques Distler at
Why aren’t you doing so?
There are multiple answers to that. The shorter one can be found here. The longer one is outlined here.
Posted by Sam Ruby at@Sam: But surely there are better ways to discriminate against IE users. Perhaps wrapping your Adsense code with conditional comments? Oh, the irony. (I acknowledge your longer answer, though.)
@Jacques: wow, filed and confirmed almost a year ago and still not a single reviewable patch. Well, lots of luck with that. I’ve seen the statistics on how many bugs get fixed after lingering for a year, and it ain’t pretty. If I were you, I’d start looking for an alternate browser sooner rather than later.
Posted by Mark atHeh. Hurry, find a new browser! Something that’s in its very first alpha doesn’t work right yet! It’s time to panic, it’s time to fear! I’m filled with uncertainty and doubt, because the total rewrite of the graphics layer, which is still broken in innumerable ways, is broken in that way too!
Posted by Phil Ringnalda at
Phil,
If there’s a reason for pessimism, it’s not so much that the bug is old, it’s that
- It spans different components (GFX and MathML).
- It has not been assigned to anyone (perhaps not unrelated to above).
I’d even been blissfully unaware of the bug, until Cairo got turned on in MacOSX builds (as of late November).
Posted by Jacques Distler atI can’t find fault with Aristotle’s latest regex after 15 minutes of trying.
Wow, what a compliment. :-)
Posted by Aristotle Pagaltzis at
Does anyone know what the rationale for the change was?
Posted by Bob Aman at