It’s just data

Gran Paradiso

The RewriteCond instructions in this article will be out of date with the release of Firefox 3.0.

Bon Echo:

Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

Gran Paradiso:

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.


Does anyone know what the rationale for the change was?

Posted by Bob Aman at

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.

Posted by Justin at

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.

Posted by Sam Ruby at

See bug #309438.

Posted by zcorpan at

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 at

Justin 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.

Posted by Sam Ruby at

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 at

Should 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 at

Heh. 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

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 at

I can’t find fault with Aristotle’s latest regex after 15 minutes of trying.

Wow, what a compliment. :-)

Posted by Aristotle Pagaltzis at

Add your comment