Code

Opened 7 years ago

Closed 7 years ago

#3700 closed (wontfix)

Middleware to degrade XHTML into HTML

Reported by: Dave Hodder <dmh@…> Owned by: adrian
Component: Contrib apps Version: master
Severity: Keywords: xhtml middleware
Cc: Triage Stage: Design decision needed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

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

Attachments (6)

middleware.py (3.1 KB) - added by Dave Hodder <dmh@…> 7 years ago.
django.contrib.xhtmldegrader.middleware.py
xhtmldegrader.txt (2.7 KB) - added by Dave Hodder <dmh@…> 7 years ago.
Documentation
middleware.2.py (2.9 KB) - added by Dave Hodder <dmh@…> 7 years ago.
django.contrib.xhtmldegrader.middleware.py
xhtmldegrader.2.txt (2.7 KB) - added by Dave Hodder <dmh@…> 7 years ago.
Documentation
middleware.3.py (3.1 KB) - added by Dave Hodder <dmh@…> 7 years ago.
django.contrib.xhtmldegrader.middleware.py
xhtmldegrader.3.txt (2.7 KB) - added by Dave Hodder <dmh@…> 7 years ago.
Documentation

Download all attachments as: .zip

Change History (13)

Changed 7 years ago by Dave Hodder <dmh@…>

django.contrib.xhtmldegrader.middleware.py

comment:1 Changed 7 years ago by Simon G. <dev@…>

  • Needs documentation set
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed

Changed 7 years ago by Dave Hodder <dmh@…>

Documentation

comment:2 Changed 7 years ago by Dave Hodder <dmh@…>

  • Needs documentation unset

Documentation attached.

Changed 7 years ago by Dave Hodder <dmh@…>

django.contrib.xhtmldegrader.middleware.py

Changed 7 years ago by Dave Hodder <dmh@…>

Documentation

comment:3 Changed 7 years ago by anonymous

  • Component changed from Uncategorized to Contrib apps
  • Keywords xhtml middleware added
  • Owner changed from jacob to adrian

comment:4 follow-up: Changed 7 years ago by 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).

Changed 7 years ago by Dave Hodder <dmh@…>

django.contrib.xhtmldegrader.middleware.py

Changed 7 years ago by Dave Hodder <dmh@…>

Documentation

comment:5 in reply to: ↑ 4 Changed 7 years ago by 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.)

comment:6 Changed 7 years ago by Simon G. <dev@…>

  • Has patch set

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

comment:7 Changed 7 years ago by jacob

  • Resolution set to wontfix
  • Status changed from new to closed

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.