wrote:
> [...] Thomas 'PointedEars' Lahn [...] wrote:
>> David Mark wrote:
>>> On Jan 21, 1:32 pm, "jackcha...@gmail.com" <jackcha...@gmail.com> wrote:
>>>> Unfortunately, I am not the administrator of the server, and I think it
>>>> is IIS powered by ASP.NET. I guess I am looking forward to client
>>>> workaround solution for IE7.
>>> You are screwed.
>> Not at all.
>>
>>> The responseXML property will not be an XML document unless the response
>>> was served with an XML MIME type (and that does not include XHTML MIME
>>> types.) The overrideMimeType method is a hack to get around this, but IE
>>> doesn't support it.
>> However, it is possible to parse the value of the `responseText' property
>> into an XML document object:
>>
>> http://www.faqts.com/knowledge_base/...d/6826/fid/616
>
> Thanks for the link!
You're welcome.
> As David mentioned, I might use the ActiveX version of XHR.
It would seem that you misunderstood him. He meant quite correctly that if
one was to use an ActiveX/COM object for parsing the value of the
`responseText' property into an XML document, one could also use the
overrideMimeType() method to make `responseText' available then. (I don't
agree with the conclusion, though; overrideMimeType() is an evil hack
compared to parsing `responseText'.) However, his assumption was that since
you asked specifically about the so-called native (but not native at all)
XHR object, you were in a position where you could not use ActiveX/COM
objects and so you could not follow the aforementioned approach.
> In addition, from my experience the ActiveX version of
> XHR doesn't care whether the content-type is set right.
You are mistaken, as the above FAQ points out.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee