Bug 17242 - Consider doing anonymous requests as a constructor argument rather than as a separate constructor
Summary: Consider doing anonymous requests as a constructor argument rather than as a ...
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: XHR (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Anne
QA Contact: public-webapps-bugzilla
Depends on:
Reported: 2012-05-30 07:28 UTC by Jonas Sicking
Modified: 2012-10-11 09:52 UTC (History)
8 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Jonas Sicking 2012-05-30 07:28:04 UTC
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
Comment 1 Anne 2012-05-30 08:51:00 UTC
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?
Comment 2 Ojan Vafai 2012-05-30 23:07:27 UTC
(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).
Comment 3 Jonas Sicking 2012-05-31 09:02:39 UTC
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.
Comment 4 Anne 2012-05-31 09:05:52 UTC
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.
Comment 5 Anne 2012-05-31 09:06:53 UTC
Not sure whether we should restrict invoking open() on such instances though.
Comment 6 Ojan Vafai 2012-06-01 05:16:46 UTC
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.
Comment 7 Ojan Vafai 2012-06-01 05:17:13 UTC
Lol. That is to say, hope I'm *not* beating a dead horse.
Comment 8 Anne 2012-10-09 14:54:13 UTC
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/
Comment 9 Jonas Sicking 2012-10-10 00:23:12 UTC
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.
Comment 10 Anne 2012-10-10 10:42:54 UTC
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.
Comment 11 Anne 2012-10-10 10:44:48 UTC
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.
Comment 12 Jonas Sicking 2012-10-10 22:19:06 UTC
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.
Comment 13 Anne 2012-10-11 03:54:24 UTC
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.
Comment 14 Jonas Sicking 2012-10-11 06:00:50 UTC
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.
Comment 16 Anne 2012-10-11 09:52:16 UTC

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.