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
