Re: XMLHttpRequest.getResponseHeader and missing headers

Since calling getResponseHeader/getAllResponseHeaders does not make sense
before readyState is 3 or 4, raising a DOMException INVALID_STATE_ERR makes
more sense. That way, these two methods would be aligned with status and
statusText attributes.

There is a related inconsistency with respect to the behavior of responseXML
and responseText before readyState is 3 or 4. Currently responseText is
required to be an empty string, but again, an INVALID_STATE_ERR makes more
sense. I would argue for the same behavior for accessing responseXML before
readyState is 4. IE 6 behaves in this manner throwing an exception with
message "The data necessary to complete this operation is not yet
available."

Subbu


On 8/10/06, Anne van Kesteren <annevk@opera.com> wrote:
>
>
> On Tue, 20 Jun 2006 13:38:19 +0200, Alexey Proskuryakov
> <aproskuryakov@gmail.com> wrote:
> > "If no headers of that name were received, then it MUST return the
> > empty string."
> >
> >   This matches the behavior of Internet Explorer and Opera 9, but not
> > of Firefox 1.5 or Safari 2 (the former returns null, while the latter
> > returns undefined).
> >
> >   I don't see any restriction on the semantics of empty vs. missing
> > headers in RFC 2616, and indeed, the difference is sometimes
> > significant, at least in the case of requests (SOAP, Atom API). Thus,
> > the Firefox behavior appears the most reasonable to me. It is
> > documented in the idl at
> > <
> http://lxr.mozilla.org/mozilla/source/content/base/public/nsIXMLHttpRequest.idl#148
> >.
> >
> >   Can the specification be adjusted to match it at this point?
>
> Yeah, fair enough. It also seems more consistent with other methods.
>
> Now I wonder if it should be null before readyState is 3 or 4 as well...
>
>
> --
> Anne van Kesteren
> <http://annevankesteren.nl/>
> <http://www.opera.com/>
>
>
>


-- 
------------------------------
http://www.subbu.org