17242 2012-05-30 07:28:04 +0000 Consider doing anonymous requests as a constructor argument rather than as a separate constructor 2012-10-11 09:52:16 +0000 1 1 1 Unclassified WebAppsWG XHR unspecified PC All RESOLVED FIXED P2 normal --- 1 jonas annevk adrianba ian mike mjs ojan public-webapps travil w3c public-webapps-bugzilla oldest_to_newest 68296 0 jonas 2012-05-30 07:28:04 +0000 I propose that we do anonymous requests using something like: new XMLHttpRequest({ anon: true }); rather than the current new AnonXMLHttpRequest(); That way we can more easily add other "constructors" which affect the security model that an XHR object uses. For example, in B2G we are adding the ability for apps to get permission to get low-level network access and do things like open raw sockets. As a convenience, we'd also like to expose the XMLHttpRequest API since that exposes no additional functionality but is a much easier to use API. In that scenario we need the ability to instantiate an XHR object which never sends cookies, but also is allowed to make network requests cross site without relying on CORS. See https://bugzilla.mozilla.org/show_bug.cgi?id=692677#c39 68301 1 annevk 2012-05-30 08:51:00 +0000 Nobody has implemented AnonXMLHttpRequest to my knowledge. So the first question should be whether we want to have it at all I think. Then, secondly, if we add an object to initialize XMLHttpRequest, maybe we should give that "url", "method", ... parameters? 68331 2 ojan 2012-05-30 23:07:27 +0000 (In reply to comment #1) > Nobody has implemented AnonXMLHttpRequest to my knowledge. So the first > question should be whether we want to have it at all I think. I don't feel strongly either way, but I don't see a rush to drop it either. Is keeping it in a lot of maintenance work for the spec? I'm a little bummed/annoyed none of the proponents of this stepped up to implement it given how strongly they fought for it. > Then, secondly, if we add an object to initialize XMLHttpRequest, maybe we > should give that "url", "method", ... parameters? Yes, that would be great. I have a minor aesthetic preference for the initialization object over the new constructor, and while we're at it, a mild preference for naming the property "anonymous" instead of "anon". I don't think this is a case where shortness will have much impact on the convenience or uptake of the API (unlike, e.g. querySelector --> find). 68379 3 jonas 2012-05-31 09:02:39 +0000 I'm not really sure what it means to do: x = new XMLHttpRequest({ url: "..." }); Does that mean you don't have to call .open on such an XHR object? If so, does that mean that you can only use it for one request? I'm not necessarily against such a design, I'm just trying to understand what is proposed. 68380 4 annevk 2012-05-31 09:05:52 +0000 The idea would be that you can avoid invoking open() indeed. Maybe even send(). So it would work just like EventSource. You just pass the information to the constructor. 68381 5 annevk 2012-05-31 09:06:53 +0000 Not sure whether we should restrict invoking open() on such instances though. 68473 6 ojan 2012-06-01 05:16:46 +0000 Hope I'm beating a dead horse since I know this has been discussed before, but we could forego XHR entirely and just create a new class that doesn't have any of the baggage where there are no invalid states that need errors thrown (only invalid combinations of options, e.g. data + method=GET). HttpRequest(url, options) or even just Request(url, options), in theory the latter is future-compatible should we want to support protocols other than http. The only method it has is abort. "options" allows the following properties: anonymous, on* (e.g. onloadstart, etc), method, headers, asBinary, responseType, timeoutMS, withCredentials, data. Should it have username/password? Obviously, no way to do sync requests. An HttpRequest instance has the following properties: status, statusText, response, responseHeaders. headers/responseHeaders is a dictionary. I think the rest are self-explanatory. Not really sure how the upload related stuff would fit in here. I suppose you could have onupload* events on the options dictionary. 68474 7 ojan 2012-06-01 05:17:13 +0000 Lol. That is to say, hope I'm *not* beating a dead horse. 75687 8 annevk 2012-10-09 14:54:13 +0000 So yeah, that is a dead horse. We try to avoid introducing new APIs that does largely the same thing, because the costs (implementation, tests, potential for even more divergence) outweigh the benefit. So far however there does not appear to be much interest in AnonXMLHttpRequest at all. I marked it as such in the specification: http://xhr.spec.whatwg.org/ 75758 9 jonas 2012-10-10 00:23:12 +0000 FWIW, we've experimentally added the proposal in comment 0 to Firefox 16 which was released earlier today. Feel free to test it! There's a know bug where explicitly set username/passwords aren't sent for anonymous requests. This should be fixed in Firefox 18. 75814 10 annevk 2012-10-10 10:42:54 +0000 I tried both anon:true and anonymous:true and in both I can set withCredentials to true, so if you implemented anonymous mode, it's buggy. You did not like the suggestion of spelling it out (Ojan suggested anonymous) since it's an object member? I think that would be better. 75815 11 annevk 2012-10-10 10:44:48 +0000 Username and password are supposed to throw in anonymous mode too by the way. Are you guys even reading the specification when implementing or just doing willy nilly and then telling us later? This has happened a few times now, I don't really like it. 75893 12 jonas 2012-10-10 22:19:06 +0000 There's a reason I said experimental. Why should anonymous requests throw for explicitly specified username/passwd? While setting .withCredentials to true doesn't throw, it should still not be adding any credentials I'd hope. 75930 13 annevk 2012-10-11 03:54:24 +0000 Because when you start including username/password, they're no longer anonymous. However, we similarly forbid username/password for cross-origin requests, and maybe we should start allowing that again too, as it will require a preflight request for the Authorization header anyway. 75938 14 jonas 2012-10-11 06:00:50 +0000 I've always thought "anonymous" as meaning "UA won't add user identifying information". There's no way we can make "anonymous" requests meaning "no user identifying information will be included" since the page can add user identifying information in the URL or in the headers. Indeed, this is quite common I believe when making "anonymous" cross-site requests. With regards to "anon" vs. "anonymous" I feel like one of the most common complaints we get from JS authors is too long and inconvenient names. 75945 15 annevk 2012-10-11 07:23:03 +0000 https://github.com/whatwg/xhr/commit/d43a3637bf99933df33712d14dc8fdef7a29bea7 http://xhr.spec.whatwg.org/ I'll look into fixing comment 13 and comment 14 a little later. 75954 16 annevk 2012-10-11 09:52:16 +0000 https://github.com/whatwg/xhr/commit/08fb7d6b1d0d28116710e9db231e709b3890fca3 http://xhr.spec.whatwg.org/ Now everything should be in order. You can always use the user/password arguments as the dictionary attack is fiction. After all, the server needs to opt in to the Authorization header. This commit also cleans up how the user/password arguments are defined in IDL and prose.