[webkit-dev] ACCEPT request header in XMLHttpRequest not
max at ac-mb.info
Fri Jan 4 08:46:06 PST 2008
Le 4 janv. 08 à 00:24, Max Barel a écrit :
> 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 max at ac-mb.info wrote:
>>>>> 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
>>> 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:
>> 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
> 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
>>>>> 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.
Filed a bug to report #cdata problem and also namespace requirement on
injected xhtml chunks:
More information about the webkit-dev