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?

(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).

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.

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.

Not sure whether we should restrict invoking open() on such instances though.

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.

Lol. That is to say, hope I'm *not* beating a dead horse.

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/

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.

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.

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.

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.

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.

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.

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.

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.