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

[Max Barel]

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