Bug 46150 – XMLHttpRequest: send(document) does not throw INVALID_STATE_ERR exception if the document cannot be serialized

• Status: NEW
• Component: XML

[Jian Li]

XMLHttpRequest: send(document) does not throw INVALID_STATE_ERR exception if the document cannot be serialized

Per the XHR spec:
  If data is a Document
  ...
  In particular, if the document cannot be serialized an INVALID_STATE_ERR exception is raised.

TEST: http://tc.labs.opera.com/apis/XMLHttpRequest/send-entity-body-document-bogus.htm

[Luke Macpherson]

This test assumes that an empty Document cannot be serialized. In webkit createMarkup is serializing the document to the empty string.

We could throw INVALID_STATE_ERR when the Document serializes to the empty string, but I'm not sure that is really the intended behavior in http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#the-send-method

[Anne van Kesteren]

http://www.whatwg.org/specs/web-apps/current-work/complete.html#serializing-xhtml-fragments says serializing such a Document should throw. send() just re-raises such exceptions.

[Luke Macpherson]

Cleaned up discussion from whatwg IRC:
ojan: Hixie: yt? we are looking at some XHR issues that point to the XML fragment serialization algorithm. Not quite sure why the spec lists all the exceptions. Unless we're testing it wrong, it doesn't seem that any browser fires these exceptions. e.g. serializing an element node with two attributes with the same local name doesn't give an exception in any browser.

ojan: Hixie: http://tc.labs.opera.com/apis/XMLHttpRequest/send-entity-body-document-bogus.htm expects an error because of this, but it's not clear to us that it's worth implementing all these exceptions

Hixie: macpherson: well we have to do something, throwing an exception seemed like a simple thing to spec
Hixie: macpherson: if there's something else we can do, we can spec that

macpherson: Hixie: our observation is that existing browsers don't throw an exception, but instead produce sanitized output

Hixie: works for me
Hixie: file a bug saying how each bug is to be sanitised and i'll spec that instead

[Ojan Vafai]

It turns out the browsers do currently error on some of these cases for XML documents, but not HTML documents. For example, if you create a foo.html file with the following contents, you get an error about a duplicate attribute name (tested Chrome and Firefox):
<div bar='bar' bar='baz'></div>

So, the bug here is specifically in our serialization of XML documents? As it is, no browser passes this test.

I also tested the following:
<script>
function iframeLoad() {
    var client = new XMLHttpRequest()
    client.open("POST", "foo.html", false)
    try {
        client.send(document.querySelector('iframe').contentDocument);
        alert('failed');
    } catch (e) {
        alert('passed, error thrown');
    }
}
</script>
<iframe src="scratch.xhtml" onload="iframeLoad()"></iframe>

And scratch.xhtml is just: <div bar='baz' bar='foo'></div>

If you load scratch.xhtml in Opera, WebKit, Firefox you get an error. If you XHR.send that document though, you don't get an error.

I don't feel strongly about this, but I'm not really sure this is worth changing. Anne, isn't it fine to have all documents use the HTML serialization algorithm?

[Anne van Kesteren]

The scratch.xhtml example Document you are sending is a very different Document though that no longer contains that <div> and can be serialized without error.

If XML documents should be serialized using the HTML algorithm, always, I think HTML5 should be updated to say that, no? As it is XMLHttpRequest just defers to Document.innerHTML which HTML5 defines.