[webkit-dev] ACCEPT request header in XMLHttpRequest not meaningful

[Max Barel]

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:
>
>> 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.

>  As you said, serving as XHTML is your policy. Obviously, the  
> priority of
> the bug would be higher if it cited technical reasons for this  
> policy, as it
> would mean that many people could benefit from a fix.

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.

>> 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.

> - WBR, Alexey Proskuryakov.
>
>