Expanding the XHR interface to mirror expansions to the fetch interface?

[davidvancleve]

My understanding is that it's generally discouraged to add flashy new features to XHR. (I don't have a ton of domain expertise, so please let me know if this premise is wrong.)

I have a question about a special case. If a new Web Platform feature is primarily an extension to Fetch (for instance, defining an addtion to the interface and some corresponding new request handling logic), does it seem like it might be reasonable to mirror the fetch API changes (e.g. expanding RequestInit) with corresponding XHR changes? The motivation would be that there are some people who, for whatever reason, can't use the fetch API but can use XHR; this would allow them to make use of the new Fetch-first Web Platform feature.

(The specific example I have in mind is the Trust Token API, which expands RequestInit to take a new argument specifying a cryptographic operation to execute alongside the request; in its prototype implementation in Chromium, we add a corresponding new setter to XMLHttpRequest so clients can access the same functionality via XHR. @jeremyroman, who was reviewing my XHR change, suggested I drop by and ask whether there are any issues with this approach.)

[annevk]

No, we don't want to extend XMLHttpRequest with new features, except if it gets them through a shared primitive, but that would not be the case here. Also, could you please file an issue against whatwg/fetch with the proposed extension? (See https://annevankesteren.nl/2014/02/monkey-patch for context.)

[davidvancleve]

(cc @csharrison)

[davidvancleve]

At the risk of straying off the topic of this issue, I don't understand what you'd like the whatwg/fetch issue to describe. Would it just be a high level "we have a prototype implementation including an extension to the interface and implicit extensions to some of the spec's algorithms and hope to, at some point, codify this new functionality by extending the spec" kind of comment?

[annevk]

Yeah and maybe explicitly solicit feedback from the community on the approach taken.

[davidvancleve]

Sure; created whatwg/fetch#1047.

[annevk]

Can this be closed or is this still being considered?

[davidvancleve]

Hi Anne, I'd like to ask that we keep this open for a couple weeks until @dvorak42 uploads the draft Trust Tokens spec (which he's working on as a local patch against Fetch), which might provide some motivation for discussing this further (or might not, depending how it ends up). BTW, one question: what's an example of a "shared primitive" in this passage?

we don't want to extend XMLHttpRequest with new features, except if it

gets them through a shared primitive Thanks!

…

On Mon, Mar 1, 2021 at 12:14 AM Anne van Kesteren ***@***.***> wrote: Can this be closed or is this still being considered? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#284 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANFTZDDEJXKSRK3O5RAZMYLTBNEHXANCNFSM4OL3DLWA> .

[annevk]

E.g., say that we started supporting fetching of blah: URLs. XMLHttpRequest would not go out of its way to exclude that. (On the other hand, we have excluded ReadableStream object support from XMLHttpRequest despite it initially supporting that: #277.)

[davidvancleve]

Got it! Thanks.