- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 23 Jun 2008 15:14:50 -0700
- To: Zhenbin Xu <Zhenbin.Xu@microsoft.com>
- CC: Anne van Kesteren <annevk@opera.com>, Sunava Dutta <sunavad@windows.microsoft.com>, Ian Hickson <ian@hixie.ch>, "public-webapps@w3.org" <public-webapps@w3.org>, IE8 Core AJAX SWAT Team <ieajax@microsoft.com>
Zhenbin Xu wrote: >>> responseText: >>> If the state is not DONE, raise an INVALID_STATE_ERR exception and >> terminate these steps. >> >> This doesn't seem very consistent with the other response properties >> though. Seems like .getResponseHeader and .getAllResponseHeaders work >> fine (without throwing) even in state HEADERS_RECEIVED and LOADING, so >> it seems better to let .responseText work fine there too. >> >> Additionally, our API has for a long time been defined such that you >> can >> read .responseText all through the LOADING state in order to read >> streaming data. This has been advertised to authors so I would expect >> them to depend on that at this point and so if we started throwing here >> I would expect websites to stop working. >> > > [Zhenbin Xu] This shouldn't be a compact issue since IE throws exception > before DONE state since first release of XMLHTTP and we have not seen > compact issue from Internet sites or enterprise applications. People do write a fair amount of code that is specific to non-IE browsers. Especially in the cases where other browsers supply a different feature set than IE such as in this case. Do you really suspect that sites currently depend on IE throwing and would break if an empty string was returned? > Streaming is a good topic that we should refine and define clear specifications, > thus it is better suited for XHR2. And like you have noted below, progress > event is a better design for streaming. ProgressEvents only supply notifications on when data comes in, the data still needs to be read elsewhere, in this case preferably through .responseText. >>> responseXML: >>> If the state is not at least OPENED, raise an INVALID_STATE_ERR >> exception and >>> terminate these steps. >> I think we additionally need to throw in the OPENED state. Until all >> headers are received there is no way to know what document, if any, >> should be created so we need to either return null or throw until we're >> in state HEADERS_RECEIVED. > > [Zhenbin Xu] An empty XML document can always be created before all headers > are received. You shouldn't always create a document at all, for example if the content type is "text/plain". See http://www.w3.org/TR/XMLHttpRequest/#xml-response-entity-body Additionally, in mozilla we have several different types of XML documents, such as for SVG and we won't know which one to create until we have a content-type. >> Though it does seem scary to start throwing in more states for this >> property as throwing more tends to break sites. So possibly we would >> have to go with returning null in the OPENED state even though that >> would be inconsistent with the other properties. > > [Zhenbin Xu] Yes throwing on more states has more possibility of breaking > sites. So I don't think it is a good direction to go. > > Returning null in OPENED state would break sites that are expecting > a non-null responseXML after open() call. OTOH, If the site is already testing > for null, it will continue to work if non-null responseXML is returned. So > what I stated previously is a good specification. Experience from deploying an XMLHttpRequest that returns null after open() shows that no sites break. Even when we originally deployed XHR and all code was written specifically for IE. / Jonas
Received on Monday, 23 June 2008 22:15:08 UTC