On Wed, 28 Feb 2007 22:54:47 +0100, Dan Winship <[EMAIL PROTECTED]> wrote:
That description isn't quite right, since readyState is 3 *while*
receiving the message body too. Maybe:
Fixed.
Where is SECURITY_ERR defined? (AFAICT the answer is "nowhere".)
It will be defined in a revision of DOM Level 3 Core.
User agents MUST at least support the following list of methods (see
[RFC2616]):
* GET
* POST
* HEAD
* PUT
* DELETE
* OPTIONS
...
When method case-insensitively matches GET, POST, HEAD, PUT or
DELETE user agents MUST use the uppercase equivalent instead.
OPTIONS got added to the first last in the most recent draft, and should
probably be added to the second list as well for consistency.
Added.
When url is a relative reference, it MUST be resolved using the
current value of the baseURI attribute of the Document object
currently associated with the Window pointer and the fragment
identifier component, if any, MUST be dropped.
Fragments MUST be dropped on relative URLs, but not on absolute URLs???
Fixed.
If data is passed to the send() method it MUST be used for the
entity body as defined by section 7.2 of [RFC2616] The following
rules apply:
There's a period missing between "[RFC2616]" and "The". (It's also not
clear on first reading if "data is passed to send()" is intended to
contrast with "send(null)" or "send()" with no argument. "If non-null
data is passed..." would be clearer.)
Fixed.
If the response is an HTTP redirect (status code 301, 302, 303 or
307), then it MUST be transparently followed (unless it violates
security, infinite loop precautions or the scheme isn't supported).
Note: HTTP places requirements on user agents regarding the
preservation of the request method and entity body during
redirects, and also requires users to be notified of certain kinds
of automatic redirections.
It's actually a stronger requirement than just notification: "the user
agent MUST NOT automatically redirect the request unless it can be
confirmed by the user". Might be better to let the implementation just
not follow the redirect in this case:
If the response is an HTTP redirect (status code 301, 302, 303
or 307), then it MUST be transparently followed (unless doing so
would violate a requirement or recommendation of this
specification or [RFC2616]).
or something.
It's a note because it doesn't make sense to reiterate the requirements
from HTTP. It does clearly list, imo, that it's a requirement in HTTP.
If something goes wrong [during send] (infinite loop, network errors)
the state MUST be set to loaded... In addition, all registered event
listeners MUST be removed.
When invoked, this method [abort] MUST cancel any network activity for
which the object is responsible and set all the members of the object
to their initial values as well as removing all event listeners.
Does the onreadystatechange listener get invoked in these two cases? An
implementation that performed the actions in the order written (change
state first, remove event listeners last) would cause the listener to
be invoked, but nothing says that the implementation has to do it in
that order, which seems to make this implementation-defined.
Fixed.
HTTP requests sent from multiple different XMLHttpRequest objects in
succession SHOULD use a shared HTTP connection.
How does this deserve an RFC2119 "SHOULD" ("the full implications must
be understood and carefully weighed before choosing a different
course.") And why does it only talk about requests from *different* XHR
objects? What about multiple requests from the same object? If you're
going to say anything here, just say "Implementations SHOULD NOT suck"
and be done with it. ;-)
Dropped based on a comment from someone else.
Cheers,
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
