Middleware to degrade XHTML into HTML

[Dave Hodder <dmh@…>]

I've created a module called XhtmlDegraderMiddleware, which I'd like to submit for possible inclusion.

When Django sends contents as XHTML (with the "application/xhtml+xml" media type) it checks to ensure that the requesting browser can accept XHTML. If so, it does nothing; however if the browser has poor XHTML support it changes the contents to "text/html".

It doesn't interfere with contents that is already using the "text/html" media type.

(If accepted, it could be placed in django/contrib/xhtmldegrader.)

Thanks,
Dave

[Dave Hodder <dmh@…>]

django.contrib.xhtmldegrader.middleware.py

[Dave Hodder <dmh@…>]

Documentation

[Dave Hodder <dmh@…>]

Documentation attached.

[Dave Hodder <dmh@…>]

django.contrib.xhtmldegrader.middleware.py

[Dave Hodder <dmh@…>]

Documentation

[Johann Queuniet <johann.queuniet@…>]

You might want to take a look at the similar middleware written by Sune Kirkeby two years ago: ​http://code.ibofobi.dk/public/file/trunk/ibofobi/src/ibofobi/middleware/xhtml.py?rev=1536

It addresses a few issues of the patch given here, like a ill-ordered middleware stack with a GZip compressor.

Also, I think the _supports_xhtml function is too hack-ish. What if IE 8 still doesn't support this mimetype? What if another browser has the same behavior? Browser often use */* as a mere fallback for content they're going to download or dispatch to a plugin, I don't think it's appropriate to take it in account instead of sending the expected text/html in this case. Also, what about search engines? The way Google handles pure XHTML is still not exactly perfect, and it can end up listed as foreign content (see ​http://www.google.com/search?q=site%3Awww.lirmm.fr+application%2Fxhtml%2Bxml for an example).

[Dave Hodder <dmh@…>]

django.contrib.xhtmldegrader.middleware.py

[Dave Hodder <dmh@…>]

Documentation

[Dave Hodder <dmh@…>]

Ah, I wasn't aware of Sune Kirkeby's middleware when I first wrote this. I've attached another version which doesn't examine the User-Agent header inside _supports_xhtml().

The first two versions fall back to User-Agent sniffing when the Accept header is '*/*' or not present. My thinking was that this would allow the likes of Apple Safari ("Accept: */*") and the W3C validator (no Accept header) to still receive application/xhtml+xml contents. Given your Google example, and the fact that Safari 3.0beta has fixed it's Accept header, I've decided to remove the UA sniffing.

(The first two versions also don't properly cope with the default PlayStation 3 browser.)

[Simon G. <dev@…>]

Dave, this looks interesting, and I like it, but I'm not sure if this is something that needs to be included in Django. Can you make a post about this on ​django-developers, and make a case why this would be useful to include, and see if you can get some comments back from the core developers.

Thanks,
Simon

[Jacob]

Marking wontfix; see ​http://groups.google.com/group/django-developers/msg/6db0e9a51583e2fc.