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

[Max Barel]

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

Filed a bug to report #cdata problem and also namespace requirement on  
injected xhtml chunks:
http://bugs.webkit.org/show_bug.cgi?id=16731