W3C home > Mailing lists > Public > public-webapi@w3.org > March 2007

[XHR] Re: Last Call - XMLHttpRequest

From: Dan Winship <danw@novell.com>
Date: Wed, 28 Feb 2007 16:54:47 -0500
To: web API <public-webapi@w3.org>
Message-Id: <1172699687.19425.113.camel@blorple>

Here's what I found reading through the last call draft:

> readyState...
>   3 Receiving 
>       Immediately before receiving the message body (if any). All HTTP
>       headers have been received.

That description isn't quite right, since readyState is 3 *while*
receiving the message body too. Maybe:

        3 Receiving
            All HTTP headers have been received. The message body (if
            has not yet been fully received.

> a SECURITY_ERR should be raised

Where is SECURITY_ERR defined? (AFAICT the answer is "nowhere".)

> 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.

> 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???

> 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.)

> 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.

> 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.

> 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. ;-)

-- Dan
Received on Thursday, 1 March 2007 21:51:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:23 UTC