Le 3 janv. 08 à 22:32, Darin Adler a écrit :
On Jan 3, 2008, at 2:03 PM, Max Barel wrote:
Le 3 janv. 08 à 22:29, Alexey Proskuryakov a écrit :
on 03.01.2008 23:06, Max Barel at [EMAIL PROTECTED] wrote:
As I know no way to guess xhtml capability from javascript and
modify this default header, webkit gets xhtml served as text/html.
Does this qualify for a bug report or a feature request or do I
miss something?
We could probably change the default to match Firefox, but I do
not really
see the logic behind using the same Accept string for main
resource loading
and for XHR, given that Firefox itself uses different Accept
strings for
subresources.
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.
That is not correct.
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.
We sure agree on this and, in fact, Firefox default Accept header is
rather open:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/
plain;q=0.8,image/png,*/*;q=0.5
And the current draft of the W3C XMLHttpRequest specification <http://www.w3.org/TR/XMLHttpRequest/
> explicitly forbids setting the Accept header field:
"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."
You get a point. I didn't see this and the reason for this prohibition
is beyond my understanding.
WebKit is not currently conforming to this, because it's sending "*/
*" rather than no header at all.
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.
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.
I still have to investigate the DOMImplementation.hasFeature method
you suggested to see if it's a working way to reliably discriminate
browsers and then set the Accept header accordingly.
Once again doing thing (simple DOM injection) the right way (xml
compliant and DOM methods) will turn trickier than the dirty way (raw
html string into innerHTML).
Or if you like this behavior and think that other browsers need to
support it, then we should get the W3C XMLHttpRequest specification
fixed.
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.
Is this a difference from Firefox? This sounds like something
worth investigating to me.
In Firefox, blank/linefeed are shown as #text node, in both case,
served as text/html or application/xhtml+xml.
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.
That seems important. Would you be willing to file a bug with a test
case?
OK, I'll do it, even if I'm not sure how to entitle it.
Max
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
