Re: [XMLHttpRequest] Comments on Feb 13 draft

On Sat, 17 Feb 2007 18:00:54 +0100, Julian Reschke <julian.reschke@gmx.de>  
wrote:
> see below some comments on the current draft.

Thanks!


> 1. Introduction
>
> "First, the object is data transport agnostic - it supports any data  
> format, including XML."
>
> Actually, it doesn't. As far as I can tell, it only supports text based  
> formats and XML. There's no way to send or retrieve binary content.

Fair enough. In due course it will though. Fixed.


> 1.2 Conformance
>
> "conforming implementation: A user agent that implements all interfaces  
> described in this specification and follows all MUST-, REQUIRED- and  
> SHALL-level of criteria in this specification."

Reworded that.


> Then:
>
> "A document that follows all MUST-, REQUIRED- and SHALL-level of  
> criteria in this specification that apply to document authors."
>
> So is the document really putting requirements on the *authors*?  
> Shouldn't it define requirements on the documents?

Changed to "conforming script" per your later suggestion and changed the  
description.


> 1.2.1 Dependencies
>
> "Implementations MUST support the http  scheme defined in HTTP. Other  
> requirements regarding HTTP are made throughout the specification  
> [RFC2616]."
>
> s/scheme/protocol/?

Reworded and used your suggestion.


> 2.1. Members of the XMLHttpRequest Object
>
> "If the method argument doesn't match the method production defined in  
> section 5.1.1 of RFC 2616 a SYNTAX_ERR MUST be raised by the user agent.  
> If the user agent doesn't support the given method for security reasons  
> a SECURITY_ERR SHOULD be raised. [RFC2616]"
>
> s/method production/"Method" production/

Changed.


> "User agents MUST at least support the following list of methods (see  
> [RFC2616]):
>
>      * GET
>      * POST
>      * HEAD
>      * PUT
>      * DELETE "
>
> Why is OPTIONS missing from this list?

Because it's not generally supported and vendors had concerns about it. If  
you can convince them, let me know.


> "Otherwise, if the nominated request header field already has a value,  
> the new value MUST be combined with the existing value (section 4.2,  
> [RFC2616])."
>
> That's a bit misleading. What does "combine" mean precisely? Is the  
> intent to require implementations to assume that the header format is a  
> comma-separated list?

Yes.


> In that case, why doesn't the preceding list contain other headers known  
> not to have that format? (c-ext, ext (RFC2774), cookie, cookie2  
> (RFC2965), if, lock-token, status-uri (RFC2518), label (RFC3253),  
> apply-to-redirect-ref, redirect-ref (RFC4437), ordering-type (RFC3648)).
>
> It seems to me that it would be wise for the specification to specify a  
> way to remove a header, so that list-typed headers can be set to a known  
> value reliably.

I'm not sure what you mean.


> "If data is passed to the send() method it must be MUST for the entity  
> body as defined by section 7.2.1 of [RFC2616])."
>
> s/7.2.1/7.2/

Fixed.


> "Authors SHOULD specify the Content-Type header..."
>
> I think we should add requirements on the client of the API (the  
> script/program), not the author.

Changed.


> "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 that HTTP  
> ([RFC2616]) places requirements on user agents regarding the  
> preservation of the request method during redirects, and also requires  
> users to be notified of certain kinds of automatic redirections."
>
> 1. Add note: following a redirect requires re-sending the request body,  
> when present.
>
> 2. To follow a redirect on a non-safe method without the user's consent  
> is forbidden in HTTP (see RFC2616, 10.2). No, notification is not  
> sufficient.  And yes, this also applies to POST.

Done.


> "If the user agent implements server-driven content-negotiation  
> ([RFC2616]) it SHOULD set Accept-Language, Accept-Encoding and  
> Accept-Charset headers as appropriate; it MUST NOT automatically set the  
> Accept header. Responses to such requests MUST have content-codings  
> automatically removed."
>
> What does "removed" mean here? If we want to require the implementation  
> to undo the transformation, let's be specific about that.

I don't know. This bit was proposed by Mark Nottingham. If you have a  
specific proposal let me know.


> "If the user agent supports Expect/Continue for request bodies  
> ([RFC2616]) it SHOULD insert Expect headers and handle 100 Continue  
> responses appropriately."
>
> Are we talking about "Expect: 100-continue"? Then let's be specific  
> about that (there can be other values for "Expect"). Furthermode,  
> RFC2616 requires support for 100-continue anyway (it's not optional),  
> and is also more precise on the requirements (see for instance RFC2616,  
> 8.2.3). In particular:
>
> --> "A client MUST NOT send an Expect request-header field (Section  
> 14.20) with the "100-continue" expectation if it does not intend to send  
> a request body." (RFC2616, 8.2.3)

Ok, dropped this bit.


> "If the user agent can't derive a character stream in accord with the  
> media type specification, reponseText  MUST be null."
>
> s/reponseText/responseText/

Fixed.


> "Note: For HEAD requests this attribute will always be null (it remains  
> unchanged). Similar to the responseXML attribute."
>
> I don't like special cases. So will it be null for any response without  
> entity body, or just for HEAD?

This is just a note to inform people. Then again, I guess if a server  
gives you a request body with a HEAD it should prolly be filled...  
Suggestions?


> "...(typically 200 for a successful connection)."
>
> s/connection/request/

Fixed.


> That being said, it's dangerous to be specific here. In general, all 2xx  
> series codes signal some kind of success.

This is just a non-normative note. It even says "typically". I don't think  
it's very specific...


> "HTTP requests sent from multiple different XMLHttpRequest objects in  
> succession should be pipelined into shared HTTP connections."
>
> That's misleading; HTTP pipelining is something very specific beyond  
> re-using a connection (see  
> <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.8.1.2.2>).

Suggestions?


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Saturday, 17 February 2007 18:52:31 UTC