427352 - Please promote application/xhtml+xml to first position in the Accept: header

Status: RESOLVED INVALID

(Core :: Networking: HTTP, defect)

Description

[Mike Hommey [:glandium]]

I understand how it came to be second, from bug #309438 which demoted it to be q=0.9, and bug #361892 which brought it back to q=1.0, but now that application/xhtml+xml is handled incrementally, is there a reason to avoid it to be used over text/html?

This breaks the simplest content negociations in place with Apache, using the following directives:
Options +MultiViews
DirectoryIndex index

Where a directory would contain both index.html and index.xhtml.

With the current Accept: headers, index.html is returned. With the Accept: headers before bug #309438, index.xhtml was returned.

Comment 1

[Jesse Ruderman]

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html seems to indicate that order shouldn't matter given that both text/html and application/xhtml+xml are both q=1.0.

Comment 2

[Mike Hommey [:glandium]]

Order will obviously matter at some point for types with the same q rate, because you still have to choose between both. While there's no problem when only a document of one of these types is present on the remote server, there is one when both are present.

Comment 3

[Gervase Markham [:gerv]]

What's the relationship of application/xhtml+xml to HTML5?

Do our layout hackers agree that we actually do prefer application/xhtml+xml to text/html?

Gerv

Comment 4

[Benjamin Smedberg]

I don't think so: I think we should prefer HTML to XHTML for the simple fact that the error handling is not draconion, which in most cases is better for our users.

Comment 5

[Brendan Eich [:brendan]]

Cc'ing bz and dbaron in case they think this should be wontfix not invalid, or dealt with otherwise.

/be

Comment 6

[Boris Zbarsky [:bzbarsky]]

> is there a reason to avoid it to be used over text/html?

The parser for XHTML less efficient and less carefully tuned to produce good behavior, now that we're using the HTML5 parser for HTML.  Further, this reduces one of the main benefits XHTML used to have (the ability to inline SVG/MathML in it).

Also, a noticeable fraction of XHTML out there is malformed, so we want to make sure sites don't send us XHTML by accident; if they're really sure they want to do it, we make it easy: just set the server-side q for XHTML higher than for HTML, no?

Let's turn the question around; what are the user benefits of getting xhtml instead of html?