- From: Anne van Kesteren <annevk@opera.com>
- Date: Sat, 17 Feb 2007 19:52:21 +0100
- To: "Julian Reschke" <julian.reschke@gmx.de>, public-webapi@w3.org
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