Re: [XHR] Re: Last Call - XMLHttpRequest

On Wed, 28 Feb 2007 22:54:47 +0100, Dan Winship <danw@novell.com> 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/>

Received on Friday, 9 March 2007 16:24:04 UTC