<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">On Jan 3, 2008, at 2:03 PM, Max Barel wrote:<br><br><blockquote type="cite">Le 3 janv. 08 à 22:29, Alexey Proskuryakov a écrit :<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">on 03.01.2008 23:06, Max Barel at max@ac-mb.info wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">As I know no way to guess xhtml capability from javascript and modify this default header, webkit gets xhtml served as text/html.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Does this qualify for a bug report or a feature request or do I miss something?<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">We could probably change the default to match Firefox, but I do not really<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">see the logic behind using the same Accept string for main resource loading<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">and for XHR, given that Firefox itself uses different Accept strings for<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">subresources.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Well, I just checked it again and see that Firefox send the very same accept string in XHR and normal get. Thus it gets xhtml correctly served.<br></blockquote><br>That is not correct.<br><br>An XMLHttpRequest could be used to get any kind of content, even non-XML. There's no reason to assume it would be XHTML. I don't think it's right for the browser to assume that XMLHttpRequest is going to be getting an XHTML document as opposed to other kinds of XML and set the Accept header field accordingly.<br><br>And the current draft of the W3C XMLHttpRequest specification &lt;http://www.w3.org/TR/XMLHttpRequest/&gt; explicitly forbids setting the Accept header field:<br><br>"If the user agent implements server-driven content-negotiation it should set Accept-Language, Accept-Encoding and Accept-Charset headers as appropriate; it must not automatically set the Accept header."<br><br>WebKit is not currently conforming to this, because it's sending "*/*" rather than no header at all.<br><br><blockquote type="cite">Serving xhtml as application/xhtml+xml is the conforming content-type and, moreover, the user agent is due to parse the returned data and return a document object into XMLHttpRequest.responseXML . This must be the right way to go rather than injecting raw html strings into innerHTML/outerHTML or parsing the markup. Or else responseXML is an empty concept.<br></blockquote><br>Sounds fine. I think you should set the Accept header field based on the browser capabilities. The fact that Firefox is currently giving you this Accept header field automatically is a bug, and I think you should not rely on it.<br><br>Or if you like this behavior and think that other browsers need to support it, then we should get the W3C XMLHttpRequest specification fixed.<br><br><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Side note: As long as the correct namespace is used, document content is almost OK. Almost because every linefeed between elements created from ajax data is displayed as #cdata-section in the web inspector.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Is this a difference from Firefox? This sounds like something worth investigating to me.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">In Firefox, blank/linefeed are shown as #text node, in both case, served as text/html or application/xhtml+xml.<br></blockquote><blockquote type="cite">WebKit inspector does not show them when application/xhtml+xml and as #cdata-section when text/html. This might be of no importance but warned me somehow.<br></blockquote><br>That seems important. Would you be willing to file a bug with a test case?<br><br> &nbsp;&nbsp;&nbsp;-- Darin<br><br></body></html>